Are We Repeating Our Leadership Mistakes at AI Speed?

10 min read

We’re learning extraordinary new ways to build software and run organizations. Having lived through several major transformations, I’m beginning to recognize some familiar leadership patterns. And I wonder whether we’re applying what we’ve learned from those experiences or allowing the speed of AI to amplify the same mistakes we’ve made before.

One thing I’ve been noticing in recent conversations with senior technology leaders is how quickly an opinion about AI can become an expectation for an entire organization.

I’ve heard ambitious predictions about how much software AI should generate, how quickly teams should deliver, and what future engineering organizations might look like, sometimes from executives whose own AI experience is relatively recent.

I understand the excitement. I build with AI tools and agents myself, and I’ve seen how much they can accelerate what one person can accomplish. The more I learn, the more I realize how much we still have to figure out.

What concerns me is how quickly an early success or promising capability can become an organizational target, sometimes before we’ve had enough experience to understand its broader consequences. Once an executive sets that direction, it can become difficult for others to challenge the assumptions behind it.

Senior leaders are expected to establish direction and communicate confidence. I’ve carried that responsibility for years. AI is moving so fast that even experienced leaders are still developing their understanding.

I’ve seen what happens when leaders refuse to reconsider their assumptions. Now, with AI moving so quickly and pressure coming from every direction, I wonder how much of that experience we’re about to repeat.

I spent the first part of my software engineering career in environments shaped by Waterfall, extensive governance, long development cycles, and management practices that emphasized planning and control.

Over time, I helped organizations transition to Agile, Lean, DevOps, continuous delivery, and eventually value stream management.

Those changes taught me how hard it can be for leaders to change how they think.

I’ve seen organizations invest heavily in Agile training, roles, and frameworks while operating under familiar assumptions. Teams were expected to become autonomous, but decisions still required multiple approvals. Organizations wanted faster delivery while maintaining governance designed around infrequent releases. Leaders celebrated velocity while prioritizing utilization and individual output.

Practices changed faster than management behaviors.

I experienced that friction firsthand. Some leaders were exceptional: they stayed curious, listened, challenged their own assumptions, and learned alongside their teams. Others seemed convinced they already understood what the transformation required.

I’ve written about these experiences repeatedly because I believe leadership mindset heavily influences whether transformation succeeds. I also had to reconsider my own habits.

One of the central lessons I explored in my book, Profitable Engineering, came from that experience:

The hardest part of becoming a senior leader was not learning new tools or practices; it was unlearning habits that had once made me successful.

I’ve returned to that lesson often as I’ve watched AI adoption accelerate. The technology is different, and the speed is extraordinary. Some of the leadership patterns are becoming familiar.

I came into leadership through software engineering. Although I’ve spent more than a decade leading engineering organizations and developing managers, I’ve never lost my interest in building software.

For roughly the past year and a half, I’ve been vibe coding, experimenting with AI coding tools and agents, and building solutions. I wanted to understand the technology firsthand and explore opportunities outside my day job that would’ve previously taken more time or resources.

It’s been exciting and occasionally frustrating. I’ve watched ideas become prototypes remarkably quickly, then spent hours correcting implementations, improving context, debugging, and questioning agents’ decisions.

That experience has influenced how I approach AI adoption as a leader. My journey began several years ago with AI literacy, understanding capabilities and limitations, and establishing sensible practices around security, privacy, and intellectual property.

As the tools matured, our focus expanded into enterprise adoption, engineering practices, context, testing, quality, and how to help teams use AI responsibly. More recently, I’ve been exploring the broader implications of agent autonomy, organizational design, and AI economics.

Each stage has expanded my understanding and raised new questions. I expect to keep learning.

A conversation between Lenny Rachitsky and Molly Graham helped me think about the human side of this transformation.

Molly revisited her Give Away Your Legos advice about handing off responsibilities as organizations grow. AI complicates that idea.

A capable colleague can eventually take ownership and much of the mental burden. With agents, we still provide direction, evaluate results, correct mistakes, and remain accountable. I’ve experienced that myself. Several agents can work simultaneously, but their output and next steps still require my attention.

