Skip to content

November 9, 2021

Pathways to Success: A Playbook for Aligning Technology & Business (Part 3)

By IT Revolution

This series of posts is adapted from the DevOps Enterprise Forum guidance paper Winning Together: A Playbook for Aligning Technology & Business by Dominica DeGrandis, Ana E. Torres, Elisabeth Hendrickson, Levi Geinert, and Jeffrey Fredrick.


Carve Out Capacity for You and Your Team and Get Started

What are technology leaders supposed to do when business leaders don’t consider Technology as their partners? While there are many ways to address the issue, one of the best solutions is to measure the value you’re delivering, review your learnings, and repeat. In this section, we’ll cover the common objections you’ll hear from business leaders and how to respond to them, plus the ways in which technology and business leaders alike can use Objectives and Key Results (OKRs) to develop a healthier, more resilient partnership.

Measure the Value

When business leaders prioritize in a vacuum, they neglect to ask for and include input from engineering leaders. The impact can range from mild to severe. Let’s look at this story as an example: The VP of Sales thinks features take too long, so she promises a major customer that a big feature can be built and delivered in three months. The follow-up pandemonium results in delays to other features in progress, which causes other business leaders to complain that “things take too long.” Sigh. The cycle continues—and another project spirals out of control.

 

When people complain that things take too long, technology leaders should be positioned to demonstrate just how long things actually take to do in a way that others can see.

In the above example, the VP of Sales says that things take too long, which is a common objection. One way to respond is to look at how long features actually take from start to finish.  This measure of speed is known as Flow Time, which is one of five key metrics for measuring business value (see Table 1). Other objections that you might encounter are listed in Table 1, along with suggested responses and  useful metrics to use when building your argument.

Table 1: Prepare for Objections with Key Metrics

Objection

Response

Key Metric

“Things take too long.”

“Here’s how long features actually take to do.”

Flow time: measures speed. Clock starts when work begins and ends when the customer can consume the value.

“Not enough features get
delivered.”

“The capacity of the teams is
often less than the demand. Teams are constrained by conflicting
priorities.”

Flow Velocity: measures
throughput—the number of items completed over a period of time. This is useful for gauging capacity.

“We should just outsource this
to vendors.”

“Outsourcing this work will likely insert more dependencies into
the workflow, which impacts efficiency due to back-and-forth communication delays.”

Flow Efficiency: the ratio of
wait time vs. active time. Prompts the reasonable question, “Do we need more wait states in our toolset to accurately reflect all the wait time in the value stream?”

“We need features to be
delivered, but you just want to refactor architecture.”

“We need to change the oil in
the car every now and then.
Otherwise we won’t have a
car to drive.”

Flow Distribution: the distribution of different work item types. Ex., 30% features, 60% defects,
10% debt.

“We are at risk of not
completing all the initiatives on this year’s roadmap.”

“Attempting to do too many things at once results in lower quality and slower delivery.
It’s why Steve Jobs killed many great ideas at Apple, so they could do fewer things really well.”

Flow Load: the amount of work started but not yet finished. Lots
of partially completed work-in-progress (WIP) is expensive.

It may seem as though conversations like these are adversarial. However, we suggest a reframe: they are essential partnership building discussions. Every good objection has a worthwhile objective to consider. As Dale Emery said in his post “Resistance as a Resource”: “Sometimes, as I work to understand the other person, the two of us end up at a third point of view, different from where either of us started, and we both change in ways we hadn’t expected.” Consider different perspectives as feedback to move into a shared path forward.

Listen to stakeholders to learn more about real business problems and then work to make them visible. When others can see the problems, the necessary conversations can happen. Use the problems voiced as a bridge to dialogue between objections and solutions. Let curiosity govern your collaboration. Common objectives and key metrics are a workable solution to the problems identified.

Meeting business objectives requires an understanding of business outcomes—to see if the objectives are met. One way technology leaders can address what matters to stakeholders is through the skillful use of business Objectives & Key Results (OKRs). As we mentioned earlier, it’s best to think of OKRs as three to five goals with measurable results of value.

In this insurance company example presented by Mik Kersten at his keynote at DevOps Enterprise Summit-Virtual Europe 2021 and in Figure 2 above, the goal of the value stream is to make products that customers love. There’s a lot of competition from insurance organizations, so a 20% improvement in NPS (net promoter scores) was a key part of hitting the objective set by the value streams responsible for producing mobile and web experiences.

