I recently finished reading The Dichotomy of Leadership by Jocko Willink and Leif Babin, and found the book very valuable. This book describes a series of “dichotomies” that leaders must balance to run effective teams and organizations. Each dichotomy is explained with a series of examples fom the authors’ experience as Navy Seals and leadership consultants.
I found myself easily recalling examples of these dichotomies from my experience as a software engineer, so I decided to write up some of this myself in notes. The book is roughly divided into three sections: Balancing People, Balancing the Mission and Balancing Yourself. This series will follow that same pattern.
Part 1: Balancing People
The Ultimate Dichotomy
This chapter is mostly about creating relationships with your peers, and the balance you must strike if you have to ask someone to do something that could put them at risk. Outside of a true combat context, the general idea is how to balance caring for your teammates when their individual incentives may not be inline with the team or company objectives.
I encountered this a few times as a tech lead and manager at Google. Promotion at Google is done via a detached committee. Engineers assemble a “packet” containing their work and why they feel they are ready for the next level. This “packet” consists of a self evaluation as well as feedback from a set of peers, usually at this next level or higher.
The committee reviews a set of these packets and makes final decisions. A manager’s role in the process is to help the engineer assemble the best packet possible and provide advice along the way.
This means that managers have to balance a dichotomy: they have to help their reports assemble the best case possible for promotion, but also look out for the best interest of the team. One common method to help someone make a good case for promotion is to ensure they have a set of solid projects completed to write about in their packet- The sad reality is that not every project will earn someone a promotion.
A manager may be in a situation where an important project needs to get done, and one engineer is the best person to complete it quickly. The manager must balance the assignment of this project with the career needs of their reports. There is no right answer here - it’s possible to over-focus on keeping engineers happy and their careers at the expsense of getting things delivered as a team. At the same time, ignoring the personal and career needs of engineers means they will quickly get unhappy, unproductive and ultimately leave for another team or company.
Own It All, but Empower Others
This was one of the most useful chapters to me. The authors cover the challenges of owning a system, product or deliverable while delegating some or all of the work to other team members.
This is a classic challenge in engineering. Managers and leads struggle to balance doing work themselves with assigning the work to team members. Most leaders in an engineering organization were engineers themselves and feel a need to “stay technical” by continuing to contribute directly to important projects. They can also feel intense pressure to fix an important issue or complete a set of work on time. In some cases they may feel the best way to ensure completion is to “just do it yourself”.
Again, there is no easy answer here. It is important for managers and leads to stay connected to the work their team is producing. This helps them understand the day-to-day workflow of their team and maintain a working knowledge of the codebase and architecture. Unfortunately it is easy to go overboard here, especially for new leads and managers. Now on a manager’s clock, they find themselves with little time to focus on complex tasks and are often interrupted. Bug fixes and simple features that would have been a few days of work before stretch out into weeks.
Even when a lead is the best one to get something done on time, it still might not be the best idea. The lead should consider why they are the best one to get something done, and come up with a plan to remedy this situation. If no one else on the team knows how to do something, that is a problem. If no one else on the team has time to work on something urgent, that is a problem. The solution to these problems is delegation and mentorship. The lead needs to recognize that they have become a single-point-of-failure, and ensure that others on the team can step up.
The other big situation this dichotomy comes up in is when mistakes are made by a team. A critical service crashes. A severe bug is introduced in the latest release. A feature slips past a critical deadline. In all of these cases, the manager/lead is ultimately responsible, even when the code was written by a team member. The lead needs to own the failure and the remedy to it.
A bug could have been caught with a better testing protocol. The feature could have been scoped down ahead of time, or had more resources assigned earlier. A crash should have been mitigated with better monitoring and a more advanced deployment strategy. These are all ways the lead could have prevented the situation ahead of time, even when the task itself was delegated.
Resolute, but Not Overbearing
This is also a very important chapter in today’s software industry. It covers the tricky balance between flexibility and enforcement of rules and policies. In order to compete and retain engineers in today’s brutal hiring market, teams and companies are adopting more flexible workplace policies. Work-from-home arrangements, both temporary and permanent are taking the place of fixed office hours. Low-process “agile” development methods are replacing detailed reporting requirements and status updates from the waterfall days.
Blurry lines around these formerly standard workplace guidelines make enforcing and rolling out new policies difficult. Managers and leads are in difficult positions balancing flexiblity with disciple when running a team. One or two well-motivated engineers can usually be trusted to deliver a solution to a well-defined problem on schedule, but ten engineers in a room with no oversight are unlikely to add enough value to pay their salaries. Some amount of process is necessary. A manager should to strive to implement the minimum amount of process necessary, and no less.
This chapter also touches on the concept of leadership capital. This is an imaginary concept that can only be measured when a leader attempts to cash it in. You’ll quickly find out how much leadership capital you have, and how much you just spent when you try to implement an unpopular policy. Explaining the reasons for a policy in ways the team understands can cushion the capital hit incurred. Better yet is following up and showing the team the benefits of this policy after - this can actually help build capital back up.
I’ve seen leaders fail on both ends of this spectrum. Large organizations tend to accrue policies over time. If one tries hard enough, usually possible to find policies that conflict with other policies. The only way to get work done in one of these environments is to evaluate all of the applicable policies, and follow the ones that make the most sense.
I was on a team once that built an infrastructure platform. Other companies could use our platform to run their applications on, which were served directly to customers. After a series of outages, a new VP decided that we needed to focus on our own stability. He declared a production freeze, and any changes made had to be approved by him.
This had the short-term effect of improvinig stability - things rarely break when left on their own. But it had the long term effect of burying the team further in debt and making the problem worse. Layers underneath us were constantly shifting, and without the ability to make improvements to our platform we rapidly fell behind. Our own system was running on deprecated infrastructure, making it harder to improve our own stability. He still held the line, blocking all changes he didn’t understand. Even necessary or trivial changes were blocked and put in a queue for the VP to approve, that he was never able to get through.
After a year of this freeze, the VP finally declared victory, even though the system had not improved. The next 18 months were spent fixing up all the problems we had postponed earlier, only now we had a much smaller, less-experienced team because many senior engineers left.
The rigid enforcement of any policy needs to be carefully thought through. In this case, the policy was well-intentioned but ill-informed. Without a working exception process, the teams were unable to fix the infrastructure issues that led to the stability problem in the first place. And every engineer knows that running software has a half-life - putting off fixes and improvements leads to more work in the future. The fix here would have been to either reinforce the importance and priority of stability and let teams figure out how to deliver on their own (Decentralized Command), or to enforce a more flexible policy that allowed for necessary fixes.
On the other end of the spectrum, managers must enforce some set of policies - even in Silicon Valley’s lax culture. Few organizations are lucky enough to operate in a space where engineers are sufficiently self-motivated to work at their best every day, and team dynamics rarely allow for long-term stability without some guiderails.
When to Mentor, When to Fire
This chapter covers one of the ultimate balances a manager must face, and one of the least favorite parts of most manager’s jobs: deciding when to fire an underperformer. In some cases the decision to fire is clear. Termination of employment can be an easy decision if an employee has violated an important company policy, broken the law, or harassed a coworker, but in other cases the decision is much harder.
Maybe a new employee is taking a long time to ramp up. Maybe someone is struggling to pull their own weight and their peers are forced to pick up the slack. Maybe the job requirements have changed, and an experienced employee is having trouble with the switch. In all of these scenarios, the manager must first figure out what support the employee needs. Mentoring, coaching and training are almost always cheaper than hiring and ramping up a replacement, especially in today’s hiring market. Reversing the trajectory of a low-performer is also one of the most rewarding things a manager can do.
Unfortunately training and mentoring aren’t always options. Sometimes even after all options have been exhausted, an employee still can’t step up. There is a limit to everything, and a manager has to make the call on when to move on. Low-performers rarely effect only themselves - pressure on the team to deliver may be mounting, and resent from other team members could be growing. A manager spending all of their time mentoring and working with a single employee is unfair to the rest of the team.
Like the rest of the dichotomies in this book, there is no easy formula to use when making these decisions. There are several warning signs to look out for, though. When performance issues of an individual start affecting the morale of the team as a whole, when the rest of the team is feeling ignored or neglected, when a manager has tried everything they can, and exhausted every available option, it may be the right time find an employee another role where they can be more successful, or let them go.