Failureship deliver things instead of value

The failureship deliver things rather than value. The successful delivery of things is normally under the control of the failureship, whereas successful delivery of value is often outside of their control. A common behaviour-plex observed in failure cultures is a tendency towards delivery of things instead of value. The form of the behaviour-plex is as follows:

  1. A senior executive decides they want to develop a strategic solution. To justify building the solution, they create a robust business case declaring the delivery of massive value that will be delivered in several years time.
  2. The investment starts and value is never mentioned again. No one ever goes back and validates that the agreed value is delivered.
  3. As there is no feedback mechanism to validate the value is delivered, completion of the investment is subject to the opinion of senior executives who have a vested interest in declaring success.
Photo by Torsten Dederichs on Unsplash

When an executive or manager instructs a product owner what to build, the product owner has no responsibility for the impact of what is built. They can only act as a delivery manager, and the executive should take full responsibility for any failure to deliver business value.

An alternative variant of this behavior-plex is as follows:

  1. Someone identifies a metric that should be improved. For example “The number of customers defecting to the competition”.
  2. An investment is agreed to improve the metric.
  3. The team perform an analysis and decide that the best solution is to build a “widget”
  4. Based on the analysis presented, the executives agree that building the “widget” is the best solution. The team get an agreement from the executives that the goal is now to build the “widget”.
  5. Value is never mentioned again.
  6. As there is no feedback mechanism to validate the value is delivered, completion of the investment is subject to the opinion of senior executives who have a vested interest in declaring success.

The key point here is that the executive(s) have control over whether an investment is deemed to be a success. This success is normally negotiated several times during the investment, always with a reduction of “scope”. Success for the project manager responsible for delivering the investment is more about managing the relationship with the stakeholders than the actual delivery of value.

When an executive or manager agrees on what the product owner should build, they are taking responsibility for the value delivered.

In order for this behaviour-plex to work, there needs to be a large power distance between the team and the executives so that the decision cannot be challenged. The executive needs to be powerful enough to dictate reality.

The risk managed approach is as follows:

  1. A senior executive decides they want to develop a strategic solution. To justify building the solution, they create a robust business case declaring the delivery of massive dollar value that will be delivered in several years time.
  2. A product owner (team) is assigned to the product. They immediately try to understand the value of the solution to the customer and the business. They establish the metric that will be used to determine the success of the project and agree that with the executives. The metric is one that is either measurable or will be measured as part of the product initiation.
  3. As the original robust business case had a dollar value, the product owner (team) can now agree the initial exchange rate between dollars and the success metrics. The exchange rate or financial impact of the improvement is the responsibility of the executive team.
  4. The product owner (team) now understand the value of moving the metric and can focus on understanding the (internal or external) customer needs to be met in order to move the metric. Responsibility for moving the success metric sits with the product owner (team). They should be completely empowered to ignore the strategic solution suggested by the executive.
  5. The product owner (team) should meet regularly with the executives to reflect on the progress at moving the metric, whether the metric is still the correct metric, and whether moving the metric is having financial impact that the executive team stated it should. Success is about moving the metrics, it is not about implementing a solution. The executives cannot declare success if a solution is implemented but does not move the success metric or achieve the financial goal.

At Skype, Yuval Dvir and his team introduced a formal mechanism where every month the Product Owners would meet with the Product Executives for a formal discussion of their metrics. Every quarter the Product Owners and Executives would discuss the metrics with Mark Gillett, head of Skype. Yuval built a dashboard at Mark’s direction that showed all of the available metrics in a single place.

This process to formally review metrics was separate and distinct from the quarterly capacity planning session that was used to build an organisational (meta) backlog. The discussions in the review process had a significant influence on the discussion in the capacity planning as they were about the same metrics.

When a product owner asks executives if they are building the right thing, the executive can share an opinion but they should make it clear to the product owner that they are still responsibility for moving the metric.

When an executive pushes a product owner to “build a feature”, the product owner should push back if it will not move their metric, or alternatively get the executive to agree a new metric.

Whereas the executive cannot chose the solution that will meet the customer need and move the metric, they should ensure that the solution is coherent with the success metric. It is common for “product owners” to claim their solution will move the success metric simply because they want to build a particular feature. For example, claiming that adding adverts to an app will increase engagement because the organisation wants to focus on engagement rather than revenue. This means the executive should challenge the proposed solution if it is not coherent with the outcome (metric).

Focusing on metrics instead of things pushes responsibility for success to the product owner (team) in a manner aligned with the goals of the organisation. Specifying success as moving the metric allows the product owner (team) to innovate in the way that it is achieved.


About theitriskmanager

Currently an “engineering performance coach” because “transformation” and “Agile” are now toxic. In the past, “Transformation lead”, “Agile Coach”, “Programme Manager”, “Project Manager”, “Business Analyst”, and “Developer”. Did some stuff with the Agile Community. Put the “Given” into “Given-When-Then”. Discovered “Real Options” View all posts by theitriskmanager

2 responses to “Failureship deliver things instead of value

  • El Combe (he / him) (@c_combe)

    I often refer to the point you are making in your point 1 as ‘ego driven architecture’. I am all for senior people pointing out a potential need they see common across multiple customers / markets, but they should not get involved or overly influence the problem / opportunity but instead provide safety for a team to enable safe to fail experiments with a customer based to validate learning and hypothesis rather than building a spaceship when only a bicycle is all that is required to validate the needs in the market.

    Solve a problem, make it work before you build for scale, validation of value is key.

    Determining a solution is strategic before it is validated is tyranny and top-down management to the nth degree. Jabe’s recent talks on commons and how it applies to platforms is great in that regard especially when he talks about recommoning and harvesting (an often overlooked / ignored strategy, to take something that is already providing value to a market and harvesting it for a wider market rather than starting from nothing).

    The platform stuff I’m referring to is at least half way through the video but the context is interesting if you’ve not heard the ‘origin story of commons’.

    • theitriskmanager

      Thank you El Combe

      I’m not sure if its “Ego driven” as “Back scratch driven” as it seems to be common for those executives to get a job with the company producing the product they are hammering into the org. However, completely agree with your statement.

      Thank you for the link to the video. Very interesting and informative. The “Network of Value Streams” problem that Jabe describes is the one we solved at Skype and several other organisations using capacity planning.

      Many thanks again

      Regards

      Chris

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: