Nick (a friend of mine :) loves developing software. But he doesn't really like meetings. His manager just asked him, hey, Nick, about this new feature you are going to develop, can you set up a meeting with a product, project, team leads, UI, backend teams just so we are all aligned? Now Nick needs to handle a meeting. It was all wired up in his head, but communication, as to say, is not his strongest skill, and he is afraid of a failure.
Luckily, Nick got the dev.to summary mail with a blog post named "Scared of high-tech meetings? Follow this plan!", he has read it and this is how it went and what the plan he read was:
Our plan:
You are talented, you already know how you want the meeting to end.
The plan is simple and involves one step. We are going to set up the meeting, however, we already know how we want it to end, our design should be approved.
In order to achieve this plan end goal this is what Nick does:
He creates a one-page document with the design and shares with all meeting participants and asks them to review prior to meeting. In addition, he summons the meeting and attaches the doc to the meeting.
John sends him back an email and mentions to him that he suspects there is another field in DB he should discuss with Sebastian.
Nick then goes to Sebastian and they find they can merge both fields. Document updates and Nick resends the change. Note that Nick makes enough noise before the meeting to get as much feedback as possible.
Nick moves on and goes to the key person in the company and discusses and asks for their advice, those people were not invited to the meeting but they key insights are important, some new insights are gained.
George which hasn't noticed the first mail from Nick opens it and reviews the updated design for the first time, he has other comments and mentions his team will need two weeks to confirm with the new feature. Nicks get in touch with the project manager whom he never talked with before the meeting and talks to him about it. They manage to set up some timeframe for an external person to help that other team.
Now do you see what's happening here if Nick was waiting for the meeting to occur all these issues would be risen there, the original target of the meeting was to discuss this new feature so you might claim this is why we needed this meeting, but I'm afraid this meeting would go into disaster! It would take too long, people might yell at each other it was not in their plans and their sprints are so busy.
Nick is sorting all these things out before the meeting, our end goal is that when the meeting happens it goes as smooth as possible almost like this:
Nick: "Here is the agenda, ..., our meeting target is to approve the feature, here is my design, any questions? design approved". The meeting ends in 15 - 30 minutes, as Nick already discussed with all personnel prior to the meeting, if anything new has risen he would be able to handle it.
If you wait for the meeting to discuss a design, it's too late.
So here is the recipe:
Clear agenda.
If anything is unclear discuss with personal before the meeting.
Try to communicate with meeting members before the meeting even if no-one replies to the early design document.
If you see any sign of disagreement or questions raised before the meeting this is a big red flag, make sure all are aligned with the solution before the meeting.
During the meeting:
If the meeting deviates to any other storyline not related to your meeting target - you must put an end to it You are the owner of the meeting, don't let this happen.
I repeat, no matter what happens, no matter who talks in the meeting and takes it to a different place, you will get much honor by taking control of the meeting, just ask politely, and say: "This is an important topic, however, we have deviated from this meeting target, I would like to get back to it, the feature as I explained has this, and this is...".
You might get into a situation where the meeting is canceled - this is a great situation, you finished all preparation for the meeting!
Create a 1-page doc for the meeting the one-page doc should be presented on the screen during the whole of the meeting.
Sometimes I manage to get this one-page doc to include:
Agenda
Design
Timeline
Known issues.
By having this 1-page doc already on the screen when the meeting starts, I get the following benefits:
No one will raise this smart known issue because it's already on screen.
All are aware of agenda, they know what I'm going to do so they won't interrupt me with things that are supposed to be already in meeting they just did not know they were going to be.
I'm ready with the timeline, I did my homework.
I find this one-page doc much better than a presentation where people need to guess what's in the next slides, as they cannot do it more questions meeting will deviate into questions that should not be risen.
Be aware of high-risk open questions meeting If your meeting target is inherently open question meeting, this is a high-risk meeting, do whatever you can to prior talk, investigate, get to the solution before the meeting.
Summary
The best meeting is a canceled meeting before you did enough homework.
Send a doc to all meeting participants ask them to confirm and review.
For high-risk meetings talk to each of the participants before the meeting.
If you identify any suspicious questions, get to the bottom of them before the meeting.
During the meeting present a clear agenda and that one-page doc, you have thought of everything.
Plan for X minutes time meeting and try to finish the meeting in at most 1/2 X the time you planned for.
If the meeting is by nature a brainstorming non-planning meeting, this was not about it, most meetings are for approvals and decisions.
Book
I have learned much of the pieces of advice presented here from the great book *A Survival Guide for New Consultants *. I have found that even though I'm not a consultant, behaving like a consultant can make me a much much better software engineer.
Comments