Flight Levels comes up constantly in conversations about organisational agility, but for anyone encountering the term for the first time, a genuine definition is more useful than fluent name-dropping. Here is the plain version, starting with where the name itself comes from.
Where the name comes from
The term is borrowed from aviation. Aircraft in controlled airspace fly at standardised altitude bands, and a pilot's view of the world changes with altitude: low down, individual obstacles and details are visible; higher up, the picture is broader but coarser. Klaus Leopold, who developed Flight Levels, used this as a deliberate metaphor for organisations: different levels of an organisation genuinely see different things, and none of those views is more "correct" than another, they simply cover different scope.
The three levels, briefly
Flight Levels describes three layers of activity in an organisation. The operational layer is where teams do the work itself: sprints, tickets, day-to-day delivery. The coordination layer is where work flows across teams, dependencies get managed, and priorities are set across multiple product areas. The strategic layer is where organisational direction is set, and where that direction should connect back to what teams are actually doing. Each layer needs its own way of working; none of them substitutes for the others.
The problem it exists to solve
Most organisations investing in agility have put the bulk of that investment into the operational layer: team-level Scrum, Kanban boards, sprint ceremonies. That investment often produces genuinely better-functioning teams that are still, collectively, working on the wrong things, in the wrong order, or blocked waiting on decisions made too slowly elsewhere. The teams are healthy; the layers above them are not. Flight Levels exists to name that gap explicitly and give organisations a vocabulary for closing it, rather than continuing to invest exclusively at the level that already got the most attention.
Why it's a thinking model, not a framework to adopt
Flight Levels doesn't prescribe specific ceremonies, roles, or artefacts the way Scrum or SAFe do. It gives a way of diagnosing which layer a real problem actually lives in, and designing a response fitted to that specific organisation, rather than importing a standard playbook. This is a deliberate design choice: two organisations can both apply Flight Levels thinking and end up with genuinely different coordination systems, because the systems are built for their own context rather than copied from a template.
Where this fits with the rest of what's on this site
This piece is deliberately just the plain orientation: what the name means, what the three levels are, and what problem the model addresses. For a closer look at why Flight Levels resists being treated as a framework, see the companion article on that distinction; for how the thinking actually translates into practice, see the piece on its five key activities. If applying any of this to a specific organisation is the goal, our FL2D and FL3D workshops are the most direct route in.