Daniel called on a Thursday afternoon. That is not his real name, and I am intentionally blurring the identifying details because the pattern matters more than the person. He had the tone. It is the one I hear from leaders who are genuinely trying and genuinely stuck. Somewhere between frustrated and exhausted.
He runs engineering at a company doing solid revenue with a couple hundred engineers. He was brought in eighteen months ago to modernize the organization. Push artificial intelligence adoption. Get teams shipping faster. The board wanted transformation. Daniel wanted to deliver it.
I like Daniel. He cares about his people. He is not posturing. He is not checking a box for the chief executive officer. He actually wants this to work.
That is why this conversation was hard.
The first ten minutes were fine. Daniel walked me through what he had tried. Tooling rollouts. Copilot licenses. A couple of internal hackathons. A Slack channel for artificial intelligence tips. A large language model evaluation committee. A training budget.
Standard playbook. I have heard it a hundred times.
Then he said the thing that stopped me.
My teams only really have about thirty minutes a week they can dedicate to learning this stuff. Maybe an hour if we block a Friday afternoon. But realistically, it is thirty minutes.
I asked why.
Sprint commitments. Velocity targets. We are already stretched. I cannot just pull people off delivery to go experiment.
I did not say anything for a second. Not because I was surprised. Because I was trying to figure out the kindest way to say what I needed to say.
Here is what I told Daniel. Daniel, you are asking your engineers to learn the most significant shift in how software gets built since the internet in thirty minutes a week. You are doing this between sprint commitments and velocity targets that were set before any of this existed.
That is not an adoption strategy. That is a signal to your team that you do not actually prioritize this.
I know that is not your intent. I know you care. I know you have budget pressure and delivery targets and a board that wants results by the third quarter. I know you are trying to balance a dozen things at once and thirty minutes felt like the space you could carve out without blowing up something else.
But here is what your engineers hear when you give them thirty minutes. They hear that this is not important enough to change anything for.
And they are rational people. They respond to that signal exactly the way you would. They nod. They attend the optional training. They do not change how they work. And then you wonder why adoption is not sticking.
You built that outcome. Not because you are careless. Because the system you are running was never designed to absorb this kind of change on the margins.
The question I asked next was whether he could show me his value streams. Not his organization chart. Not his team topology. Not his Jira board structure. His value streams. I wanted to see the actual flow of work from idea to production. I wanted to see where it moves, where it waits, where it gets handed off, where it gets blocked, and how long each phase takes.
He paused.
We have not really mapped that out formally.
I hear this constantly. I wrote about how to actually do this using a whiteboard, a Tuesday afternoon, and the people who do the work. It is not complicated. It is just revealing. Leaders running hundreds of engineers across dozens of teams, spending millions on tooling and headcount, and they cannot draw the path a unit of work takes from request to delivery.
If you do not know your value streams, you do not know where your time goes. And if you do not know where your time goes, you cannot tell me where artificial intelligence should be applied. You are guessing. You are buying tools and hoping they land somewhere useful.
Value stream mapping is not a nice to have. It is not a process improvement exercise you get to when things calm down. It is the diagnostic that tells you where your organization actually spends its time. Total time might be forty-five days to ship a feature. Actual work might be eight days. Waiting, handoffs, approvals, and queue time take up the rest.
You optimized the eight days. You gave your engineers thirty minutes a week to optimize the eight days. Meanwhile thirty-seven days of waste sit there untouched because nobody mapped it.
That is not an artificial intelligence problem. That is a leadership problem.
Then Daniel brought up the manual quality assurance defense.
We still need our manual quality assurance process. Our product is complex. Automated testing does not catch everything. We have tried.
I asked him what the return on investment looked like on the current manual quality assurance setup.
Silence.
Not because there was no return on investment. Because nobody had measured it. The team had always had manual quality assurance. It was load bearing. It was how things worked. Questioning it felt like questioning whether the building needed walls.
Here is the thing. I am not telling you automated testing catches everything. I am not telling you to fire your quality assurance team tomorrow. I am telling you that if you are defending a process that you cannot measure, in an era where artificial intelligence can generate, execute, and maintain test suites at a scale your manual team will never match, you are not making a technical argument. You are making an emotional one. I wrote about why the separate quality organization expired and about how the Testing Pyramid itself was a financial compromise that no longer applies.
And that is fine. Change is hard. Letting go of something that kept you safe for years is genuinely difficult. I respect that.
But you called me because adoption is not working. And when I look at your organization, with engineers who have thirty minutes to learn, value streams nobody has mapped, and a manual quality assurance process defended on instinct instead of data, I can see exactly why it is not working. Anyone looking at this from the outside can see it. And I suspect the honest people inside your organization see it too. They are just not sure it is safe to say it.
Daniel mentioned that his teams were struggling with a process framework addiction. He said they were running a hybrid Agile and Kanban approach and that they were still tuning it.
I want to be careful here because I know how much energy organizations have poured into process frameworks. I know teams that spent years getting good at Scrum. I know managers whose entire identity is wrapped up in being excellent Agile coaches. I know organizations that restructured reporting lines around the Scaled Agile Framework.
That investment was real. The effort was real. The people who led it were not wrong at the time.
But the conversation about whether Agile or Kanban or some hybrid is the right framework ended two years ago. Not because the frameworks were bad. Because the constraint they were designed to manage changed.
Agile was a response to uncertainty in a world where building was slow and expensive. You could not predict what to build, so you iterated in short cycles. Kanban was a response to flow problems. You visualize work, limit work in progress, and optimize throughput. Both frameworks optimized around a world where human engineering capacity was the bottleneck.
That bottleneck moved.
When an engineer with an artificial intelligence agent can produce in a day what used to take a sprint, the question is no longer how do we organize our sprints. The question is what do we build and how fast can we validate it. That is a fundamentally different question, and Agile and Kanban were not designed to answer it.
If you are still tuning your hybrid framework, you are polishing a system that was built for a constraint that no longer binds. That is not transformation. That is comfort.
This is the part you own. Daniel, I want to be direct with you because I think you can hear it.
This is not an adoption problem. This is not a tooling problem. This is not an engineer motivation problem.
This is a leadership problem. And you own it.
You own the sprint structure that leaves thirty minutes for learning. You own the missing value stream maps. You own the unmeasured quality assurance process. You own the process framework that nobody has questioned in two years. You own the incentive structure that rewards delivery velocity over capability growth.
Your engineers are doing exactly what you asked them to do. They are shipping against sprint commitments, maintaining velocity targets, and following the process. They are rational actors in the system you built.
If that system does not produce artificial intelligence adoption, the system is the problem. Not the people inside it.
Here is what I told Daniel to do.
Map your value streams. All of them. Not the idealized version. The real one. Where does work actually flow? Where does it actually wait? Put numbers on it. Total lead time. Active work time. Wait time. Handoff count. Approval gates. Manual steps that could be automated. Do this for your three most critical delivery paths. It will take two weeks with a small team. It will be the most important two weeks you spend this quarter.
Know your productivity metrics. Not story points. Not velocity. The real ones. Cycle time. Deployment frequency. Change failure rate. Time to restore. Customer facing lead time. If you cannot produce these numbers by team within an hour of being asked, you are flying blind. You cannot improve what you have not measured, and you cannot adopt artificial intelligence strategically if you do not know where the leverage is.
Give your engineers real time. Not thirty minutes scraped from the margins. Give them dedicated time. Structured time. This is time where the expectation is not to also keep shipping, but to learn how your job is changing. Two hours a week minimum. Four is better. Yes, velocity will dip for a quarter. That is the investment. If you cannot make that trade, you are telling me the transformation is not actually a priority, and your engineers already know it.
Stop defending processes you cannot measure. If your manual quality assurance process is essential, prove it. Measure the defect escape rate. Measure the cost per bug found manually versus what an artificial intelligence generated test suite catches. If the numbers support manual quality assurance, keep it. If they do not, and I suspect they do not, have the courage to change.
Stop tuning the process framework. Your teams do not need a better hybrid Agile and Kanban configuration. They need clarity on what to build, time to learn new tools, and a delivery path with thirty-seven fewer days of waste in it. That is a value stream problem, not a ceremony problem.
You are holding an oil can next to a steam engine. I want to say something that might be harder to hear than everything else.
Everything I just described, including the value stream mapping, the metrics, the dedicated learning time, and the quality assurance measurement, is the minimum. That is the floor. And honestly, Daniel, I am not sure the floor is enough for where you are.
Because here is what I see when I look at the whole picture.
You are treating artificial intelligence like an oil gun. You are walking around your organization squirting lubricant on the gears of your current machine. A little Copilot here. A hackathon there. Thirty minutes of learning greased into the sprint schedule. And when the machine still runs slow, you try a different oil. A different vendor. A different training format.
But Daniel, the machine is a steam engine. And it is twenty twenty-six.
You are not in a world where better lubrication fixes the problem. You are in a world where the mode of transportation changed. You would not stand next to a coal fired car in twenty twenty-six and say we just need to optimize our fuel intake process. You would look at it and ask why you are still burning coal.
That is the question I need you to ask about your engineering organization. Not how do we adopt artificial intelligence into our current system. Ask instead why our current system still looks like this.
We need first principles, not incremental improvement. This is the part where I stop talking to Daniel and start talking to whoever is above Daniel.
If your engineering leader has had eighteen months, and in artificial intelligence time eighteen months is a decade, and the organization still cannot tell you its value streams, then there is a problem. If they still defend unmeasured processes on instinct, still give engineers thirty minutes a week to learn, and still debate which flavor of Agile to run, then this is not a problem you solve by tuning harder. This is a problem you solve by going back to first principles.
What would this organization look like if you built it today? Not inherited it. Built it. From scratch. Think about what you now know about what artificial intelligence agents can do. Think about what a small team with the right tools can ship. Think about how fast the market is moving.
You would not build what you have. Nobody would.
You would build something leaner. Something where engineers spend most of their time building, not waiting. Something where customer signal reaches the team in hours, not quarters. Something where testing is continuous and automated, not manual and ceremonial. Something where the question of what framework you are running does not even make sense because the cadence is dictated by what customers need, not by what a process consultant recommended four years ago.
That is the organization you need. And you do not get there by greasing the steam engine. You get there by building the new thing alongside it.
Stand up a parallel team. Small. Five to ten people. Give them real autonomy, real tools, real time, and a real customer problem. No legacy process. No inherited sprint structure. No Jira board configured by someone who left two years ago. First principles. Let them build the way building works now. Measure what they produce. Compare it honestly to what the rest of the organization produces.
That comparison will tell you everything you need to know.
This is a chief executive officer and board conversation now. I say this with genuine care for Daniel and for leaders like him. But if your engineering leader has had eighteen months and could not create the conditions for transformation, then the chief executive officer and the board need to ask an honest question. If he could not clear the calendar, could not map the value streams, and could not question the sacred processes, is this a resources problem or a leadership problem?
Maybe Daniel needs more air cover. Maybe he needs the chief executive officer to publicly reprioritize and take the heat for a velocity dip. Maybe he needs a board that understands the investment required and gives him room to make it. If that is the case, then the failure is upstream, and the chief executive officer owns it.
Or maybe the role needs someone who will not ask permission to do what is obviously necessary. Someone who walks in on day one, maps the value streams by day fifteen, stands up the parallel team by day thirty, and has data by day sixty that makes the case for everything else.
Either way, the current trajectory does not work. I am not being dramatic. I am doing math.
It is early twenty twenty-six. By twenty twenty-eight, the gap between organizations that figured this out and organizations that are still greasing the steam engine will not be a competitive disadvantage. It will be an existential one.
Five kids from Stanford with artificial intelligence agents and a clear customer problem will be shipping faster than your two hundred engineers. Not because they are smarter. Because they are not dragging forty-five day cycle times, manual quality assurance ceremonies, process framework debates, and thirty minute learning blocks behind them.
They started with a blank page. You are still annotating a page someone wrote in twenty nineteen.
That is the gap. And it is widening every month you spend optimizing what you have instead of building what you need.
This is the kind part. I told Daniel all of this. Every word. And I meant it with genuine respect.
He is not failing because he is incompetent. He is not failing because he does not care. He is failing because he is trying to pour a new future into an old container and wondering why it will not fit.
Most leaders I talk to are in Daniel's position. Good people. Smart people. People who genuinely lose sleep over their teams and their organizations. They are stuck not because they lack intent but because nobody has told them clearly enough that you cannot incrementally improve your way to a fundamentally different operating model. At some point you have to stop lubricating the steam engine and build the new thing.
That point was eighteen months ago. But today is the second best time.
Map the value streams. Measure what matters. Stand up the parallel team. Give your people real time to learn. And if the organizational structure will not let you do those things, then escalate. If the sprint commitments and the velocity targets and the process ceremonies are more powerful than the transformation mandate, go to the chief executive officer. Go to the board. Tell them what you told me. Tell them the truth.
Because the market is not waiting for you to finish tuning your hybrid Agile and Kanban configuration.
The market is not waiting at all.