The Trap of Instant Heroism in the Era of AI
AI has expanded what engineering leaders can do. An engineering leader or manager can now draft a design doc, generate a prototype, build a feature, and refactor code in a reasonable amount of time, or sooner than an engineer would have in the past.
And that is exactly the trap.
The reason is that leadership has never been about maximizing output. Leadership is about multiplying your team’s output and outcome. AI makes it easier than ever to confuse “doing” with “leading.”
Instant heroism is cheap now
In the past, heroism (as writing code 🙂) required ingredients such as deep codebase context, long hours, and the willingness to carry risk. Today, heroism is cheap.
With AI, an engineering leader can parachute into almost anything, produce something that looks credible, and be proud of themselves: “I unblocked the team by writing the first version”, “I rewrote the whole codebase to speed it up”, “I fixed it myself because it was faster”.
It can be useful in the moment. But it has a long shadow.
When a manager becomes the fastest producer, the team quietly learns:
Their Decisions are moved elsewhere
Their Work might not be needed tomorrow
Their Ownership is temporary
Engineer managers can deliver a lot personally and still hurt the team.
Leadership is leverage, not speed
As an engineering leader, if you disappeared for two weeks, would the team keep moving forward?
If the answer is “no,” then you are not leading a team or a system. You are acting as a high-privilege IC with a calendar.
AI does not change this. If anything, it raises the bar. As individual contribution becomes cheaper, leadership becomes more clearly defined by multiplication:
Defining clarity on what matters and why;
Distributing real ownership with decision rights;
Facilitating fast feedback loops;
Making quick, high-quality decisions without constant escalation.
Your job as a leader is not to be the person who can do the work fastest. Your job is to make it easier for engineers to do great work without needing you to do it for them. It should amplify engineers closest to the work, not turn the manager into the primary operator.
When a leader should jump in
There are moments where jumping in and being hands-on is appropriate. The difference is intent and structure. Jumping in is healthy when it is:
Time-bound (“I’ll help for 48 hours”),
Preserving Ownership (the Individual Contributor remains the owner),
Learning related (pairing up with an Individual Contributor to empathize with the new workflow),
Exceptional (not the default).
Just watch out: a manager who frequently rescues the team trains it to be dependent and disempowers it.
Everyone can feel like a hero with AI today, which is precisely why leadership matters more. The best leaders in the AI era will not be the ones who can do the most. They will be the ones who create teams that can do the most, without needing a hero.