Business and Technology Synchronicity: The Seven Domains of Transformation

This is part of our Seven Domains of Transformation series, which has been adapted from the Project to Product Transformation white paper by Ross Clanton, Amy Walters, Jason Zubrick, Pat Birkeland, Mik Kersten, Alan Nance, and Anders Wallgren. You can download and read the white paper in its entirety here.

Why Is Business and Technology Synchronicity Important?

So, how can enterprises establish a product management capability with product managers who understand business/technology alignment?

The evolution of project-based delivery to product-centric value streams intends to create a frictionless flow from business architecture through product development to valuable outcomes. This fundamental change in an organization’s workflow focuses on the orchestration of integrated value creation as opposed to a relay race of handoffs toward value.

A significant outcome that enterprises are trying to achieve by moving to a product-centric model is to prioritize their customer. Focusing on products rather than projects enables enterprises to better orient their teams around customer outcomes.

Further, by basing the engineering organizations within IT on the same model, the product can be seamlessly exchanged between parallel engineering and product organization teams. This type of structure allows enterprises to optimize for speed and agility by significantly reducing the waste and handoffs that typically exist in traditional operating models.

What Is Business and Technology Synchronicity?

The business and technology synchronicity domain addresses the enterprise’s structure and the engagement models needed across technology and business teams during the shift to a product-centric operating model. This is the structural change that makes business digital transformation possible. (The primary organizing construct that companies typically follow to drive their product alignment will be discussed in a later post.)

Not only do we need to look at the structure of the teams, but also how work is organized, prioritized, and delivered across the organization.

It is not simply a software development life cycle but a product life cycle. We will explore the roles between the business product organization and its IT counterpart as they relate to intake, prioritize, and the delivery of the product.

A key outcome of this domain is to create an environment in which business and technology leadership fully engage in product development together.

How Are Enterprises Achieving Success?

We found 7 areas in which enterprises are achieving success within this domain:

1. Pivot from Project to Product
2. Prioritization
3. Network-Based Organization
4. Business and Technology Work as One
5. Shift Discovery and Delivery Models from Outputs to Outcomes
6. DevOps Practices in Place
7. Incorporate Product Discovery

1) Pivot from Project to Product

At the core of the change to the operating model is the idea that organizations need to pivot from a model where they optimize for cost and efficiency to one where they optimize for speed and agility.

Traditionally, since most enterprises optimized for cost and efficiency, they created disparate teams centered on individual aspects of the production cycle, such as analysis, development, operations, and quality assurance. The philosophy around the traditional model was that each team could optimize their efficiency.

Ironically, scaling this model across enterprises led to significant inefficiencies, not because each team wasn’t efficient with the localized process for their function, but because it was highly inefficient to manage the work end to end across the entire software delivery value stream. As a result, waste built up in the technology delivery processes and, at an aggregate level, the costs of technology increased.

Leading enterprises have completely flipped this traditional model from one where teams are organized around functions and outputs to a model where teams are now organized cross-functionally around customer outcomes.

Introducing this change into an enterprise is extremely difficult. For many companies that we interviewed, these changes largely started in their technology organizations, as they were treating these transformations as a technology strategy.

However, the organizations that were able to deliberately tie this transformation to their overall business strategy and treat it as a joint business and technology transformation saw the most success. Additionally, leading enterprises were more data-focused and made their progress and challenges visible and transparent. This helped align business and technology, as previously technology delivery was often viewed as a “black box” by their business counterparts.

2) Prioritization

Prioritization changes significantly in a product-centric operating model. The project-based model typically results in businesses defining their requirements up front, often at the beginning of the year before the project is even funded. Then the engineering organizations look at all the requirements for the entire project and estimate the level of effort needed to fulfill them. The estimation then sets what the funding needs are, and the project gets funded if it appears to have a positive ROI (return on investment).

There are many well-documented concerns with this process. Many of the requirements aren’t typically needed, it is nearly impossible to accurately estimate what it will take to deliver them, and the customer is missing from this equation entirely. In fact, the first time the customer gets exposed to what is being delivered is typically many months later (or even years), which is a significant anti-pattern in a product-centric model.

