Using the Health Check Model to Evaluate Team Perceptions at Mark43

One of the key focus areas for us here at Mark43 is increasing our inter and intra team communication to ensure that teams are working smoothly and have the resources and direction needed to perform efficiently. Yet, when we talk about communication, often the conversation tends to focus on how teams interact with each other in a direct work capacity and less on how individuals within those teams communicate their perceptions of the work, their role, and overall team health. This is a crucial oversight, as individual and team perceptions of the work and their role in it are a key factor in overall organizational health. In other words, understanding how a team feels about how they are operating is critical in determining not just where we stand as an organization, but where we are heading in the future.

To formalize this process of assessing team health, Mark43 recently developed a version of something called the health check model, taking inspiration from versions promoted by Spotify and Atlassian. The health check model is designed to let teams procedurally take their internal temperature on a semi-regular basis. Teams grade themselves on a series of metrics related to internal perceptions of everything from “Health of Codebase” to “Fun”, and then fill out a scorecard accordingly.

Once all teams complete the health check, we merge their results into a master dashboard where we can track not just how teams compare to each other, but also how the organization at large is doing across specific metrics. For example, we confirmed that virtually every team felt that they were “delivering value,” but more than half of our teams felt that there was room for improvement in regards to the speed with which they operate. These might have been previously internalized understandings for some members of our organization, but seeing them visualized on the dashboard, particularly when juxtaposed against other metrics, was a true catalyst for incorporating meaningful, targeted change management into future planning.

Our current list of metrics is:

• Support
• Teamwork
• Pawns or players
• Health of codebase
• Suitable process
• Delivering value
• Learning
• Speed
• Fun

Each metric is defined by a series of questions that each team asks itself during the health check. Based on that discussion, the team (and ultimately the team leader) makes a determination on the status: red, yellow, or green.

For example, our “Support” metric is defined by these questions:

• Do we feel… that our team is supported by the organization and other teams in our work?
• Do we feel… that our team has the resources it needs from the organization to do our work?
• Do we feel… that we have the backing of the organization in the decisions that we make as a team?
• Do we feel… that the organization understands and values the effort we put into our work?

Each team conducts the health check separately over the course of a month, and is shielded from the results of other teams until they complete their own health check. The day before the meeting, the team leader shares out the metrics as well as definitions and examples of what constitutes green, yellow, and red scores. This lets the team think through each key health indicator before the health check.

At the start of the meeting, the team leader assigns:

• A notetaker to take notes from the discussions and;
• Someone to tally the results of each vote.

Neither of the roles can be assigned to the team leader, who is facilitating the discussion and leading the Health Check.

For each metric:

• The team votes on the quality status (green/yellow/red);
• The team discusses their vote. Every status that receives at least one vote is discussed;
• If there’s been a noticeable change in consensus, the team votes again on the quality status.

While the process should be as democratic as possible, ultimately it’s up to the team lead to decide what status they give for each indicator. For example, if 6 team members vote red, and 5 vote green, the team leader could decide to score the category yellow.

A notable struggle for our teams was norming on what constitutes a certain score. We tried to be as specific as possible with our definitions for each category, but ultimately leaving this decision up to individual teams and how they feel is really the point of the health check. Thus, it’s important to emphasize that the health check and resulting dashboard are really a metric of our team’s perceptions, and not any truly quantifiable metric. For example, here’s our definition of what constitutes a red vs. green score for “health of codebase”:

• Green: “Our team is proud of the quality of our code. It’s clean, easy to read, and has great test coverage. Our tech debt is reasonable and doesn’t impede on our ability to function as a team.”
• Red: “Our code is indecipherable to anyone without an extreme, in-depth knowledge of the codebase. We’re using a number of languages that makes changes and further development almost impossible, and/or our tech debt is crippling.”

Notice how there’s no real way to measure language such as being “proud” of the code, nor of it being “indecipherable.” Likewise, you could fit several football fields between our green and red definitions. This is intentionally designed to give our teams the flexibility to put the score they feel is right instead of the score that conforms to what the data says. We have plenty of systems in place that tell us where our code is from a technical standpoint, but we want to use our health checks as a space for perceptions.

Another key benefit of conducting the health check is that you can track trends over time. We chose to run the health check biannually, meaning that every six months we receive a new picture of where our teams stand and can compare these results to previous cycles. Doing so lets our leadership track which initiatives are having an impact and which need to be reconsidered. It also helps us measure the health of our teams against specific product and company milestones.

Running the health check provides our leadership with a much clearer picture of where each team feels it stands, and thus where to allocate resources and support accordingly. But, crucially, it also provided significant holistic value to each team as well. The feedback from our team managers and individual contributors was that it allowed them the space to communicate their thoughts and feelings in a productive yet open setting, something that they felt they rarely had the opportunity to do previously outside of 1:1s and other less team-focused interactions. It turns out that, for Mark43 at least, the act of diagnosing the problem itself was a vital part of the solution.