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 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.


  1. JT Casino: Online Slots - JT Hub
    Online 인천광역 출장샵 Slots - Newest 남원 출장안마 and Best Casino Games 2021! JT Casinos UK · 김천 출장안마 Online Slots - 사천 출장안마 Top Casino 광양 출장마사지 Sites.


Post a Comment

Popular posts from this blog

Functional Programming in Scala for Working Class OOP Java Programmers - Part 1

Introduction Have you ever been to a scala conf and told yourself "I have no idea what this guy talks about?" did you look nervously around and see all people smiling saying "yeah that's obvious " only to get you even more nervous? . If so this post is for you, otherwise just skip it, you already know fp in scala ;) This post is optimistic, although I'm going to say functional programming in scala is not easy, our target is to understand it, so bare with me. Let's face the truth functional programmin in scala is difficult if is difficult if you are just another working class programmer coming mainly from java background. If you came from haskell background then hell it's easy. If you come from heavy math background then hell yes it's easy. But if you are a standard working class java backend engineer with previous OOP design background then hell yeah it's difficult. Scala and Design Patterns An interesting point of view on scala, is

Alternatives to Using UUIDs

  Alternatives to Using UUIDs UUIDs are valuable for several reasons: Global Uniqueness : UUIDs are designed to be globally unique across systems, ensuring that no two identifiers collide unintentionally. This property is crucial for distributed systems, databases, and scenarios where data needs to be uniquely identified regardless of location or time. Standardization : UUIDs adhere to well-defined formats (such as UUIDv4) and are widely supported by various programming languages and platforms. This consistency simplifies interoperability and data exchange. High Collision Resistance : The probability of generating duplicate UUIDs is extremely low due to the combination of timestamp, random bits, and other factors. This collision resistance is essential for avoiding data corruption. However, there are situations where UUIDs may not be the optimal choice: Length and Readability : UUIDs are lengthy (typically 36 characters in their canonical form) and may not be human-readable. In URLs,

Dev OnCall Patterns

Introduction Being 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 b