The Organizational Structure for True Agility

Hardly any larger company gets by today without daily stand-ups, sprints, and Kanban boards. Working in an agile way is taken for granted, and yet the organization behind it usually remains a classic hierarchy with departments, budgets, and decision paths from the age of industrialization. This article shows why true agility is not a question of method but of organizational structure: vertically sliced product teams, decentralized decisions, leadership by objectives, and software that coordinates the teams.

Agility is a question of structure, not of method

The notion of agile working comes from software development. Because the end result of a software project can never be defined exactly in advance, self-organizing, cross-functional teams have proven to be the most suitable form for working on a solution together: adaptive planning, short iterations, daily coordination on completed tasks and obstacles, continuous feedback from users. This approach shortens lead times, brings different perspectives to one table, and raises the quality of the results.

Consultants and managers have transferred this approach to entire organizations over the past two decades. Since the scientific management of the early 20th century, Taylorism and Fordism, hardly any management approach has found as much support as agile management. The reason is simple: in a world where new technologies rebuild entire industries within a few years, companies have to be extremely adaptable. And growth that rests on the permanent change of structures and roles can no longer be steered with rigid plans.

That this also pays off financially is suggested by a survey by PA Consulting (2019) among 500 senior executives: the top 10 percent of companies in the sample by financial performance are nearly 30 percent more likely to have an agile organization.

And yet, in our projects we observe a pattern that I consider the real problem: the rituals are adopted, not the structure. Teams hold their daily stand-ups, plan in sprints, and run retrospectives. But budget, staff responsibility, and the decision about what gets built at all continue to run across departmental boundaries and hierarchy levels. The result is agile islands within a hierarchical organization. A method can be introduced in a few weeks. Changing a structure takes years, and that is exactly why this step is skipped so often.

The brakes: grown structures and old software

Organizational agility in many cases means fundamentally reworking the business model. In doing so, many companies are held back by two things: by grown, rigid, and complex organizational structures, and by outdated software. The two are more closely linked than they appear at first glance, because a company's software has grown along its departments over the years, and the departments have solidified around their systems.

An example from the banking industry that I describe in more detail in my book "Das selbstfahrende Unternehmen" (Springer Gabler 2021, in German): the most important core banking applications of a large share of Europe's systemically relevant banks were written in COBOL or related programming languages from the 1950s. The technology behind them rests on the punched card, which was originally developed to control mechanical looms. These banks are therefore working with a system carried forward across three generations that goes back to the loom, and at the same time they are trying to offer an omnichannel experience to the outside world: the same information and the same business options at the counter, on the phone, on the website, in the app, and in the messenger. According to my assessment in the book, around 80 percent of all banks have this legacy. That it does not produce much agility is obvious. Almost all executives in banking know that the path to true modernity runs only through the complete renewal of the technical foundation. To this day, hardly anyone is willing to take that step.

Similar scenarios can be found in other traditional industries. How structure and system landscape have to work together is something I described in the article Enterprise Architecture for Self-Driving Companies. This article is about the other side of the same coin: the organization.

Vertical product slicing instead of horizontal service layers

What an agile structure looks like is best shown by software companies. Those who consistently align themselves with the expectations of their customers develop from an IT service provider into a digital solution provider. What counts is not the product perspective of the manufacturer but the needs perspective of the users: which problem do we solve? Whoever keeps responding to this question makes their services better, strengthens customer loyalty, gets recommended, and lowers acquisition costs.

The prerequisite for this is a vertical product slice. Classic organizations are sliced horizontally: there is a separate team for each task, a head of sales who knows the market, a research and development department, a marketing department, a data center. Over the past decades, these service layers were stacked on top of each other like multi-layer sandwiches, because with very large numbers of employees this was the way to realize cost synergies. The price is breaks between the units, friction, political turf wars, and the tendency of every department to develop its own goals and pursue its own interests. The holistic perspective on the product and the shared vision are missing.

With a vertical product slice, one team is responsible for a product or service across its entire lifecycle: from gathering customer requirements through prototype, testing, and operations to lifecycle management and growth hacking. At the top are product managers who are networked with all relevant actors in the company. Bringing business, development, and IT operations together in one team is known as BizDevOps. Because responsibility for entire products now lies with the team, decision-making authority must lie there as well. This decentralization is the greatest advantage of agile organizations: decisions are made where the information is, and the company can respond to change practically in real time.