Even though this isn’t an ideal method of prioritization, it is relatively entrenched in most enterprises. When in the incubation stage, most of the early teams try to operate within the existing model. This means they set up a separate prioritization model for their team, but they must do extra work to integrate it back into the model dictated by the Project Management Office (PMO). While this isn’t ideal, this technique is often leveraged by teams just getting started.

As enterprises hit their scaling stage, they begin to introduce leaner prioritization models where they pull key product stakeholders together on a relatively frequent cadence to discuss priorities and dependencies. Then, the respective leaders for the different products commit to delivery for the upcoming iterations. This is a huge improvement from the use of a single session of planning and prioritization at the beginning of projects.

From a strategic planning perspective, leading enterprises typically move to a quarterly product planning model (or twice annually). This is not the heavy-weight program increment planning that many of the companies who have implemented Scaled Agile Framework encounter, but a lighter-weight model that is focused on getting product owners to commit to their quarterly OKRs, which should tie to the funding model (which will be discussed in the next section).

As these enterprises further advance into an optimized state, the quarterly product-planning routine evolves into self-organizing product networks with other product teams that have interdependencies. This exercise becomes a joint planning session to work through interdependencies and conflicting priorities.

3) Network-Based Organization

In fact, one key sign of success in optimized organizations is that they have pivoted from a hierarchical organization to a network-based organization of small teams who are able to collaborate horizontally without layers of management telling everyone what to do.

The product owners are empowered to connect with other product owners to align their product objectives with their value stream priorities and/or dependencies. The product owner teams then determine the level of frequency that they should connect to synchronize product roadmaps and OKRs, manage dependencies, and remove blockers for their respective teams.

Product owners also start to become a more authoritative source on priorities instead of just a proxy representing many different business stakeholder interests.

With this shift, organizations take on a “you build it, you run it” philosophy. This can be incredibly difficult as there are typically leaders for these different functions, and this progressive model defies what many believe is conventional wisdom for operating a technology organization.

In the incubation stage, teams should be structured around the product organically. The teams aren’t yet at a point where they need a more formalized organizing construct. To ensure the highest possibility of success, these early teams need to be organized full-stack and full-life cycle so the organization can apply the product-based model on a small scale before pivoting the whole enterprise. We will describe these full-stack team structures further in the workforce and talent domain in a later post.

To read more articles like this one, sign up for the IT Revolution Newsletter here.

In these early stages, teams are often matrixed into a model where they still have formal reporting relationships following the traditional functional model. These early teams may still be relatively technology-centric as well, especially if the transformation started within the technology organization. In these cases, the product owner may come from IT. Generally, though, business management should be involved in this change as well.

4) Business and Technology Work as One

As the transformation begins to grow and scale across the organization, it is imperative to have business and technology working together. At this stage, begin to reorganize your teams around customer-centric product outcomes. You will need to align an organizing construct, such as business capabilities, which we will discuss further in the product taxonomy domain.

Most companies start to align their technology organization to how the business product organizations are structured. The business and technology executives work closely to align how they are leading their respective organizations.

It is also an advantage when colocation of people is feasible. When teams sit together it can create a similar experience for different business and product groups. In specific cases we found that when most people were colocated geographically within a single business, complexity was limited.

For the most optimized enterprises, the product and engineering teams start to operate as though they are one organization. Product decisions happen at the team level. In some cases these teams physically meet to discuss their processes.

In one example, the CTO of an organization we interviewed had reorganized all of the product management competency into the technology organization.

At a minimum, aligning the product teams on a common set of OKRs can be a key tactic to get them working as one team.

5) Shift Discovery and Delivery Models from Outputs to Outcomes

As companies go through this transformation, most introduce the concept of Lean value streams into their organization. Value stream mapping provides visibility into the overall product ecosystem. This also starts to orient teams to focus on the delivery of outcomes, and it provides a great structure to measure and continuously improve your delivery process to achieve those outcomes. For many organizations we analyzed, this shift led to the formalized role of a value stream architect.

6) DevOps Practices in Place

Nearly all the organizations we interviewed were already somewhat mature in their DevOps practices. This is a critical capability that gives organizations the ability to scale into the product-based model. However, when most organizations start, they don’t yet have control over the deployment of their applications, as that function is typically segmented to a separate team responsible for deployment. During the incubation phase, this responsibility must be given to the early experimental teams. It is critical to address this disjunction before scaling this model.

