Ten Rules for (Developer) Meetings

A scrum during practice by the local team in Levuka, Fiji.

Since being trained up to be a Product Owner (PO) at my work, my professional education has shot up massively.  POs are responsible for managing the work flow of the team; at the beginning, this required a huge amount of work, discussions, and meetings.

After about a week, I realized that meetings were taking up way too much developer time.  WAY too much.  I also realized that one implication was that even when developers had time to themselves, their flow was always potentially interrupted by a meeting, so only rarely could they get into a state of Deep Work.

So I came up with a rule: no afternoon meetings.  Unless a true emergency came up – a fire that needed fighting – I vowed to not allow anyone to call afternoon meetings with my team.  If they did, I’d urge the developers to say no, and I’d go in their place.

And it was a success, from the developer’s point of view.  They got more time, fewer interruptions, and got a heck of a lot more done.

Some people get frustrated, but it’s worth it.  Much developer time was spent on “emergency” meetings that weren’t emergencies and didn’t actually require meetings; now, we’re eliminating that as much as possible, and the team is responding.  For example, at our last retrospective, someone put this on the board:

Something I’m doing is appreciated!

I’ve been adding to our meeting scheduling rules, and refining them, and now there are ten rules for developer meetings.  They seem to work well for programmers, but I suspect they’d work for most meetings as well.  Please leave any thoughts or additional rules in the comments!

  1. No afternoon meetings.  Described above.
  2. Schedule time in between meetings.  Give everyone a buffer between meetings so they can decompress, collect their thoughts, take any immediate actions necessary, then come back with an empty bladder and full cup of coffee.  BUT: rather than take 30 minute breaks, as I was originally inclined to do, my co-worker Alan suggested something brilliant: treat breaks more like time between classes.  If you have an hour meeting, only take 50 minutes of it, then take a break.  If it’s a 30 minute meeting, only spend 20-25 minutes in the meeting.  (Morning games of dodgeball optional.)
  3. Schedule really unwanted meetings at 11:30.  This is particularly useful if someone wants a meeting and they have the tendency to go far over time, ignoring the schedule of everyone else in the room.  If everyone is hungry for lunch, it is far more difficult for a windbag to keep the meeting going past lunchtime; you can stop five minutes before, explicitly state the next actions and takeaways, and then leave.
  4. Keep them predictable.  For developers, try to keep regular meetings regular, and only reschedule when absolutely necessary.  They like predictability.
  5. PO should take meetings so developers don’t have to.  See above; if someone wants a meeting that might affect work flow, in the morning or afternoon, the PO should take the meeting and only bring developers in if necessary.  Take the fire and let them work.
  6. Keep meetings invitees to a minimum.  My natural impulse is to invite everyone, just so they feel included, but that’s wrong.  Only invite people if they need to be there.  If they’re just there because you didn’t want them to feel excluded, they can probably be doing more to help everyone by actually doing work.
  7. Let people walk out.  If someone isn’t getting something from the meeting, and they aren’t contributing, they should be able to walk out of the meeting without feeling bad.  Alan, the team lead, does this all the time, and it’s great.  We respect his time.
  8. Schedule your afternoons.  If you have things to do, or follow-ups from the morning meetings, schedule them in for the afternoons IN YOUR CALENDAR.  People will want to barge into your time, but if they look at your calendar and can’t find a free slot, they are much more likely to respect your time and attention and not interrupt.
  9. No phones.  Developers are actually really good at this; in my experience, non-developers are far more likely to be distracted in a meeting by random texts or emails.  I can remember a few people at previous jobs who would check Instagram or Facebook or text messages in meetings, scroll through, laugh, then ask everyone to rewind the meeting and repeat themselves because they weren’t paying attention.  Respect others: leave your phone at your desk.
  10. Bring in two packs of post-it notes.  This is purely a personal thing.  I always bring in yellow post-it notes for work-related follow-ups and any other color – pink, blue, green – for personal things.  If something comes up that I have to do – write a Jira card, for example – then I put it on a yellow post it.  If something comes up that I want to remember that isn’t work related – polish my cowboy boots, buy more butter to make a pie crust, and schedule five minutes every evening to practice juggling are the ones currently on my desk – then I put it on a non-yellow post-it.  That makes it easier to separate the important ones – boots, pie crust and juggling – from the non-important ones.

Again, I’m super interested to hear what other rules people have found to be useful so that we can implement them here and make meetings great again!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s