The conversation about jobs
The first question is about jobs, whether or not anyone asks it out loud. You can't promise an outcome you don't control, and the promise you make instead has to be one you'll still be keeping in a year.
Announce an agentic tooling rollout and the room will have exactly one question. Most of the time nobody asks it.
They ask about the tool instead. Which model. What it costs. Whether it works on the legacy service.
Reasonable questions, all of them. None of them the one people actually went home thinking about, which is whether this is the beginning of needing fewer of them.
Silence on that point is not agreement.
It's people deciding the question is unsafe to ask.
An org that has decided a question is unsafe answers it privately instead. Badly. Out of whatever it can assemble from the news, a hiring freeze it half remembers, and a sentence somebody's partner heard at another company.
You have to go first
What it costs to say a true and unwelcome thing is a price you set with your own behaviour. That's the rule from elsewhere in this curriculum and it applies here more than anywhere. Waiting to be asked sets the price high.
So raise it yourself, in the same conversation where you announce the tooling, before anybody has to be brave. Not a reassurance slide. The actual subject, given real time, with the uncomfortable parts left in.
The version that fails is the one everybody has already sat through.
A warm paragraph about freeing people up for higher-value work. No specifics. Next slide.
Engineers are professionally trained to notice a claim with no mechanism behind it, and that paragraph tells them you thought carefully about the messaging and not at all about the thing.
What you can't promise
You can't promise nobody's job changes. It will.
Headcount you probably can't promise either, because you don't control it.
You might have this year's plan. You don't have next year's, and the conditions that produce a freeze have nothing to do with what your team is doing with any tool.
So a CTO saying "nobody is losing their job over this" is making a promise with somebody else's authority. Everyone in the room hears the footnote.
Make it anyway and one of two things happens. It holds, and you got lucky.
Or it doesn't, and every subsequent thing you say is discounted, including the parts that were true. That's the real cost. It lands months later, on something unrelated, in the conversation where you most needed to be believed.
The honest sentence is smaller and it survives a bad quarter. Close to: I don't control headcount, I won't pretend I do, and here's what I do control.
What you can commit to
Four things, and all four sit inside an engineering leader's actual authority.
How the decision would get made, if it ever came to that, and that it would not be made on the basis of who adopted the tool fastest. People need this one most, because the fear underneath the fear is that usage metrics quietly become a performance record.
That nobody's standing depends on the tooling looking good. Say it plainly. The incentive to make it look good is enormous and it starts at your level, not theirs.
Notice, if the composition of the team is going to change. People hear it from you, early, the same way a board hears bad news early. No surprises isn't a courtesy you extend upward only.
And what you're investing in on their side: what the job becomes, which skills it now rewards, what you're doing to get people there. Real, with hours attached to it, or it reads as a consolation prize and gets filed as one.
Fear corrupts the measurement
This next part is an engineering problem, not only a decent-human one, which is usually what convinces the sceptic in the room.
Everything in this track about running the rollout as an experiment depends on honest reporting.
Cycle time you can pull from a system. Whether the thing actually helped, on this ticket, in this corner of the codebase, only ever arrives from a person willing to say it didn't.
Now let that person suspect adoption is being read as a proxy for attitude.
They won't say it slowed them down. They'll use it where it looks good, mention the wins, quietly hand-write the parts where it struggled. The evaluation comes back beautifully positive and entirely useless.
You spent a quarter measuring the incentive you created.
A rollout in a frightened organisation can't be evaluated.
Stronger claim than it sounds, and I'd defend it. The whole apparatus of baselines and matched cohorts assumes the reports are honest, and honesty here is a function of what people believe the numbers are for.
Which gives you a concrete reason to say what the numbers are for, out loud, at the start.
They're for deciding whether the tool is worth the money. They're not an input to anyone's review.
Then hold that line the first time a number would have been convenient the other way. That's the moment everyone is watching for.
The failure modes to watch
Three, in the order they usually show up.
Shadow usage, where people use tools that haven't been sanctioned because asking felt risky. You find out during an incident, or you don't find out. Cheaper to make the sanctioned path good and asking safe.
Performative usage, where the tool gets used because a leader mentioned it in an all-hands and everyone can read a signal. Looks like adoption on a dashboard. Produces nothing, and it's expensive, because someone is now doing their job in a way that doesn't suit the work.
And the quiet one: the engineer who has genuinely found the limits of the thing, could tell you exactly where it breaks in your codebase, and has decided it isn't worth the conversation. That person is the most valuable input you have and they're the first one you lose.
Write it down and don't improvise it twice
This belongs in writing, for the same reason every other consequential thing does: a message delivered verbally gets retold, and each retelling drifts toward whatever the reteller is afraid of.
Short. What we're adopting and why. What we expect to change about the work. What I can commit to and what I can't. What the numbers are for.
Then say the same thing, unchanged, every time it comes up for the next six months. Consistency is the only evidence available that you meant it.
And when something does change, say that early too. The trust you're spending here isn't really about the tooling. It's the same account you'll be drawing on for every hard thing that comes after it.