7) Incorporate Product Discovery

As organizations move to the optimized stage, they expand from focusing on delivery to also incorporating product discovery into their practices. This level of maturity is accomplished when transformations adopt a “test and learn” attitude as every advancement to the product is treated as an experiment.

To achieve this, you must build product discovery capabilities into your organization as early in your transformation as possible. This experimental and iterative approach allows product owners to quickly determine whether the company should continue investing more time building out a set of features, or whether you should pivot to a different experiment. Transformed organizations establish routines around discovery and delivery.

Constraints That Need to Be Overcome

There are many barriers to changing the operating model found in organizations. The business and technology synchronicity domain requires a significant focus on changing management structure to achieve the desired transformation results.

Some of the primary constraints are as follows:

1. Excessive Politics and Organizational Bureaucracy
2. Product Planning Exercises with High Overhead
3. Fake Agile
4. Partially Allocated or not Fully Dedicated Product Team Members (aka “Resources”)

1) Excessive politics and organizational bureaucracy

Organizations create and use many processes over time. In fact, teams build process upon process, optimizing not for the end-to-end experience but for the team who built it. These processes become entrenched in the organization, and it can be hard to get people to pivot and re-evaluate them. Compliance is commonly used as the reason why these processes need to exist.

Typically, there are many ways to solve the problems that these processes were created to address. In many cases, there are more engineering-centric ways to solve compliance problems that provide better control and efficiency.

To get past this constraint, arm yourself with examples of how others (preferably in your industry) have simplified similar processes in their organizations. Suggest trialing a new approach on an extremely small scale. Call it an experiment and use the results to get support and momentum from others who are also frustrated with legacy processes. You will need to build support and momentum to convince most of these teams to change.

2) Product planning exercises with high overhead

Many Agile and product-centric transformations fail due to the excessive bureaucracy that becomes layered into the model. This often happens when program management philosophy is the main force driving the transformation.

We found little evidence that large groups of people need to come together for every program increment planning cycle. You shouldn’t have excessive coordination between products.

When operating in a highly coordinated release process, there is little incentive to modernize architecture and eliminate dependence on others. This is an anti-pattern that is commonly implemented in enterprises. The proper way to solve this is to do lightweight product planning. Product leaders should be able to connect with their interdependent products to align priorities. Establish expectations and priorities for teams to reduce dependencies in the overall architecture.

3) Fake Agile

Many Agile transformations fall short of their goals because they aren’t tackling the hard changes necessary at the organizational and team levels to truly become Agile. They tend to lack focus on the Agile mindset and values.

In these cases, enterprises will often adopt Agile frameworks, practices, and ceremonies without fixing their broken and inefficient model. Additionally, many of these unsuccessful transformations tend to focus on technology delivery while ignoring the important aspects of the value stream related to how business and technology teams interact with each other from a discovery and planning perspective.

The focus on the customer is noticeably absent in these fake Agile transformations, with many handoffs and layers of bureaucracy in place between the idea and the customer.

4) Partially Allocated or not Fully Dedicated Product Team Members (aka “Resources”)

Persistent or long-lived cross-functional teams who are fully dedicated to their product are critical to success. When shifting from a project-based operating model, it can be difficult to shift mindsets away from project-based resource allocation. Partial allocation of a team member leads to constant context switching, which is detrimental to the success and overall morale of a product team.

Another critical cultural component to a healthy transformation is to stop referring to people as “resources.” People are not resources or machines; they are experienced knowledge workers with skills and qualities that are critical to the success of a product.

In the continuing posts in this series, we will explore each of the Seven Domains of Transformation in more detail. 

• Seven Domains of Transformation
• Transformation Implementation
• Business and Technology Synchronicity
• Product Taxonomy
• Workforce and Talent
• Funding Model
• Architecture
• Culture and Leadership

In the full white paper, The Project to Product Transformation, you will find not only the guidance indicators to create, increase, and sustain velocity, but also the negative force learnings that should help you avoid pitfalls in your transformational journey.

- About The Authors

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 Revolution on Social Media

• 
• 
•