Note: I recorded a short video on high work in progress you might find interesting
On to this week’s post…
A team member at Amplitude recently asked the following question:
How do you figure out whether teams are more mature or less mature so quickly?
After challenging the notion of maturity (not my favorite word), I explained the following:
Knowing a team is more mature/less mature has nothing to do with WHY they might be more mature/less mature. Same with health. Same with performance.
Nor does it mean you have the skills/experience to take a company along that journey.
Very rarely is there a single Why for anything in complex socio-technical systems. Don't believe people who say so.
It helps to have a high N across companies. But remember that just helps you pattern match.
Strength in one area can more than make up for weaknesses in other areas. Lots of companies succeed despite their product savvy.
Maturity is contextual and non-linear. If you are a bank operating like it is 2012, but your competitors are operating like it is 2006, that might be just fine. Unless you risk being disrupted soon. I might have a high N across a big cross-section of companies, but I probably don’t know 10 of Company X’s competitors.
What signals do you look for?
After reiterating the above, I did a lot of introspection. I thought about health and performance (instead of “maturity”). What do I actually listen for? What signals do I pick up on in the first fifteen or twenty minutes? And I asked Twitter. Here's what I came up.
There's flow. The team describes regular progress. Something has reached customers in the last couple days or weeks. When things go longer, there's still regular, tangible progress.
The team describes a structured approach to learning. Techniques vary, but the common thread is intentionality and focus. What did we need to learn? Why? How did we learn? What did we learn? What decisions did that inform?
The team has higher decision authority and spends less time waiting on other people to make decisions. They describe fewer sign-offs and approvals. More of their destiny is within their control.
There's a strategy. A real product strategy. Detailed enough to provide the necessary context without sapping agency. This is one of those "you know it when you hear it" type things.
The team describes their progress using the language of experimentation and impact. When things "work", and when they don't. Not everything needs to be an A/B experiment. But the "we assumed this, learned this, tried this, and this is how it worked out" muscle is strong.
The team navigates fewer dependencies. There's a tangible difference when the team has fewer dependencies to juggle. Less 3-dimensional chess. Less cognitive overload. More room to breath. More time feeling like a creative problem solver.
The team uses structured research, insights, and direct customer contact to understand the customer. Fewer proxies. The team is well versed in the world of the customer. Details surface in conversations frequently.
The team describes fewer distractions, interruptions, reactive shifts in direction, and swoop-and-poop. More time to think. More time for deep work.
The team describes acute challenges, but fewer chronic, lingering elephant-in-the-room type challenges. Things general work themselves out.
The team describes grappling with uncertainty, but doing so in a way that turns out well for their team, their company, and the customer.
The team describes more ad-hoc (and willing) collaboration. More laughter (thanks for the reminder @GeePawHill). More fluid and less transactional conversations.
Brilliant distillation, John.
How do we looks at this from a portfolio perspective with enterprise size? Maybe it goes back to strategy. Complex legacy systems can cause hidden dependencies that have to be worked through. It makes difficult autonomy of a single team. Sometimes as a multi teamed approach is needed.
Thanks for sharing.