One of the most crucial factors for a company to be successful is to have thriving teams. So for me, the health of the team is a very crucial KPI.
At Appsilon we look at team health at various levels. We use Officevibe to track different team metrics on a company level and within different teams (tech team vs. operations etc.). Engineering managers hold regular 1-on-1 meetings with their reports. They discuss various topics, also metrics related to happiness at work. Also, delivery managers have regular 1-on-1s with Project Leaders.
But, my intuition was that we would benefit from a standardized way of monitoring health within our project teams. Why? Because we already saw in the past that someone can be pleased with being at the company, but can be in a toxic project that impact won’t (fully) be seen in Officevibe. Additionally, I wanted to have a consistent way to compare projects and track health over time.
Team Health Check at Appsilon
I introduced a team health check inspired by Spotify’s Squad Health Check model into our wrap-up/business review process. We ask 10 questions:
- Delivering Value
- Perfect: We deliver great stuff! We’re proud of it and our stakeholders are really happy.
- Crappy: We deliver crap. We feel ashamed to deliver it. Our stakeholders hate us.
- Fun
- Perfect:We love going to work and have great fun working together!
- Crappy: Boooooooring…
- Health of Codebase
- Perfect: We’re proud of the quality of our code! It is clean, easy to read and has great test coverage.
- Crappy: Our code is a pile of dung and technical debt is raging out of control.
- Learning
- Perfect: We’re learning lots of interesting stuff all the time!
- Crappy: We never have time to learn anything.
- Mission
- Perfect: We know exactly why we are here and we’re really excited about it!
- Crappy: We have no idea why we are here, there’s no high lever picture or focus. Our so-called mission is completely unclear and uninspiring.
- Partner or handyman
- Perfect: Our recommendations are valued and influence final decisions made. Client seeks our advice.
- Crappy: We are just pawns in a game of chess with no influence over what we build or how we build it.
- Speed
- Perfect: We get stuff done really quickly! No waiting and no delays.
- Crappy: We never seem to get anything done. We keep getting stuck or interrupted. Stories keep getting stuck on dependencies.
- Stress
- Perfect: Things are pretty relaxed and under control.
- Crappy: We jump from one fire to another. Things are very stressful and affect our well-being.
- Appsilon’s Purpose
- Perfect: We feel the project is well aligned with our purpose. We advance tech and improve human life.
- Crappy: Project has nothing to do with our purpose.
- Inclusivity
- Perfect: Everyone is welcome with respect and has a genuine feeling of belonging.
- Crappy: People feel excluded. Some team members seem more equal than others.
Some cards e.g. Fun or Learning are taken as-is from Spotify’s model, but others e.g. Stress or Inclusivity are added by us. We modified the initial list by Spotify. This is something that worked and mattered for Spotify in 2014, and we are not Spotify 2014. Appsilon is a consulting company, not a product company, that also has its values.
Our teams use 4 colors to answer the questions:
Green doesn’t mean Perfect. It means the team is happy with this and sees no major need for improvement.
Yellow means some important problems need addressing, but it’s not a disaster.
Red means this sucks and needs to be improved
Grey means this doesn’t apply to me.
How to work with it?
Collect feedback from the team and discuss it e.g. it can be done as a retro session if you are using SCRUM. There could be many things that are not “Perfect” especially if you are doing this for the first time. It’s OK! It’s a good thing because there is enough psychological safety in the team to speak about the problems. It’s excellent! However, it’s important to act on the feedback and together decide on the things to address first. We select ONE initiative that the team will focus on. We also decide when we will do the next check and compare the change.