AI Adoption Sticks When Leaders Are Willing to Fail in Public

Enterprises are pouring AI into their engineering organizations and watching pilots multiply without ever reaching production. The tools are good enough to use. Individual contributors already use them daily. What decides whether any of it scales is the person at the top, whether they will lead the change, experiment in front of their teams, and keep pushing after the novelty wears off and the hard parts show up. Amplitude spent six months learning that firsthand and came out shipping three times as many pull requests over that period with the same headcount. For leaders watching their own proofs of concept stall, the problem usually starts with them.

Wade Chambers is the Chief Engineering Officer at Amplitude and was the first to hold the role. He brings more than 25 years of engineering leadership experience from Included Health, Twitter, and Yahoo, and has spent much of the last two years relearning his own craft as the ground beneath it has moved.

"AI progression is largely not a technical issue. It's a cultural one," says Chambers. Amplitude rebuilt its pipeline and cut cycle time to under an hour, and the gains came as much from how teams worked as from the tools.

The bottleneck wears a title

Chambers no longer sees individual skill as the thing standing in the way. Roughly nine in ten organizations now use AI in at least one business function, and most engineers experiment on their own without being asked. He locates the real limiter higher up, in the leader who has to decide what to delegate to AI, whether the spend will pay off, and how to move the work forward without bolting the technology onto the way things were always done.

"The appetite and the ambitions of the person that's at the top, it has to be their willingness to go work through the change management inside of their organization, building buy-in at every single level and addressing some of the real challenges that come up as a result," says Chambers. Accountability lies with the person who owns the vision.

Leaders went on stage first

Amplitude ran two internal AI weeks. Before the first, Chambers told senior leaders they would stand in front of the entire engineering, product, and design organization and build something live. An SVP of product might code in front of everyone, or a head of design might take on an engineering problem, with roles sometimes swapped to force leaders outside their comfort zones. He gave them four to five weeks of runway and did not much care if they found workarounds they were comfortable with. The point was moving from knowing about the tools to knowing how to use them under pressure.

The exercise put leaders inside the same uncertainty they were asking everyone else to tolerate. Competence with the tools was almost beside the point. "That is fear-inducing," says Chambers. The demos did not go perfectly. Leaders adjusted their approach on stage and shipped working code into production anyway.

More than the code shipped that day, people saw their leaders take the risk. Employees reported a 35% to 40% improvement in productivity across engineering, product, and design after the first week. By the second, when the whole company went through the same exercise, people who had already lived it were there to coach everyone else.

The leaders had to feel it first

The stage exercise worked because people felt safe failing, and Chambers had already been through that discomfort himself. Two years ago, he could read his own field almost on sight. Now he describes himself as back at the beginning, relearning daily, the world different enough from yesterday that he has to catch up every morning. A 25-year engineering executive became a beginner again, and decided he could not ask his organization to do something he was not willing to do himself.

When people think one bad AI experiment could make them look obsolete, they are less likely to take the risk. "The more that people understand, oh, this isn't going to replace my job, I'm actually going to be able to delegate certain aspects of my job, but that opens up new things for me," says Chambers. People need to understand what AI is giving them before they can be expected to get comfortable being bad at it.

Nobody plans their way to a working agent

Amplitude paid for its agent education up front. The team started building agents before it had the evaluation infrastructure that agents require. They learned what infrastructure they needed by building the thing that exposed the gap. The opaque failures and unexplained costs made the missing pieces impossible to ignore, and the team built evals and guardrails into the system. Going through it firsthand also meant the problems Amplitude hit turned out to be the same ones its customers face.

"You've got to make it safe. You've got to have the evals, you have to have the guardrails," says Chambers. He is skeptical of the executive habit of copying what worked for someone else off a LinkedIn post and expecting it to transfer, since another company's playbook meets a different set of operations, resources, and constraints. When teams see the work demonstrated directly, the old engineering discipline still holds: clear separation of responsibilities, moving data once and keeping it as small as possible, and controlling the output.

Waiting for the blueprint is the slowest death

Chambers has watched Fortune 500 companies hang back, hoping a competitor absorbs the learning curve first, and he doesn't buy it. That kind of learning does not come secondhand.

The mistake, in his view, is treating AI adoption as a project that will eventually be completed. Each improvement exposes the next, and the organizations building that muscle now will be readier for the shift after this one because they have already learned how to change.

"You're going to be on the treadmill for a while," says Chambers.