|29 Apr 2017|Klaus Leopold

Flight Levels: The Organizational Improvement Levels


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:
>  Flight Level 1 – Operational Level
>  Flight Level 2 – Coordination
>  Flight Level 3 – Strategic Portfolio Management
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. The Flight Level model is an instrument of communication that reveals the effect of specific improvement steps at different levels, and for finding the most useful starting point within the organization to begin with improvements.

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. Is that a waterfall?
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.

Andreas Schliep
11 Jun 2017 19:08

The 3 flight level concept for Kanban makes even more sense than the 4 level concept. On an operational level you could almost always extend the scope of observation until you find the boundaries of queue management. This emphasises the importance of a holistic systematic approach.

Klaus Leopold
14 Jun 2017 10:57

Very glad, that you find it useful! I’d even go one step further and call it the flight levels for organizational improvements. 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. What method you’re using for improvement is a whole different story. You might choose Scrum or Kanban, or whatever. In fact, I see many companies who use flight level 2 systems to coordinate multiple Scrum teams working on the same product. So, everything is possible… 😉

Matías E. Fernández
18 May 2018 14:43

Hi Klaus, in your Book “Practical Kanban” you write “The larger the company, the more value creation chains there are within the company. Thus, there are more coordination boards being used.” whereas here you write “Thus, there are more coordination boards being used that can also be hierarchically structured.”
What was your motivation to remove that comment?

Klaus Leopold
21 May 2018 14:24

What do you mean by “to remove that comment”?
The difference between the two sentences I see is the remark about “hierarchically structured”. I don’t know where this difference comes from – it was not a conscious decision and most likely it just happened in the writing process, i.e., there’s no deeper meaning behind it 🙂

27 Jul 2018 23:30

What inspired you to create flight levels? I would like to know what the advantages are and if you have a case using flight level, Thanks

Caio Cestari
05 Nov 2018 02:31

Klaus, while I was reading your blog post the SAFe layers (Team, Program, Portfolio) came to my mind. What would you say about the differences between the three flight levels and these three SAFe layers? Thanks!

22 Nov 2018 12:02

Unfortunately this link take you to a “403 – forbidden” page.
Winston Royce described the waterfall model as an iterative process

Klaus Leopold
25 Nov 2018 22:05

Hi, Steve, thanks for bringing this to my attention. Probably the providers have blocked the link :-/

Fay Simcock
26 Jul 2019 11:01

I really like this, it aligns very well with how I learned to run projects when I first started working in IT. However, in my experience of waterfall we never, ever pulled a whole project in one go. Always phased, maximum quarterly, with reviews and chances to change direction. Not so different from PSIs, for those who’ve worked with SAfE. And actually cross-functional interaction was often much better than now with Scrum (including actual users in my definition of cross-functional). I think younger developers often forget how much we were constrained by hardware and software limitations (talking about the 80s and 90s here). Overnight compilation before you can see if your code has worked and every last bit (yes, bit) being made to do 3 things means you have to get it right first time and you’d better focus first on good design.

Stefan Norrvall
13 Jan 2020 22:13

Hi Klaus, someone just pointed me to this and although its an old post I could not resist commenting. The idea of different levels is something well explored by Elliott Jaques (Requisite Organization) and Gillian Stamp (BIOSS) ( and of course Staffford Beer’s work on the Viable System Model explains in detail the key systems required for a viable organisation. There is also the most excellent work by Luc Heobeke which brings all three together (
I guess my question with regards to this is how you see it as being different or an improvement or perhaps building on the work of the previously mentioned authors.

This conversation lacks your voice:
Your E-Mail Address will not be published.