Flight Levels for leaders explained

Here’s what you can learn from this episode of Pragmatic Talks:
Kirill Klimov’s career path
- Technical Origins: Kirill started as a software engineer and spent over a decade in product development, working in a distributed organization where he gained experience in sales and support in addition to engineering.
- Shift to Agile Consulting: He became interested in agile methodologies like Scrum and Kanban, which led him to start a consulting career. For more than a decade now, he has been helping organizations with change, focusing on culture, structure, and leadership through modern management approaches.
Explaining the flight levels model
- A Metaphor for Perspective: Flight Levels uses the metaphor of flying altitude. Flying high gives a broad overview with few details (strategy), while flying low shows many details but no big picture (team operations).
- The Three Levels:
- Level 1 (Team Level): Focuses on how teams work. Teams can use any process they prefer, like Scrum or Kanban. This is where value is created.
- Level 2 (Coordination Level): This is about the value stream–how work flows across multiple teams to deliver a product or service to the customer. It addresses the challenge of coordinating between teams.
- Level 3 (Strategy Level): Concerns the organization’s overall direction, goals, and long-term plans. It answers the question “Why are we building this?”.
- Not a Hierarchy: Kirill emphasizes that Flight Levels are “lenses” to view the organization, not a reflection of the organizational chart. The hierarchy usually exists within the coordination level (Level 2).
How flight levels help organizations
- Connecting Strategy and Operations: A common problem is the disconnect between the company’s strategy and the daily work of teams. Flight Levels helps make the strategy clear and shows how operational work contributes to it.
- Solving Value Stream Problems: It addresses situations where individual teams are efficient and “agile,” but the organization as a whole fails to deliver value because of problems between teams, such as long handovers or misaligned work.
- Using Metrics and Objectives: Each level has relevant objectives. For example, the team level might measure how an enabling team helps others, the coordination level measures customer value, and the strategy level tracks progress on big-picture goals. This is compatible with systems like OKRs.
The five activities of flight levels
These five activities are applied continuously on all three levels to drive improvement:
- Visualize the Situation: Making invisible knowledge work visible is essential for collaboration. How you visualize work will be different for the team, coordination, and strategy levels.
- Create Focus: Limiting what you work on to get things done. On a team level, this could be a WIP limit in Kanban or a sprint goal in Scrum. On the strategy level, it involves different techniques to prioritize initiatives.
- Establish Agile Interactions: Creating the communication and collaboration pathways needed for work to flow smoothly through the system.
- Measure: You need to measure to understand if you are improving. This applies to both the product you are building and the process of organizational change itself.
- Improve: Using measurements and observations to make iterative improvements across all levels. The frequency of improvement cycles varies–team-level changes might be frequent, while strategy reviews happen less often, perhaps quarterly.
Flight levels, systems thinking, and organizational change
- Designing the System: Implementing Flight Levels requires systems thinking, especially when creating the “flight level system architecture”–a design for how information and work flow in your specific organization.
- Avoid Big Upfront Structural Changes: Kirill advises against starting with heavy organizational restructuring. It’s better to first observe how value flows and then organize around that. Structural changes should follow process improvements, not lead them.
- Compatibility with Existing Methods: Flight Levels is not a replacement for existing frameworks. It can be used on top of Scrum, SAFe, LeSS, or Kanban to provide better visibility and alignment. Many of its ideas come from the Kanban body of knowledge.
The future of modern management and AI
- The Need for Simplicity: In an increasingly complex world, organizations need simple ways to start making improvements. Flight Levels offers an accessible starting point.
- AI’s Role in Management: Kirill believes AI will not replace jobs, but people who use AI will be much more efficient. AI is already a powerful tool for learning and generating ideas–for example, a Scrum Master can use ChatGPT to get inspiration for a retrospective format.
- Universal Advice for the Future: The best way for organizations to prepare for the future is to build their internal capability for business agility. The ability to adapt to change quickly is more important than ever. Organizations must avoid complacency, even when things seem fine at the moment.
Full Transcript
Wiktor Żołnowski: Welcome to the next episode of Pragmatic Talks. Today we are at the AI by Example conference, and we are with our guest, Kirill Klimov. So, a very first question: Kirill, our audience would love to hear more about you. So who is Kirill, and what is your story?
Kirill’s origin story
Kirill Klimov: First off, thanks for inviting me. I’m excited to be here. It’s great to be at AI by Example. Great conference, great talk. I started my career on the technical path, starting as a software engineer. In the first part of my career, which was a bit more than a decade in product development, I was in a distributed organization. We were building software as a service, even though it wasn’t called using these terms back in those days. As is always the case with smaller organizations, I had a great chance to work on very different stuff–not all engineering. I was involved in sales, involved in support, and all that. So obviously, I learned quite a lot because of all those interesting challenges. I spent a bit more than a decade there, and during that time, the agile term hit me. I started to explore and learn more about those ideas and concepts and started to introduce some of that to our team initially. It was Scrum initially, and then we tried some of the more Kanban stuff. It was obviously working and bringing some success, and it was very interesting to me. So I started to help some friends who were having the same challenges, and that’s how my consulting career initially started. So, the second part of my career, which has also been a bit more than a decade by now, I was splitting between internal and external roles, primarily helping organizations to change using this set of agile approaches. Again, initially more focused on the teams–working with teams–and later on, more on the culture, structures, and leadership, which is always, or oftentimes, very much connected to these changes. So that’s what I’m doing these days: helping companies go through change with the help of modern management approaches.
Explaining flight levels
Wiktor Żołnowski: Okay, great. So in today’s talk at the conference, you spoke about Flight Levels. Tell us more, starting from the beginning. What is it? Of course, you will be repeating some things from the talk, and for everyone who would like to hear more about Flight Levels, I truly recommend Kirill’s talk from AI by Example.
Kirill Klimov: The metaphor is very easy: depending on the altitude of your flight, that’s the level of the detail that you can see. So if you are flying in an airplane really, really high, you can probably see hundreds of kilometers of the surface around you. However, you don’t see any of the details on the surface. On the contrary, if you are flying really low, you can see all the details, maybe the buildings, maybe what’s even happening within the building, but you don’t see the bigger picture. All those flight levels have their specific attributes, properties, pros, and cons. And all those perspectives are valuable. When you bring it to the organizational context, there are three levels. The first one is the team level, so basically everything happening with the teams. It could be different structures for the teams; it could be stream-aligned teams, enabling teams, platform teams, using Team Topologies terminology. Teams could be using different processes, like Scrum, Kanban, something else, their own ad-hoc processes–it doesn’t matter. Obviously, the value is created on that level. The second level is the coordination level, and that’s the value stream where the value actually gets delivered to the customer. So if we are talking about a product, that’s the product level or the service level. Again, it’s not necessarily the case, but my experience with a lot of organizations is that oftentimes, in order to deliver value to the customer, more than one team is involved. If so, then you have to coordinate somehow between those teams, and this level is what it is about. And then the third level is about the strategy: where are we going? Why are we building this? And what are our mid- and longer-term plans in terms of the product or the whole organization? So those are three levels, and they provide these special kinds of lenses you are viewing your organization through. And then there are five activities, and you apply all five activities on all the levels. And then, different organizations, of course, will have different challenges, but by applying those, you can improve over time.
Flight levels vs. organizational hierarchy
Wiktor Żołnowski: So for some people, that might sound like Flight Levels has something in common with the organizational hierarchy, yeah?
Kirill Klimov: That’s very, yeah, that’s very common. I like to think about those three levels as lenses. All the hierarchical stuff basically sits within the second level, coordination. Because yeah, there might be multiple teams, multiple streams, and still, all of that is the second level. So if you think about the so-called agile scaling challenges or issues, all that is leveled. Most of the complexity actually goes there as well. So it’s not that if I am in the lowest part of the organization, I’m just a regular employee, I shouldn’t look at the higher level. I should look through all of the levels. That depends–the usual consulting answer–that highly depends on how your organization is structured. Because again, these are just lenses. Now, what type of collaboration and communication you have between them really depends on the organization. The most probably complex part of all this is the so-called system architecture, system topology, when you are building this for your organization. And there are a lot of different patterns for how that can go, yeah, how those levels are connected and working with each other. The shorter answer to your question is it could go really differently.
Objectives and metrics for each level
Wiktor Żołnowski: Sometimes, actually, as a team member, I’d like to limit the amount of stuff I’m involved in, in order to decrease my cognitive load, because it’s impossible, yeah. So could you provide some examples of, I don’t know, objectives or metrics that are used on these levels so people could have a more clear view on what we mean by each level?
Kirill Klimov: Again, let’s start with the coordination one. Product-relevant stuff will be relevant there. So what we are building, how we are measuring it–it’s already the level of customer value. Basically, it could be what we’re bringing to the customer. On the team side, again, depending on the objectives of the team, what you are delivering. If it’s for stream-aligned teams or fully-featured teams, that would basically be the same: you’re bringing value to the customer. It’s the same metric. However, if it’s, let’s say, an enabling team, that would be how you are serving other teams. For example, you’re onboarding them with a new process, a new technique. That would be your metric, your objective. And then the strategy level, obviously, has bigger objectives, how we are achieving those, and then learning and feeding it back to effectively change our strategy according to our progress. Okay.
Wiktor Żołnowski: So those few levels and few different levels of goals and objectives, they’re interconnected somehow, right? Or at least they’re expected to be.
Kirill Klimov: So it’s pretty similar to OKRs, objective key results. With OKRs, you can cover the different levels. So you can use OKRs and Flight Levels together as well. A lot of people are actually using OKRs. That was my first impression; it’s very similar. So, it begs the question of whether they are used together. Again, there is no contradiction. So if you’re using OKRs, continue doing it with Flight Levels. If you’re about to start using Flight Levels, you don’t have to use OKRs, but you can. So from your experience, how does that thinking model help organizations, help people to execute their strategies better?
Addressing strategic challenges with flight levels
Wiktor Żołnowski: Again, if you talk about strategies, there are several typical challenges that Flight Levels is about to address for us. I don’t really see a lot of companies that are really missing a strategy. It’s not that they don’t know where they’re going; it’s more or less always there.
Kirill Klimov: It’s more the disconnect between strategy and the operation. Or the strategy is not explicit, not shared within the organization. So somebody knows about it, and a lot of other people don’t. Or it changes too often, so spontaneously, and that might look scary for others if they don’t see the reason for that. And then obviously the disconnect between strategy and operation. So that’s one of the typical challenges Flight Levels are addressing. Another one is just basically the value stream. One of the things that is so well described in one of the initial books is that we may have a lot of agile teams, and on the team level, it’s working perfectly. The team can deliver something, but then as a whole organization, not much is happening. And basically, there is not much value delivered, where all the teams are so great. Because that something that was delivered is not something that was right. Yeah, again, on the team level, it’s okay, but between teams, it got lost. Yeah, or long handovers and a few other things could go wrong there. Okay.
Wiktor Żołnowski: Yeah, that’s another typical one. But again, those were kind of the quick, easy starters, some reasoning why you would start using Flight Levels. But it’s just a start because later on, by seeing the organization through these different lenses and applying those five activities, you find what’s your real pain point or where you have to focus your attention at the moment, where to improve. And you improve, and then you move on. And through that process, that’s the way how you can improve your organization. Flight Levels essentially provide more transparency to the entire organization in terms of the transparency about strategy and execution of that strategy, and the other way around. Is that correct?
Kirill Klimov: Yes, yes. Okay.
The role of systems thinking
Wiktor Żołnowski: You already said a little bit that you need to design solutions that fit the context of the organization when you’re trying to adopt that model. How is it related to systems thinking, or is it related at all?
Kirill Klimov: Yes, I think the easiest way to explain and connect it to systems thinking would be through the process that I’ve already mentioned, which, in Flight Levels terminology, is called flight level system architecture: create a new topology for your organization, basically designing this system for your organization. And yeah, that requires quite a lot of systems thinking. And overall, I think part of the challenge is that most of the people on the ground–and by on the ground, I mean within the organization–they don’t have this expertise in designing and building organizations. That’s not the stuff they’re doing, right? They’re building either the product or their service, bringing it to the customer. It’s not that they learn how to build organizations. Oftentimes, people who are working have spent their whole career in one organization. That’s why the process might be challenging, because you see it through some predefined lens, and you don’t see a lot of different options. And that’s where external help might be useful, just to extend your perspective. That’s actually what happens with that system architecture. Basically, you see what you have, and you see what the options are for designing around it. And obviously, you’re designing around the value, the value stream of how value is delivered through your organization. And with that, we are trying not to do a structural change right away, at least not for sure, not the first thing to happen. Later on, maybe if you decide it’s a good move, okay, but at least not starting from the structural changes, because those are the heaviest changes.
Wiktor Żołnowski: It’s not the first time in Pragmatic Talks that I hear from experts that organizational structure changes should actually follow some other changes, not trigger the changes themselves. So I think that there is something important in that.
Kirill Klimov: First of all, yeah, it often requires a lot of work. There will be some pushback. Most of the time, it puts pressure on people because it’s really changing not only the way they work but also direct reporting lines and so on and so forth. It’s really heavy stuff. And the usual challenge we see with all the agile stuff is don’t plan upfront when you have the least information, because oftentimes, those structural changes are kind of planned upfront with some ideas and intentions, but they’re not necessarily going to pan out. So again, from my experience, it’s way more often than not better to basically observe and learn how the value is delivered, what’s required for that, and then try to organize ourselves around that.
Wiktor Żołnowski: And not always do you even have to make structural changes for that. What I’ve seen a few times in my history, when I used to be a consultant and work with organizations, was that often, actually pretty often, the organizational structure changed by itself. You didn’t need to design it. If you changed some processes or actually changed goals or objectives for people, etc., they followed that and figured out how to change the structure, even if the official structure didn’t change. People’s roles, people’s objectives, and way of working changed. So actually, later on, changing the names of the roles or moving them somewhere in the structure was just a formality. Yeah.
Kirill Klimov: It highly depends on the organization and basically what’s possible and what’s not, because if your scenario is possible, that’s great. With some organizations, I can imagine it would never happen, yeah, because there are too many constraints that would prohibit people from doing that. Of course, the culture also matters. Yeah, if there are people who… basically, what could be done is that you remove those constraints so that that’s possible. And sometimes, the constraints are people.
Wiktor Żołnowski: If you, yeah, but you can remove them, at least in some context. In some countries, it’s not so easy, it’s not so difficult to fire someone.
Kirill Klimov: It’s like one of the mantras I think I learned it from the LeSS community, which I like quite a lot: job security but not role security. When going through the change, we are not going to fire you, but your role is lost, yeah. So you need to adapt to a new reality.
Wiktor Żołnowski: Most of… and this is something that, nowadays, happens a lot. People need to adapt really, really fast to a fast-changing reality, even if the organization is not under any transformation or whatever, because everything is changing so fast that we need to follow it, and we need to adapt.
Kirill Klimov: That part might be–sometimes it’s too pressuring for people because when they realize, okay, my role is not relevant anymore… With some organizations, they are really fine. Okay, sit back, look around, and find what you’re going to do, what’s the way you’re going to bring value to the organization. It might be too stressful for some. Yeah, that’s true, that’s true. They could have a hard time basically finding their new role, and they may leave because of that.
Integrating with existing methods like kanban
Wiktor Żołnowski: So you already mentioned that it doesn’t matter, actually, what methods the teams use when working with Flight Levels.
Kirill Klimov: Actually, not only the teams. It could be something bigger than that, like something used for coordination as well. So, for example, using LeSS and Flight Levels. There are plenty of reports of people who use SAFe and then Flight Levels on top of that, and how Flight Levels was helpful. Because again, the usual story is that SAFe is oftentimes, at least perceived, as too complex, too complicated, with really a lot of stuff, and people are not so agile, not willing to dive into all of that in order to do something. So viewing it through these lenses could really help get value out of it. I know quite a lot of people are using it.
Wiktor Żołnowski: So what about, let’s say, Kanban portfolio management? It could be used in the same way, like teams use Kanban, we use portfolio management to actually manage the value streams.
Kirill Klimov: Overall, I would say that with Flight Levels, a lot of that stuff comes from the Kanban body of knowledge, if you wish. And yeah, all the authors were initially involved in the Kanban community, so there’s a lot of similarity in the ideas and then evolving and emerging. But some of the tooling that was built through the years, some of those are unique to me; I haven’t seen it around, and it’s really useful again when building, for example, that organizational topology, when exploring how you are approaching the work and how you’re interconnecting the systems. Some of that stuff is new.
Wiktor Żołnowski: There are many people who think about Kanban as something like, you know, we have a board, like a Trello board, Jira, whatever, and we use Kanban. That’s it. But even in a situation right now, there is much more behind it. So could you help our listeners understand what Kanban is and what it is not?
Kirill Klimov: I definitely think that board itself shouldn’t be called Kanban. I’m not even trying to fight that war of what should or should not be called Kanban. Yes, Kanban is way more. And that was exactly the feedback at one of my Kanban classes years ago. Usually at the end of the class, I have a closing circle with people sharing some reflections on what they’ve learned and what they might have found. The sharing was that before the class, I thought what we were about to do for two days here… Kanban is just a board and tickets we play with, right? So it’s half an hour of learning, what else? And now, after the class, I realize there is so, so much more, and there are other classes. So there is way, way, way more stuff built together over the years. Now I see it. And yeah, I won’t be able to show what’s built over the years in a few minutes. However, that is exactly one of the challenges I’m seeing around, because the other feedback from another participant of my class was, again, comparing it. He was sharing that, okay, before the class, I thought that Scrum is easy to understand but hard to do. With Kanban, I can see that there’s so much stuff that it even takes some time to understand. And that’s exactly the challenge I’m facing because very often, I mean, yes, you can start with just the board and WIP limitations, right? But in order to even design the Kanban system to start using it, it’s a couple-of-days class, and people are really not ready to invest their time. And that’s why there is a need for more lightweight approaches. I don’t know if it’s good or bad. I don’t know if we should really try to force some minimal amount of learning before doing something or not. I’m keen to try and to see if it works, because really, sometimes it’s not a question. If it’s, let’s say, two days, it’s not going to happen.
Wiktor Żołnowski: Yeah, I think we are not empowered to–we cannot prohibit someone from using a board and calling it Kanban. They could do this and harm themselves a little bit. Or maybe not, maybe that will be the very first step. Then they will learn something new, add, let’s say, WIP limits on each column, then add something else, start measuring things. It happens anyway all over. People just read on Wikipedia what Scrum is and start using it, and then everybody blames Scrum because it’s not working. Come on. I think that our job is to build this awareness of what the methods are and try to teach as many people as possible how to do it well. Sooner or later, there will be enough people on the market who will just be telling others, “No, it’s not as you think. It’s way more complex.”
Kirill Klimov: But that’s also very much a function of the method or approach and what’s the amount of stuff you have to learn before you can start using it. I think it is a very relevant question of finding easier ways of using some of the stuff and introducing it to the organization. And that’s where Flight Levels really comes in.
The five activities of flight levels
Wiktor Żołnowski: Yeah, I was about to say that that may be a good way to introduce other tools, other methods to an organization, because it sounds easy to implement at the very beginning. And starting from that level, when you have some metrics, when you already have some thinking model about your organization, you can see that, for example, there is something missing on the delivery level, and you need to improve it to have a better value stream or something. So then you are at least motivated to do some changes or invest some time. As you mentioned, people don’t have time to invest to learn something, but when you see it, you can simply see the need for investing the time.
Kirill Klimov: Or you’re starting, let’s say, with the strategy because you think there are some challenges there, and then you realize your value delivery is not working, and then you focus there. Because of course, in order to execute on the strategy, you have to bring value. So you have to have a functional level two in order to start working on the strategy, because there’s no point in strategy if you cannot deliver anything.
Wiktor Żołnowski: So it’s pretty similar to the promise of Scrum that I heard years ago: that Scrum will not fix any of the problems that you have. It will only show you where the problems are and make it so painful that you will have to solve them one day or another.
Kirill Klimov: I mean, yes and no, because with the five activities, you’re measuring, then you’re improving. So yes, they are pretty generic, and you’ll have to find your way to do it depending on the level. The implementation details, because, for example, even the first one, let’s say “Visualize the Situation,” how you are going to visualize stuff on the team level, on the value stream level, on the strategy level would be different. Or the second one, “Create Focus,” right? So what are the constraints, and how are you going to do it on the team level, again, stream level, and then the strategy would be very different. Still, though, if you’re going and doing that, you are going to improve over time. So yes, you’ll have to think about the implementation on the particular level, and that would be different. You may have some experience from what you’ve been doing in the past, you can reuse it, or you’ll have to find new ways of doing it. But still, after you’re doing it, you’re going to be improving your system. Because, for example, just to provide a quick illustration so it’s not that abstract: creating the focus on the team level or even the stream level, limiting work in progress would be one way of doing it. Timeboxing would be another way of doing it, typical for Scrum. Now, on the strategy level, it’s not going to work.
Wiktor Żołnowski: Yeah, I painfully felt it recently when we tried to do this. No, it doesn’t work.
Kirill Klimov: You have to find other ways. And yeah, there are other ways and other ways out. So the way you’re going to implement these practices across the levels would be different. Still, you have general guidance, and also you have a community of people who are… not really even important, the community of people who are doing it. You have a lot of people who are doing it even without calling it this name. So you can definitely look for inspiration, advice, whatever you call it. Basically, steal it from others.
Wiktor Żołnowski: You already mentioned a few times those five activities from the five Flight Levels. Could you name them all for people, yeah?
Kirill Klimov: So that is: 1. Visualize the Situation. Most of us are in knowledge and creative work, which is, again, by definition, intangible. You cannot see the result of the work. Therefore, visualizing the work is a prerequisite for being able to collaborate around it, to align on it, and so on and so forth. And of course, you can do it on all the levels. 2. Create Focus. So that’s about constraints or how you are more or less selecting what to do and then not disturbing people with other things. As you mentioned, in Kanban, it will be with a WIP limit, a work-in-progress limit. In Scrum, it will be the sprint; the sprint with the sprint goal is where the focus comes from. And basically, you’re taking all the stuff that you’re capable of delivering. 3. Establish Agile Interactions so that we can obviously operate the whole system and make the work flow through it. 4 and 5. Measure and Improve. And of course, in order to improve, you have to measure where you are. And that measurement is on the product side, where you have to measure in order to be able to improve what you are delivering and adjust accordingly, but also for the change. Because in order to make meaningful change, you should not only understand where are you going but also how you’re going to measure your progress. Because if not, then later on, how can you evaluate if you’re alone? And then you iteratively improve, measure, and improve. And what is important in the Flight Levels context is you apply those on three different levels because it’s going to be different. So you’re doing it with your team in order to improve how your team works and what your team is delivering. You’re improving it on the stream level, the value stream level, in order to improve how teams interact together to bring value to the customer. And you’re improving it on the strategy level as well, in order to align the work that you’re doing.
Wiktor Żołnowski: So what about the frequency of measuring and improving on each level?
Kirill Klimov: Depends on the level, yeah. I can imagine that on the team level, it’s probably most often, but then the value level, the product level, is less often. And the strategy, you are not changing, you are not messing around very often, but you are still kind of observing, monitoring. So measurement happens, could happen, all the time, live. And then the cadence of other activities, again, you’re designing it. So in different contexts, it could be different. Strategy, I just got this question today after the talk, the strategy review, the adjustment of your strategy based on how you’re going, how often to do that. From my experience, it might happen once a quarter, once every two months, maybe not more often than that, because not enough is likely going to happen in a shorter timeframe. Still, I can easily imagine some contexts where even more often would be applicable, possible, but that will require probably a bit more instrumentation behind that.
Advice for leaders in complex organizations
Wiktor Żołnowski: If you could provide advice for leaders, especially leaders from some very complex organizations like big organizations, very heavily regulated organizations, where to start or how to start with Flight Levels, what would be the advice?
Kirill Klimov: I should fall to the usual answer, which is, “it depends.” But I can clarify, because oftentimes, the challenges that organizations are facing are very, very different. Basically, you should start by addressing your main issues, challenges at the moment. And from there, maybe after that is solved and not an issue anymore, you jump to something else. However, oftentimes it is a problem or a challenge even to see what your main problem is. In order to do that, sometimes visualization can help, sometimes bringing some measurement and thinking about metrics, searching for bottlenecks, for example. Yeah, measurements, visualization. “Oh, here we have a bottleneck, so here we have some problem.” I don’t think just that, but observing that over time will potentially reveal some bottlenecks. And again, it’s like every system obviously has a bottleneck. The problem with knowledge and creative work is that the bottleneck is moving through the system. Because if it’s a static place, it’s easy to spot, and probably you’ve already not only figured it out but fixed it. But it’s way more interesting and challenging, and interesting because of that, when it’s dynamic, so it moves over time. And then how do you manage that?
The future of modern management and AI
Wiktor Żołnowski: Okay, let’s try to imagine what the future will bring us. You already mentioned what you see is that people and organizations require some kind of simplification and some easy method to actually start making changes when the learning curve is too steep and people need to learn a lot to actually start working. They usually don’t have time for that.
Kirill Klimov: I mean, that’s yes and no, because it would be nice for this kind of concept, idea, model, metaphor, whatever, to be attractive and easy enough to start with. Because overall, the world has become only more and more complex. Organizations are really complex for a good reason. They’re not going to oversimplify, and it would be naive to expect simple solutions to fix really complex organizational problems. And that complexity, overall, I would say, is about to grow. And first of all, our internal capabilities should grow as well in order to support that. However, it doesn’t mean it should be there from the very beginning. So we should start from somewhere. We should see a method or approach at least helping us along the way. With a lot of change, overall, and in organizational change as well, momentum is built. So basically, when you see something is working, you are ready and willing to invest more time and energy into it. And yeah, that’s what I think a lot of people are looking for.
Wiktor Żołnowski: How do you think, what will the role of AI be in modern management methods? This is the question that I’ve recently been asking everyone I speak to.
Kirill Klimov: Two parts of the answer. The first one, I think you probably already got it from a lot of people, which is, while not necessarily AI is going to kill a lot of jobs, still, people who are using AI would be way more efficient than those who are not. The other thing is that, yeah, that’s kind of interesting. It’s something I was about to put into a blog post for a pretty long time, still wasn’t able to do it, so I can quickly share. Interestingly, years back, I was thinking, okay, probably the first jobs it’s going to kill would be more mechanic, simple jobs, like drivers, so autonomous driving and so on and so forth. And we are fine, we are the creative industry, like coaching and all that stuff, we are fine, we are safe. Interestingly, it turns out to be the other way around. Because with, let’s say, some autonomous driving, there is legislation in the way, so it’s not everywhere, for sure it’s not going to be anytime soon. With that, I can see AI already doing quite well on the coding side. So that one for sure is affected already. So that’s very interesting to me. The other part is that it is already huge in the learning process, so how you can learn new stuff and to what extent it might be helpful already. So if in the past, let’s say, you are an internal change agent, a Scrum Master, you have some challenge you’re facing, you have to run the second retrospective of your life, and last time you did it so you have something, and now you basically heard from somewhere that you should be switching different approaches, different formats so that your team isn’t bored and it works. You can, these days, easily discuss it with ChatGPT and get ideas from there, get some inspirations. It is perfect for that matter. And you can not only get direct learning from it but also new directions. And for that purpose, it’s really perfect. Not even starting the whole point about using it with software engineering, like copilots. That’s also really, really working well.
Wiktor Żołnowski: So last but not least, according to what you said about how AI is impacting our work, some things will change, some things will stay the same. Of course, it’s impossible to prepare fully for anything that will happen because we still don’t know what will happen. But how could people prepare themselves, their organizations, their approach to building, creating strategies, implementing those strategies, for what is going on in the market right now and this, I don’t want to use the word “revolution,” but the progress that we as humankind are making with AI?
Kirill Klimov: I think that’s kind of universal, and my advice won’t change. I don’t know to what extent it’s practically helpful, but that is building the internal capability for the business agility of your organization. So basically, being ready to change, because the change is coming, it’s inevitable. The more capability for quicker change you have, the better you’ll be over the years. But again, this has been the case for many, many years. Those companies who are able to address and react to change, but also not only be in a reactive mode but also try to predict what’s happening, evaluating, experimenting, and seeing what makes sense, obviously they’re going to be more successful.
Wiktor Żołnowski: Thank you very much. That was quite a brilliant piece of advice. As you said, it’s pretty universal, but I believe it’s still valid, and not so many organizations or people in organizations are aware of it yet, so it’s good to repeat it over and over again.
Kirill Klimov: You see, it’s crazy because oftentimes, we tend to fall too much into the situation like, “What if it’s fine now? Now, if it’s okay now…” Behind that, that’s kind of the general case, the general issue I’ve seen so many times. So, for example, for an organization, for the top of the organization, it might be obvious that in five years, there is no future if we don’t change. We are not changing, somebody else is eating our lunch, not breakfast, everything. For everybody in the organization, for the whole middle management, there’s no motivation for changing. We have plenty of cash at the moment, it’s okay now, why do we have to change? That’s a big issue. That’s one of the real challenges a lot of organizations are facing. And how you’re going to spread that motivation for change, because again, sometimes it’s clear to somebody, and then how are you communicating that? Sometimes it’s not even clear, but then, boom, the next day, somebody eats all your breakfast. Yes, so…
Wiktor Żołnowski: Thank you, thank you very much, Kirill. It was a great pleasure to talk with you about Flight Levels, about all of these thoughts, about strategy, about how organizations should approach the changes that we are facing all the time. Thank you to everyone who watched this. I hope you enjoyed it. Please remember to subscribe to our YouTube channel, Spotify, and Apple Podcasts. But also, Kirill, how can people find you on the internet?
Kirill Klimov: The easiest way to find me would be through the website, kirillklimov.com. Just search. And then yeah, social networks, all that stuff. So I’m there. Feel free to reach out.
