A note up front: don't expect any innovative AI tools or techniques here. This article just describes how to find the time for AI the good old-fashioned management way.

The problem: "I don't have time for that"

If I had to name the one overwhelmingly dominant reason why companies don't innovate, don't fix long-term problems and don't adopt AI in any depth, it's the sentence "I don't have time for that" coming from a leader/manager. Often it doesn't even get said out loud, because obviously nobody has time! This article is a case study of how Milan dealt with exactly this situation.

Milan's context: Developing people starts with developing the leader

Milan manages 6 engineering teams. He's a thoughtful guy who is always studying something and puts the same energy into developing the people around him. He sees learning and innovation as part of his role as a leader.

His department worked in a classic way - Team Leaders ran their teams and had regular 1:1s and joint meetings with Milan. They worked together on standard operations as well as on big projects and development activities. He didn't make decisions alone, he brought his Team Leaders in. He knew why his team exists - to deliver value to the company - and he was willing to change even the way he himself works, based on data and his own reflection. Milan had the overview, helped wherever he could and reported for the department to company leadership.

Over time, though, he realized he was doing more and more things he no longer needed to do, and he was struggling to keep up with it all. Instead of taking it as a given, he started tackling it systematically. Not so he could work less, but so he could put the saved time back into developing people, innovation and exploring AI.

The request: How do I free up my hands?

So Milan came to me with a request: he needed to free up a significant part of his capacity for strategic and development activities. He knew exactly where the real problem was:

• That he often handles things his team could/should handle
• That by doing "more than needed" he sometimes actually slows his team down
• That his 1:1s are more "co-creating and co-working" than a proper development meeting
• That they had already solved this change with the team before, more than once - but he kept slipping back into the old way of working, especially when under pressure it was faster to just solve the problem himself

We agreed that just "delegating more" wouldn't be enough. The change had to be prepared so that the team understood the point of it, could take part in the new split of responsibilities, and so that it was clear how we'd measure that the new model works. So we put together a joint workshop on redefining responsibilities. My role was mainly preparing the structure of the change, facilitating the joint discussion and making sure the good intention turned into a real change in how the team works.

Preparation and the workshop itself

(a hands-on guide you can use in practice)

The preparation had two phases:

