Some heroes pull frightened puppies out of flooded rivers. Others self-merge huge pull requests in the final moments before project deadlines.
That second type of hero doesn’t earn the keys to the city — or even a laudatory BuzzFeed headline. They just accrue technical debt and make people mad.
“Heroing,” or some engineers’ tendency to “fix” other people’s code late in the game, solves short-term problems at the expense of long-term growth. On small teams especially, this behavior can cause less zealous developers to second-guess their contributions — or check out entirely.
Steve Goldsmith, head of product for integrations at Atlassian, views heroic programming as a team structure problem. Atlassian makes productivity software for engineering and product teams, and Goldsmith takes care to practice the collaborative work processes his company preaches.
“That effort to jump in and help is actually coming from a good place, and it is prevalent in the open source world,” he said. “If that’s somehow rubbing people the wrong way, you’re probably doing it wrong. The one or two people working on a particular product are not going to do a better job than the collective wisdom of the entire team, if you can channel it correctly.”
At machine learning company SparkCognition, VP of engineering Randy Groves has learned to make the fine distinction between an over-eager engineer and a toxic team member.
“You have some of those who are super team players and everybody looks up to them and asks them for advice and works with them,” he said. “And then you have the others who are really good coders, but don’t know how to play nice with others.”
How to deal with heroing on an engineering team
- Learn when heroing is helpful and when it’s harmful.
- Understand the effects of heroic engineering — on the team and the product.
- Structure the code review process to minimize heroing.
- Don’t be blinded by a “hero’s” productivity.
- Prioritize transparency and trust in your team culture.
When heroing happens, pay attention to the context
To know when heroing becomes a problem, it’s important to understand when it’s not.
In a startup environment, for example, when teams are rushing to ship products without blueprints to guide them, chains of command can fall by the wayside. Sometimes, it’s more important to get a product across the finish line than to stick to a clear-cut review process, even if that ruffles some feathers.
In that scenario, Groves suggests managers level with their teams by addressing the heroing and putting it in context.
“When you start getting all kinds of hurt feelings and distrust is when somebody comes in and changes your code without an obvious business motivation for it,” he said. “So when a project’s in crunch mode and something’s blocking us, people are much more willing to accept that kind of behavior.”
“If the hero’s having to step in and redo the same person’s code on a consistent basis, that’s a red flag.”
Other times, there’s more to heroing than meets the eye. What looks to be a heroing problem may actually be an underperformance problem, especially if the recipient of the hero’s unwanted assistance is always the same person.
“If the hero’s having to step in and redo the same person’s code on a consistent basis, that’s a red flag,” Groves said. “Rather than doing it for the person, if you can help them learn so they up their skill level, that’s obviously the right long-term thing for the team. But if that’s been tried several times and they're still not able to do it, that's a different problem.”
Heroing can affect the product, not just team dynamics
The move away from siloed development and operations toward integrated DevOps has implications for heroing, according to Goldsmith.
No longer can a coding hero dust off their hands after making a massive, last-minute commit — their team likely has to answer for how each change affects operations.
“You really start to look at code changes in the context of operating a service for end users.”
“This code is eventually going to be part of a solution we’re providing to end users, and any of the changes that anybody makes eventually wind up affecting the functionality of this product and might cause outages or errors or make it faster or slower,” Goldsmith said. “You really start to look at code changes in the context of operating a service for end users.”
In an environment where development and operations are still separate endeavors and communication about code changes is sparse, negative effects could be even more pronounced, Goldsmith said.
“That service is now being operated by people who didn’t make those changes.”
Heroing can be fixed — or worsened — by the code review process
If a problematic hero doesn’t get called out by their colleagues, the code review process will often give them away.
This might come in the form of merging their own pull requests as a deadline approaches or ignoring feedback from other team members. Alternatively, the hero’s pull requests may receive very little feedback because teammates are too hesitant or too disengaged to disagree.
Managers can help by adjusting the code review process. Smaller and more frequent commits let the hero air their opinions during the process rather than jumping in later on. They also give less vocal team members a low-stakes opportunity to weigh in, rather than confronting the hero right before a deadline.
“If the reasons are more stylistic than substantive, that can cause team dynamics problems.”
“People should not be making large pull requests on a consistent basis,” Groves said. “Help them learn how to segment their problems into more manageable chunks that everyone else can understand better.”
Sometimes, a hero is identifiable not by the feedback they receive — or lack thereof — but by the feedback they give. A person who finds fault in every pull request can create discord, especially if their feedback is more about personal preference than functionality.
“If the reasons are more stylistic than substantive, that can cause team dynamics problems,” Groves said. “Even if the person’s not actually going in and rewriting your code.”
Know when to cut the cord on a hero
Heroing may cause team members to resent the guilty party and stop working well together. Or, it may cause them to check out, assuming the hero will pick up the slack and fix sloppy work.
Both outcomes are bad. It’s up to engineering managers to weigh the costs and benefits of keeping the hero on the team if they fail to adjust their behavior after it’s brought to their attention.
“There’s been several times I waited too long to rip the Band-Aid off.”
What’s toughest about making that call, Groves said, is that heroes are often extremely productive contributors. The high self-esteem that makes them tough to work with also makes them quick and creative, so the decision to remove them from a team can be a painful one — especially if there’s potential for them to use their powers for good.
At some companies, managers could solve the problem by assigning problem contributors to solo projects. In many environments, however, that’s not an option, and managers must decide if the contributor is receptive enough to be coached toward better teamwork.
“I’m someone who always tries to do as much coaching as possible for anyone on either side of the productivity spectrum. But it’s easier if somebody’s just not cutting it than to let somebody go who’s obviously brilliant and very productive,” Groves said. “There’s been several times I waited too long to rip the Band-Aid off.”
Preempt heroing by getting intentional about team culture
The best time to address heroing is before it happens.
The structure of your team and its workflow is a huge factor in preventing unhealthy dynamics. By striking a balance between ownership and collaboration, you can sidestep problems down the line.
For Goldsmith, that means creating an environment where contributors have complete visibility into team members’ assigned tasks, but no one feels too possessive about a given project.
“These symptoms tend to happen in these organizations that have this walled garden, closed philosophy around source code.”
“Everybody should have access to that information and make good decisions with it as a group, so it’s not like, ‘Only my boss can see where I’m at on this project.’”
For him, heroing becomes an issue when team members feel insecure about accepting help.
“These symptoms tend to happen in these organizations that have this walled garden, closed philosophy around source code: That only the following list of people can make changes to it and we’re not willing to accept contributions from other people,” he said. “Therefore, when those contributions do come in unasked, there's this cultural problem.”
Team culture starts with company culture, which starts with company values. Use your company’s stated values as something concrete to point to when team dynamics go awry — there’s likely something in there about collaboration, modesty or flexibility.
Atlassian even conducts values-based assessments during the interview process, in which employees from departments outside the candidates’ prospective team evaluate how well the candidate works with others, among other criteria.
By building a team culture of transparency and trust, Goldsmith said, managers can avoid the types of situations in which heroes are most tempted: when deadlines are approaching and stuff isn’t done.
“Transparency and openness around what work remains on the team’s plate, and even the practices around that of stand-ups and sharing progress, creates a culture that lets people say, ‘You know, this task is bigger than I thought. I’m not going to meet my deadline. I need some help on it.’”
