Friday, May 1, 2015

(Software Engineering) Meeting Best Practices

The TL;DR Version:

Software engineering teams should have two types of engineering meetings:
  1. A forward-looking one that explores new technologies
  2. A self-checking one that discusses current issues and challenges

Have them biweekly, one type of each every single week. Use active listening techniques to encourage equal and engaged participation. Have them in the morning, afternoons should be reserved for writing code and getting work done.

(Software Engineering) Meeting Best Practices

It was a Monday in February of 2010, around 11 am when I received a ping in Campfire to discuss the place we would go to have lunch and have our weekly Tech Talk meeting. We tried to combine lunch with our engineering conversations on Mondays, as that was the day when everybody was in the office. We decided to go to a restaurant, which did not work for us very well. We just couldn't have an engaging conversation when someone was fighting with the fries and the other person heard only half of what the speaker was saying thanks to the loud music at the restaurant.

A year later, when I worked for another company, we had no technical conversations at all. I initiated brown bag lunches combined with watching technical talks, but that was pretty much it. We never really had a recurring event to discuss code or best practices.

I was the first engineer at my current employer. We could have started whatever made the most sense for our team, however, we did not really need a technical meeting until our team grew. We could just stay longer on the call after our morning standup and discuss topics right there. We did not need to schedule and break for another meeting.
In retrospect, I had waited too long to start any kind of engineering meetings. It was one of our senior engineers who started Lightning Talks, and that meeting turned into our "forward-looking", tools, languages, frameworks exploration meeting.

At the beginning of this year, I also started "self-checking", architecture meeting. Engineers can (and are encouraged to) sign up with topics they want to discuss. We usually have one larger topic that someone presents, and we have one or two minor discussions around smaller subjects if we can fit them into one hour. Our team is remote, the presenter shares his/her screen during the Zoom session to show the slides.

We set an order of the participants at the beginning of the meeting, and we go around the room following that order. This way everybody has a chance to speak up, ask questions, and voice an opinion. If someone does not have questions or comments, that person still has to state he/she does not have anything to add. I found this technique working really well for us, as the discussion is not hijacked by opinionated and very vocal team members.

We have our "self-checking" meeting on Tuesday one week, and our "forward-looking" meeting on Thursday the next week. This way there is a large enough gap between these two meeting.

One day my schedule was scattered with meetings and 30-60 minutes break in between them. I had a chunk of 20 to 45 sessions to get any work done. That works for sending an email or killing small chores, but it's just not enough time to get in the zone, understand a problem, and solve it. I need about 3-4 hours of uninterrupted working time to get "wired-in" and be effective.
Therefore, I asked our product and leadership team to support my idea: let's condense all meetings for engineers in the morning, and leave their afternoons meeting-free. This way the engineers will get more done, and the business will benefit from it.

I hope you will find these techniques helping the engineering team to be more effective.

No comments:

Post a Comment