TBM 8/52: Avoid Mono-Process (But Embrace Shared Language)
Many companies treat all product work the same . The same stages and phases. The same approaches to budgeting, discovery, work decomposition, and collaboration. The same time-box lengths.
It's tempting to use a mono-process. The argument goes something like: "If we can't figure out how to work one way, how can we figure out how to work using many ways?" But what if trying to work one way is actually part of the problem?
Sometimes the rationale is more nuanced. The team wants to do apples to apples comparisons between work for prioritization. By holding something constant—time for example—that gets easier. At what cost though? Do outcomes suffer?
Sometimes the rationale is a veritable minefield: comparing teams, by artificially standardizing their processes. This happens more than you’d think.
Why does this matter?
Consider how teams approach different problems in different ways. Team A is trying to improve a well-worn workflow. Team B is trying to refactor a thorny area of the codebase. Team C is researching a whole new customer type. There's no way that Team A, Team B, and Team C should adopt the same approaches to their work. Even if you ask them to—or try to force them to—they'll likely go off script to do great work.
When I meet teams, I ask them about their "work taxonomy". What is their classification system? And how do they map those classifications to their processes?
The effective teams are way more likely to have an answer. They are far more likely to support multiple ways of working, while standardizing in only the places where it really adds value. Importantly, they have evolved a shared language to describe the differences. This is counterintuitive to some. Doesn’t shared language mean shared process? Not necessarily — we can have shared language to talk about differences too.
The language is where every company can start. Right now.
The big lesson I've learned over the years is to make the language unique to your company. When pressed for language, teams hit Google and come back with a model like "performance features, delighters, and table-stakes". Or "protect revenue, increase revenue". While helpful (especially to some people), this is never the whole story. I've never done this type of activity with a team and ended up with fewer than 10+ categories.
Try this:
Ask the team to blurt out work from the last year or so
Group similar pieces of work. Don't overthink it.
Explore why you grouped work. What made these similar? This discussion is the important part.
Note dimensions (e.g. "knowledge of key persona" or "prior work in this area of the code" or "high profile and many dependencies"). Importantly, don’t force a framework or a set of sliders. I highly recommend named types, not a bunch of sliders. If sliders are your jam, then consider doing that, and naming common patterns and clusters.
Evolve the taxonomy to a place where you can comfortably classify new ideas/initiatives
Explore your working agreements for each type of work
