Skip to content

Podcast Transcript

Will You Make It?

Executive DeckListen
March 5, 2026

·

Read the full article

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 Chief Technology Officer. He is at a Fortune five hundred company. He runs about three hundred engineers. I asked him that question. There was a long pause. Then he laughed. Not a real laugh. The kind of laugh that means I do not want to answer that.

If you are having that reaction right now, this is for you.

You have been in that chair a long time. Twenty years. Maybe twenty-five. You have 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 are 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.

Right. Here is what nobody says to you, because you have been in that chair long enough that people stopped trying. The waiting was not caution. It was comfort. Every year you delayed was a year the organization 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, did not have to change.

The waiting kept you in power. That is why you waited.

Let me describe your Tuesday. Tell me where I am 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 is listening. Everyone is 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 have not connected to the work in years. You are watching a ritual you created and calling it management.

After standup you have got a staff meeting. The topic this week is 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 will 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 have got a plan everyone agrees to and nobody believes in. Sixty days from now you will be back in the same room explaining why you hit seventy percent and calling it a success.

You do not have a value stream map. You cannot tell your Chief Executive Officer how many days it takes to go from idea to production. You cannot tell the board what your cost per feature is. You cannot 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 do not know how bad because you have 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.

You have spent more money on consultants in the last five years than the value your engineering organization delivered in the last two. Seven figures for a PowerPoint.

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 fourteen of a board deck that nobody reads past slide six. 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 would not give her sprint time to do it properly.

You did not 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 was not. She did not fit your comfort. That is different.

How many people did you do this to? Not fire. Redirect. Slow down. Demoralize. I keep running into them, by the way. They are at startups now, most of them. They are 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 will never bring to you because they saw what you did to the last person who tried?

You did not 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 organization means stop challenging and start nodding, they are the ones you call senior now. They are on your leadership team. They are the culture.

You built a culture that punishes the future to protect the present. And you are wondering why the organization is not ready for the future.

Look at what is still on your organization chart. You still have a manual quality assurance team. In twenty twenty-six. Real human beings clicking through the same regression suite they clicked through in twenty nineteen. You know this can be automated. You have 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 is not ready for that risk.

What you meant, and I say this gently, is that you do not know what your role becomes if testing is automated. I do not know where those forty people go and I do not 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 have still got a change advisory board that meets on Thursdays to discuss changes that shipped on Tuesday. I could not make this up.

None of these exist because they are necessary. They exist because removing them would require you to build something you do not know how to build.

You know the theory. Every system has a constraint, a bottleneck that limits throughput across everything downstream. You have read about it. Highlighted the good parts. Bought copies for your direct reports. 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 did not 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, and mean time to recovery. You have been to the conferences. You have 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 are malicious. Because the ideas were safe to agree with. The actions were not. The actions would have required you to actually change. And that was never a risk you were willing to take.

Let's talk about 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 are 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 did not 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 is not 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 have talked to enough of your former reports to know that your best people saw it years ago. That is 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 are doing exactly what you trained them to do.

And now you are sitting in rooms evaluating them. Drawing quadrants. Sorting people into who will adapt and who will not adapt. Making decisions about their careers, their mortgages, their kids' college funds, based on a model of work you yourself have never done.

You do not get to label someone resistant to change when you are the person who has resisted the most change for the longest time.

Your board is already asking. You think you have time. You do not.

Your Chief Executive Officer had dinner last month with a founder who has eleven engineers shipping what your fifty-person department cannot. 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 are not highlighting them. They are 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 was not curiosity. It was the beginning of an evaluation.

Here is 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 are not asking whether AI works. That question is done. They are asking why you are not moving. And we are evaluating is not an answer anymore. It is a confession.

The Chief Executive Officer 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 is not 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 Chief Technology Officer who ships with agents and teaches the organization to do the same. A Vice President who killed two layers of process overhead in the first quarter because agents made them unnecessary. A director who cut the team in half and doubled the output, not because they are 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 is not 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 organization can keep pace with companies that started five years after you and are already ahead.

You have been safe in that chair a long time.

The chair is not safe anymore.

The only move left is to go first. Here is what I have 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 integrated development environment. Pair with an agent. Feel the friction of not knowing what they are 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 Chief Technology Officers do this. He runs a live business to business Software as a Service company. Millions in revenue. Dot net monolith. The works. Real customers, real stakes. Two engineers. Him and one associate. Twelve months. They decomposed the architecture, built the continuous integration and continuous delivery pipeline, shipped the features, and did not hire a single person.

He did not manage that transition from a whiteboard. He was in the code every day. He understood the model because he was living in it.

That is the difference. Leaders who make it go first. Leaders who get replaced form a committee and ask for a status update.

It is now or never. I am 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 have 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 is not 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 have seen it happen with cloud. I have seen it happen with DevOps. The gap does not narrow. It compounds.

You have been in that chair a long time. It has 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 does not care how many years you have been in the room.

You have got two choices.

You can do what you have 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 have seen how that ends. You have 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 have built the model. We have run the experiment. We know what the go-forward organization looks like because we have built them.

If you are 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 are paying attention. It means it is not too late.

But the window is closing. I am not saying that to sell you something. I am saying it because I have watched it close before.

Companion