Dichotomy of Leadership Book Review — Part 1
Balancing People
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 from 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.
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 expense 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. Many 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.
I was once on a team that was not performing very well. Features were slipping past dates we had committed to customers, production stability was on a downward trend and morale was low. Leadership recognized the tough position we were in, but unfortunately they gave in to instinct which often points the wrong way. Instead of empowering individuals to make remedies, they instituted a rigorous proposal and review process. Teams had to present all new ideas and projects before an executive committee, who provided feedback weekly. This committee quickly turned into a bottle-neck, requiring teams to wait months to even present work they needed to start immediately. Proposals were rarely approved, sending them back into this queue after another round of feedback. Work slowed to a halt.
This approach took “ownership” to the extreme. Things weren’t going well, so our executives decided they needed to review and approve every single thing. Instead, they should have worked with the team to understand why features were slipping and stability was falling. Then, they should have set clear priorities to help the team focus and deliver only what was truly necessary to dig out of this backlog. Instead of requiring every decision to come through their committee, they should have worked to empower and trust the individuals on the team.
Some of the best praise I’ve ever heard for an engineering leader came from one of my coworkers, and follows this pattern:
She sets incredibly high expectations for your work, and then makes sure you have everything you need to deliver.
This represents one way to balance this dichotomy. Set high expectations, and hold individuals accountable, but still own the overall deliverable by making sure the team is unblocked and has everything they need to deliver.
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 flexibility 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 clearly 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.
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 guide rails.
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 under performer. 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.
Wrapping Up
I found this entire book (The Dichotomy of Leadership) to be massively helpful in my career. I was surprised with how many of these lessons from military leadership directly carry over into software leadership. But as Jocko always says on his podcast, “every problem is a leadership problem”.
I plan on writing up similar summaries for the remaining parts. Writing this up has been even more helpful to me, and I can’t help but see more and more examples of these dichotomies being balanced (and not) in my day-to-day job.
