Lost art of effective meetings

The biggest killer of developer time is meetings, it is a double whammy when it is run by people who do not know how to run it or how to finish it. So often a meeting eats up as much as the 25% of day without adding benefit to any of the attendees.

Image courtesy: Unsplash

Developers cannot spend time in 30 minute slots like non developers. It takes some time to get into the groove and let the mind feel the code as if it is the extension of the natural language. 3 hours of unbroken developer time is the golden rule for me, it does not matter if I am coding, writing something or just starting out of the window thinking about something. The biggest killer of my productivity is when people pull me out of my zone for status checks during the middle of the coding session.

Also too often the planned meetings are more of information gathering sessions for the highest placed person in the corporate ladder. Any agenda or plans are thrown out of the window when the first question comes from a leader. These meetings scheduled for about 30 minutes will get converted to rants, status checks, random questions, fears and more that drags on and on to go well into 90+ minutes.

The best way to run meetings is to

  • Set agenda & time window (Make sure attendees are prepared, if it is a status check it is best done at the start or the end of the day)
  • A facilitator who can keep time and moderate conversations if that goes away from the agenda
  • A parking lot to make sure to capture random thoughts that can easily derail a meeting

Any one I have spoken to, agrees to the above points, but fails to keep the meeting in check because it is mostly run by non developers who don’t mind those additional 30 or 60 minutes getting wasted; or they just keep quiet and stay on so that the seniors are not offended.

If you are a manager and have a development team, please give unbroken chunks of time to developers and learn to run precise status checks and meetings without draining the energy that can otherwise be put into solving problems.

p.s: Design discussions and dev huddles do not follow in the above category but they also need to be facilitated well by the tech lead.

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 )

Google photo

You are commenting using your Google 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