It was October 28, 1922. The temperature at Grant Field in Atlanta, Georgia was in the low 70s, a perfect day for football. The Notre Dame Fighting Irish found themselves trailing Georgia Tech 3-0, unable to make a dent. Right guard Noble Kizer knew that something drastic had to happen—and soon—if they were to stand a chance of winning.
The story goes that Kizer stopped play in the second half of the game, pulled his team aside and said: “Boys, let’s have a Hail Mary.” Following a quick prayer, fullback Elmer Layden went on to score a touchdown. On the next possession, Kizer said again: “Let’s have another Hail Mary,” and Layden scored yet another touchdown. Thus was born the Hail Mary play—the rest is history.
Fast forward 94 years: somewhere in Silicon Valley, an engineering team is discussing the latest mission impossible. Perhaps it’s the last minute project guaranteed to secure their biggest customer to date, or completing that one feature that will save their largest customer, or maybe it’s fixing the mother of all scalability problems that’s brought their data pipeline to a screeching halt. It’s time for a Hail Mary: a call to arms for a team that is likely no stranger to such prayers. If they succeed, this will be a career defining experience, a story for the ages.
Sure, the story is an exciting one, but it’s likely that a “Hail Mary” play needn’t have been the best option for this team. But within engineering teams at a lot of today’s companies, there seems to be a tendency to celebrate the “heroes”—the leaders of those “Hail Mary” calls that exemplify the ideals of the extraordinary engineer. They’re always ready to tackle and achieve the impossible, to save the day when their teams are seemingly at a complete loss.
But at the same time we glorify engineering heroes, it also feels like we’re pushing the engineering “anti-hero” to the side—the methodical engineer that executes well on plans and sticks to commitments. While the image of an engineering team sitting down for a sprint retrospective, discussing the predictable, possibly boring, outcome of the latest production release, may not be the most exciting one, it’s time we start to celebrate the engineering anti-heroes of our world.
The Hero and The Anti-Hero
To make my case for the engineering anti-hero, I’ll define the hero and anti-hero.
Let’s start with the hero: the hero represents the extraordinary and exemplifies the ideals. They go for the dive and catch, save projects that have gone off track or are late and get things back on track. The hero jumps in when systems fail or major production/customer issues arise. There will always be something that goes wrong, so the hero will be needed in those times. But wouldn’t it be better to exist in a reality where the hero isn’t needed all the time? Where extraordinary is defined through consistency and cadence?
The anti-hero does not possess many of the familiar heroic traits associated with the team or person going for the “Hail Mary”. In the engineering world, the anti-heroes are methodical in their planning. The anti-heroes plan for every contingency, double and triple check their work and insist on multiple code reviews with every commit. The anti-hero mitigates the project going off track, thus never having to dive in. The anti-hero can be the hero when necessary and jump in to save an unavoidable situation, but even then, has enough foresight to plan for the disaster situations.
So what does the anti-hero playbook look like? The anti-heroes build their playbook through strategic planning before the project even starts. In practical terms, they define methodology for load testing, their team works to perfect sprint planning and estimations and they capture and define tooling and technical debt into their sprints. When the anti-hero encounters entropy throughout the course of their work, they are able to correctly diagnose and apply the right tactical solution in the context of their well defined strategy. Their work is solid and their outcomes are predictable.
Celebrating the Anti-Hero
When we start to see the value in anti-heroic behaviors, we can also start to celebrate the anti-heroes. While it’s no question that heroes play a vital role in saving certain projects, it’s the anti-hero who learns what’s fundamentally broken and puts in place mitigations to ensure that the hero isn’t fixing the same problems repeatedly.
Of course, we should still give thanks to the heroes that save the day, but don’t forget to give thanks to the consistent output of the anti-heroes. Heroes should not be overly leveraged or used; instead, both types of engineers should complement each other when working together within a team. We will always need heroes when we have to fix a poorly designed data model, address some mounting and unchecked technical debt or prioritize a feature needed to save our biggest customer. But if we create more anti-heroes, we’re also less likely to ever get to that point.
How can we foster an engineering culture of both heroes and anti-heroes where both groups will feel recognized and know their value? We should learn from the heroes to understand what’s fundamentally broken, and put in place mitigations to make sure that the hero isn’t fixing the same problems repeatedly. If the hero is going in and fixing the same issues over and over again, the anti-hero is not doing their job, which should be to mitigate.
Let’s acknowledge the consistent output of the anti-hero, thank the hero for saving the day and challenge the anti-hero to mitigate against the issue that the hero had to save. When all’s said and done, our anti-heroes should fundamentally change the definition of the hero.