Years ago I read a book called “Extreme Ownership”. At the time the philosophy really resonated with me. The basic idea is that it’s the leader’s job to ensure the team’s success; they own making it happen. Failure falls squarely on the leader. Of course it’s not at all about taking credit; success is always the team’s, not the leader’s. At the time I was leading a growing team and consciously developing my leadership style for the first time.
I applied this style of leadership to the role of tech lead by doing things like telling the team that defects found in prod were my fault. I should have caught them in the PR review. Inaccurate or incomplete implementations were my fault because I should have written better tickets, better acceptance criteria, more detailed design documents. If a deadline slipped, then I should have planned better. The idea isn’t to be the scapegoat. Rather, by holding yourself responsible, by owning failure, you’ll be forced to drive the necessary changes to make your team higher performing. You also set the expectations and an excellent example for others to follow.
The book was written by a pair of elite military personnel. The principles are based on skills and practices that keep people alive in battle situations. That makes this philosophy quite well suited for stressful situations like when you’re under pressure from unrealistic deadlines or handling major setbacks. Demonstrating to the team that you have their backs and pulling out all the stops to lead by example both sets the tone and gives them the peace of mind they need to focus on the task at hand.
I used this approach effectively to lead through some serious challenges. We had moments of glorious success, when everything came together and the team delivered something of high value under immense pressure. We even managed to have some fun doing it. I am proud of the team and those successes.
However, a couple years in I can admit that we failed to manifest all the necessary changes to sustain this approach, I’ll own that. Over time my style of leadership became something of a crutch for the team, whether they knew it or not because I was shielding them, and held me back while adding undue stress (especially during a pandemic). With a desire to expand my responsibilities beyond one team I realized I needed to make a change. I had to shift from “I won’t let you fail.” to “I’ll set you up for success.”
“I won’t let you fail.” doesn’t scale beyond a large team or project; not for me at least. To bring my experience to bear on other initiatives, hopefully adding more value to the company, meant I needed to take a load off. The thing weighing on my shoulders most and taking a disproportionate amount of time was the level of involvement that extreme ownership required.
My new philosophy is “I’ll set you up for success.” This subtle change in mindset has profound impacts on the team dynamics. We’re taking the (unintentional) crutch away and asking the team to stand on their own when it comes to execution. I’m still involved in the planning (maybe too much), but by transferring ownership of the execution to the team they are now more empowered and invested. It hasn’t been easy or painless.
My manager frequently has to remind me that it’s OK to let them struggle. It’s best for everyone; we all benefit. Letting go and seeing them stumble is very hard for me. I’ve had numerous relapses where I see things going awry so I lean in and take control. Like anti-lock brakes engaging instinctively to prevent a crash. It’s also nice to feel needed. It’s a learning process for all of us. Software engineers need to be perpetual students and so too must our leadership styles evolve and adapt.