1. Milan told his team he intended to work on this - and why he was doing it. The important thing was to get across that the goal wasn't to "hand out tasks to subordinates", but to prioritize all the activities together and split them as partners, based on everyone's options and skills. Leaving everything as it was was also an acceptable outcome.
2. We collected input from Milan and from his team, the specific questions were:
   
   1. What does the company want from us and how do you recognize a well-functioning department? (We need this to align our goals)
   2. How do we measure it? (So we don't mix up soft goals with the real measurable goals Milan/the team have in their KPIs)
   3. What do we need for a self-managing department?
   4. What stays with Milan?
   5. Bonus: What should Milan be doing that he isn't? (So we don't leave out something important just because it isn't happening right now)

We put everyone's outputs onto a prepared Miro template. That gave us a list of areas we had to go through. Before the workshop, Milan went through the list on his own and marked the areas he felt he didn't want to, or shouldn't, give up.

At the workshop with the whole team, we then went through each area:

1. What it's about and why we need it as a team
2. Whether we can manage it without Milan and what we need for that
3. For the areas Milan didn't want to/couldn't give up, we clarified why (and for some of them we changed it after all)
4. For each area, the team chose a new owner responsible for it - either a specific person (the lead tester took over incident management and communication with company leadership), a rotating responsibility (running the team meeting), or the whole team (preparing topics for the team meeting).
5. For each area, we wrote down the actions that have to happen for the team to take it over (e.g. communicating this to leadership, sorting out access to systems, redefining the formal role with HR, etc.)
6. For each area, we also thought about how Milan will know the activity is running properly without him - this was the harder part, but all the more valuable, because the team had previously paid little attention to formalizing measurement like this. Which is why there were a lot of "start measuring X" type actions here.
7. Every now and then, change activities/projects got mixed in with the regular responsibilities (BAU) - we went through those the same way, so that Milan wouldn't be indispensable for them either.

In the end we had a complete list of the activities the department needs to run, their new owners and metrics.

Team autonomy: Being able to leave room for others

Already at the workshop it was becoming clear that the Team Leaders had enough experience and skills to handle many of the areas themselves, they just weren't fully using it yet. So we agreed on a number of experiments in which Milan would no longer be the main active "driver", just an observer and contributor on request. This was new for both sides - for the team to take on more responsibility and occasionally even have room to fail a bit, and for Milan to not step in, even when the team's solution went in a different direction than he would have taken it. We kept reminding each other that unless it's a major failure, this is exactly the necessary part of the learning process.

Milan and I wrote to each other about how it turned out several months later. Direct quotes as Milan sent them to me:

1. How many hours a week did you spend on operations before, and now?

I wouldn't want to exaggerate with an exact number, but realistically we're talking high single digits of hours a week that I used to spend on operations, in meetings and in 1:1s, dealing with things the Team Leaders now handle themselves. That time has now been freed up for more strategic topics. It's not just about extra hours – it's mainly that my head is now free for things that need longer, uninterrupted thinking, not just firefighting.

2. Did delivery change when you stopped managing hands-on?

Honestly – at first it was a bit bumpy. The Team Leaders were reaching for decisions I used to make, and we had to find common ground on what exactly falls under their mandate. But it settled down fairly quickly and today I'd say things run more smoothly, because nobody's waiting for my approval. The best proof came on its own – we had a weekly operations meeting where I used to bring most of the topics. After we announced the change, the Team Leaders took it over, filled it completely and solved everything themselves, without me stepping in. It was unexpectedly fast and it was a moment of self-reflection for me – that until then I'd maybe been unnecessarily standing in the way.

3. The hardest moment when you had to bite your tongue and not step in?

It's not really a dramatic moment, more a recurring experience that still surprises me: I hand over a task the way we agreed, I frame the problem the way I'd solve it – and a Team Leader comes back with "wait, it should be like this" and it fits really well, better than the way I saw it. At first that was hard to swallow, but these days I tell myself – he really does know better, and that's exactly the result I wanted.

4. Where does the freed-up time go?

The whole point of the change was to get out of operations into a role where I work across project and strategic topics: setting up KPI/OKR frameworks for the whole department, developing people and their AI adoption, process and compliance topics. It's a shift from "I'm part of solving most problems" to "I'm building a system where people can solve problems well on their own". My capacity is a limited resource just like any other energy in the system. The point isn't to use it at a hundred percent, but to use it where it brings the most value.

5. What surprised you most about the Team Leaders' reaction?

The strongest positive surprise was that story with the operations meeting - how quickly and independently the Team Leaders made it their own. I'd give it 5 out of 5. The second big realization was how much it helped that we went through the change together - not me sending them on a course, but us learning the same thing at the same time. One thing that ties in well with this started even before we launched the transformation: one of the Team Leaders and I set up a reading club where we read development books together and then talk about them. Thanks to that we had the same concepts and analogies synced in our heads - for example from the books No Rules Rules and Drive - and when the actual transformation came, we were able to talk about it in a shared language. I think that made the whole process a lot easier. As for negative reactions, I didn't notice any big resistance, more a natural fumbling around at the start that gradually settled down.

Conclusion

The plan worked out and Milan now has significantly more time for AI adoption and for further developing his teams. It's hard to measure, because he immediately reinvests the freed-up time, but his statement that "my head is now free" confirms we went about it the right way and got rid of whole topics, not just shortened the intervals (see my recent article on the Attention Tax). Four leadership lessons were confirmed for us:

1. Good delegation is a way to make much better use of the skills and energy of the whole team. When a manager handles things their people know how to do and can decide on, they aren't just wasting their own capacity - they're unintentionally slowing down the whole team. Taking on more responsibility costs you some capacity in the short term, but in the long term it removes a lot of waiting for the manager and increases independence.
2. It's important to be ready to really delegate responsibility and not step in. If you just hand out more tasks and at the same time keep checking and fixing everything, you won't free up your head. So functional delegation needs not just a task, but also a clear mandate and a way to tell that it's working.
3. Really delegating isn't easy - the "I'd do it better" urge shows up almost every time. Sometimes even rightly so. The leader's job is to create an environment where their people can take on more and more responsibility and where everyone can learn faster than before.
4. Delegating responsibility also forces a manager to redefine where they themselves bring the most value. For a senior leader, this value typically shifts away from operational management towards developing people, the system of work, strategy and change. That's exactly what creates space for the things that easily get pushed aside in day-to-day operations: thinking, learning and experimenting. Today, for example, in AI.

‍