Playing the "no game" in meetings.
Tags: management, meetings, leadership
Published: 2022-06-07 11:35:10

Ok, I need to confess something. I have lost uncountable hours in meetings during my career. Not only because they could have been an email or not needed at all, but for things that seemed reasonable. Those hours spend on legit meetings are always justifiable, and we see them as necessary but sometimes they take more than needed.

Don't get me wrong. I'm not saying those meetings were a complete waste of time. My point is that sometimes those meetings are missing something essential to be effective, The Objective™. **Being in a meeting without a clear objective is like playing a game without knowing the rules or the goal you need to reach; you are playing the “no game” game.** Without it, something that could take 10-15 minutes is "done" in 40, people in the meeting lose focus, and your energy level after the session is sea bottom level. 

![Two dots from different colors in a white background, so nobody knows the game they are playing](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/15zvps5rzzwgrfwzk7f5.png "The “No game” game")<center>_The “No game” game_</center><br>

This is especially relevant with teams with very different skills and backgrounds. When you don't know which game you are playing, you just play the game you are more comfortable with. Developers play code, Managers play hours, DevOps play security... you know "their games". Even when the objective is mentioned in the event's email or at the start of the meeting, someone can start playing the "no game", and our natural tendency is to play with them. This is not related to the team experience or excellence, I have been in meetings with brilliant and capable people, and we have started to play the "no game" pretty heavily. 

Let me share three real-world situations I have been involved in and how noticing we were playing the "no game" game saved us from the bottomless time pit.

### Unblock the release
We migrated a mobile app backend from Firebase to Booster framework to support multi-cloud, and use some exciting features (event-sourcing, serverless, etc.). Hence, we needed to update the app code to use the new GraphQL interface. We updated the iOS application and applied some design changes along the way. Still, the Android app was a bit behind on the update, so we decided to have a meeting to discuss how to unblock the situation and release the new app as soon as possible since it was impossible to release only one version.

The objective was evident when we started the meeting, but it didn't take much to start playing the "no game" game. We discussed the need to update the Android app to be on the latest and greatest software stack to make it easy to keep the iOS pace in the future. We mentioned that the app was old, and giving it a good refactor makes total sense. After some time, we started talking about taking two more months to release it, and as expected, the product owner was a bit concerned and started asking. 

Fortunately, someone from the team grabbed us back into the "right" game, remembering that the goal was to unblock the release, not update the Android app to the same point as the iOS. After that, we all agreed on a plan that could be executed in a few weeks. We ended the meeting there, and everyone could keep going with their stuff. This saved us a lot of time and frustration on the team.


![Same two dots but now the white background has the football field lines, so they are playing football](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wseesoh6852306h99vs4.png "The Football game")<center>_The Football game_</center><br>

### Unit testing a Proof of concept project
At that time, we were doing some product research, and we had a potential client we wanted to show some concepts to and discover if they were appealing to them. The first meetings were tremendous, and they wanted to keep exploring the solution, so we decided that we could present them with a "Proof of Concept" application to engage even more with the product.

We had a meeting to coordinate and plan that "Proof of Concept". Since our team was excellence-focused and we were all passionate engineers, someone started talking about adding tests so the future refactors and maintenance were easier. We would create it from scratch, and we could enforce them in every PR. That way, we could ensure the highest code coverage possible. If you have been in this situation, you know that early testing debates can last forever. Someone mentioned that our goal was to have something pretty and functional to show to the client quickly. After that, we all agreed to enforce the tests later on when building the real thing. It seems trivial, but by clarifying our objective, the game got so clear that we quickly create a plan and finished the meeting.


![Same two dots but now the white background has the Squid Game field lines, so they are playing Squid Game](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/70ii3gkb8ldioo9j0woh.png "The Squid game")<center>_The Squid game_</center><br>

### Brainstorming too specific
We were throwing crazy ideas to the table in a brainstorming session, and suddenly we started going way too far with the reality checks. We started designing a specific solution for that idea and arguing about different approaches. It is always lovely to debate and get passionate about implementation details, but sometimes it is outstanding that someone just raises their hand and remembers the game we are playing. It saves time and prevents going too deep into the design of something that will change or be dismissed by another idea.


![Same two dots but now the white background has the Tennis field lines, so they are playing Tennis](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wfu736t3ws2a48f5g2pm.png "The Tennis game")<center>_The Tennis game_</center><br>

With no effort, you can probably tell similar situations you have been involved in, and they took ages to finish with probably no clear outcome. The worst part is not the time you waste arguing in the meetings but the frustrating feeling of talking with a different game in mind. Whether is a manager, team lead, or teammate, clarifying the objective is always helpful.

From my experience, the biggest takeaways from those situations are the following:

- Always communicate the objective of the meeting
- Having an objective in mind removes noise and brings you clarity for the decisions to make
- Sometimes you need to remember the objective of the meeting. A.K.A.: The "game" you are playing.
- Have the main objective clear. If other games need to be played, it is vital to do it at the right time (or meeting).
- Even when you agree with the given statements, if they are playing a different game, the best thing to do is remember the objective and leave it aside for a moment.
- Great leaders always try to keep the objective in mind and fresh to help the team be on the same page and focus on the current game.

Knowing the game you are playing is key to being practical. It is a positive spiral that allows you to waste less time, have less anxiety/frustration, solve problems better and faster, and make things 10x better.