How serial heroics across teams can quietly damage the organization
The problematic traveling salesman
Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.
Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.
Some engineers build systems. Others build teams. And some build a personal legend. This article is about the third type.
You have probably seen this pattern. An engineer joins a team, spots a high-visibility pain point, ships something impressive, gets praised, and then quickly moves to another team to repeat the cycle. From the outside, it can look like having a super hero around. One team after another appears to benefit from this person’s “high impact.” But when you look closer over 12 to 24 months, the picture changes. What looked like heroism often turns out to be a selfish optimization loop: maximize personal visibility, minimize long-term ownership.
Impressive vs impactful
Work can be impressive or impactful where impressive work is always easy to notice. In contrast, impactful work is often slower, quieter, and harder to market.
Some examples of impressive work are:
a flashy rewrite
a complex migration
a clever architecture move
a productivity boost with a dramatic demo
The problem starts when the work is selected for visibility rather than durability, which creates a pattern of short-term wins followed by long-term fragility.
Impactful work, on the other hand, survives the author. It improves how the team operates after the spotlight fades. You can recognize impactful work when the engineer leaves the team, does the team become stronger, or simply more dependent on what only they understand?
The knowledge vacuum left behind
When people rotate quickly after shipping major change, knowledge does not transfer automatically. What gets left behind is usually predictable:
undocumented assumptions hidden in code
operational caveats known only by the original author
fragile components no one feels safe touching
“temporary” shortcuts that become permanent debt
The new team receives the engineer’s energy and fame whereas the old team inherits the “done” code. This creates asymmetric cost since the individual will get the career upside whilst the team pays the maintenance tax for years.
This is not leadership.
Culture degradation is the hidden cost
The technical debt bad yet it is still visible but cultural debt is worse since it won’t be easy to detect it. When a team is repeatedly left to support someone else’s showcase project, people learn damaging lessons:
visibility matters more than ownership
maintenance is low-status work
cleanup belongs to whoever stayed
short-term wins are rewarded more than long-term reliability
Over time, this erodes trust. Engineers who remain feel like custodians of abandoned monuments. They become more risk-averse, less motivated to own ambitious work, and more cynical about recognition systems.
Eventually, you get a predictable split:
a small group optimizing for portfolio projects
a larger group carrying operational burden without recognition
Once this norm sets in, quality drops and collaboration becomes transactional.
Why organizations reward this behavior
It is tempting to treat this as an individual character flaw and it might be the case. More often, it is an incentive failure. Many organizations over-index on visible launches and under-value sustainability. Promotion packets often celebrate what was started, not what is still healthy a year later.
If your system rewards:
novelty over maintenance
scope over stability
influence over accountability
then you should expect more traveling salesmen. Don’t forget that people will optimize for the scorecard they are given.
What managers should do differently
If you want to stop this pattern, make ownership part of performance, not a side quest.
You could, for example:
Measure delayed outcomes. Evaluate major initiatives again 6–12 months later.
Require handover quality. No “done” without docs, runbooks, ownership map, and training.
Track maintenance burden. Make post-launch support visible and attributable.
Reward team durability. Promote people who leave systems healthier than they found them.
Normalize finishing. Starting a high-profile project is only half the job.
And for internal mobility:
Set minimum stabilization windows after major changes
Require explicit succession plans before transfers
Include receiving and departing managers in sign-off
Mobility is good but unaccountable mobility is expensive.
A better model: builders, not tourists
Healthy organizations create builders, not tourists. Builders do not just ship. They document, they teach, they de-risk. They make themselves progressively less critical to day-to-day operation.
Paradoxically, the people with the highest long-term leverage are often the ones whose systems keep working after they move on. That is real impact not a trail of dramatic demos followed by years of cleanup.
Conclusion
The “traveling hero” pattern is seductive because it looks like momentum. But when each stop leaves behind hidden fragility, the organization is not accelerating. Instead, it is borrowing from its own future.
A great engineer should leave more than artifacts. They should leave capability. If your best stories are always about who saved the day, ask a harder question: Who is making sure the day does not need saving next year?