More AI. More Pressure. Why?

Ron: Where the Problem Became Visible

It was a hot late-spring evening, and I was at a brewery with several other families celebrating our kids’ successful navigation of kindergarten. My son was playing soccer with his friends about 10 yards away. My wife was talking with the other parents. I was walking back with a cold beer when I heard what I always hear: “Hey, Jay!”

Yep, Ron.

Ron is the life of the party, always with a big smile, and the kind of guy who will yell hello across a crowded school event whether I’ve seen him or not. He’s also a senior engineer, a husband, and a father of two young kids.

I asked how his job search was going.

“I had to stop looking.”

When I asked why, Ron told me work had become overwhelming. His company had even offered him a new customer-facing role that sounded like a great fit, but he turned it down. As he described how much work he already had, it became pretty clear why: he couldn’t take on anything else.

I asked whether he was using AI to help, and he said he was. Even with it, he was still struggling to finish everything. From what he described, it seemed like expectations were increasing right along with the tool.

One thing kept bugging me: if AI is making engineering faster, why does it feel like the pressure is getting worse?

The Business Still Has to Make the Decision

Ron is where the problem becomes visible, but he isn’t where it begins.

Engineering has plenty of data, but from the outside, much of it still doesn’t answer the question the business actually has: What can I confidently plan around? That’s what makes engineering feel like a black box to so many business leaders.

The business still has to decide what to fund, what to stop, what to promise, where to put capital, and how much risk it is willing to take. That exposure doesn’t disappear because engineering is uncertain.

When leaders have experienced missed commitments before, wanting a better answer is rational. AI raises expectations because it promises greater capability. Engineering metrics may improve, but from the business perspective the underlying question can remain unchanged. If engineering can now do more, it seems reasonable to expect a clearer answer about what can be delivered.

What the business is asking for is confidence: a forward-looking answer it can use to make those decisions. The business isn’t wrong to need it.

So what does a responsible organization do?

It gets more rigorous.

More Rigor. Same Operating Assumption

When engineering misses important commitments, it’s reasonable for the business to try to reduce that risk.

Engineering knows it missed. So what happens next? It plans harder. That often means more detailed planning to get better estimates, reviewing more requirements before committing to a date, and more status reporting with red, yellow, and green indicators. I’ve even seen teams spend more time planning the details before they were allowed to commit.

I was in one planning session where the leader told the teams they had to be 80% confident in their plan before they left. I’ve also seen executives reach down into teams and ask why their work wasn’t story-pointed. All of it was intended to build more confidence in the plan.

Then there’s the business. It has seen engineering miss important commitments and often doesn’t understand why, because it was told along the way the team would hit the date. If engineering is already a black box, bringing in outside experts is reasonable. They have the frameworks, bring process and structure, have done this before, and often sound more certain. So why wouldn’t the business trust them?

More planning, more detail, more estimates, more expertise, and on the surface, it looks exactly like what a responsible organization should do when it wants more confidence in the commitment.

The assumption is that more detail will give us more confidence in the commitment.

Then the Organization Starts Acting on the Confidence

Once a commitment is accepted, it stops being just an engineering date.

I’ve watched this happen when a new capability was expected to arrive before a critical business period. The team delivering it expressed confidence in the date, and the rest of the organization started making decisions around that confidence. Sales changed how it prepared, and another team delayed work it normally would have done because the new capability was supposed to make some of that work unnecessary.

From their perspective, that was completely rational. Why spend time building a fallback for something you have been told will be there?

But that also changes how the rest of the business should think about the date. If the uncertainty had been clearer, that team might have kept the fallback work moving, or the business could have knowingly accepted the risk of stopping it.

Then the date moved.

Suddenly, the missed commitment was not contained to the team that missed it. Sales had to catch up on deferred work, and other teams had to put backup plans in place. People who expected the new capability had to return to the old way of working, at least temporarily.

The cost of a missed commitment isn’t limited to the commitment itself. It includes the decisions other people made while expecting the date to stay the same.

Flying Blind Did Not Lower Expectations

