13 min read
Not your team. You.
When was the last time you opened a terminal? Not watched a demo. Not reviewed a dashboard. Not nodded along in a vendor pitch while someone showed you what an agent could do. When was the last time you actually sat down and built something?
I had a call last Tuesday with a CTO — Fortune 500, runs about three hundred engineers — and I asked him that question. There was a long pause. Then he laughed. Not a real laugh. The kind of laugh that means I don’t want to answer that.
If you’re having that reaction right now, this article is for you.
You Have Been in That Chair a Long Time
Twenty years. Maybe twenty-five. You’ve been leading engineering organizations since before the iPhone shipped. You survived the transition from waterfall to agile — or at least you survived the renaming. You were in the room when someone first pitched cloud and you said “not yet.” You were there for DevOps and said “we’re not ready.” Continuous delivery — “maybe next quarter.” Microservices, platform engineering, infrastructure as code, all of it.
And every time, your move was the same. Wait. Evaluate. Commission a report. Form a committee. Run a pilot that touches nothing real. Wait some more.
Here’s what nobody says to you, because you’ve been in that chair long enough that people stopped trying: the waiting wasn’t caution. It was comfort. Every year you delayed was a year the org stayed shaped the way you understood it. A year where your mental model of how software gets built — the model you built your entire career on — didn’t have to change.
The waiting kept you in power. That’s why you waited.
Let Me Describe Your Tuesday
Tell me where I’m wrong.
You start the morning in standup. Fifteen people on camera going around in a circle saying what they did yesterday and what they plan to do today. Nobody’s listening. Everyone’s waiting for their turn. The scrum master keeps it under twenty minutes and considers that a win. You attend because it makes you feel connected to the work. You haven’t connected to the work in years. You’re watching a ritual you created and calling it management.
After standup you’ve got a staff meeting. The topic this week: story points versus t-shirt sizing. Your director of platform feels strongly that points create false precision. Your director of product engineering feels strongly that t-shirts are too vague. Neither of them can tell you how long it takes a feature to go from idea to a customer’s hands. Neither of them has ever been asked to. You spend forty-five minutes on this. You’ll spend forty-five minutes on it again next month. The quarter after that someone will suggest Fibonacci and the whole thing starts over.
Then quarterly planning. Three days. Lunch is catered. Three catered lunches, because apparently the cost of feeding your leadership team sushi is easier to approve than the cost of giving one engineer a Friday to automate the deployment pipeline. There are sticky notes. Always sticky notes. Breakout rooms where teams negotiate dependencies with other teams and everyone pretends the commitments are real. By day two the energy is gone. By day three you’ve got a plan everyone agrees to and nobody believes in. Sixty days from now you’ll be back in the same room explaining why you hit seventy percent and calling it a success.
You don’t have a value stream map. You can’t tell your CEO how many days it takes to go from idea to production. You can’t tell the board what your cost per feature is. You can’t tell anyone — including yourself — how much of your engineering budget goes to new capability versus just keeping the lights on. You know the number is bad. You don’t know how bad because you’ve never measured it. Measuring it would make it real. And real is the one thing your operating model has been designed to avoid for the last decade.
Seven Figures for a PowerPoint
You’ve spent more money on consultants in the last five years than the value your engineering org delivered in the last two.
I know. Sit with it.
They left you with beautiful frameworks. Maturity models with five levels and color-coded assessments, the kind that look great on slide 14 of a board deck that nobody reads past slide 6. Transformation roadmaps with eighteen-month timelines and quarterly phase gates. You paid seven figures for a PowerPoint that told you what the engineer you managed out three years ago told you for free.
Her name was — well, you know her name. She showed you the deployment frequency numbers. She showed you what the industry had moved to and what it was costing you to stay where you were. She had data. She had proposals. She had prototypes she built on weekends because you wouldn’t give her sprint time to do it properly.
You didn’t promote her. You reorganized her into a “special projects” team. Took her off the critical path. Gave her a title and no authority. And when she left — because they always leave — you told yourself it was a culture fit issue.
It wasn’t. She didn’t fit your comfort. That’s different.
How many people did you do this to? Not fire — redirect. Slow down. Demoralize. I keep running into them, by the way. They’re at startups now, most of them. They’re the ones building the companies your board keeps comparing you to. Funny how that works.
How many engineers stopped pushing for better because they watched what happened to the ones who did? How many people on your team right now have ideas they’ll never bring to you because they saw what you did to the last person who tried?
You didn’t push those people aside for being wrong. You pushed them aside for being right too early and too loud. The people who stayed — the ones who learned that surviving in your org means stop challenging and start nodding — they’re the ones you call “senior” now. They’re on your leadership team. They’re the culture.
You built a culture that punishes the future to protect the present. And you’re wondering why the org isn’t ready for the future.
What Is Still on Your Org Chart
You still have a manual QA team. In 2026. Real human beings clicking through the same regression suite they clicked through in 2019. You know this can be automated. You’ve known for a decade. Your team told you. They sent proposals. They showed you the tools. They built prototypes.
You said no. “Not yet.” “Compliance requirements.” “The business isn’t ready for that risk.”
What you meant — and I say this gently — is: I don’t know what my role becomes if testing is automated. I don’t know where those forty people go and I don’t want to make that decision. So you kept them. Clicking. For years.
You still have a release process that needs three humans to approve a deployment. You still have architects who draw diagrams that developers ignore. You’ve still got a change advisory board that meets on Thursdays to discuss changes that shipped on Tuesday. I couldn’t make this up.
None of these exist because they’re necessary. They exist because removing them would require you to build something you don’t know how to build.
You know the theory. Every system has a constraint — a bottleneck that limits throughput across everything downstream. You’ve read about it. Highlighted the good parts. Bought copies for your directs. Quoted it in leadership meetings.
Then you went back to your desk and kept being the constraint.
You know about refactoring — the patient, honest discipline of making a system better than you found it. You shared the articles. You put it in strategy decks. “We need to invest in our foundations.” Standing ovation. Then you approved zero refactoring sprints because the roadmap was full of features the sales team promised, and you didn’t have the spine to push back on commitments you knew were unrealistic when they were made.
You know about deployment frequency. Lead time. Change failure rate. Mean time to recovery. You’ve been to the conferences. You’ve got the tote bag.
Your team still deploys once a month. On a good month.
Twenty years of agreeing with the right ideas and blocking the right actions. Not because you’re malicious. Because the ideas were safe to agree with. The actions weren’t. The actions would have required you to actually change. And that was never a risk you were willing to take.
The Peter Gibbons Problem
I need you to hear this with kindness, because I genuinely mean it with kindness.
Your career has started to look like a Peter Gibbons arc. Without the self-awareness.
Showing up. Doing enough to not get fired. Optimizing for stability over impact and calling it leadership. Eight bosses. TPS reports — except now they’re Jira dashboards and you call them “velocity metrics.” Meetings about meetings. The only real difference between you and Peter is that Peter eventually admitted he didn’t care.
You still think you do. That might be the saddest part of this whole thing.
Because you do care about your people. I believe that. You care about the product. You care about the company. But caring isn’t the same as leading. And somewhere — maybe ten years ago, maybe fifteen — you stopped leading and started maintaining. Stopped building, started protecting. Stopped asking “what should we become” and started asking “how do we keep what we have.”
I’ve talked to enough of your former reports to know: your best people saw it years ago. That’s why they left.
The ones who stayed learned to operate inside the system you built. A system that rewards compliance, punishes initiative, and mistakes activity for progress. They run standups because you run standups. They estimate in story points because you asked for story points. They attend three-day planning sessions because you scheduled three-day planning sessions. They’re doing exactly what you trained them to do.
And now you’re sitting in rooms evaluating them. Drawing quadrants. Sorting people into “will adapt” and “won’t adapt.” Making decisions about their careers, their mortgages, their kids’ college funds — based on a model of work you yourself have never done.
You don’t get to label someone “resistant to change” when you’re the person who has resisted the most change for the longest time.
Your Board Is Already Asking
You think you have time. You don’t.
Your CEO had dinner last month with a founder who has eleven engineers shipping what your fifty-person department can’t. Your board sat through a presentation from a portfolio company that rebuilt their entire platform in six months with three people and agents. Your investors are reading the same case studies you are — except they’re not highlighting them. They’re comparing them. To you.
The question is already in the room. Maybe it came wrapped in polite language at the last board meeting — “Walk us through your AI adoption timeline?” You heard curiosity. It wasn’t curiosity. It was the beginning of an evaluation.
Here’s what your board sees when they look around: startups with eight engineers outshipping your entire department. Competitors who were eighteen months behind you now launching features faster than you can approve a requirements document. Companies half your size, a quarter of your headcount, moving at a speed that makes your roadmap look like something from a museum.
They’re not asking whether AI works. That question is done. They’re asking why you’re not moving. And “we’re evaluating” isn’t an answer anymore. It’s a confession.
The CEO who hired you hired you for a version of engineering leadership that made sense five years ago. Headcount planning. Vendor management. Sprint cadences. Architecture review boards. That was the job.
That isn’t the job anymore.
Somewhere out there — maybe already on LinkedIn, maybe already getting a recruiter call — is the person who replaces you. And this is what they look like: a CTO who ships with agents and teaches the org to do the same. A VP who killed two layers of process overhead in Q1 because agents made them unnecessary. A director who cut the team in half and doubled the output — not because they’re ruthless, but because they understood the math before the board had to explain it to them.
Your board will find that person. The only question is whether it turns out to be you.
For the first time in your career, the answer isn’t protected by tenure, or relationships, or institutional knowledge that only you have. The answer is visible. In the output. In the velocity. In whether your org can keep pace with companies that started five years after you and are already ahead.
You’ve been safe in that chair a long time.
The chair isn’t safe anymore.
The Only Move Left
Here’s what I’ve learned about leaders who actually make it through these transitions. They go first.
Not by sponsoring a budget line. Not by approving a transformation initiative with a cute name and an executive sponsor. They sit down and do the work. Open the IDE. Pair with an agent. Feel the friction of not knowing what they’re doing — and stay in it long enough to get past the friction. Ship something. Not a strategy deck. Something that runs.
I watched one of our CTOs do this. Live B2B SaaS company, millions in revenue, .NET monolith, the works. Real customers, real stakes. Two engineers. Him and one associate. Twelve months. They decomposed the architecture, built the CI/CD pipeline, shipped the features, and didn’t hire a single person.
He didn’t manage that transition from a whiteboard. He was in the code every day. He understood the model because he was living in it.
That’s the difference. Leaders who make it go first. Leaders who get replaced form a committee and ask for a status update.
Now or Never
I’m going to be direct with you.
This is it. Not next quarter. Not after the board offsite. Not after you finish evaluating. Now.
Every transition you’ve been through — cloud, DevOps, continuous delivery, all of them — you waited too long and you know it. You lost years. You lost people. You lost competitive position you never recovered. And every time, you told yourself the next one would be different.
This is the next one. Are you doing it again?
Agent-driven development isn’t a tooling upgrade you can adopt incrementally while everything else stays the same. It changes the economics of your entire organization — how many people you need, what those people do, how fast they ship, what leadership even looks like. And the companies that move in the next sixty days will open a gap that the companies who wait eighteen months will never close. I’ve seen it happen with cloud. I’ve seen it happen with DevOps. The gap doesn’t narrow. It compounds.
You’ve been in that chair a long time. It’s been comfortable. Comfortable is over.
The people you pushed aside were right. The changes you delayed were necessary. The future you spent twenty years waiting to understand is here. It doesn’t care how many years you’ve been in the room.
You’ve got two choices.
You can do what you’ve always done. Read this. Agree with it. Maybe share it in Slack. Go back to standup tomorrow and quarterly planning next month and the catered lunches and the story points debate. Wait for someone else to go first. You know how that ends. You’ve seen how that ends. You’ve lived how that ends, multiple times.
Or you can pick up the phone.
We work with leaders who are done waiting. Not people who need convincing — people who already know, and need someone who has actually done this to help them move. We’ve built the model. We’ve run the experiment. We know what the go-forward organization looks like because we’ve built them.
If you’re reading this and your chest is tight — if you recognize yourself in these pages and the recognition scares you — good. That fear is the right fear. It means you’re paying attention. It means it’s not too late.
But the window is closing. I’m not saying that to sell you something. I’m saying it because I’ve watched it close before.