Is your digital engineering gaining momentum? Or is your organization already struggling to support digital efforts at scale? Many companies face these kinds of challenges. 

While it may be tempting to look to AI as a solution, the truth is that these technologies may amplify existing problems. Ultimately, fast and high-quality human decision-making is more important than ever. In this blog post, I’ll share some practical tips for steering the various disciplines in the digital space at scale, from software and infrastructure to data and AI.

This blog post is part of a series. So far, we talked about the power of a slice-based digital transformation approach moving strategic digital products fast. Previous articles touched on the importance of iterative, probe and sense change approaches and the importance of the pull effect through well-chosen 'Exemplar' teams. A Product map was introduced to give digital transformation stakeholders a common language to tie transformation slices to business goals through clear, attributable customer vaue. 

To steer effectively at scale there are two aspects that need to come into focus:

1. Decisions at scale. This is about how we manage an increasing number of product and technical decision-makers.

2. Craft at scale. Who enables the decision-makers and advances their way of working?

This blog post describes effective steering traits to tackle both of these things. We’ll look beyond the nucleus of digital work — the ‘slice’ or the autonomous product group — and at the organizational tissue that surrounds it and pulls it in the right direction. Both are crucial if we’re to move the needle through digital transformation.

The autonomous product group: Key steering traits

Let’s quickly recap which steering traits makes the autonomous product groups successful:

The two key positions to address the management traits above are the product owner (PO) and technology lead (TL):

Product owner

The product owner is accountable for the business and customer outcomes as measured by business and product metrics. They make sure the right product is built in the right way. This includes designing an effective part of the organization and setting the right incentives for software development teams.

Technology lead

The technology lead is responsible for the quality of the software running in production. Their primary measure of success is that systems and software work as intended. They also anchor cross-organization quality initiatives in their part of the organization. At the same time, they are the most senior engineers and responsible for the developer experience. This includes methods, tools, processes and architecture design for a smooth flow of work.

The organization tissue around the digital nucleus - key steering traits 

We cover three key traits which sum up the most important organization steering aspects to run digital efforts at scale:

1. A clear decision-making hierarchy

2. Accountability through measures of success

3. Stewards of processes, methods and tools

Clear decision-making hierarchy

Product decisions are made by more people than just POs. If duties and ways of working aren’t aligned across the hierarchy, POs cannot succeed because they get overruled or their goals conflict with the way of working of the organization.

Therefore, before diving into operational enhancements, it’s worth clarifying what this hierarchy involved in digital product steering at scale could look like.

The most important aspect of effective steering hierarchies is subdivided accountability — not any accountability, but the one for financial results. In reality this means that leaders accountable for profit and loss break it down into smaller pockets which their respective reports will be accountable for. The smallest pocket of accountability is the financial results of (a group of) product(s). This ensures product decisions are incentivized coherently along the decision-making hierarchy and positively impact the bottom line. It’s important, however, to keep organizational complexity to a minimum, where possible. Fast-moving, strategic product steering should benefit from short decision-making paths and autonomy in tactical choices.

Another important aspect to product decision-making is technology. Architecture fitness, quality assurance and development teams’ capabilities are crucial input parameters to any product strategy and planning. Hence this discussion needs a place in the decision-making hierarchy, too. The implementation of the technology lead role should align with the complexity of the product and technology landscape that informs decision-makers at various levels of the hierarchy.

Technology leads depend on guidance, too. A cross-group architecture forum consisting of seasoned, senior software engineers develops, communicates and supports the implementation of principles of what a “fit” architecture looks like. They define how to measure and maintain quality engineering solutions as well as software engineering capability development and career pathways. Although this forum is part of the digital business organization, input to its latter responsibilities can come through a central tech governance body, such as the office of the CTO, too.

Now, with a clear, aligned decision-making hierarchy, you will see that both structure and processes are attuned to each other; the order is intentional. Simply said, the greatest process won’t fix a broken structure. And while the organization can work around hindering structure for a few strategic autonomous product groups, it will become tedious when scaling the amount of decision-makers across the organization (I experienced this from a number of >4). 

Accountability through measures of success

Imagine product groups achieve high targets, but business growth is still less than planned. This should be taken as an indication that targets have been defined along activities instead of business outcomes. Examples are the on-time end of a project or delivery of roadmap items rather than looking at the aspired (and achieved) revenue or profit margin increase.

Nonetheless, beyond having business outcomes as target, some additional operational targets are needed to align work. This increases the amount of measures. To remain focused, a classification and systematic cascade of measures of success can help.

The measures can be categorized in the following way:

• Business measures (direct or shared accountability for profit and loss).

• Product measures (direct or shared accountability for product market fit).

• Process measures (subdivided accountability for the effectiveness of processes).

• Satisfaction measures (subdivided accountability for and/or customer/employee satisfaction).

Business metrics are typically only showing what has already happened (lagging indicators), but they remain the main expression of success. 

Product, process and satisfaction metrics are typically look-ahead (leading indicators) and therefore give guardrails and a pre-warning if the direction gets lost. 

Revisit business metrics in e.g. quarterly business reviews and if necessary leave flexibility to run experiments and see the effect on the bottom line. For example, this can mean to accept insecurity about a quarterly user growth target to test a high-value customer conversion feature.

The image above shows examples of measures being cascaded down the business hierarchy. Breaking down measures means keeping targets, but for smaller scope. Sharing measures means that exactly the same targets and scope are communicated to teams while the actual accountability resides with the sharing entity. 

The start of the cascade varies based on business hierarchy level. While lagging business measures are broken down from the top, leading product and satisfaction measures can be defined below where stronger product strategy knowledge exists. An exception are process measures, which are usually related to software engineering performance. This is why the technology lead hierarchy is best suited to be accountable for such results.

Stewards of processes, methods and tools

The rapid pace of today's world requires quick, high-quality decision-making from leaders to maintain competitiveness. This necessitates effectively steered delegation, ensuring decisions are made wherever they are needed. While the specific application of the 'sensible defaults' discussed here will vary by organization, it's crucial to recognize that success depends on two sides: structure and process, and the necessary skills. Decision-makers rely on a 'caretaker' function to support and maintain the codified concepts, or sensible defaults, they are expected to follow. Although this article focuses on the defaults themselves, the vital role of the caretaker is further detailed in relevant articles by my colleagues, which can be found here.

By intentionally designing your digital product engineering organization grounded in:

• Leadership of the digital nucleus – the autonomous product group,

• and as “tissue” around the nucleus:

  • a clear decision-making hierarchy, 

  • a break-down of accountability with outcome-based measures, and 

  • dedicated stewardship of the practice of executing the above

you can successfully transition from isolated digital successes to sustainable, at-scale business impact.