Building a High Performance Delivery Engine

Building a high performance delivery engine in your organization is super hard. We need to have expertise within our teams, within various contexts, and I think we mostly underestimate the level of competence that’s required for the people participating in the software delivery process to build those high performing teams. A high performing delivery engine to get stuff out the door. We need not only competence in the technical tasks—that’s usually what most organizations focus on—but we also need competence within the context of business, right? Business and business need, and how business works, and what business wants.

Every member of the team should be a product developer. Well, every member—you’re going to have some extremely unusual technical people who probably just want to focus on the technical side, but you want to have at least a high enough number of product developers rather than just software developers on your team. What I mean by that is that they’re focused on product and delivering a successful product, which includes many different things, right? You don’t just magically deliver a successful product. You need to focus on the right technologies. Do we have the right technical skills to be able to deliver this product? Do we understand the business need? Do we have the right hypothesis to be able to test our product within the market? Have we got the right market fit? Do we need to change the way we do things? This is every member of the team, as much as possible, thinking about these things as they’re building the product, as they’re developing features.

And then you also need a keen understanding of the philosophies and theories behind these things. We’re talking about Agile, we’re talking about DevOps, we’re talking about Lean, talking about Scrum, right? And mixing a few things in there. But we need to understand the core philosophies, theories, and practices that underpin these things so that we can apply them in a way that adds value to our organization, right? Because we’re trying to deliver. We’re trying to create a high performing delivery engine. We’re trying to deliver lots of stuff and lots of the right stuff, or as much of the right stuff as we can. And for that, we need to be able to leverage the right emergent practices, right? The evolution of our practices over the life of the product lifecycle and how we pick the best stuff.

And to do that, the people doing the work, the people managing the work, the people overseeing the work, all need to be practitioners, right? They need to be playing at the practitioner level to understand how those things influence it. I usually—the analogy I usually use is if you’re renovating your house and you want to remove a wall, right? So we want to change the way we fundamentally do something and see whether it makes sense. Can we just knock down that wall? Well, no, we should probably do a little bit of due diligence. We should probably understand the structural integrity of the context. We should probably understand whether it’s a good idea to remove the wall or is it a bad idea? And if it’s a bad idea, is there something we can do to mitigate it so we can do it? Because we want to do it right.

And you can absolutely remove any wall in your house, any wall in your house, with due diligence to the structural integrity of the building. The same is true when you’re changing your business, when you’re changing your team structure, when you’re changing your system of doing work. You need to have the competence in your high performing delivery engine to build it in a way that enables you to maximize the value delivery to your stakeholders.