Molly describes engineers who miss writing code, solving problems, and working closely with colleagues. Others are excited about directing agents. I understand both reactions. I still enjoy writing code, even as I appreciate how much AI allows me to accomplish.

Lenny’s 2026 technology-worker survey reported a significant year-over-year increase in burnout, from about 45% to 56%. At the same time, many respondents said they felt more productive, empowered, and excited about their careers. The survey doesn’t establish that AI caused the increase, but it raises important questions about expectations, workload, and how people are experiencing these changes.

People can accomplish more while feeling exhausted or uncertain about their professions. Respondents who rated their managers more highly also tended to report better work experiences, another reminder of how much management matters during change.

Vanessa Meyer, founder of Afoot, recently described five things beginning to break as AI-native organizations rethink management. One observation caught my attention.

I’ve often learned a lot about what’s happening on a team simply through the questions people ask. Sometimes a question about requirements reveals that something isn’t clear, or a conversation about priorities uncovers dependencies we hadn’t considered. Those everyday interactions also help managers understand where people might be struggling or need additional guidance.

When more of those interactions happen privately with AI, managers may lose visibility into what people understand, where they’re struggling, and what support they need.

AI also makes it easier to work beyond traditional responsibilities. Engineers generate designs, designers build prototypes, and product managers create software. People can unknowingly duplicate effort or introduce conflicting solutions and dependencies.

The work can become less coordinated even as individuals become more productive.

I’ve spent years helping organizations understand work in progress, bottlenecks, and the difference between individual productivity and end-to-end flow. AI makes those lessons especially relevant. More output may look impressive. We still need to know whether flow, quality, and customer value are improving.

This is where I see some familiar leadership patterns emerging. We spot a promising improvement, start measuring it, and sometimes make it an organizational expectation before we understand its broader impact. With AI, those numbers can improve remarkably quickly, while problems involving quality, coordination, and people may take longer to become visible.

Jacob Morgan’s article, Your Best New Managers Have No Direct Reports, adds another perspective. He describes people who manage consequential work through AI agents, exercise judgment, coordinate complex workflows, and remain accountable for outcomes without anyone formally reporting to them.

He distinguishes agent leadership from people leadership. Engineering organizations already recognize that technical leadership and people management require different capabilities. AI expands the opportunities for technical and agent leadership, which may deserve new recognition and development. People still need coaching, feedback, and help with difficult performance issues.

A senior manager recently described an engineer who appeared to use AI agents to generate code and answer pull request (PR) review comments.

A senior reviewer raised technical questions and received almost immediate responses, suggesting an agent was replying. Eventually, the team had to call on the author directly to engage.

Using AI was acceptable. The concern was whether the author had reviewed and understood the implementation and was taking responsibility for it. The manager knew of a previous tendency to cut corners. Response speed alone can’t establish what the engineer understood, but the situation raises questions about quality, ownership, and collaboration.

Someone needs to understand what happened, provide coaching, and address recurring concerns. The reviewer who spent time seeking meaningful answers needs support too.

I’ve frequently emphasized a principle throughout our AI adoption efforts:

AI reduces task effort, not responsibility.

An engineer may save time generating code while a reviewer spends much longer validating it. The productivity gain can shift work to someone else.

Meanwhile, some organizations are reducing management layers and expanding reporting spans. Executive expectations can become team commitments before we understand their impact on quality, delivery, and people.

I’ve supported flatter organizations for years. In one I helped lead, small, autonomous, cross-functional teams owned delivery while dedicated managers developed people. We kept management spans modest to preserve time for coaching, feedback, and support. That model evolved through years of experience and learning.

I’m still trying to make sense of what AI will ultimately mean for engineering team structures. I’ve written about the possibilities before, drawing on industry research, conversations with other leaders, and my own experience designing and leading engineering organizations. In From Two Pizzas to One: How AI Reshapes Dev Teams, I explored how AI might enable smaller, more autonomous teams. Later, in AI Can Shrink Your Team. It Cannot Shrink the Work, I examined what happens when more responsibilities and judgment become concentrated in fewer people.

I’m hearing different predictions about flatter organizations, individuals managing agents, and AI taking on more responsibilities within existing roles. I can see possibilities in all of them, depending on the organization and the work.

