"But we're already doing this”
Multi-disciplinary teams? ✅
Agile? ✅
Outcome-focused? ✅
User-centred? ✅
Embedded assurance? ✅
Working in the open? ✅
Hypothesis-driven design? ✅
Roadmap instead of gantt chart? ✅
Scoped to end-to-end services? ✅ "
But are you getting the results? Many aren't - because the devil is in the detail.
Throughout my career it has been quite common for me to hear “but we’re already doing this”. It’s a sentence typically followed by a usually unstated “so why will this be any different?” or “so you can leave me alone, I know what I’m doing”. Every so often I hear…”so why are we not getting the results?”.
This blog post is for this latter audience.
The things on the list in the list above - they’re all shorthand, with the detail not always made explicit. I’m going to write a short series of blog posts, providing some of that devilish detail for each of them.
Multidisciplinary teams.
This means - a team with the skills and domain knowledge necessary to do what needs to be done. They’re not cookie-cutter teams - the team profile needs to evolve with the needs of the work. There will be roles you need embedded from day one. There will be roles you don’t need until you’re iterating a live service.
Technically, a delivery manager, and a product manager are a multidisciplinary team of two. But it’s going to be rare that just the two of them have enough of the specialist knowledge and skills, and the autonomy, to deliver the work on their own.
You might need skills and knowledge from across a dozen disciplines. Before you freak out over the cost of this - we need to stop assuming that people only have the domain knowledge of a single discipline, and that everyone on the team must be working full-time on it. The profile of your team members, the amount of time they spend working on the service - it’ll come down to the needs of the work. Legal, for instance - you can have a legal advisor working in the team - expected to manage their own workload so that they’re available as needed, and to flag potential capacity issues in advance. You don’t need your legal department to commit 100% of a lawyer to the team, just to have them twiddling their thumbs or doing lower value work to stay occupied.
So - you’ve got a team that matches the need. That's not enough though.
They need enough autonomy to move forward at pace. This means empowered by leadership to make decisions - so ideally the team contains people extremely familiar with the user experience, the service, and the challenges within it. This is because we know decisions are best made by those closest to the problems they’re working to address.
But at the same time this active empowerment mustn't carry excessive risks, or else leadership confidence (and so autonomy) will inevitably crumble. Either the work needs to either be tightly scoped to only those things with no consequences for any other services or platforms (which may be an impossible to achieve), OR the team must commit to collaborating at the boundaries of their scope. For instance, there are two teams, each working on a different side of a two-sided platform, it would be absurd for them to not work closely together (no matter how much the delivery managers might prefer the narrower scope). Sure, it adds communication tax, and means working through tensions and trade-offs, but the two pieces of work cannot afford to diverge or undermine each other.
More generally teams need to understand their dependencies. They need to aim for loose couplings, or even decoupled scope. They need to watch for unintended consequences in related products and platforms. And their decisions need to be designed to be reversible - two-way doors, easy roll-backs.
These are just some of the small things hidden inside the concept “multidisciplinary teams” that occur to me on this sunny Sunday afternoon. Multidisciplinary, yes - the necessary skills and knowledge for the task. But also a team that is given enough autonomy and empowerment to get things done - in return for active derisking of those decisions, as well as diligent scope management, and communication, collaboration and likely negotiation at the boundaries.
Are you truly already doing this and still failing to get results? Let me know.
If so, perhaps it's not the teaming that's the problem. I'll cover the other points in successive blog posts