This is an adaptation of a document I wrote in 2018, while working at Google on the Assistant on Android Auto team. Each day I’d make sure everyone on the team got an easy, low pressure invitation to have lunch with their teammates. I wrote it to explain why I did that and solicit feedback for improving the process. I wanted to share it here in hopes that other people would find it helpful. I left it mostly intact, but cut out the references to Google/Auto-specific stuff.
I love team lunches, I think they’re important for team cohesion and psychological comfort. I love lunch so much I try to organize some form of team lunch daily.
A new team mate of ours recently told me that he had been speaking with friends on other teams and was surprised to find out that our team’s lunch standard wasn’t part of some Google-wide mandate, and was instead just part of our team’s culture. This document is an attempt to explain the reason I organize lunches, and to ask for input about how it could go more smoothly.
A couple of years ago I worked over at Intuit. I was on a feature team that was heavily reliant on a front end infrastructure team. We weren’t really sure where our effort stood in terms of their priorities, and we didn’t really have visibility into their process, which would have allowed us to find out.
Independently, my team was in a bit of a crunch time. To fight off the stress, I started mixing cocktails for my team every Friday. One Friday I was particularly proud of my concoction and I wanted to show my handiwork off, so I invited some of the nearby teams, including the infrastructure team. Drinking and joking while we coded quickly turned us from acquaintances into friends, and suddenly our teams were comfortable reaching across cubes for input and requirements and feature requests and bug reports. We became a cohesive effort, it gave them a chance to get a more intimate understanding of our project, and gave us a window into their workflows.
There is something to be said for working with people you feel comfortable with. I can’t really provide any sort of academic rigor for its benefits, but I would bet that anyone reading this goes to the people they consider friends for help with work before they go to the people they don’t. Being friends with your team makes engineering easier.
My former Intuit coworkers will tell you that my one fear leaving to join Google was being socially isolated. My former IBM coworkers will tell you that my one fear leaving to join Intuit was being socially isolated. I’ve been in bad social situations, joining a new team, having lunch alone, and not knowing whether that was going to be the way it was for the rest of my career.
I’ve joined teams where I went weeks before I knew anyone well enough socially to break through the anxiety and try to have lunch with them. I’ve been on teams where it never made it to that point.
It’s painfully easy to not subject people to this. It’s practically unavoidable to fall into social cliques that look exclusive from the outside, but team lunches offer the crucial benefit that by definition they’re open to everyone on the team. It’s an easy way to make sure people don’t feel completely alone on a team.
In an ideal world, my lunch efforts would adhere to the following standards:
- Everybody feels that they are invited to lunch, not just nominally, but like they are legitimately welcome
- Nobody feels pressured to attend lunch
- Everyone who wants to attend is able to
It’s clear that some of these standards are partially at odds with one another. They might actually be legitimately impossible. My implementation is the closest thing I’ve found that adheres to these standards.
I start lunch at 11:30. It’s early enough that the lines are short in the nearby cafeterias, and the larger tables aren’t occupied yet. Early on, I tried a later lunch, but frequently it meant people would take their lunch alone or in small groups, not knowing whether they’d be invited to a larger lunch. 11:30 is early enough and consistent enough to avoid that problem.
I send a lunch invitation to our team’s off-topic group chat. Every day I also personally invite the people who consistently attend lunch, as well as the people who have specifically asked that I gather them daily. I’m certain it would be more welcoming if I could personally invite everyone every day, but there are a lot of us, and it’s unsustainable.
Thursdays and Fridays we have an actual calendar slot booked for team lunches. Those days I do personally walk around our cube area and invite each team mate personally. I’m of the opinion that this cadence of 3 days of mass invitation and 2 days of direct invitation provides the right balance that allows people to continue to feel invited, without being forced to reject my invitations daily.
There are people who never come, and that’s OK. I do my best to invite them every time, it’s really easy to stop entirely because you expect them to decline, and before long they don’t feel invited anymore. I try to avoid expressing disappointment when people opt out; I want them to feel as comfortable as possible saying “no.” Everyone has to at some point and I don’t want to introduce any unnecessary stress if avoidable.
These are the weaknesses I see in this scheme. I don’t have a good way to address them. Please ping me if you have any suggestions, I’d love to improve.
Not everyone is checking their group chats all the time, so it’s easy to miss. I try to give a few minutes for people to see it before heading out. I hope the minorly disruptive group forming is enough of a signal for the people who want to have lunch to recognize what’s happening.
It makes sense to me that the perception is that asking me to never invite you to lunch would be damaging to your social reputation with me or the rest of the team, and feeling that you have to reject my invitations regularly is also unpleasant. I want everyone to be as comfortable as possible, so I’m personally totally open to the concept. In an ideal world people would recognize that there are tons of reasons to never want to attend a team lunch.
Some people have late breakfasts and 11:30 is too early for them to be considering more food. It’s harder to find tables later, and varying the time would result in more people getting confused or skipping lunch when they’d otherwise prefer to join in. That being said, I’m open to varying the time, but I don’t have a handle on a good system for choosing and coordinating time.
I fill this pretty strange niche in my team. Most of my motivation for writing this was to tell them why I organize lunch the way I do, and to level set that I recognize it’s distinctly non-ideal. I hope the takeaway from this document is that I want to know if there are better ways to approach this that I haven’t recognized yet. Do you feel invited? Can you think of anything that would make you feel more invited? Do you feel pressured? Is there anything I can do to lessen the pressure? Is there anything getting in the way of you joining if you want to? I welcome the feedback!
And if you’d like to have lunch, let me know!
Out of all of the documents I’ve produced in my career, this is the one I’m most proud of. It’s stuck with me longer than every technical design, architecture overview, and system investigation I’ve ever produced. People aren’t machines you can use to exchange a salary for engineering. Company and team culture are important for the wellbeing of the people who get things done.
I look back fondly on the time I spent with the Auto team, some of them are still some of my closest friends, 2 years and a company transition later. When I left, I got a lot of messages about the impact I had to team culture, but the reality is that I didn’t have any special magic that allowed me to affect team culture the way I did. The lunch process grew organically out of wanting to make friends and wanting everyone to be included. It could have been anyone, I just stumbled into it. If you’re up for it, you can make strides for your team’s culture too.