Want to be a great engineering manager? Let your developers fail

Most engineers don't stick with a project long enough to learn from their failures. That's a mistake.

Tips for how to become a developer

Facebook's Mark Zuckerberg popularized the idea of "moving fast and breaking things," which is a great recipe for agile software development. In the real world, however, those broken things sometimes stay broken for a long time. Worse, the developers responsible may not stick around long enough to learn from their mistakes. I was reminded of this in a conversation with Jean-Michel Pettit, a colleague and vice president of engineering for Adobe Experience Manager (AEM). Over the last 25 years, AEM has evolved to see a significant percentage of its engineers working on the product for a decade or longer.

According to Pettit, one of the best things about having an engineering team live with a product for so long is that they have to deal with the consequences of their coding mistakes. That may not sound like much fun, but it's a great recipe for helping to develop engineers as they, in turn, develop software.

When crashing and burning is a good thing

LinkedIn engineering lead Tom Dale agrees. Citing his colleague Stefan Penner, he noted in a tweet that "when mentoring junior developers, most people know it's important to give them challenges they can grow into. But it's also important," Penner went on, that "they be responsible for fixing it when the wrong solution crashes and burns."

In other words, Dale summarized: "There needs to be a direct line between tech decisions and the costs that come with them. If someone else swoops in to clean up your mess, it's harder to reflect on and learn from your mistakes."

SEE: Job description: Platform developer (Tech Pro Research)

Recently, Dale also noticed "a correlation between the 'we need to rewrite this legacy mess!' Folks and short tenures" at the company. "They don't often have to live with the fallout of their grandiosity," he continued.

Playing helicopter engineering manager to younger developers or to older developers on so-called "legacy code" results in stunted learning. If you don't allow people to fail and learn from that failure, Penner added, "you're robbing them of key learning opportunities." This isn't a matter of "throwing them to the wolves," which might also not fit well with delivery timelines and business objectives. It's simply a matter of allowing developers to learn by doing, and "doing" must include failure.

Keeping it interesting

Of course, not everyone wants to hang out with their code to see it through its awkward teenage years and into adulthood. As EmpireJS developer Kelly Sutton hhighlighted: "Asking folks to stick around to see things behave can be hard: it's put to the engineering manager to keep the challenges interesting and continuing." Developers, he went on, "need variety after a long-running project."

So what's the secret? "Vacations and patience are key," he noted.

This might have been meant a bit tongue-in-cheek, but the principle is right, and reflects the hallmarks of great leadership and mentorship. This is arguably one of the greatest functions an engineering manager (or, really, any manager) can fill: Helping employees grow. When managers see their roles in this way, near-term code problems become long-term building blocks to developing talent within their organizations.

Also see