Your Impatience Is Not Their Urgency

When I picked up the CEO hat and effectively stopped being an engineer, out of sheer necessity as the team grew around me, I felt a constant sense of impatience. Things didn’t go fast enough. They’d be faster if I could just do it myself. I’ve got all the context, after all, knowing plenty about the product’s insides and about the business and market. So clearly I could just spend a weekend building what the engineers on my team seemed to take forever to build. The results would be better and I’d not have to wait for my team to get them done.

The irony was that, as an engineer myself, I was aware of the processes and complexity involved. What I wasn’t aware of back then was that my responsibility was elsewhere. I was supposed to help my team do their best work. In my role as CEO, I was supposed to give guidance, direction, and the right context on what’s important and what isn’t. But it was a lot easier to just do the work myself, giving me an instant sense of satisfaction.

It’s such a classic trap to experience this level of impatience, which is really what’s behind the urgency. In conversations with my coach back then, I talked about a sense of urgency that I was missing in the team. Today my clients tell me the same thing. They talk about wanting a sense of urgency in their teams. They want their teams to move faster. They imply that teams aren’t working fast enough, working on the wrong things, that they themselves could just do everything themselves. It’s faster to do it themselves than taking the time to explain everything and give feedback throughout. And with AI, why do you need so many engineers anyway? This isn’t my question, this is what I’m hearing from clients who hear it from their CEOs or are wondering themselves.

Behind it all isn’t just impatience. It is part about not fully understanding the complexity of software engineering. Even when AI is taking over so much of the development lifecycle, human judgment, coordination, collaboration, and communication still need to happen. AI doesn’t remove dependencies. This isn’t to say software development is magic pixie dust. It’s the CTO’s job to make the process transparent to the executive team. But software development isn’t just writing code and deploying it. That belief was pretty widespread before AI came along, and it’s only exacerbated now, as the boundaries of what’s possible seem to evaporate.

The other parts may be fueled by the bubbles we exist in. Tech as an industry has a tendency to make everything about survival. Adapt now or be left behind. Charles Darwin beckons.

And then there’s the engineers who (at least appear to) resist the introduction of AI, or at least they don’t seem to be fully embracing it. They’re still slow, after all, when they could just do so much more. Executive words, not mine. Why do we need them again? In times when one could just spin up a slew of agents and have them get into a loop of analyzing, planning, building, testing, and shipping, why do you even need people?

Executives do tend to live in their own little bubbles, a reality distortion field that’s in part of their own making and part created by the nature of their position on the organizational chart. But that doesn’t mean the gap between relentless optimism and reality shouldn’t be constantly adjusted. Executives do need to make an effort to understand the work as it’s being done not just as they wish it to be. You can’t have one without the other. You can’t just will transformational change into existence.

Impatience is not a good advisor as you want your teams to change. Taking on the work yourself, just to show the teams that even you can do it, isn’t convincing. That’s in part just showing off and likely contributes to increasing the sense of hurt and loss your teams might be feeling. Some CEOs have little patience for the fact that an entire industry is mourning, that they lost a sense of identity and are being asked to move, nay run, towards an uncertain future.

Lacking any meaningful way to prove that things are slow, leaders fall back on metrics that have long been known to show no representation of actual value: output-based metrics like number of pull requests, lines of code, features shipped, or tokens used. They provide the illusion of progress and speed. According to Atlassian’s State of Teams 2026 Report: “89% of executives say AI has increased the speed of work, but only 6% feel confident they can point to specific organization-wide AI ROI.”

Lines of code written/generated and shipped to production have little correlation with value for the customer. The uncertainties of how to measure individual and team contributions of engineers to the bottom line remain. But in times of such rapid transformational change, it’s easy to fall back onto what feels predictable and safe, no matter if it’s the right or wrong way to measure performance. In times when performance becomes an even fuzzier term, it’s nice to hold onto something that feels certain.

Whether the change needs to happen and whether it’s fast enough, I’m not here to argue about that. What I want to bring up is a sense of empathy, maybe one of the few things we still have left that makes our work feel human. Executives need to build up more empathy for what motivates their teams, for what they’re losing as they’re asked to adapt to rapid change, and as that change isn’t happening as fast as imagined. Executives need to seek to better understand how work is actually being done and talk to their teams about how the gap to how the work should be can be closed effectively.

What do I advise to clients who come to me with the questions described above? You need to talk to your teams. If you can’t understand why some engineers aren’t adopting AI as fast as others, talk to them. If you don’t understand what’s still taking so long to get code shipped, talk to people, understand the process and all the steps involved before making a judgment. Understanding the whole is the precursor to start making changes.

Even more importantly, this is an opportunity to reflect. If you find yourself, like I did once as a CEO, impatient with your team, tempted to just have a crack at it yourself, take a moment of pause. Ask yourself if you really fully understand the process, enough at least to make a judgment on whether it’s slow. Reflect on whether you’ve done the work of leadership, including providing your teams with clear priorities, a strategy, and the right levels of authority and autonomy to make fast decisions. When code costs next to nothing to create (at least in terms of time), it’s so much easier for entire teams to move into the wrong direction.

Think about whether you’ve set the right expectations with them or whether you’re just upset that they’re not doing what you think they should be doing. None of these artifacts really exist, and nor can your teams expect to live up to them, unless they’re spelled out, written down, and accessible in a shared space. AI changes none of that. It’s still the main work of leadership.

Reflections

Reflect: Think about the last time you experienced a sense of impatience. What was going on, what did you experience? Did you use the word urgency to describe it and deflect responsibility to your team?

Assess: When you felt this sense of urgency, did you fully understand the situation and all contributing factors? What could you have done to help rather than judge? What work of management hasn’t been fully done yet, like putting the right direction, priorities, and processes in place? Look at how your team is making decisions and also what blockers or bottlenecks might be in the way of them shipping faster. Talk to your team to understand more about their processes and what’s getting in the way.

Do: If you haven’t done it already, do the work of management and leadership. Create the right artifacts that tell your team what’s important and what isn’t. Figure out what the next bottleneck is in the processes or organizational structure and work to remove it or work around it. If there are people closer to the bottleneck, get them involved in the conversation.

• #Leadership
• #Communication