If you’re the leader of a software development team, chances are good that your engineers spend more time than they’d prefer on things other than developing software. Much of this time is probably taken up by meetings; Harvard Business review reports that time spent attending meetings in the workplace has more than doubled since the 1960’s.
As they increasingly become part of cross-functional teams, your developers benefit from the collaboration and innovation that takes place during productive meetings with a diverse group of people. But equally important is that they have time for independent introspection and reflection.
Here’s how you can protect their time–and yours–by making sure you run the most effective meetings possible.
Ensure a meeting is necessary.
Think of it this way: how much will this meeting cost? Even if you skip the fancy reservation and snack buffet, a developer’s time is money. Do a quick estimation of what it costs to have a few engineers sitting in a room together for an hour. Now imagine writing a check for this. Is this meeting worth it?
Schedule a meeting if you want to…
- make a decision
- solve a problem
- generate ideas
- craft a plan for moving forward
- reflect and improve
Don’t schedule a meeting (and instead find a different way to achieve the same results) if you want to*:
- share information/review/recap
- encourage employee buy-in
- get motivated/energized/inspired
* Engineer’s exception: Department all-hands
Invite the right people, choose the right time, and commit to lead.
Invite the right people
Nothing destroys the effectiveness of a meeting like having too many–or the wrong–people there. Keep the group as lean as possible, while ensuring that the following are
- A timekeeper and notetaker (The meeting leader should not be taking notes.)
- Enough diverse perspectives and skill-sets necessary to achieve desired results
- Key decision-makers for the issues involved
There is no magic formula for how big meetings should be, but a general rule for size, from smallest to largest, is based on the purpose of the meeting:
make a decision < solve a problem < generate ideas
Choose the right time
The good news: that you’ll have fewer people attending means fewer schedules to work around. The bad news: everyone is still busy.
Schedule the meeting depending on the invite list, taking into consideration time zones, lifestyles, and work culture. The purpose of the meeting will inform when you should schedule it, too. In general:
- Tuesdays are the best days to meet. This gives people time to prepare the day before while still getting a head start on end-of-week deadlines.
- Mornings are the best time to make decisions. This study finds that people tend to make more thoughtful, accurate decisions in the morning and quick, risky decisions in the afternoon.
- Afternoons are the best times to brainstorm. Surprisingly, studies have shown that creative, out-of-the-box thinking comes to us most when our brains are a little tired!
Commit to lead
Do not call for a meeting if you can’t commit to being an organized, thoughtful, articulate leader. Practice these skills as necessary, but not using your team’s valuable time.
*Engineer’s pro-tip: be ready to pull the group back if the conversation falls into a technical rabbit hole. Engineers love to learn, experiment, and exchange ideas, but letting this go on in a meeting when you’re working to address a user problem may get in the way of addressing what the actual need is.
Specify and share an agenda.
Forget any negative connotations you have with the word agenda. The truth is, you will not run an effective meeting without at least a skeleton agenda, even if the first item on it is to determine the rest of the agenda as a group.
Everyone you invite wants to know why they are included, how they will contribute, and what the expected outcome is. If you want to get a head-start on fostering collaboration, send instructions no less than 3-4 days before the meeting asking participants to submit agenda requests.
Use these requests to craft the agenda and send it out no less than two days in advance, along with all preparation materials. At the least, an agenda should include:
- Time and location (meeting room/virtual conference)
- List of attendees & roles
- Overview of purpose for the meeting
- Topics to be discussed and time estimate for each
- Action items review
Emphasize engagement, contribution, and results.
Leading a team of engineers may look a bit different than leading another group. Here are quick and easy suggestions to emphasize three key components in meetings:
Two quick and easy ways to maximize engagement
- Take agenda requests: set the expectation for engagement before the meeting begins by asking invitees to submit agenda requests. This sends the message that you value their input and expect them to be active participants. If you aren’t able to accomodate a request for this particular meeting, let them know that you’ve heard their ideas/concerns/questions and will plan another time to address them.
- Insist on shared screens: break from the standard advice to ban open screens by insisting on using shared screens. The minute a developer begins explaining a feature or bug with words-only, half the room has checked out and the other half is only getting partial information. Everyone should be looking at the same code or interface at the same time. This will result in greater understanding, more specific feedback, and faster resolve.
Two quick and easy ways to encourage contribution
- Model vulnerability: it takes a certain amount of trust to speak up among a group of colleagues and this trust is only built by experience. When the leader of the group is not afraid to say, “I’m not sure I fully understand” or “Do I have that right?” you are modeling to the rest of the group that they’re in a safe space to think outside the box, voice confusion, or process as needed.
- Capture ideas: as the leader with an agenda to follow, you’ve got to keep the show on the road. You may do such a good job building trust and encouraging participation that you find you need to cut it off to keep moving. Have a white board nearby to capture whatever comes up that is worth returning to another time.
Two quick and easy ways to focus on results
- Summarize as you go: in addition to helping the notetaker, your ability to rephrase things in a simplified way will ensure understanding and coherence among your team. Even with a group of engineers, you should practice translating technical information in a nontechnical way. Keep in mind, they are all working at various levels and some may be deeper into a project than the rest of the team.
- Pull action items: again, help the notetaker here by confirming what people have committed to and assign action items as they come up.
Assign next steps and end on time
If you’ve done a good job up to this point–inviting the right people, following an agenda, and summarizing as you go–this last part should be a breeze.
- Review action items: This is where you get a break and the notetaker takes over. No need to go over all the notes: action items only. The person assigned should be clear on the item. (And don’t assign something to someone who isn’t present!)
- Adjourn: That you started the meeting on time should go without saying, but it’s equally important that you end on time.
Sticking to the agenda should help you with this, but if things got off track, jot down those last items on your whiteboard and determine what needs to happen to achieve the purpose of the meeting.
But no matter what, end on time. This helps build trust in your management ability and gets engineers back to engineering!
Source: Talent Acquisition - hired.com
