One of the most difficult challenges when running an engineering org is understanding if a team is functioning well or not. Lines of code don’t work. Story points don’t work. It’d be so nice if there was just a speedometer, right?

That doesn’t really exist. Teams are more than just groups of people, with the connections between individuals and connections across the org playing a huge role in how effective any give team can be. Teams also have lifecycles. They are formed, grow, and mature. They evolve as people come and go. And then one day, they stop existing.

Watching a group of people become a team is one of my very favorite things.

Understanding these dynamics only compounds when running multiple teams. You no longer have the bandwidth to understand each team intimately, and (especially with more junior managers reporting to you) it can be difficult to understand if a team is struggling or not.

Breaking Down Team Maturity

These were the problems I was facing when I created the Engine e ring Team Maturity Matrix. Which sounds very fancy, but is really just a set of facets that can be used to examine a team. These facets where chosen and have been iterated on in order to highlight where the team is right now and what might be holding them back. Those facets are:

  • Roadmaps

  • Project Management

  • Workflow Process

  • Metrics

  • Self Determination

  • Goal Setting

  • Program Management

  • Budget

  • Decision Horizon

  • PredictabilityTeam Alignment

  • Cohesion

  • Stakeholder Relationship Health

  • Reflection

What is the Engineering Team Maturity Matrix?

Each of these facet is evaluated on a scale from Tier I to Tier IV, representing a spectrum from early-stage or immature practices (Tier I) to highly mature, optimized processes (Tier IV).

This tool not only helps teams visualize where they stand in their development, but also opens up valuable discussions about where they could go and the barriers that may stand in their way. By applying the matrix, teams gain clarity on their strengths and weaknesses, setting the stage for continuous improvement.

However, It is critical to understand that the goal is not to be Tier IV in every single facet. This team exists inside a business context, and that business context dictates and optimizes for certain behaviors. One goal of this matrix is to help understand where a team is and where the business needs it to be. Attempting to force too much maturity too early in a business’s development can be catastrophic.

How I Used it

The exercise for using it is very simple, but has always yielded great insights. I simply sat down with an engineering manager, explained the matrix at a high level, and then had them self-evaluate the team on each row, one at a time.

For each row, we’d explore why they self-evaluated that way, where they thought the team should be, and, if that were different, then what was holding them back. Sometimes a manager will say the team is somewhere between two tiers, and that’s ok. Sometimes a manager will say the team is more mature than you know them to be, and that’s ok. Pushing back and finding shared understanding is your job as a Sr. Leader.

These sessions are always eye-opening for myself and the manager. I’ve had some amazing deep meaningful conversations with managers when doing this exercise. It often reveal disconnects between different parts of the business and can often help pinpoint bottlenecks that may have been overlooked.

Why This Matters

The beauty of the Engineering Team Maturity Matrix lies in its flexibility. Whether your team is at the beginning stages of its journey or a seasoned group of engineers working at scale, this matrix helps tailor next steps for growth. It encourages introspection and provides a concrete structure for continuous improvement. In the past, teams have surfaced moving from one tier to the next as part of their quarterly goals. It’s a versatile tool. By breaking down the complex elements of engineering operations into manageable, assessable pieces, teams can set realistic, actionable goals that align with both their capacity and external demands.

I feel like I shouldn’t have to say this, but I also know that I do - this entire exercise presupposes a fair amount of trust between you, your managers, and those ICs. If that’s not something that exists, then you have bigger problems.

In future blog posts, I’ll take a closer look at each facet of the matrix, providing my own experiences on how to assess and identify where your teams are and where they belong on this matrix. For now, I encourage you to think about where your team might fall within the various categories and how those various categories are helping or hindering your org achieve its goals.

[googleapps domain=“docs” dir=“spreadsheets/d/e/2PACX-1vSibyrXfV6RuPjb08FEMAl-zAOYM2UA5u_9xxqoJ4d9oqtVQI6MF7-XwGA0wpUtuKje08qEpvLVzc7L/pubhtml” query=“gid=834962024&widget=true&headers=false” /]