A senior technical executive I know spent six months at a company without ever setting up its product on their own machine. They were technical, experienced, and capable, and they were able to get by pretending at every meeting. By the time the gap became visible, they were so deep into the performance that asking felt more dangerous than continuing to act like they knew everything.

This is what happens when leaders don’t make it safe to not know something. People chose the only other option available: act like they do. That loop from competence performed at the expense of competence actually developed is one of the most expensive failure modes in engineering leadership and it almost never shows up in a postmortem.

I have spent 30 years watching this dynamic play out, and the thing I keep coming back to is how straightforwardly it can be interrupted. Leaders set the ceiling on what their teams feel permitted to do. When I ask a question I probably should have known the answer to eight months into a role, I am not displaying weakness, I am telling everyone around me that curiosity is allowed here, that the cost of not knowing something is lower than the cost of pretending.

Engineering teams need that signal more urgently right now than at any point in recent memory. The demands on them keep compounding: accelerate output, adopt AI tooling, do more with teams that have not grown and in many cases have shrunk. According to Gallup's State of the Global Workplace: 2025 Report, 40% of employees worldwide report significant daily stress, with North American workers hitting 50%. Stress produces self-protection, and engineers under pressure who do not feel safe to admit uncertainty make the same choice that executive made: they perform competence instead of building it and the organization absorbs the cost invisibly.

The quantifiable consequence of that dynamic is significant. A recent large-scale study by Boston Consulting Group found that 12% of employees with the lowest levels of psychological safety planned to quit within a year, compared to 3% of those with the highest levels. That’s a fourfold difference in attrition risk, driven almost entirely by whether people felt safe to speak up. For engineering teams already operating lean, it’s the difference between a group that holds and one that hollows out.

Gallup's research identifies the lever most directly in a manager's control: managers account for 70% of the variance in team engagement scores, and manager engagement fell three points in 2024, the steepest decline since the pandemic. That number tells me the behavior being modeled from the top is deteriorating exactly when teams need it most. What engineers see their leaders do, they will emulate. If the person running the team projects that uncertainty is shameful, the team will hide its uncertainty. If the person running the team asks openly, admits mistakes, and treats not-knowing as a starting point rather than a liability, the team follows that instead.

This is not a philosophy I landed on quickly. I used to call it hero coding. Early in my career I was the fastest engineer in the room, and I led accordingly. I was telling people how to build things, stepping in when I thought I could do it better, optimizing for my own output rather than the team's. What I eventually recognized was that approach produces a team of people executing your vision, which is a ceiling, not a foundation.

Real ownership means letting an engineer determine the technical direction, not just the delivery. I have a billing team member right now who built something I would not have chosen. But he could defend it strongly, and there was no meaningful reason his approach was worse than mine. It was just different. Overriding that decision would have told him with everyone watching that ownership at this company is conditional. That the agency we talk about stops at the point where it becomes inconvenient.

The AI transition is making this harder to get right. My team went from averaging 12 to 15 story points per sprint to 45 in a single sprint after fully adopting AI-assisted coding. That represented a genuine threefold productivity increase. That kind of acceleration creates pressure to keep pushing, to treat the throughput gain as the goal. But the engineers who are getting the most from these tools are the ones who understand that AI needs steering, that the value they bring is context, judgement, and the ability to catch what the model gets wrong. Developing that capacity requires an environment where engineers can say out loud that something the AI produced does not look right. This is exactly the kind of admission that dies in teams where uncertainty has been trained out of people.

The engineering leaders who will build teams that last through this transition and beyond are the ones who resist the pressure to perform infallibility. The leader’s job right now is to make it cheaper to ask than to pretend, and let engineers own the decisions that are actually theirs to make. Leaders must demonstrate visibly, repeatedly, and at some personal cost to their own image of authority, that being human at work is not a liability. That is where durable performance comes from. Everything else is just throughput with an expiration date.