Why Are We Having This Meeting?
How Test-Driven Development Can Lead to Better Meetings
Recently, I started transitioning into a management role (more code review, hiring, and team-building related work). I felt a bit intimidated at first because I thought I wouldn’t be able to use my development skills anymore.
But the more I learned about management, the more similarities I found between management and software development. Even more fascinating, I found that I can apply the same discipline to the management process as I did to my coding process.
In today’s post, I want to highlight the similarities between Test-Driven Development (TDD) and organizing a meeting and show you how your management process can benefit from this approach.
What is TDD and how do we do it?
TDD is a development approach where tests are written before the development of a feature. This is done in increments so that only enough code necessary to pass the tests are written. The test drives the production code, rather than the other way around. This forces developers to be agile and to focus on the requirements of the feature before writing any code, ultimately resulting in fewer bugs.
Practicing TDD in the traditional Red/Green/Refactor cycle.
The Red/Green/Refactor cycle essentially defines the steps of TDD, where red represents a “failing test” and green represents a “passing test.”
- Red
In this step, we write a test with detailed description to define the problem we need to solve. Here, we define the specifications for the feature we want to develop and create tests for each of and only the functionalities of the feature. At this stage, the written tests should fail so as to ensure it won’t produce false positives or false negatives. - Green
Then we write just enough code to pass the test and turn it green. We emphasize minimal code because it’s the only way to keep things simple. By keeping things simple, we maintain readability which helps the refactoring process and minimizes bugs. We should focus on coding what’s required for this specific functionality and only let future requirements push us towards more complexities. - Refactor
After passing a test, we review our code and see if there’s anything we can refactor. Refactoring is when we fine-tune our code and improve its structure, all the while ensuring that its external functionality remains the same. Although you may not think it’s necessary because the improvements are behind-the-scenes, this step is the crucial line of defense against bugs.
With this process in mind, I realized that when we unconsciously applied the same discipline to our management process, things work better. For example, we could use this TDD approach to organize a meeting.
How do we arrange a meeting?
You might think this is a dumb question — the answer is obviously to announce the meeting via some sort of communication channel, invite participants, and have the meeting! But I’m not referring to just logistics here. To truly have a productive meeting and not waste anyone’s time (because, really, who wants to attend another meeting?), we should stop and ask ourselves:
1. What’s the problem?
What is the problem we are facing and does it require a meeting?
I remember once I thought we weren’t communicating enough about our projects (the problem). I made a suggestion to our team that we do our daily stand-up over Slack (a potential solution). My team didn’t understand why I would make this suggestion and change our usual stand-up process. I realized then I needed to call a team meeting to communicate to them what I thought was a problem.
Basically, the whole purpose of this phase is to set the goal for the meeting so we can focus on finding a solution.
At this point, we shouldn’t bring up any potential solutions because that would only work to divert our focus and confuse people about why it’s necessary to have a meeting in the first place.
This is just like writing a test that’s not tied to our implementation. It’s much harder to develop a test when we think about writing production code at the same time.
2. Who can provide the solution?
After defining the problem, we can now go about identifying the appropriate people with whom we could work to solve the issue and finding the potential solutions. It’s important that we invite only the people necessary to solve the problem.
Is it a management problem?
Find the PM.
Is it a technical issue?
Find the technical leader.
Is it a spec misunderstanding?
Talk to the client and find out what they need.
It’s equally important that the meeting covers only the defined topic of the problem and that it doesn’t last too long. This simplifies the problem-solving process and maximizes efficiency, in the same way that writing the minimum code necessary to pass the tests developed in the red phase helps keeps things simple. Just as in the green phase, we solve only the problem at hand and defer complexities to a later time.
3. How can we assess and adapt the solution?
Once we implement the solution, we should see if it really solved the problem and assess whether it needs any adjustments. At Ekohe, we believe there is always more than one way to solve a problem. A solution that works today may not be the best solution tomorrow.
That’s why it’s always helpful to look back from time to time and check if the solution is still working as expected. With the new feedback and information, we can adapt our solution if necessary. This results in the most appropriate solution, just as refactoring leads to cleaner code.
In summary, these basic principles of TDD can be applied to meetings (or nearly any other problem that requires a solution):
- Set clear goals / define specifications
- Find the simplest solution
- Gather feedback and improve
I hope this short piece helps you think across domains and gives you some insight on a different approach to management (whether in tech or in life).
