Meeting Creep

Constance Xu has a great article “We Need to Talk about the Software Engineer Grind Culture” where she discusses the craziness of back-to-back meetings and crazy schedules:

“When I started working fulltime, I realized I got into a habit of skipping lunch as well. I work pacific coast hours from Texas, and sometimes a meeting will go straight through my lunchtime and then I have back-to-back meetings, and suddenly, it is 6PM , and time for dinner.”

Throw in working across several time zones globally and it gets even worse. A day that starts at 6:00AM and ends with a 9:00PM meeting is not uncommon. 6:00AM my time is 6:30PM in Bangalore. Meetings can go until they’re headed to bed around 11:00pm, you can throw in some calls with EMEA until early afternoon, then the west coast people fill your afternoon, and finally the folks in India are starting their day around 9:00PM. You can fit in some time for dinner and errands on a light day, but working remotely can quickly devolve into working around the clock if you’re not careful.

We’ve tried to have the rule that “No one should have to work past 9:00PM”, but that’s just not possible. I know people that regularly have to do calls with US/EMEA/India/Singapore. Someone is going to have to stay up late.

How To Cope

I’ve participated in a few practices that seem to work pretty well in dealing with this:

• All meetings start promptly. The meeting organizer uses a mobile phone for exact time, and the meeting stops when the minute flips over to 1 past. We play “the pizza game” where we voluntarily throw money into a virtual hat if we’re late to a meeting. Seems only fair that if you leave other people sitting you should pay for some of their next pizza party. A lot of the extra length of meetings is because the first 5 minutes can be wasted with waiting for everyone to join.
• All meetings start at :15 and :45 past the hour. Meetings are scheduled for either 15 or 45 minutes. This eliminates the problem of being late to the next meeting because your previous meeting ran over. Whatever you could do in an hour can also be done in 45 minutes if you realize you’re on a shorter deadline. It also means you don’t go multiple hours without a bio break, being able to respond to an email, or just catch your breath.
• Personal time is blocked in the calendar. Lunch and dinner go in as an event so that someone can’t schedule over you. I block out time in the late afternoon to hit the gym.
• Meetings that are before 8:00AM locally for anyone must be scheduled or cancelled before 10:00PM their time the previous night. There’s nothing worse than setting your alarm for an early morning meeting and waking up to find out you could have slept another 2 hours. Likewise, waking up and finding out you missed a meeting that someone scheduled during the middle of their day isn’t fun either.

Don’t Have So Many Meetings

I wish I could say the answer was “Don’t have so many meetings” but we really do our best to not have useless meetings. Most meetings could be an email, or a direct conversation between two people that results in an email to a wider group to keep everyone on the same page. When we see that happening, we evaluate whether we really need the meeting.

A lot of people complain about the daily standup. Here’s a hint: the daily standup should only be about blockers. If no one has a blocker, cancel it. Having people stand around and talk about which Jira ticket they’re working on is useless. I can read the dashboard in Jira just fine myself, thank you.

I’ve tried having a “No Meeting Wednesday” but that quickly broke down with outside groups scheduling meetings when my calendar freed up. And then I started having meetings with just my direct managers, and it all broke down.

Having a lot of meetings is just part of the collaboration and coordination that takes place with software development. A one-person team sitting in a cube slinging code by themselves is not going to accomplish very much.

Keep Your Pace Sustainable

Let’s not forget about the Agile principle of sustainability:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

I wrote about sustainability in “Keep Your Pace Sustainable”. The key is “the grind” or what I call “coding on caffeine and adrenalin” is just not sustainable. Eventually those people burn out, and then all of the hard learned domain knowledge walks out the door. You are much worse off in the long run.