The organization still had to make decisions, but it did not necessarily have a strong forward-looking view of what engineering could deliver. Plenty of engineering data existed, but much of it described what had already happened or what teams were doing.

That is what I mean by flying blind.

And as AI expanded what engineering could do, expectations didn’t lower.

At a recent engineering conference, one engineering leader described his problem: his teams were delivering features faster than customers could accept them.

“Then why don’t you slow down?” I asked.

The table laughed.

“No, seriously. Why don’t you slow down?”

I took the reaction as a sign that slowing down didn’t feel like an obvious option. In the conversation that followed, greater engineering capacity was treated as something that should become more output. Later, another leader described executives asking for three times more productivity from engineering.

This time my question was different: why three times more?

What is the business trying to accomplish that it doesn’t believe engineering can support today?

This question was difficult for the table to answer. Leaders could point to improving engineering metrics; deployments were increasing, cycle time was lower, and DORA metrics looked better. But when the conversation changed from engineering activity to what the business could actually expect from delivery, one leader waved that part away as the “hand-wavy stuff.”

In the 2026 LeadDev Engineering Leadership report, 77% of engineering leaders reported internal AI adoption as a priority, up from 45%. When measuring AI’s impact on productivity, 63% of respondents used employee feedback, while only 31% looked at development time per feature. At the same time, 45% said they were working more hours and 41% reported less-motivated teams.

I don’t believe these are separate problems.

The pattern I see is expectations for capacity rising faster than the evidence leaders have for what that actually means for delivery. Engineering may be moving faster, and the metrics may even be improving, but the business can still be left asking the same question it had before AI arrived: what can we actually count on?

What Are You Actually Voting On?

Which raises a different question: what are we actually calling confidence?

I’ve written before about the difference between belief-based confidence and decision-grade confidence. Belief-based confidence comes from experience, judgment, and good-faith intent. Decision-grade confidence comes from evidence strong enough to support the decision being made. Both can sound convincing. Decision-grade evidence can confirm confidence, lower it, or sometimes increase it. It does not eliminate uncertainty or guarantee the outcome.

Earlier, I described a planning session where the teams were told they could leave only when they were 80% confident in the plan. In many planning frameworks, teams are asked to rate or vote on how confident they are that the plan is achievable.

So what are they actually voting on?

In most cases I’ve seen, the answer is some version of judgment: “We believe we can do it,” “the team believes the plan is reasonable,” “we’ve done this before,” or “this is our best estimate.” None of those answers are irrational. Expert judgment is valuable because experienced people have seen things others have not. The problem starts when the organization begins treating that judgment as decision-grade confidence.

A team says it is confident, leadership accepts the answer, and then product, finance, and the rest of the business begin making decisions around it. I call that Confidence Consensus: the shared organizational reality that forms when people begin coordinating around a delivery-confidence commitment. It can form around belief-based confidence or decision-grade confidence. The consensus itself is not the problem. The real question is what the consensus is built on.

A confidence vote can create consensus, but it cannot create delivery evidence on its own. The organization can become more aligned around the commitment even though the evidence supporting it has not changed.

A small, reversible decision can tolerate confidence based largely on judgment. But when millions of dollars and other parts of the business depend on the commitment, the question becomes whether the evidence actually supports that confidence.

AI did not create this problem. It increased expectations for engineering without necessarily changing how the organization builds confidence in what engineering can deliver. It can also raise confidence inside engineering. When teams feel more capable, the confidence vote can go up, even if the delivery evidence behind it hasn’t changed.

So what is the confidence built on?

When Confidence Starts to Slip, the Control Reflex Begins

When a commitment starts to slip, leadership usually leans in more to deliver the outcome the business wants. The business may already have planned around the commitment, customers may be expecting something, and other teams may have delayed work or changed priorities. And money may already be committed. So leaders start looking for more confidence.

I’ve seen this show up in many different ways: more status meetings, more detail in those meetings, more questions about exactly what the team is working on, more scrutiny of the plan, and more pressure to reconfirm the date.

