As soon as you get something written down, you look at it, think about it and continue to develop it. This was exactly the case with the Flight Levels model. Just as they were being released in my book “Kanban in der Praxis”, and despite already having been discussed many, many times before when consulting customers, at trainings and at presentations, my point of view changed—thanks to feedback from readers, audience members and training participants.
The Flight Level model poses one main question: Which organization levels offer which leverage for improvement? Along this line, I reorganized the Flight Levels because whether or not the input occurs in a controlled or disorderly fashion (until now, the distinguishing characteristic between Flight Level 1 and 2) is a question of detail that distracts from the essentials of the model. In most companies, there are mechanisms in place for deciding what should be done next. Whether these mechanisms are efficient or not is exactly the topic of improvement, but is not important for the Flight Level model. As a result, a new structuring of the flight levels emerged and looks like this:
Although the flight levels came about through working with Kanban, it is still a general-purpose model for organizational development. When working with my customers, for example, often the focus is to implement measures at Flight Level 2 and 3 to improve coordination and strategic direction, while the team level, or operational level, works with Scrum. As such, it isn’t important which method is used at the individual levels, but rather how the communication and coordination between the levels will be organized. If you can make improvements here, the entire creation of value will begin to be optimized—and that is ultimately our goal.
I did not randomly choose the label “flight levels”. Flight level relates to flight altitude and so it should also be understood in this context: The higher you fly, you have more of an overview with fewer details. The lower you fly, you can see more details but no longer the entire landscape.
Flight Level 1: Operational Level
The first flight level belongs to the team that completes the daily work. Often those who are involved are highly-specialized experts, and I encounter such teams again and again, especially in high-tech environments. These specialists work exclusively in a sub-area of an enormous system, such as the fuel-injection systems for automobiles or the graphical processing of a weather radar for airplanes. Another typical manifestation of entities at Flight Level 1 are cross-functional teams, such as a designer, developer and tester, who work together on a small product or subsystem. Usually a large piece of work makes its way to a team where it is broken down into workable pieces, and implemented step-by-step. Looking at it from this point of view, a work system helps the team visualize, limit and continuously improve their work process. When a company consists of many teams, and not just one, the limits of optimization occur at the interface to other units and it can—as we already saw in the flow experiment—even lead to sub-optimization of the entire system. The improvements are limited to within the team, and can lead to difficulties in other teams.
The biggest disadvantage is that the customer’s wishes are not necessarily better fulfilled, despite the best intentions of the team. To explain this, I am going to use the keyboard as an example.
Let’s assume a customer would like a letter written. Let’s further assume that each team in the company is responsible for a row on the keyboard. Each team is the master of their row, but there is always room for improvement. For example, Team 3 can optimize themselves to the point of having a new world record for typing A the fastest. Fantastic! However, the customer’s letter will not be written any faster because of this. When writing a letter, it isn’t going about how fast you can type one single letter of the alphabet. It’s more important that the correct letter is typed at the right time, in order to achieve an actual increase in performance. That’s why the focus of improvement should involve the entire organization. The organization should be the one adjusting to the customer with an evolving process: What must be done in order to generate optimal value for the customer? If there is more than one team at the operational level, it is important to coordinate the work. It doesn’t matter in which branch or which area: On the road from “concept to cash” there exists, as a rule, dependencies between the teams. Each team, or each unit, completes only one portion of the value creation for the customer. For the coordination to be useful, the value creation chain of the products or projects must first be identified. Whether an organization is agile or not has nothing to do with the number of agile teams within the organization. The interaction between the teams must be agile.
Flight Level 2: Coordination
We can look at this in terms of a typical situation in the business world. The following picture shows a situation I see again and again in larger companies (40 to 40,000 employees). Several teams are required in order to generate value for the customer.
In most cases, the customer gets no value when tested code is delivered. The value is achieved once the code is integrated into a larger (live-) system within the company. On the other hand, customers rarely specify their wishes so clearly that they can be immediately implemented. In fact, it’s quite the opposite. As a rule, there is much to be done before the actual development work can be started. There needs to be leads generated and project teams drafted, the team must understand what the customer wants, contracts must be signed, etc. As soon as you take a look at the other areas, the value stream looks completely different, such as in product maintenance or in product management. Nevertheless, the idea behind it is the same: Creating value for the customer is more important than a hyper-productive team. This is exactly where Flight Level 2 begins.
At Flight Level 2, the interaction of the teams is optimized. To stay with the keyboard metaphor, at Flight Level 2, we ensure the right team is pushing the right key at the right time, i.e. working on the right work at the right time. A Flight Level 2 system coordinates the work of several teams who together are involved in fulfilling customer wishes, and bring specific services into the value creation chain. The goal is to optimize the work flow beyond the team border. Flight Level 2 work systems achieve massive performance improvements primarily for two reasons:
1 . The employees work on the right things at the right time because the work flow is coordinated beyond team boarders.
2. The number of work items is limited throughout, so the work system as a whole can be optimized.
Since the work flow is optimized over the entire value stream, the waiting time at the interfaces is reduced and, most importantly, the bottlenecks become clearly visible. Anyone who has experienced organizations at this flight level can only chuckle when high-performance teams are hyped as the secret to success. The larger the company, the more value creation chains there are within the company. Thus, there are more coordination boards being used that can also be hierarchically structured.
If we look at Flight Level 2 from the change management perspective, initiatives at this flight level are sometimes easier than at Flight Level 1, even if coordinating several hundred people. The decision to implement an across-team optimization falls to higher management. That means management has to set a good example and be the change they want to see. At the same time, there is no immediate need to change the way individual teams work at the operational level. Whether a team uses Kanban or Scrum, or just simply works on their stuff, is completely irrelevant. The only change, if you want to call it that, is that the delegates of the teams coordinate with each other in specific meetings, typically in routine Standups.
When you look at this picture, you might have the opinion that flight level 2 is the manifestation of a waterfall-type implementation. What does waterfall development mean? Just because things are worked on sequentially does not mean you are automatically in a waterfall development process (by the way, Winston Royce described the waterfall model as an iterative process). It is, however, a good model—such as programming software functionality before delivering it.
Working literally according the waterfall principle means work items pulled through the work flow are very large, such as a complete project. It is not expedient to first analyze an entire project, the develop it and finally implement it. This is not point I am making. Instead, the work items should be as small as possible, so you can verify the correctness of the approach as quickly as possible. This requires getting feedback as quickly as possible and be able to learn something from it.
Flight Level 3: Strategic Portfolio Management
Normally organizations do not work on just one project or one product. A company’s portfolio is comprised of a variety of projects and products, as well as strategic initiatives that keep the company fit for the future. Flight Level 3 manages exactly this mix. You want to gain an overview of what takes place in the company. You also want to know which projects and strategic initiatives are having an effect in which way, and how far the implementation has progressed. Can a new project already be started or should you wait until another project is completed? What investments should be made? Should a new market be conquered, or should an existing market share be increased? Which change initiatives are currently running in the company?
This last question—what is currently running with which purpose in the company—is especially suited to be visualized on a strategy board. This way, top management can recognize if contradictory orders were given and whether or not the initiatives are obstructing one another. Such contradictions occur primarily when companies want to become agile and several consultants, with their various opinions, are working with the company. On one day, self-organization is promoted, and the next day old-school reporting is requested. At this flight level, it’s going about strategic management of the entire organization and not about micro-managing the operational implementation. Large companies with offices around the globe have several strategies due to the various local market requirements, and as such, several strategy boards exist and a coordination board for all locations is at the company headquarters.
Having more demand than you are able to supply is fundamentally a good problem, otherwise a company must reduce its workforce. As a result, there is competition at the portfolio level between the options. This disparity between options and implementation possibilities must be explicitly clear, otherwise there might be an impression that there are unlimited resources available. This is not the case and this is exactly the point of a work system at Flight Level 3: making prudent choices and combination of projects, developing products and strategic initiatives, recognizing dependencies and optimizing the flow through the value creation chain with the currently available resources.
At Flight Level 3, the types of jobs being dealt with are large work items, such as “market entry in Hungary” or “less automotive, more aviation business”. At this Flight Level, these vast functionalities and initiatives compete with one another, so the organization is forced to make a well-considered and deliberate decision about what should be completed next. The focus is no longer the goals of the individual projects, but rather the overall result for the organization. Demand and possibilities must be balanced exactly.
The following diagram consolidates the flight levels into one complete picture:
Flight Level 3 is the strategic heart of the organization. The projects and initiatives of the company converge here and strategic management is located here. Flight Level 3 is connected with several systems at Flight Level 2 and Flight Level 1, where the operational work is managed. The example “market entry in Hungary” at Flight Level 3 may only contain two tickets, “prepare product group X” and “prepare product group Y”, but at Flight Level 2, these superficial work items will be broken down into smaller workable items and handed on to the teams at Flight Level 1.
It also happens quite often that work from Flight Level 3 flows directly to a team at Flight Level 1. Let’s assume that our company is an auto parts supplier and the strategy at Flight Level 3 states “more aviation business”. There is a product that is being developed for the automobile market, but with slight modification, in theory, the product might also interest the aviation market. A team of specialists take care of testing this theory, so the work item flows directly from Flight Level 3 directly to a specialist team at Flight Level 1.
Flight levels are not a model for maturity or evaluation. A team problem cannot be resolved with a strategy board, just as a strategy cannot be implemented through a scattered team initiative. Nonetheless, I see similar thought processes with agile initiatives. There is a strategic problem, namely the uncertainty about how the market will develop in the future. And although nobody knows what the future brings, all the teams are made agile as a preventative measure. Agility is a strategic topic and cannot be resolved primarily at the operational level, especially in areas where it is not even necessary. If you want to make improvements in an organization, you must first be clear which level is best suited to achieve them. The flight levels should help identify the appropriate level. Generally, it can be said that the higher the flight level, the greater the leveraging effect. If there is the possibility to start an initiative for improvement at Flight Level 3, you should do it. The only agile team that is needed at the start of becoming an agile organization is an agile top-management team, which carries out strategic portfolio management. Everything follows from here—lead by example.