Team Maturity

Recently I pondered on how to evaluate the maturity level of my teams. I came to conclusion that it correlates with 7 levels of delegation.

For the sake of brevity, let’s group these levels based on team’s autonomy:

• 🐣 Low autonomy: little/no work is done without managerial input.
  Think of “Tell”, “Sell” and partially “Consult” delegation levels.
• 🧑‍🎓 Partial autonomy: some work can be done without managerial intervention.
  Pars with “Agree” and “Inquire” levels.
• 😎 Autonomous teams can perform (almost) all work without formal management.
  Corresponds with “Delegate” and “Empower” levels of maturity.

Team’s autonomy isn’t one-dimensional; the level of maturity often differ drastically across technical and product/business axes. Different aspects, such as team structure and motivation, affect these levels.

For instance, the team can lack some expertise which implies low technical maturity: the Tech Lead must take a more directive role (and dedicate more time to coaching and knowledge sharing). Such teams show pretty distinct behavior on the refinement meetings: 1-2 people know the answer to the question “How are we going to implement it?”; the rest of the folks obey the seniors. In formal terms: Knowledge silos, lack of shared architectural ownership, passive participation.

However, even technically strong teams which hardly ever stuck on the “How?”, can be pretty bad at product vision. They work well if there is a backlog; whatever isn’t formally described, won’t be implemented. Such teams often practice exhaustive refinements in order to get “juridically” exact acceptance criteria. Wasn’t written → won’t be implemented 🙁

The utmost level of maturity is the initiative. On the technical side, the team proposes solutions taking the future roadmap into accounting. From the product point of view, the team actively contributes to the Product discussions of the “What?” level (or proposes unexpected “How?”-s which achieve given feature goals as well: alternative UX/UJ¹ or exploiting existing flows in new ways).
This does not mean the Team’s ideas always take precedence; the fact of active involvement and deep understanding of the product is distinctive.

Understanding a team’s maturity level is important because it shapes the way you lead and what you delegate (≡ where you invest your time):

• Over-managing mature teams frustrates them and slows things down.
• Under-managing less autonomous teams creating confusion and rework (and also frustration).

Maturity is not about labeling teams as “good or “bad”; it’s about recognizing how much autonomy they can handle and what support they need to grow: from directive guidance to full empowerment. Even tactically, the user story writing looks different: less mature teams require more details behind the “As a [WHO], I want [WHAT] in order to [WHY]” formula².

On a broader level, maturity awareness helps managers make better decisions about hiring, coaching, planning, and stakeholder expectations. A team with low technical maturity might need structured mentorship (read “expertise and time invested into skill-building; take into accounting during planning“). A team strong in delivery but weak in product thinking might benefit from more exposure to product discussions and customer problems.

This fills the theoretical exercise of the team maturity evaluation with very practical purpose. Knowing the teams helps building more realistic plans and spotting opportunities to growth.