What gets done at which Flight Level and what should be happening at that flight level? We encounter this question over and over. This is partly due to how we use terms like “strategy”, “strategy operationalization”, end-to-end coordination, etc.

There is nothing worse than creating confusion by using inconsistent and undefined terms. This article will answer this question again for everyone (including us), so that we will remain uniform in our communication about flight levels.

The Flight Levels Model is a way of thinking that can be applied to any company. It is compatible at all levels with existing methods and is not itself another “method”. The Flight Levels Model is a tool for reflection. What can we leverage within the company in order to improve our business agility and achieve the desired direction in the market?

Flight Level 3 is dedicated to strategy. Here, objectives are defined and are put into a larger temporal context (e.g. three-year or five-year goals). Then, the focus is placed on the next year, the next three months, or some short-term timeframe. What does the company want to concentrate on in the next iteration? Which actions bring us closer to our goal and how will progress be measured? One popular tool for this strategy work is OKR – Objectives and Key Results (see https://de.wikipedia.org/wiki/Objectives_and_Key_Results). Regardless how the strategy is developed and how many hierarchical levels are at Flight Level 3, eventually “actions” (also known as initiatives, activities or projects) are created that will need to be coordinated end-to-end at Flight Level 2. ATTENTION: Strategic topics from the levels below can and must be included in the strategic planning!

These actions are prioritized at Flight Level 3 and serve as input for Flight Level 2, where actions are started as soon as capacity is available (pull principle). This prioritization and the selection of actions to be executed in the next iteration creates the focus required to move forward efficiently and purposefully.

Each strategy topic has one or more actions. At regular intervals, the goal status is jointly evaluated by participants of all Flight Levels, which creates transparency for Flight Level 2 (and subsequently also for Flight Level 1). The joint evaluation shows how the initiatives/actions/things contribute to the company’s strategy. Strategic alignment can be so simple.

At each Flight Level there can (but not necessarily!) be several, possibly even hierarchical, boards – even at Flight Level 3. An example: The strategy of an IT-heavy company for the next iteration includes management’s business goals and the IT department’s technical initiatives. Several top-level strategy boards will exist, but a consolidated view must be generated. This consolidated view is also a strategic view with a synopsis of the two top-level topics. When developing this derived strategy board, inputs from both sides are prioritized, dependencies taken into account and the focus of the project is defined.

Flight Level 2 is the workbench of end-to-end coordination in the company. The initiatives from Flight Level 3 become the backlog items for Flight Level 2. The work or initiatives to be carried out in the next iteration are derived from this backlog. Flight Level 2 is a coordination level. Large tasks (sometimes called Epics) taken from the backlog are prioritized and placed in the implementation backlog for the teams (Flight Level 1). The teams take work (pull principle) when they have capacity available.

Each action is accompanied by “agile interactions” at regular intervals (stand-up meetings, workshops, etc.). By doing this, the flow of work through the system is maintained and improved, if necessary. These interactions also establish the area of focus for the next iteration at Flight Level 2, making it clear what Flight Level 1 should be delivering.

Flight Level 2, and the agile interactions taking place here, play a central role in the coordination and resolution of dependencies between teams/products/initiatives. Managing, and in the best case even resolving, these dependencies is often the biggest lever to improve the flow of work in the system. That’s why this topic is so important to us.

The working system at Flight Level 2 can also consist of hierarchical boards. If the boards at Flight Level 2 are oriented towards products, for example, there can be one or more coordination boards for product groups. It may also be necessary to coordinate work between different products when multiple products need to be changed for the implementation of a strategic theme. This results in dependencies that need to be managed.

Last but not least, Flight Level 1 creates the deliverables – it is the operational level in the company. This is where the operational teams who receive work from Flight Level 2 (Epics) are based. For each iteration, the teams concentrate on a certain scope (e.g. in Scrum it is the sprint target) and implement these tasks. On Flight Level 1, for example, the user stories from Epics are cut into tasks and implemented. Short iterations are planned and the finished work is delivered.

For the coordination, each team sends representatives to the agile interactions of Flight Level 2. But even at Flight Level 1 itself, there can (and will) be such interactions from a certain size of the company. Standups are an example of this. Another example would be a common architecture board, with whose help the teams coordinate the architecture of the product to be delivered. However, such a board is not a Flight Level 2 board, as it deals with topics that directly affect the delivery of the work.

As already mentioned in Flight Level 3, strategic or cross-product topics might arise which cannot be handled as purely operational work within the scope of normal activities. There might be topics that have a significant influence on the strategy. In this case, it is up to Flight Level 1 to pass these topics on to Flight Level 2 or even 3 so that they can be planned in the coming iterations.

The agile interactions at and between all levels are the tactical component of the work. Here, the existing competences can be organized around the work in such a way that the outcome, rather than the output, is maximized. “Outcome” means doing the right thing – and that doesn’t always have to happen super-efficiently. For an economically managed company, it is much more important to deliver the right thing and not be fully loaded than to deliver the completely wrong thing at full capacity.

This is what we see most often in organizations: the focus must be on the outcome. Companies often deliver a great deal (output), but have the feeling that they cannot achieve anything (no economically noticeable outcome).

Organizations must learn to align their competencies and capacities with the work, and not to align the work with the competencies. Otherwise, a lot may be delivered, but not what results in the sense of the strategy. But that is a different story and will be examined in more detail in another article.