Layers of delivery of (product) work
In Networked, Scaled, and Agile: a design strategy for complex organizations, by Kates, Kesler & Dimartino, there’s an insightful concept of the vertical organization with a few layers of leadership work (see picture below). It helps to drive clarity about the different roles and their responsibilities when it comes to design and help organization to deliver embracing the inherent complexity of organizations (networks, scale, the ambition to become more agile).
I also like to think of the time horizons which are presented along with each of the layers of leadership work as a hint on what kind of cadences are to be in place catering for those different levels and need for focus. To put in other words, the operating layer is all about “now” and what we are trying to achieve with our current choices in the constraint of current strategy, while the integrative layer is largely preparing the system for the “next” (what we might have to try out, who has to collaborate with who and how).
We can debate about the horizons being somewhat too long, in the current influx world we live in, but that kind of misses the point. It may not only be contextual, it also depends on the frame those are being taken into perspective. I look at the suggested horizons there as also giving your current strategy enough time to bear fruit, without implying you are not iterating, learning and adapting mindfully, while still sticking to the given guardrails from the top. The integrative layer therefore can be seen as the mechanism to make it easer to operate under the given guardrails and make sure the right conversations are held to better integrate things when needed.
The authors make a claim, which I can totally relate to and corroborate with my experience, that the integrative layer is often overlooked in organizations (despite being so powerful when well designed). They state – “when harnessed purposefully, this is the layer that makes the complex machinery of the organization work effectively”.
In my experience, when that’s not done well enough, there’s essentially a blurry of the operational and integrative layer, where leaders just expect the former to sort things out – after all, “they are empowered" (would be some of the buzz words phrases you could hear in that context). That brings me nicely to the core point of today…
Recently I have engaged in a couple of different conversations on LinkedIn around cadences and related misconceptions. It mostly came about on a insight on the utility (or not) of six weeks “sprints” (used here as synonym of a cadence to deliver work related to software development). The interesting part was that you could almost see the sort of biases coming to play. Generally speakingm there were essentially two groups, one of people coming more from a technical background (hand-on software development) and another more from a product background.
Essentially, as a pattern, the software folks argued against it, after all we can do way better than that these days (technicaly speaking). And indeed we’ve come a long way to be possible to deploy software in a matter of seconds, or at least make sure at least once a day all the code is merged, and stuff like that. Product folks though would point out that wasn’t quite the point, and that a six weeks window is a fair amount of time to deliver something meaningful (whatever that might mean in context) to customers, get them start using it, and hopefully even get some (early) feedback.
In my mind, the whole thing was a clear examples of “two things that can be true at the same time”. Yes, we can and should do way better these days, we have all the techniques, tooling and practices in place to do so. That helps to reduce risks related to merging code, and other technical aspects. It also helps to enforce breaking things down and thus reduce risk of delivery overall. But not all code we deploy each day will have a noticeable impact on customers, thus from a product standpoint is not quite yet as useful.
By reflecting on all of it, I eventually realized what I believe the “confusion” (for a lack of better world) may come from… And how that relates to the concept introduced in the beginning, as a kind of parallel, slightly extrapolated point. Because in the end, I believe the whole criticism from the software folks comes from the possible blurring of “sprints” (or whatever you call some kind of operational cadence overall) implying both, not only the cadence in which we expect to build something meaningful from a product standpoint, but also as by when we expect code to be merged, and all those beautiful technical stuff.
And let’s be clear on this – that often is the way in which "sprints” are used in practice. It can actually be worse and the "definition of done” is a code that at best has been merged to some pre-production stage, and we will deal with putting things to production at some point in future. It doesn’t have to be that way, though.
That’s where I believe it may be useful to articulate, similar to the layers of leadership work, a concept of layers of delivery of (product) work:
Hence, it’s cadences – plural. And it’s important to realize that and intentionally separate them up. The blurring is where things can too easily, in my opinion, risk to derail, and with that alow for much more inbreading of risk, across the board.
Hopefully this also contributes to shed some light and drive some clarity on related discussions. I will be the first one to advocate that we should aim at being neither “hot” or “cold”. It’s important to have a clear opinion and state that. Reality is that sometimes things are nuanced, and it largely depends on what frame we are taking.
Maybe that’s useful to think about while sticking to the premise of having clear stands, being either “hot” or “cold” – but do it in the context of the specific situation and understanding from which perspective we are debating about… For software delivery layer, by all means criticize cadences that imply, for example accumulating too much liability (like not making sure to merge code to the base at least once a day). By all means do that for a product delivery layer that is not taking a pause every now and then to check where we are (e.g., are the current bets paying off well enough?) and where we want to go next (e.g.,, continue down the same route and need to pivot?) – as opposed to grind your way through after some priorities were set, say, for a whole year.
By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.
Regarding the three layers of leadership, I think most companies have already adapted to this structure: C-level, Product Management (with some naming variations), and the (tactical) Product Owner. While this is a good idea, I’ve noticed that companies tend to implement it too rigidly. The problem with such strict layering—especially at the operational level—is that the role often gets minimized and excluded from strategic decision-making. This, in turn, might create decision blockers and ultimately breaks the company's agility (contrary to what the authors intended).
I’ve encountered the same kind of confusion in practice, as you mentioned—where software released to production is seen as the product release. This is one of the reasons why ideas have emerged to make sprint lengths more flexible (treat the symptom, not the cause).
Beyond this, I’ve noticed another important point in the corporate world that adds context. Releasing something into production that isn’t a fully working feature (or product) is often seen as an additional risk by product teams. When we try to mitigate these risks with specific measures—such as feature flags, hidden links, or silent releases—it can introduce additional development costs that may not make sense from a business perspective. On top of that, since we still have a lot to learn about properly sizing and defining PBIs, the distinction between software and product releases becomes even blurrier.
In the end, the solution is to find the right balance and avoid drawing rigid lines of accountability. This is one of the best aspects of Scrum—the team decides, and within that team, both product and development work together.
Of course, some changes happen under the hood, with no visible or meaningful impact on end users. These typically fall into a different category, where there’s little debate about whether they should be released as often as possible.
Just my perspective—from the eyes of a product person—so it might be a little biased. 🙂