Like companies producing any kind of offering, software companies require three elements in order to successfully deliver: knowing what to build, knowing how to build it, and knowing how to deliver it to the customer. When each of these three functions – research, engineering, and delivery – does its job independently, you get slow progress and uninspired, sub-par products. But when all three functions work together in a customer-centric fashion, you get excellence – in implementation, innovation – in concept, and world-class results – by delivering those two to the customer.
With the explosion of internet-based services in the past decade delivery has by necessity become an ongoing activity. And so in recent years much attention has been devoted to integrating development with technical operations – DevOps. DevOps integrates into a single team the skills of how to build the service and the skills of how to deliver it. But, as pointed out earlier, DevOps teams often lack the most critical element: the customer’s involvement. DevOps teams can build and deliver really fast, but don’t know what to build.
Integrating development with the customer-facing functions (marketing, sales, etc.) without technical operations results in an organization that knows what to build and how to build it, but doesn’t know how to deliver it to the customer. This organization is full of ideas – even innovative ideas – and implements them, but they don’t see the light of day. I call this a “feasibility practice” – it can show you what is feasible but it can’t deliver it to customers.
Teams that know what to build and how to deliver it to the customer, but not how to build it, also do not provide value to the customer. Such teams are close to the customer both on the inbound (understanding the customer’s needs) and the outbound (explaining the company’s offering) directions. Marketing sits squarely in this space: it knows what to build and how to deliver but can’t transform that knowledge into value for the customer.
As an executive leading a software delivery effort, make sure your organization occupies the very center so it can understand, build, and deliver the right value to the customer. The customer is here in the center as well: he participates in validating the ideas, critiquing the implementation, and accepting the delivery. It is only here that your organization can achieve excellence, innovation, and world-class results.
3 replies on “Software Delivery Operations”
In general I really like where you’re going. We need to have a more holistic understanding of software services as…well…services.
Some basic questions for you:
1. Where is design?
2. Why are Support and Finance completely in the “What to build” circle and not part of the overlap with “operations”? From a service delivery perspective, responding to customer problems, and billing the customer both seem like aspects of operating the service.
@Jeff Sussna,
Design is “how to build it”. It’s only successful if it is informed by “what to build”.
Support helps deliver, yes. But when viewed as part of the “how to deliver” competency, the needs of the support function (and finance for that matter) are often ignored: suport (and finance) needs features in the product in order to do its job. These features are part of “what to build”.
Regard your support and finance functions as customers of your service – then they’ll be able to help deliver it.
[…] all processes as elements in a single value stream: service delivery. With all component activities in the delivery process focused on this result, collaboration and […]