Highlighting Decisions in Meetings
It’s no secret that during meetings many decisions are made, and even the ones making the decision might not realize the impact or the event. Sit in on a couple meetings as a note taking and you’ll quickly understand this. At the end of the day, people are people and have conversations rather than deliberate acknowledgement of making decisions.
To give an example: a designer and a programmer are discussing the limitations around a feature. The designer says things should be like X(a), but the programmer points out various trouble areas and recommends X(b) instead. Not only has the design been changed, from (a) to (b), but several action items have been laid out. The programmer is tasked with implementing this feature while the designer has to reexamine the feature for it’s new design. Additionally, this might cause some current art assets to be obsolete, and as a result someone needs to discuss it with them. From one simple conversation, the implementation of a feature, several decisions and action items were created. This all happened without the two original parties realizing it, or did they?
A common occurance trend that I have witnessed on my teams is that they understand that this has all happened, but don’t always translate those decisions into actions. Why is that?
One book that I recently finished may be able to shed some light on this topic. It’s called Blink, by Malcolm Gladwell, and focuses on “the power of thinking without thinking.” Essentially it’s message is that trivial tasks, such as purchasing kitchenware, should be the things we really think about. Meanwhile, complex tasks, such as purchasing new furniture, should be done more in a flash second by going with our first impressions. Why? Because our unconsciousness is really good at understanding these large issues in a flash second. This is pretty similar to a designer immediately understanding when a new mechanic won’t fit into the current list, or a programmer thinking a lot about how he wants to name a variable.
This might be one way to explain why the two developers in my example might understand the decisions, but won’t put them into actions. Their unconscious has already decoded the required steps and has identified the necessary actions. However, their conscious mind can’t catch up within the allotted time of a meeting. In fact, they might become so inundated with information during a meeting that they don’t remember until it’s way too late, in this example if the artist was never told to change tasks. So it is imperative that there is an individual at the meeting that is constantly taking notes, but who?
Unfortunately there’s no one size fits all answer here. It depends heavily on the dynamic of an individual team. Any developer on a team could be the on taking notes, if they are so inclined. However, they need to make sure they capture all the relevant information, decisions, and action items that are determined in any given meeting. The only way that I’ve found for people to improve at this skill is experience. Keep going to meetings, keep failing, and always stand back up.
Thank you for reading!
Enjoy the read? Want to chat? Follow me on Twitter @LiamCraffey