As a software engineer, there is nothing more disruptive than meetings. Meetings break up your flow, slow down productivity, and are incredibly frustrating if they end up being the typical “this meeting could have been an email” meeting. However, as someone who has been building a meeting software platform for almost 4 years, I have come to realize that meetings are not necessarily to blame.
We’ve been looking at human behavior and asking the question “Why do we hate meetings so much?” If you had asked me that question four years ago, my answer would have been very different from what it is now, due to the benefit of taking a hard look at the why, not just the what. That said, we’ve tried to incorporate what we’ve learned to automate and encourage good meeting behaviors with our customers so that everyone can benefit from having the right amount of quality meetings.
Why am I here?
Asking an engineer to context switch is one of the most expensive and disruptive things you can do. If you’ve ever seen an Ironman or Avengers movie, engineers in the moment are like Tony Stark working through a problem with his holographic interface having his thoughts and ideas floating around him (because who doesn’t want to be Tony). When a meeting reminder pops in and we have to stop what we are doing, all of those ideas fall to the ground – taking us hours to pick them all back up again later.
The time we spend in a meeting is time away from creating. If that meeting doesn’t provide a clear understanding of why I’m needed, then I may either end up spending extra time and energy trying to find the “why” or not spending any time at all and show up completely unprepared.
When it comes to getting the most value from your engineers in meetings, consider creating an agenda that provides clear direction on:
Why are we meeting? This isn’t the meeting title. This is a brief sentence or two that helps me easily understand why I am needed.
What is the goal? Knowing why we are meeting is important but also equally important is what is expected when we are done. Are we coming up with a solution or a new strategy? When we leave the meeting, what do you want to have accomplished?
How do we get there? A little structure is appreciated to help keep everyone on track. Given that these meetings can include different roles, personalities, and other variables, having some structure to guide the conversation is appreciated. For example, this could be as simple as:
(1) Share the problem/challenge/idea
(2) Discuss potential solutions/options
(3) Decide and assign tasks/next steps
What is your point, exactly?
For engineers, there is such a thing as information overload. We deal with complex data structures and strategic solutioning all day long, leaving us with little space to wade through documentation and creative conversations in order to figure out what is expected of us.
We need information split into digestible chunks that are actionable (this is one of the reasons agile and scrum exist). We would much rather have a bulleted summary than having to sit through a lengthy explanation or sorting through a pile of documents. Background is good, but we don’t need the entire history, so keep the context focused.
Using an agenda, providing a clear story as to the problem, challenge, or idea could look like:
What is the Challenge? What is the reason you need me to help?
Who is affected by the Problem? What is the audience that has the burden, challenge, or need?
What is the Desired Result? Engineers will provide the “how” of the solution but we could use some direction on what you hope the solution will do for those affected by the problem.
Well, that would have been nice to know.
Without being counterintuitive to engineers wanting concise, distilled, and critical information, we do appreciate an understanding of where we are headed.
If you ask me to build a building and don’t tell me someday there may be a road that needs to tunnel under it, I may not configure the building in a way that supports future infrastructure.
If you ask me to build a swimming pool for a small athletic club and fail to tell me you are hopeful to apply to be a venue for the Olympics, I am probably not architecting it with that in mind.
While we may not be building a tunnel or olympic pool right now, if engineers know what the future may bring, you help us balance today with tomorrow to ensure getting from A to Z is smoother than building A to H and having to start over again to get to Z.
A few things to consider when sharing vision with us in meetings:
We don’t expect you to tell us how to get from A to Z. But we do hope you will help us understand milestones and goals so we can properly estimate what we are capable of doing to get there. We need to know the general theme of the movie to write dialog for the opening scenes.
Guardrails are a necessity. Most organizations don’t offer unlimited budgets, resources, or time. An engineer will always tell you anything is possible given the proper amount of resources. As soon as you know what those guardrails are, we can begin working within that framework for a solution.
Visuals are appreciated. As we meet regularly about our mutual work, visuals that express deadlines, progress, and other key measurements are a great anchor to help us quickly gain understanding of progress and feel successful. As mentioned above, keep the information in simple, digestible chunks and everyone benefits.
In Summary
Engineers understand the value they offer your team and truly want to help. Using a meeting intelligence platform like Docket, you can create agenda templates, create structure, and ensure everyone is prepared before the meeting and aligned after the meeting – avoiding the dreaded “meeting that should have been an email.” Following these guidelines will create a more meaningful collaboration between you and your engineering team, creating a trusting and successful partnership.