Introducing a vertical product slice is a radical change of the organizational form, not an add-on. Which agile organizational model a company chooses is secondary; what matters is that agility is introduced at all levels. A company whose leadership level does not itself work in an agile way will sooner or later force the structure below it back into departments.

Self-steering teams, led by objectives

The hierarchical organization with separate departments is replaced by richly networked, self-steering teams. Each of these teams unites business and IT expertise; these interdisciplinary business informatics specialists become the engine of change. In practice, it has proven worthwhile to bring in new people for the transformation phase whose thinking has not been shaped by decades of departmental logic, rather than relying exclusively on retraining.

These teams are led not by instructions but by objectives and measurable key results (OKR). The objective sets the direction, the key results prove success or failure. Unlike classic management by objectives, the goals are not cascaded from the top but broken down by each level itself for its own area of responsibility, and they are visible to the entire company. John Doerr presented the approach to the founders of Google in 1999; since then every employee there defines their own key results quarterly (Doerr 2018, "Measure What Matters"). For OKR to work, the objectives have to be inspiring and answer the question of why. From our consulting practice, however, we also know this: OKR are suited for motivation, not for binding control. On their own, they do not achieve the concerted action of many self-steering teams.

Leadership thereby changes its character. What remains in place of top-down management are leaders who, in the sense of transformational leadership, motivate through the authentic communication of their vision and by setting an example. Middle management, which spends its time preparing reports and figures, will according to the thesis of my book be largely replaced over the coming five to ten years by algorithms that perform these tasks faster and better through self-learning. That alone flattens the hierarchies.

Software coordinates, people lead

So that decentralization does not end in chaos, the agile organization also needs a framework. Scrum provides a proven foundation with clear roles: the product owner carries the business responsibility, defines the tasks in the backlog, and prioritizes them; the scrum master carries the process responsibility and clears obstacles out of the way; the team chooses its tasks itself and acts autonomously during execution. What distinguishes this framework in the self-driving company from its classic form is the role of software.

The coordination of the many teams is handled not by coordination meetings but by central, networked software systems, today for instance tools such as Atlassian Jira. Tasks and requirements are captured in backlogs, product managers prepare them for their teams, and the central software automatically ensures during ongoing operations that all teams remain aligned with the common goal. With every piece of feedback this software will get better: artificial intelligence will learn from the results, recognize bottlenecks earlier, and distribute tasks more accurately. In the book I distinguish two collaboration models for this: self-organizing teams, which decide for themselves how they do their work, and software-controlled teams, in which the software assigns each team member tasks including execution instructions and measures quality. Both forms will coexist, depending on whether a task demands creativity and empathy or can be standardized.

One point is particularly important to me here, because it is overlooked in many transformations. In our experience, introducing this organizational form in large companies takes three to five years and only then leads to a performance increase. This increase occurs only if workflows and administration are radically automated. Otherwise employees experience the new structure as more manual and more laborious than the old one, because they now have to handle the coordination themselves that the hierarchy used to take care of.

The most important ingredient for agile organizations is the unconditional automation of administration.

This is exactly where the circle closes to the self-driving company. Agile structure, leadership by objectives, and coordinating software are not three separate undertakings but three sides of the same rebuild. Whoever changes the structure without renewing the software creates friction. Whoever renews the software without changing the structure cements the departments into new systems. How algorithms replace the classic end-to-end processes is something I described in the article The End of Processes, Long Live the Algorithms; the organizational structure is the organizational counterpart to it.

What this means for your company

Five test questions follow from this analysis, which we ask at the start of every transformation:

• Method or structure? Check whether agility in your company exists only in rituals or also in budgets, staff responsibility, and decision rights. Only the latter changes the speed of response.
• Slice products vertically. Choose a product or service and hand an interdisciplinary team the responsibility for the entire lifecycle, including operations and market.
• Decisions into the team. Where responsibility lies, decision-making authority must lie as well. OKR replace the goal cascade, and top management works by the same rules.
• Automate administration before you scale. Coordination, reports, and the distribution of tasks belong in software, not in meetings. Without this step, the new structure remains additional effort.
• Renew the technical foundation. Old core systems dictate old structures. Plan the renewal of the system landscape as part of organizational development, not as an IT project on the side.

The next step

The concept of the agile organization as a component of the self-driving company, with its collaboration models, roles, and leadership instruments, is described in detail in my book: To the book. A summary can be found in the article The Self-Driving Company: A Summary of the Book. If you would like to know where your company stands between methodological agility and structural agility, book an expert meeting.