After I have the bottleneck conversation with a Chief Executive Officer, I have the training conversation. Every time. In that order. The bottleneck conversation is about the silos, the measurement gaps, and the organizational geometry that hides value from the people paying for it. The training conversation is what we are talking about here. It is the one most executives are quietly losing.
Every training conversation I have this quarter opens the same way. Tooling rolled out. Licenses purchased. Pilots underway. Training completed. A non-trivial percentage of the engineering budget is now sitting on an AI line item that did not exist two years ago. And the organization is producing almost exactly what it was producing two years ago. Roadmap where it was. Throughput where it was. The strongest people on the team keep asking, quietly, when the company is actually going to use the tools it paid for.
Then the executive says the line I have heard in every one of these rooms. We went through the training, we bought the licenses, we ran the pilots, and we are not seeing the value.
Look. Here is the diagnosis, and there is only one solution. The solution is a new standard for what it means to work at your company, and you, the executive, are the only person who can set it. For the sake of our discussion, I am going to call that standard, applied to the engineering role, the AI Software Engineer standard. You will want your own name for it when you roll it out. But having a name for the thing lets us talk about it without confusion, so AI Software Engineer is what I will use here. Your organization is self-measuring its own adoption right now because there is no bar anyone is required to qualify into. Self-measuring and missing standards are the same failure at two altitudes. That is why the engagement survey comes back green while the output stays flat, and why next quarter you are back in this conference room with a bigger tool bill.
From here the rest of the conversation turns to competencies and capabilities. What does the role actually require now, in twenty twenty-six, on this operating model? What does the organization need to be able to do, at the team level and at the seam between teams? And how do you set a standard that makes both of those answers real to the people in the building? You need competency to stop being a talking point on a slide and start being the pass or not-yet call a qualified reviewer makes on a real piece of work. That is the terrain your transformation is quietly avoiding.
Here is the thing. Standards and competencies are not certifications. Before anyone assumes where this is going, I want to say the thing clearly. I am not advocating for certifications.
I am not asking you to stand up an internal certification program. I am not asking you to pay a third party to run a two-day workshop and hand out a badge. I am not asking you to add a line on your engineers' LinkedIn profiles that says Certified AI-Native Developer with your company logo on it. The industry has run that play before. Repeatedly. And it has not produced the thing it said it would produce. We spent a decade watching Certified Scrum Masters run stand-ups that looked exactly like the status meetings they were supposed to replace. We watched Certified Agile Coaches facilitate the same release-train rituals the organization already had, with new words taped over the old ones. The certification did not transfer the competency. It transferred a receipt.
A standard is different from a certification in three ways that matter.
First. A standard is about observable work. It is not about whether you sat through the training. It is about whether your output clears the bar in the real codebase, on the real product, under the real governance posture, reviewed by someone who has already shipped at that level. If your qualification path can be completed by someone who has never shipped anything in your company's environment, you are building a certification and you are going to get certification outcomes.
Second. A standard is held by the people already doing the work. There is no external certifier coming in to grant it. There is no curriculum author in another time zone who defines what qualified means. The qualified engineers in your organization calibrate each other and they calibrate the next cohort. The bar is re-anchored every time the work itself changes. Certifications freeze a snapshot of a standard and date-stamp it. Standards keep moving because the work keeps moving.
Third. A standard has consequences on both sides. If you qualify, your role changes in a way that the organization sees. If you do not, your role does not change in that way. Certifications can be collected without consequence. That is most of the reason people collect them. Standards cannot. The organization that holds the standard organizes itself around who has qualified and who has not.
Competency is the observable demonstration of the standard. Not a credential. Not a course completion record. Not a quiz score. It is a piece of work, shipped, reviewed, calibrated against the bar by people who have already cleared it. Everything that follows here is about how to design, deploy, and defend that kind of bar. If you come away from this piece shopping for a certification vendor to roll out across the engineering organization, you have read the exact opposite article from the one I am writing.
Now. You have to realize the training was never the bottleneck. You did not have a training problem. You had a standards problem, and you tried to solve it by buying a curriculum.
An eight hundred person engineering organization does not change because you rolled out AI Software Development Life Cycle tooling and pushed a learning path through your Learning Management System. It changes because leadership defined what engineer at this company means now. The tooling, the throughput, the quality bar, the governance posture. All of it. And then you required everyone in the role to demonstrate they meet the definition. The training is the onramp. The standard is the road. One without the other takes you nowhere.
When you skipped the standard and went straight to the training, you told the organization it was optional. Optional at scale is a synonym for ignored. Your organization correctly ignored it.
So. Self-measuring is not adoption. Here is what self-measuring looks like in the wild. You ask your Vice Presidents how adoption is going. Your Vice Presidents ask their directors. The directors ask the managers. The managers ask the engineers. The engineers say yeah, I use it. That sentence travels back up the chain, lands on a slide, and becomes seventy-eight percent adoption on your next board deck.
Nobody lied. Nobody measured anything either.
This is what organizations do when they want the appearance of transformation without the disruption of transformation. The DevOps Research and Assessment metrics did not move. Lead time looks the same as it did in twenty twenty-two. Team composition is identical. The survey said seventy-eight percent, so the program is green, so the Chief Financial Officer signs the renewal. Next quarter we sit in the same conference room and have the same conversation.
Self-measuring is not a data problem. It is a governance vacuum, and the vacuum exists because you, the executive, have not yet said the words that close it.
Here are the words you have not said. I will say them out loud so you can paste them into a memo if that helps.
These are the new standards for working at this company. If you want to continue in your role, here is what you need to demonstrate, here is the qualification path, here is the timeline, and here is the support. This is not a pilot. We are burning the boats.
Every phrase in that paragraph is load-bearing. Let me walk through the ones executives flinch at.
New standards. Not guidelines. Not ways of working. Not a set of principles on a wiki page. Measurable, observable, passable or failable. A thing that says yes, you are operating at the bar, or not-yet.
Qualify into. A ritual boundary. You were on one side yesterday. You are on the other side today. Something happened in between that the whole team can point to. Without the ritual, there is no change. Your Human Resources partner will tell you this is heavy-handed. They are wrong. The heaviness is the entire point of the exercise.
Continue in your role. Consequence. This is the word executives want to delete, and it is the word that cannot be deleted. Take it out and the standard is a suggestion. Suggestions are precisely how you got here.
Burning the boats. This is the signal to the rest of the organization. A one-way door with everyone watching it close. Not a phased rollout that can be quietly walked back in the third quarter when someone gets nervous.
Right. Why does coaching not scale to this? I was talking to my friend Lance about this last week. Lance and I spent a decade in large-scale tech coaching groups. The kind that parachute into Fortune one hundred engineering organizations and try to install test-driven development across tens of thousands of developers. We genuinely believed, for years, that if we could just get test-driven development into enough hands the industry would bend. We were wrong. Not about the practice, which is still good, but about the mechanism. You cannot coach your way to a new standard at enterprise scale. You can only govern your way there. The coaches I worked with were excellent. The organizations that hired them kept their old standards intact, so the coaching was decorative.
Now with AI, the same lesson is back. Louder. A five person team with a real agentic workflow can ship what a seventy person team shipped in twenty twenty-three. That is not a forecast. That is the throughput curve the organizations that moved are living in right now. And the organizations that moved did not move because they hired better coaches. They moved because leadership set a new bar, required the people in the role to qualify into it, and was willing to have hard conversations with the ones who would not.
Coaching still matters. It is the onramp. The onramp without the standard is a parking lot.
Look at where you are stuck right now. Most of the executives I talk to are stuck in one of three places. Sometimes two.
You might be stuck in the transformation pilot. You have a lighthouse team, maybe two, producing beautiful demos that do not generalize. Why would they generalize? The standard for everyone else's role did not change. The lighthouse is an exotic. The rest of the organization is still measured on the old bar, which means the rational move for every non-lighthouse team is to ignore what the lighthouse built.
Or you are stuck in the developer pilot. You rolled out AI software development life cycle tooling to a few hundred engineers without telling them what was now expected of them. So they used the new tooling the way they used every previous wave of developer tooling. They used it as an accelerant for the work they were already doing, in the pattern they were already working in. You paid for a new capability and got a faster version of the old capability. This is not an AI problem. It is a role definition problem. No amount of additional tooling fixes it.
Maybe you are stuck in governance review. Your risk, legal, security, and compliance functions have a set of questions they wrote for the twenty-eighteen version of software development, and they are applying them to the twenty twenty-six version. The review takes nine months. During those nine months your competitor with looser governance ships. I am not asking you to ignore governance. Governance is real. The questions are real. The regulators are real. I am asking you to recognize that governance has a speed, and right now that speed is the binding constraint on whether your company exists in twenty twenty-eight.
These are the same failure wearing different costumes. You did not define the new role. You did not require anyone to qualify into it. The organization read the signal correctly and kept doing what it was doing. The organization is not broken. It is behaving rationally inside the incentive structure you set. And it gets worse when you walk a level up and a level out.
Now. Look at your middle management. Walk down a level on your organizational chart. Your directors. Your managers. The layer sitting between you and the people doing the work.
Ask yourself a quiet question. Did they actually train?
Not did they attend the leadership session. I mean did they sit down at a real codebase, configure the tooling, run an agent through a piece of work, and feel the thing their teams are supposed to feel? In most organizations the honest answer is no. They forwarded the training invite to their team, approved the licenses, and went back to running their staff meeting the way they ran it in twenty twenty-two.
This is the layer where transformations die. They do not die because middle managers are bad. They die because nobody defined the new standard for the manager role either. You told your engineers the tools were coming. You did not tell your managers that the job of managing engineers had changed. So they kept running stand-ups about story points, measuring teams on velocity, approving pull requests on instinct calibrated to twenty twenty-two output. When their teams started working agentically, the managers could not tell the difference between a good agentic workflow and a sloppy one, because they had never run one.
A manager who has not shipped with agents cannot coach someone who is shipping with agents. They cannot calibrate the standard. They cannot spot real output from plausible-looking output. That is the expensive mistake. And it is happening in your organization right now while you read this.
Can they do it? Most of them, yes. The good ones have been asking for air cover to actually build again. My phone reminds me of this every week. Some of them will surprise you. A few will not make the transition, and you will know which ones inside sixty days. That is information you needed anyway.
Why did they not train? Because you did not require it of them. Their calendar is full of meetings that made sense in the old operating model. If you want your managers to operate in the new model you have to give them the time, and you have to require the qualification. Same bar as the engineers. Same demonstration. Shipped work. In the real codebase. Reviewed by people who have already qualified.
Now, here is the honest version of the question. When you apply the standard to the management layer, the question is not only how do I retrain these people. It is also how many of those layers you still need. The honest answer in most organizations is fewer. In some organizations, quite a lot fewer. Writing code was probably not your bottleneck. Your organization was. The review chains, the approval queues, the handoffs between teams who should have been one team. The status-report theater. The managers managing managers managing managers. Flatten it. Give authority back to the strong individual contributors who are already doing the work. You know who they are. They are the people the rest of the team messages first when something is on fire. Cut the layers that existed to coordinate the old operating model, because the new operating model does not need that much coordination.
Then raise the bar for the managers who remain to the same twenty twenty-six standard you are holding everyone else to. A smaller management layer with a higher bar is not a cost-cutting exercise. It is the shape an organization takes when the bottleneck moves from how fast can engineers produce code to how fast can the organization decide what to build next and get out of its own way.
If the manager cannot hold the bar, the bar is not held. That is the whole thing.
Widen the lens. Standards do not stop at engineering.
Your product managers are writing the same one-pagers they wrote in twenty twenty-two and handing them to teams that could have drafted, prototyped, and tested three variants in the time it took the product manager to write the document. Your designers are shipping static design files into workflows that now iterate on interfaces agentically. Your program managers are running the same status rituals on teams whose work no longer fits the cadence the rituals were designed for. Your compliance reviewers are applying twenty-eighteen questions to twenty twenty-six artifacts, and your recruiters are sourcing against a job description that was accurate two budget cycles ago.
Each of these roles needs its own standard. The qualification path for a product manager looks different from the engineer's path, but it maps to the same principle. Define the role. Require the demonstration. Provide the onramp. Hold the bar.
Set the standard only for engineers and you have built a fast engine inside a slow car. The engineering throughput shows up for about a quarter, and then the rest of the organization's latency absorbs it. Intake slow. Approvals slow. Decisions slow. The engineers notice first, and the strongest of them leave first. The whole operating model moves, or none of it does.
OK. Here is what the move actually looks like. I have watched it work. I have also watched it fail, usually at step five. Nobody enjoys it while it is happening.
First. Define the role. Write the job description for AI Software Engineer at this company as if the role had just been invented. What does this person do, with what tools, at what throughput, against what quality bar, with what governance posture? One page. Your own words. No committee.
Second. Define the qualification. A bounded, observable demonstration. A piece of real work, shipped through the real workflow, reviewed by people who have already qualified. Pass, or not-yet. No participation ribbons.
Third. Set the timeline. Ninety days for the first wave. Your strongest people go first. You are setting the ceiling, not the floor. Pick the people who will make the bar look reasonable.
Fourth. Provide the onramp. Frontier model access without a token ceiling. Paired time with the people who already qualified. A working body of internal examples. Protected calendar space. The support has to be real, or the qualification is punitive. Punitive qualification is the fastest way to lose the people you needed to keep.
Fifth. Hold the line. This is the hard one. Some of your strongest people will not qualify on the first pass. You are going to feel pressure to move the bar. Do not move the bar. Move people. Move timelines. Move support. The bar is the only thing you do not move.
Sixth. Signal across the organization. A note from the Chief Technology Officer, in plain language, that says the new standard is the standard, this is not a pilot, and the people who have qualified are the ones defining what the work looks like here now.
Steps one through four are what every consultancy on earth will sell you a deck for. Steps five and six are what nobody sells you, because they require the executive to personally hold the line against their own organization. That is the job. If you cannot do that part, the rest is theater. And expensive theater at that.
Let's look at what step one actually looks like. Here is an example role definition for an AI Software Engineer in twenty twenty-six.
You build, ship, and operate production software using agentic workflows as your default operating mode. You are not a person who occasionally uses AI assistance. You are an engineer whose unit of work is orchestrate an agent, or several, against a defined outcome, review the result against the standard, and ship. You are accountable for the outcome, not the keystrokes.
Here is what you do. Own the full lifecycle of features, from problem framing through production operation. You write the specification, design the approach, orchestrate the agents that produce the code, review every change with rigor, and carry the pager for what you ship. Drive throughput that would have required a team of five to seven people in twenty twenty-two. This is the expectation. Keep the trunk green. Continuous delivery is the default. Operate with governance baked in. Security, privacy, and compliance checks happen inside the workflow.
Here is how we work. Frontier model access is provided, uncapped within reason. Token cost is a cost of goods, not a budget line to ration. Pair with other qualified engineers and with agents interchangeably. Code that no qualified human has looked at does not ship. Write the tests the agent generates, read them, and throw out the ones that do not carry their weight. Telemetry first. If you cannot observe what you shipped inside an hour of it landing, it is not done.
You are measured on shipped production change that holds up under real load. Lead time from decision to production. Quality in the field. And the quality of the reviews you do on other people's work. We do not measure you on pull request count, story points, hours in the office, or lines of code. Those are twenty-eighteen metrics and they are actively misleading.
You are expected to know how to build with agents in production. This includes prompt and context design, tool-use patterns, and evaluation harnesses. You know the fundamentals that do not change. Data structures. Distributed systems tradeoffs. Operability. Security posture. Readability. The agent does not replace any of that. It makes your leverage on those fundamentals larger. You know the tradeoffs between autonomy and oversight.
What qualifies you for this role is a demonstration. One piece of real work, shipped through our real delivery workflow, reviewed by engineers who have already qualified. Pass or not-yet. No certificates. No training hours. We provide the onramp. You provide the evidence.
This is not a role where you maintain somebody else's platform and write a ticket when you want a change. This is not a role where you pass work to a vendor and review the result. Your value is not measured by years of tenure.
Now. What about your engineering leaders? Here is the leader definition.
You are the front-line owner of a team of qualified engineers operating on our agent-driven delivery model. You own the team's outcomes. You hold the engineering standard. And you ship alongside the team. You have qualified into our AI Software Engineer standard yourself, and you stay qualified by continuing to ship. This is not a program-management role. If the last time you shipped code to production was before twenty twenty-four, the role is not for you in its current form. We will give you a real onramp if you want the seat.
What you do is own the business outcomes assigned to your team. Hold the standard. Every engineer on your team has qualified or is on an explicit, time-bounded qualification plan. You make the pass or not-yet call. You do not move the bar under pressure. Ship alongside the team. A meaningful portion of your week is in the code. Remove organizational bottlenecks. You identify the review chains and approval queues slowing your team down and you remove them. Lead the team end-to-end. Partner with Product, Design, and Program Management on intake. Carry the pager with the team.
How we work is simple. Frontier model access is provided to you and to every engineer on your team. Teams are deliberately small, three to eight qualified engineers. Recurring meetings have to justify their seat against the alternative of shipping that hour.
You are measured on team outcomes against the business commitments you signed up for. Lead time. Quality in the field. And regrettable attrition of qualified engineers. The quality of your reviews, calibrations, and promotions matters. We will read your write-ups. We measure your own continued qualification. If you stop shipping, you stop leading.
What qualifies you for this role is evidence in three steps. One, demonstrate the AI Software Engineer standard yourself on a piece of real work. Two, review anonymized work from a peer team and provide your assessment. Three, lead a working session with a real team on a real problem. No take-home case studies. No trivia interviews. We ask you to do the job in miniature.
You need a demonstrated track record of shipping production software. You need current, hands-on experience building with agents in production. You need experience managing engineers with dignity. And you need the ability to hold a standard under pressure.
This is not a slides-and-status role. It is not a role where your calendar can substitute for your output.
The Product Manager version, the Designer version, and the Program Manager version follow the same shape. Same stance. Same responsibility set built around outcomes. Same qualifying demonstration. The point is the pattern. Define the role in your own words. Require the demonstration. Provide the onramp. Hold the bar. Repeat it for every function whose standard needs to move.
Right. Here is the part Human Resources did not want on the agenda. Yes, you are going to pay these people above market.
The people who qualify into this role, internally or externally, are worth more than your current compensation bands say they are. Your bands were built for a twenty twenty-two operating model. They are already wrong. You are not paying for years of experience anymore. You are paying for people who operate at the bar you just set.
Pay them above market. Say it in writing. Say it in the offer. Say it to your existing people who qualify so they do not have to leave to find out what they are worth. If your objection is that the token budget alone makes this person expensive, you have to realize that the recruiter fee on a replacement dwarfs whatever you thought you were saving.
Human Resources will tell you the bands exist to be fair. Fair is a real value. But fair at the cost of being unable to hire or retain the people who define what your engineering organization is capable of is not fair. It is just slow. The bands have to move. The leveling has to move. You are buying the twenty twenty-six operating model.
One more thing. The person you hire at twenty or thirty percent above band, who qualifies into this role, is not more expensive. They are the cheapest engineer on your payroll, measured the way the business actually works. The expensive engineers are the ones you are paying at band who have not qualified, because their unit of output no longer justifies the line item. Your Chief Financial Officer already knows this. The question is whether your compensation structure is allowed to act on it.
Look. What you are hiring in twenty twenty-six is not what you were hiring in twenty twenty-four.
The person you were fighting to recruit in twenty twenty-four is now being second-guessed. They did not get worse. They are the same person you hired. The standard moved and they did not move with it, because nobody told them the standard had moved.
If they are not working agentically in twenty twenty-six, you are looking at their last three pull requests and wondering whether the person you paid four hundred and fifty thousand dollars is actually producing at the level of someone on the new bar making less. You are not going to say that out loud. You are going to say it with your calendar. By not putting them on the next strategic initiative. And they are going to feel it.
The people you are interviewing this quarter are operating differently. They ship with agents. They think in workflows rather than keystrokes. The gap between your twenty twenty-four hires and your twenty twenty-six candidate pool is an operating model gap. And it widened in eighteen months.
I was having coffee with my friend Jim last week. Jim is a technical recruiter. He has been placing engineers for a long time. I asked him what he was seeing. He said something I have been stealing ever since.
The right question on a resume is not years anymore, he said. It is maintenance or advance.
I asked him what he meant. He said he gets resumes with a decade of experience that look identical on paper. One of them has been shipping new production software continuously. The other three have been sitting on top of a platform somebody else built in twenty-fourteen. Writing tickets. Attending meetings. Reviewing pull requests from a vendor. They all have ten years on the line. They are not the same person.
Then he said the part that stuck with me. He interviewed someone two weeks ago who has been in the industry for two years. She shipped to production from day one, using agents from the first week. On the dimension hiring managers actually care about in twenty twenty-six, she has more real experience than the ten-year candidate who has been in maintenance mode. And the intake forms filter her out because she does not hit the years-of-experience minimum.
That is the whole thing. Your recruiting intake is probably not set up to tell the difference between advance and maintenance. You are filtering people out by tenure at exactly the moment tenure is telling you the least. The new bar has to distinguish advance from maintenance. Inside the building. And outside the building.
There is an adverse selection pattern inside this. The people you want to stay leave. The people you wish would leave, stay. This is not a coincidence. It is the rational outcome of a company that has not set a new bar. The strongest people in your organization have options. They are leaving because they can see where the industry is moving and they do not want to be stuck. Every quarter you delay setting the standard, the mix in your building gets a little worse on both ends.
So. Let us talk about the economics and the precedent your board is already using.
An eight hundred person engineering organization, at a loaded cost of roughly two hundred and fifty thousand dollars per person, is a two hundred million dollar annual spend. If a five person team with the right workflow produces what thirty people used to produce, you are currently paying for four to six times the engineering capacity you need. That is about a hundred and fifty million dollars of capacity you could be redirecting toward things that actually grow the business.
You are not going to fire eighty percent of your engineers. You are going to ship four to six times the roadmap you are shipping now. You will do it against competitors who already figured this out.
But if you skip the standard, you do not get the multiplier. You get the tool bill and the old throughput. That is the worst outcome available to you. You have spent the money and kept the constraint.
Now for the uncomfortable thing. Someone on your board is already saying it in private.
In late twenty twenty-two, Elon Musk bought Twitter and cut the engineering organization by roughly eighty percent. Set aside what you think of him personally. The operational fact is that a company with seven and a half thousand employees went to about fifteen hundred and the service did not fall over. That was pre-AI. No agents. Just a willingness to remove the layers of coordination and run the company at a headcount that looked absurd.
There are other examples. Meta removed roughly twenty-one thousand roles and the product shipped. Shopify sent an internal memo saying any new headcount request had to start by proving an agent could not do the job. They continued cutting into the existing base. These are different companies and one pattern. The coordination layer was doing less real work than the headcount said it was. The organization ran when the layer came out.
Your board watched those happen. Your investors watched them happen. The question they are quietly asking now, with agentic tooling available, is how long until they can expect the same from you. Maybe not eighty percent. But something in that direction. Delivered on a timeline that is no longer generous.
You can be the executive who gets in front of that conversation by setting the standard and reshaping the organization. Or you can be the executive who gets the question across a boardroom table and does not have an answer ready. Both of those jobs exist. Only one of them is still yours in twenty twenty-eight.
Now. Here is the conversation you are avoiding. The reason you have not set the standard is that it means telling some of the people who built this company that the thing they were great at for fifteen years is not the thing that is great anymore. That conversation is hard. It should be hard. You hired these people. You owe them a real onramp and a real shot at qualifying into the new role. Most of them will take it. A few will leave, and you will miss them.
You also owe the standard to the rest of the organization. The people who are ready. If you do not set the standard, you are telling them the company has decided to coast.
Coasting is not on the menu. The companies coasting in twenty twenty-six are the acquisition targets of twenty twenty-eight.
The move this quarter is simple. You do not need another pilot. You do not need a capability matrix. You need to write the new engineering role in your own words. On a single page. Define the qualification in terms someone can pass or fail. Pick the first cohort. And send the note that tells the organization the boats are burning.
Ninety days later you will know whether you have an organization that can compete in twenty twenty-eight, or whether you are watching one self-measure its way into a slow exit.
How do you set the new standard for working at your company? And what happens to the organization if you decide, one more quarter, to wait?