Skip to main content

Scared of high-tech meetings? Follow our plan!

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

Popular posts from this blog

API Design Paper Summary and Review

API Design Paper Summary Introduction Is building API a solvable question, how far can we get into having good API’s and what is a good API at all? these are all very hard questions, usually you know the answers once you designed multiple APIs and got experience and then reviewed the decisions you have taken. Fortunately there are papers dealing with this problem exactly, for complex API’s used by a huge amount of people, the Qt API for example a very populate framework for desktop GUI building, and today we are going to go through a summary of that paper.

“The Little Manual of API Design” is a very nice paper written by Jasmin Blanchette has released a paper while working in trolltech, which is a Nokia company. I found it to be very clear and concise, and reassuring what we think of API design. It’s a difficult task that includes both artistic, social, programming and scientific skills. We are going to summarize this paper for you.

When you write an API you combine a set of symb…

Dev OnCall Patterns

IntroductionBeing On-Call is not easy. So does writing software. Being On-Call is not just a magic solution, anyone who has been On-Call can tell you that, it's a stressful, you could be woken up at the middle of the night, and be undress stress, there are way's to mitigate that. White having software developers as On-Calls has its benefits, in order to preserve the benefits you should take special measurements in order to mitigate the stress and lack of sleep missing work-life balance that comes along with it. Many software developers can tell you that even if they were not being contacted the thought of being available 24/7 had its toll on them. But on the contrary a software developer who is an On-Call's gains many insights into troubleshooting, responsibility and deeper understanding of the code that he and his peers wrote. Being an On-Call all has become a natural part of software development. Please note I do not call software development software engineering because …

Recursion Trees Primer

Recursion trees.

Controlling the fundamentals stands at the cornerstone of controlling a topic.  In our case in order to be a good developer its not enough or even not at all important to control the latest Java/JavaScript/big data technology but what's really important is the basics.  And the basics in computer science are maths, stats, algorithms and computer structure.

Steve wosniak the co-founder of apple said the same, what gave him his relative advantage was his deep understanding of programming and computer structure, this is what gave him the ability to create computer's which are less costly than the competitors (not that there were many) and by the way there were 3 founders to apple company one responsible for the technical side, one for the product and sales (Steve Jobs) and the third responsible for the company structure and growth, each of the three extremely important, it was not only the two Steve's but that's a topic for another episode.

And with that l…