Outcome Centricity: The next frontier for agile organizations (Part XIV)

Note: This is Part XIV of the series on Outcome Centricity, focusing on end-to-end responsibility. You'll find the first part of the series here, the second part here, the third part here, the fourth part here, the fifth part here, the sixth part here, the seventh part here, the eigth part here, the ninth part here, the tenth part here, the eleventh part here, the twelth part here and the thirteenth part here.

I have written about end-to-end (E2E) responsibility in the past (cf. this article) but not yet explicitly in the context of outcome centricity. To be honest, that's actually somewhat surprising because the idea of end-to-end responsibility is deeply intertwined with outcome-centric thinking. After all, shifting from "outputs to outcomes" typically means precisely that: Widening the span of responsibility from a "delivery only" to a "delivery and impact" focus.

Now let's getter better grip on what this actually means by looking at some typical cases of responsibility gaps, which I'm sure you're all too familiar with:

• Exclusive focus on delivery responsibility: Engineering is responsible for delivery success of, say, a CRM suite but not for sales folks actually using the service (i.e. responsibility for outputs only but not for customer outcomes).
• Exclusive focus on delivery & customer success responsibility: Engineering and UX/UI are responsible for delivering a working CRM software, including delivering meaningful features and an intuitive and easy-to-use frontend, but don't feel responsible for the overall commercial case (e.g. streamlined sales processes).
• Exclusive focus on commercial success: Alas, it also works the other way round - top management is responsible for achieving certain business outcomes but isn't responsible (or doesn't feel that way) for delivering the relevant prerequisites to achieve just this success, i.e. relevant outputs and meaningful customer outcomes ("that's the team's job").

Reversely, true end-to-end responsibility in outcome-centric organizations spans the entire value creation chain from outputs to customer outcomes to business outcomes (cf. the illustration below).

You want to design your organization and your teams in a way which achieves just that. "Slice them horizontally," I typically tell our clients. In this sense, I invite you to use the formula to gauge to what extend you're setup for success from an E2E value creation perspective. To be more precise, if you just take your key teams or units in your organization and simply run through the three responsibility options above, this should give you a quick'n & dirty idea of where you stand in terms of E2E responsibility.

By the way, it's becoming common practice to ensure E2E responsibility for, say, a given agile unit such as a Tribe or a Value Stream, by creating leadership teams with three different "hats": An Engineering Lead, a Product Manager (or something of the sorts) and an Agile Coach/RTE. The basic idea is for the Engineering Lead to cover the output or delivery perspective, the Product Manager to cover the customer perspective, and the Coach to cover the internal process perspective.

To be sure, this is a good start. The business outcome perspective, however, is typically missing, not as explicit or even resides outsides the agile unit in the form of one or more "Business Owner." That's more than unfortunate because it limits the power of these agile units. Or to put it more bluntly: Why doesn't finance and controlling get a seat at the agile leadership table?

Now one last thing: I've talked a lot about "being" responsible. But what does that actually mean? It's important here to distinguish two ways you can "be" responsible for something: Either you're responsible in the sense that someone's officially assigned this responsibility to you (let's call this "assigned responsibility") or you're responsible in the sense that you feel responsible for something (let's call this "felt responsibility"). This is another topic altogether but I do want to point out two important aspects here:

• On the "assigned responsibility" side, you want what Amazon calls the "single threaded leader" (STL) where the bucks stops.
• On the "felt responsibility" side, what you typically want (and this is somewhat controversial) is for your staff to feel responsible for more things than they are actually responsible for. Because more often than not, the reverse is actually true. I would even venture to say that this is probably one of the landmarks of vibrant cultures, intrapreneurship and ultimately great companies. You need just this little bit of redundancy when it comes to responsibility because this creates the necessary resilience (which is exactly what you need in times such as these). I typically recommend that your staff's "felt responsibility" should exceed their "assigned responsibility" by 20-30%. (By the way, this goes very much against how most people actually design teams and organizations, as they typically strive for clarity, not redundancy.)

As always, I'd love to hear your thoughts and feedback! And thanks Robin for your help with this article.