I once joined a call on a program that was already more than a year late. About 35 people were on the call: directors, VPs, project managers, and engineering managers. My team was one of the last groups needed to finish the work, and I had to explain that the scope they were asking for would take longer than two weeks. I told my manager not to commit the team to anything in April. I believed we could confidently support mid-May. I went out on parental leave, and the team was then committed to mid-April anyway. They worked nights and weekends trying to hit it, missed the date, and delivered around the end of April.

When I came back, I asked the team whether waiting until mid-May would have changed how they worked. Every one of them said yes. They believed they could have avoided the nights and weekends. That left me with a different question: on a program that was already more than a year late, what did those extra couple of weeks actually buy the business?

Most of the questions leaders ask in situations like this are about the work itself: What are you working on? What’s blocking you? Are the stories estimated? Are we still confident in the date? Those answers make the work more visible, but they still leave a harder question unanswered: where is the delivery evidence supporting the confidence in the date?

An organization may have plenty of evidence that a team has delivered before, or that its engineering metrics are improving. What matters is whether evidence supports confidence in the next commitment, or whether it still depends mostly on the judgment of the people in the room.

When leaders lose confidence in an outcome the business still needs, they tend to get closer to the work and tighten control around the commitment; I call this the Control Reflex.

This response is understandable. If engineering has missed important commitments before, asking for more detail is reasonable. After enough misses, leaders may change whose judgment they trust before they change how they build confidence. If the business no longer trusts its own engineering organization to deliver, bringing in an outside firm can look completely rational.

An outside firm can bring experience, structure, and people quickly, and it can sound more certain than the internal team. But that doesn’t mean the evidence behind the commitment is better.

Eventually, the pressure reaches the people doing the work. Whether they are employees or consultants, they are asked to push harder and work longer to deliver what the business is expecting, even when they’ve been telling leadership something different.

And Someone Still Has to Make It Work

By the time all of this reaches someone like Ron, a lot has already happened. If the date starts to move, the expectations built around it don’t disappear. In many cases, they create even more pressure to deliver on the original commitment.

That pressure does not always come as someone explicitly telling a team to work nights and weekends, although I have seen that happen. More often, everyone knows the organization is counting on the date, and that can make it difficult to be the person arguing that the date needs to move. The scope may change, or the date may move, but when options run out, people work harder to deliver the outcome the business is expecting.

The people doing the work may not see any of this as a confidence problem. They participated in the planning; the team said it was confident; leaders and the business planned around that confidence; and everything looked reasonable at the time. But when the work turns out differently than planned, what the engineer experiences is simpler: too much work and not enough time.

This is how I think about Ron. From what he described, expectations for what engineering could deliver seemed to be increasing, and he was one of the people expected to keep up with them. He was using AI to help, but that didn’t make the pressure disappear.

Eventually somebody still has to make those expectations real. For Ron, the pressure was starting to affect more than just work. He stopped looking for another job and turned down a role he thought would have been a good fit because he already had too much work.

More AI. More Pressure. Why?

I believe AI is creating more pressure because business leaders see it as a way for engineering to do more. That expectation is reasonable. The tools are improving, teams are moving faster, and engineering can often produce more than it could before.

But the way many organizations build confidence in delivery commitments has not changed nearly as much. Higher expectations make those commitments more consequential. If the confidence behind them is still based mostly on judgment, planning rituals, or expert opinion, the organization may be expecting more without having a better way to understand what it can safely plan around.

For business leaders, engineering can still look like a source of delivery risk even as the tools improve. At the same time, AI can increase confidence inside engineering. Engineers feel more capable, engineering leaders see more capacity, and the organization may commit to more because the tools appear to have changed what is possible. Greater capability does not automatically mean the confidence behind those commitments is any stronger.

When confidence starts to slip, engineering leaders may get closer to the work, business leaders may ask for firmer answers, and the pressure eventually reaches people like Ron.

So I’m left wondering: what would change if engineering and business leaders had a clear enough view of delivery to make better decisions before the rest of the organization started planning around the commitment?