The focus was to deliver features that improved customers’ authentication experiences—making sure they could make it through the entire provision process quickly and with some fun.  It turned out that the bottleneck was in verification. Good automation of feature delivery was in place, but much of the wait time came from waiting on business decisions and approvals at meetings. So the team targeted a zero days wait state on business input for shipping features. Once that happened, flow time was cut dramatically. In Figure 2, we can see flow time go down from approximately thirty days to averaging under ten days. From that flow-time reduction, we see the net promoter score rise. This helped the company meet another objective to cut time to provision policies in half.

To truly partner, business and technology leaders should establish a regular monthly cadence of executive or steering committee reviews to look at business outcomes based on key flow metrics. Measure flow of value and surface bottlenecks. Including Flow Metrics in your key results helps to connect the Business with Technology.

Pathways to Success for Measuring Business Value

Build credibility by demonstrating the capability to improve predictability with respect to capacity and speed. By surfacing insights from Flow Metrics to business and technology leaders to get everyone on the same page, everyone can see that the capacity results from data-driven decision-making instead of from opinions.

It is important to frame arguments for change based on benefits for business results. For example, experiments show that reducing WIP (Flow Load) improves both speed and throughput. When there’s fewer balls to juggle, teams can focus more of their cognitive load on solving complicated problems.

Ensure capacity is allocated for improvements and that a culture of experimentation is set up. Conditions for success include allocating time to learn and time to investigate and measure results—capacity to do this helps teams deliver business value quickly—during regular business hours, especially in organizations where psychological safety is supported.

Measure the flow of business value versus activities. Just because people are busy doesn’t mean value is being delivered. Instead of measuring busyness, measure the end-to-end flow of value across your value stream(s). Measure the work, not the people.

Conclusion

Achieving a productive partnership between business and technology is a great accomplishment. The outcome isn’t just better value for customers, it is much more fun! Once you’ve had this kind of collaborative relationship you won’t want to go back.

Are you willing to do the work to establish a better relationship? Remember, it isn’t easy because changing our relationships must start with changing ourselves. The good news is, that means the first step to a better relationship is under our control.

Start by setting the stage for partnership. Do you understand the world as your business partner sees it? This is something you can test as you search for the wonderful response of, “That’s right.”

Having built some trust based on understanding, jointly frame and prioritize your transformation opportunities. Trying to define the entire roadmap isn’t working in the spirit of partnership; we’ve provided steps you can take to come to a win-win agreement on where to focus.

After jointly deciding where to focus, your partnership is ready to co-author your desired definition of AWESOME. This process of creating a joint vision for the future can be fun, and will provide the “North Star” by which future improvements will steer, step-by-step. Incremental improvement creates a momentum for change, which is why you should focus on the next big step over the big-bang approach.

A compelling vision and a clear next big step makes it easier to carve out capacity for teams to get started. This isn’t something that can be done in isolation, and the spirit of partnership with the Business is still needed to get the capacity to start. Once started, be sure to measure business value and learnings. This evidence will help keep the virtuous cycle going, and demonstrate to others the great things that can happen when the Business and Technology work to find common ground.

- About The Authors
Avatar photo

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT on Social Media

1 Comment

  • anaplan training Mar 7, 2022 10:00 am

    The blog is very well written with logical information. It's a really beautiful and amazing blog post! Thanks for sharing

Leave a Comment

Your email address will not be published.



Jump to Section

    More Like This

    Map Camp: Weird Mapping – How to Create a Revolution
    By David Anderson

    A version of this post was originally published at TheServerlessEdge.com. Dave Anderson, author of…

    Serverless Myths
    By David Anderson , Michael O’Reilly , Mark McCann

    The term “serverless myths” could also be “modern cloud myths.” The myths highlighted here…

    What is the Modern Cloud/Serverless?
    By David Anderson , Michael O’Reilly , Mark McCann

    What is the Modern Cloud? What is Serverless? This post, adapted from The Value…

    Using Wardley Mapping with the Value Flywheel
    By David Anderson , Michael O’Reilly , Mark McCann

    Now that we have our flywheel turning (see our posts What is the Value…