Why delivery management doesn't happen by accident
At Hyperact, we frame our teams and our proposition as a whole around three pillars: product, design, and engineering.
The paradox is that we know it isn’t just these three things—the three pillars are a simplified distillation of the essence of product development—and there are a dozen other competencies that you need at different points in different shapes and sizes to create and grow great products. Probably more than a dozen.
I wrote about this in my core roles article, and we touched on it when describing our overall approach and, in particular, the breadth of competencies our product, design, and engineering practitioners cover.
One of these competencies, and perhaps the most cross-cutting and fundamental, is delivery management.
In this article, I explain what delivery management means to me, why it is critical, and why it doesn’t happen by accident. I’ll also touch on what delivery management is not.
What is delivery management?
The term itself is heavily overloaded, but to my mind, four core areas of focus come under this big, old umbrella:
- Enablement
- Flow optimisation
- Focus
- Continuous improvement
So four more amorphous, heavily burdened terms, that I’ll try and unpack in turn.
Enablement
At its very essence, this means ensuring that the team has the best possible conditions for success. It is incredibly wide-reaching, and I’ve provided some real-world examples of what I mean by this below:
- Tooling - the team has the hardware, infrastructure, software, and anything that they need to enable them to do what they need to do
- Onboarding - anyone joining the team has a springboard from which to leap. This could be a one-pager. It could be A checklist. It could be a series of sessions. It could be a Hyperact team canvas
- Offboarding - often an afterthought, but a clean break is important for many reasons
- Knowledge bases - constantly striving to get critical knowledge out of heads, particularly those things in only in the one head
- Wider context - delivery managers often have many touch points across product development, if not the wider org, and therefore can often shine a light on the bigger picture and bring context to proceedings
- Clear lines of communication - not only do they tend to have an appreciation of the world beyond the edges of their team, but they also care and focus on how the team communicates internally
- A clear direction of travel - perhaps as much a product thing as it is a delivery thing
- A clear understanding of one another (e.g. team principles, manual of me) - this might be as simple as ensuring the team enjoys a game of Geoguessr together once a week
- Team health - last but not least, ensuring that the human element of what we do is taken into account
Flow optimisation
The journey from initial conception to finally landing in the hands of users is rarely simple. Every single team I’ve worked on has struggled with flow in one form or another. This is regularly an after-thought and rarely gets the attention that it truly deserves, as the bar here is so often low.
In practice, this can involve things like:
- Breaking down work into deliverable chunks
- Visualising work in progress
- Ruthlessly focusing on value realisation
- Minimising hand-offs
- Pairing, mobbing, and swarming
- Limiting work in progress
- Understanding state definitions (e.g. ready, done)
- Understanding roles and responsibilities
- Release management
- Embracing pragmatism
- Managing dependencies
- Coordinating cross-team efforts
- Sizing and planning (if and when called for)
Focus
This undoubtedly crosses over with the previous two, but still warrants a callout in my view. It usually comes in two flavours:
- The big picture
- The finer details
The big picture
The main thing here is to have that clear direction of travel mentioned above in place and to ensure that the team treats it as their North Star. Each and every activity that the team undertakes should move them in that direction. Everybody is empowered and encouraged to challenge if they feel that this is not the case. There will always be exceptions, but the initial setting and then resetting of this general direction is a powerful thing.
The finer details
I rarely write an article without mentioning story mapping, but it’s a cracking example of how to set and align focus on an item-by-item basis. And this can apply to everything the team works on - not just capabilities that they are looking to add to a product.
There are three things that you need here:
- Context - a definition of what is in and out of scope. Some boundaries that will ground the team. That we can always come back to when we inevitably meander or get lost in a wormhole. This could be a story map. It could be an “out of scope” list. It could be the mechanics of how you work together - such as ensuring each new “thing” has a dedicated point of departure where context is established.
- Discipline - possibly the hardest part is speaking up. Striving for self-awareness to stop yourself from getting carried away with something that matters to you but isn’t the thing that needs to be moved forward. To challenge others.
- Empowerment - everybody has to feel comfortable calling out things that can be parked and deferred. Without this, it can be incredibly difficult if the challenges and constant refocusing are driven by one or only a few team members.
In reality, this could be splitting out a problem into four sub-problems and acknowledging that you will only consider the first of the four. It could be taking a step back when you’re 90% there with a new feature and making a pragmatic call to defer that last gnarly challenge and ship what you’ve built so far to deliver the value early. It could be blocking out regular time to ensure your dependencies are all updated to their latest versions. Or it could be as simple as calling time-out on a lengthy discussion in a retro and taking an action to line up a dedicated follow-up conversation.
Continuous improvement
Iteration is the cornerstone of product development. We integrate and deliver continuously. We set, assess, and reset our objectives religiously. Yet we don’t apply this to the way we work.
It’s hard to do this. It takes discipline, energy, focus, headspace, and bandwidth, and it’s often one of the first things that slips when things get sticky, or as the team shape and personnel evolves.
Nothing beats blocking out time as a starter for ten: the humble retro.
The delivery lead role
Our default position is for delivery management to be owned and driven by the team itself, but we’ve already brought dedicated delivery specialists—typically titled delivery lead—into some of our initial engagements where we’ve identified that one or more teams would benefit from a helping hand.
I’ve seen firsthand that teams can be incredibly healthy and successful without a specific delivery role. That said, 56% of teams I’ve worked in throughout my career have had a dedicated delivery specialist and I know the considerable value that they can add.
When does a dedicated delivery lead make sense?
The more constraints a team is under, the stronger the case for a dedicated delivery specialist. Where there are hard deadlines, lots of dependencies—particularly challenging ones such as third-party suppliers who have proved unreliable in the past—or perceived problems with morale, productivity, or comms.
What does a dedicated delivery lead do?
They tend to be very T-shaped, with an appreciation of the different specialisms within product development as well as the wider context in which product teams usually operate.
They also tend to be able to tailor their approach depending on the team and the specific issues faced, which will sometimes be pure facilitation, and at other times be showing by doing.
Ultimately, they shine a light on those four key areas—enablement, focus, flow optimisation, and continuous improvement—and put a platform in place to ensure that they continue to get the attention they need as the team develops.
In practice, this can involve:
- Coordinating and facilitating dedicated sessions around key team artefacts, such as team principles, or ways of working
- Assessing and reassessing team health, maturity, and performance
- Leading the conversation in those exceptional circumstances when high-integrity commitments are required
- Coaching the team
What delivery management isn’t
There’s an anti-pattern here worth mentioning. One that I’ve witnessed many times, and that tends to do more harm than good—failing to improve problems (or perceived problems) whilst wasting time and energy, depleting team morale and health along the way. It’s often imposed on teams by leaders in the name of improved productivity, visibility, or predictability.
This tends to manifest in:
- Output-related measurements being implemented and monitored - such as velocity
- Template ways of working and tooling imposed on teams
- Reduced focus on team empowerment
- Increased reporting
- More and more time planning and estimating
- Teams being locked into building out lengthy roadmaps
A lot of the time, this Trojan horse arrives under the guise of delivery management, and as you can probably tell, is not something I advocate or approve of.
In summary
If there was a fourth pillar on which great products are built, it would unquestionably be delivery management. It’s at the heart of the very best teams I’ve worked with, and something I warmly encourage all practitioners to get closer to, whether that’s utilising some of the tools and techniques above within your teams, upping your own delivery management game, or looking for a delivery specialist of your own to give your teams a helping hand.