Given that experience, I’m reluctant to declare what the future structure should look like. My instinct is to start with the responsibilities that need covering, understand what AI can reliably support, and then assess capacity, coordination, and leadership needs before designing roles and teams. I fully expect some of my thinking to change as we learn more.

Whatever structures emerge, coaching, development, feedback, and support need clear ownership and sufficient capacity. That matters given how long organizations have struggled to develop managers.

Organizations have spent decades promoting strong technical contributors into management without consistently preparing them for people leadership. I know because that was part of my own journey.

I was recognized for my engineering capabilities and given opportunities to lead. I had much to learn about coaching, feedback, conflict, performance, and how my decisions affected others. I made mistakes that affected people who reported to me, and those lessons stayed with me.

Mentors, feedback, leadership programs, and learning from other managers helped me improve. Many people don’t receive that kind of support.

Now managers must navigate changing roles, AI-generated work, new productivity expectations, and employees uncertain about their careers.

Junior engineers have traditionally learned through implementation, reviews, mistakes, and mentorship. As AI takes on more of that work, we need deliberate ways to develop the judgment required to evaluate sophisticated systems and become future technical and people leaders.

I’ve always believed that people-first leadership involves helping employees develop, understanding their circumstances, providing honest feedback, and holding them accountable. Those responsibilities require time, experience, and continued development. Managers need that same support from their own leaders.

What concerns me is that we’re adding more complexity to management while some organizations are reducing the capacity to handle it.

Increasingly, executives are expected to demonstrate expertise across AI strategy, adoption, agentic engineering, security, governance, organizational design, and economics.

Recently, while talking with a software company’s leadership team, I saw those expectations expand. A potential partner asked about the scalability of its AI-based platform and the economics of operating it at different volumes, including model costs and provider agreements, alongside familiar questions about architecture, reliability, and cloud costs.

I’ve explored this in AI Token Spend Is Becoming Product Economics, where I examined how AI affects both the cost of building software and the cost of operating products that use it. These are becoming important considerations in the decisions senior technology leaders are expected to make.

I encounter similar expectations in conversations about my book, advisory work, and senior engineering opportunities, including with executives at AI-native companies. I welcome serious questions about experience. Some roles require deep specialization.

But I sometimes wonder how we’re defining expertise in a field changing this quickly. I’ve spent years learning, leading adoption, and more recently building solutions directly with AI. I recognize the value of that experience and how much I still have to learn.

These conversations occasionally bring back a familiar feeling of impostor syndrome. They also remind me to distinguish genuine gaps in my knowledge from expectations that may be unrealistic for any one leader.

I worry about the pressure executives may feel to demonstrate certainty simply because of their position. A senior title comes with decision-making authority and accountability. Developing the understanding required to exercise that authority responsibly is an ongoing responsibility.

Some of my best leadership lessons came from recognizing that someone on my team understood a problem better than I did. Learning to listen to talented engineers, architects, product leaders, security specialists, and managers, and to challenge my own assumptions, made me a better leader. That approach matters even more with AI.

I keep coming back to Agile and DevOps transformations, and what teams can accomplish when leaders encourage experimentation and work through uncertainty with them.

AI is moving faster than any transformation I’ve experienced. Companies are understandably concerned about competitiveness and new opportunities. We need leaders willing to make decisions and accept accountability even when information is incomplete.

We also need organizations where engineers, managers, and specialists can challenge assumptions and share evidence. Ambitious AI targets can encourage progress when we measure the results and adjust as we learn. The same applies to decisions about management layers, staffing, and investment.

I need to hold myself to that standard. After decades in engineering and leadership, I have formed beliefs that may need to evolve.

I don’t want to spend the next decade revisiting the same leadership friction we experienced with Agile, only with AI replacing the terminology. I’d much rather work with leaders who bring different expertise, challenge one another thoughtfully, recognize what they don’t know, and learn together.

We have an extraordinary opportunity to improve how software is built and how organizations operate. I hope we give leadership development and our own assumptions as much attention as AI adoption.

We’ve spent years telling employees they need to embrace change and continuous learning. As AI transforms our organizations, are the people leading those changes prepared to hold themselves to the same standard?

Stay curious. Learn to unlearn. Rethink your understanding.