This is the second in a series of posts where I discuss the book Small Unit Leadership: A Commonsense Approach by Col. Dandridge M. Malone, USA [retired], and how it relates to engineering team leadership in software development companies. Disclaimer: I have never served in the armed forces. These observations come from my 10+ years in the software development industry at various levels of leadership in various organizations.

---

The Same Problem

Software is a people problem. The longer I’m a part of software development the more examples of this I see. This isn’t a new idea. After reading Small-Unit Leadership I can see many ways in which the US Army is also a people problem. Unlike software development, however, the Army is a single organization focused on their particular people problem for over 240 years. It’s this enormous history of leading small teams which I found incredibly interesting, and comparing their methods with those in the software industry left me with a lot of food for thought.

A Leadership Toolbox

I won’t go into detail about the entire book, but I highly recommend picking up a copy for yourself. Most of the book consists of concrete and actionable suggestions for improving your ability to lead small teams. The first section is an overview of a fairly classic set of leadership qualities to measure yourself against. Second is an in-depth look at the tools of leadership within the US Army. Third is a set of tips and guidelines for developing soldiers. The book finishes with a literal leadership playbook covering topics like “how to be a better listener” with actionable practice steps and measures for success.

Motivation ← Performance

Motivation comes from performing well. Not the other way around. This is an incredibly simple but powerful observation made in the book. I’ve read a lot lately about motivating teams and keeping morale high. Most approaches tend to ignore actual team performance, or list it as an abstract benefit and goal of higher team morale. When teams are having issues with morale, the first response by many in management is to try to directly influence motivation with perks like free lunch or special events. They do this in hopes of keeping morale up and team output high. I have never seen these strategies work.

Of all the teams I’ve been on, the only ones with truly great motivation are the ones which consistently performed well. Being on one of these teams always feels great. You know that everyone on the team is performing their job at the top of their ability and it makes you want to perform even better still. You feel invincible. With all the attention motivation gets, I think this is an incredibly important lesson to remember. There really is no replacement for leading a team to great performance to lift up everything else within the organization as well.

Skill vs Will

When looking at job performance, you can categorize people across two axes. Skill and will. Your skill is how well you are able to perform specific tasks, and your will is how self-motivated you are when given a task. With these two measures people will fall into one of four classifications: high skill-high will, low skill-high will, high skill-low will, low skill-low will.

The book has excellent strategies for dealing with people in all classifications, but two areas really stood out to me. 1) Those high on both axes are the future leaders you should delegate responsibilities to and train for leadership. Growing leaders is the best way to increase your overall capacity and delegating responsibility is the best way to keep these high performers engaged and challenged. 2) Those low on both axes are a disproportionate drain on your resources and must be addressed directly. As a small unit leader your job is to find a way to move this person into a higher performing category. If they continually fail to improve they must then be removed from the organization. The amount of time you will spend managing these low performers otherwise makes them not worth the resources. The health of the entire team will benefit from addressing those in this classification.

I think this holds true for software development. But our advantage is that we have a higher level of control over who we let into our organizations. If we know those people with high will and the ability to gain skill are so much more effective than those without, we should do everything in our power to select for those qualities. Of course, no hiring process is perfect so having concrete tactics for dealing with all possible combinations is still extremely useful. Our advantage of control can also be a double edged sword. By selecting so narrowly we run the very real danger of excluding diversity across gender and race. Our filters for skill and will are extremely sensitive to personal bias. It’s clear that our industry is only now trying to really find ways to balance these two organizational benefits, performance and diversity.

The Golden Rule

How do you prioritize your work? There’s the daily planned work that has to get done. The constant stream of bugs and emergencies which always pop up. The random ad-hoc requests from all parts of the business. And the work to plan out and carve a path for forward progress.

Small-Unit Leadership presents a simple Golden Rule for prioritizing these competing tasks: give your attention first to the tasks which directly advance your organization’s core objective. The Army’s objective is to win the land battle. In support of that objective small unit leaders should only be focused on one of two things; leading soldiers and small units during battle, or preparing soldiers and small units to fight the battle. I think having a simple but powerful lens to view all priorities through like this in incredibly useful. What would your organization’s primary objective be? How can you help set that objective for everyone to rally behind and prioritize their decisions against? These are the types of questions organizational leadership must answer for successful small unit leadership.

I’ve seen companies without a strong objective devolve into a collection of small teams, each pursuing their own isolated objectives. Even if those small teams do amazing work and make great progress, they are all aiming in different directions and so the company as a whole will never achieve the performance possible when everyone pulls in the same direction.

How can small unit leaders help set an organizational objective? One of the qualities of leadership brought up in the book is courage. Courage happens on the battle field as well as off the battle field in dealing frankly and honestly with your superior officers. It is this courage which can help raise issues from the bottom up. Open and honest communication between all levels of leadership, in any organization, is vital to setting and communicating a unifying objective. The next time you’re in a 1:1 with your direct manager, have the courage to raise those issues that might otherwise sit quietly inside of you. The next time you’re engaged in a 1:1 with a direct report, have the courage to ask for honest feedback and dig for real issues.

Leadership Cross-Pollination

Small-Unit Leadership was a great foray into reading leadership books outside of the traditional software and general management track. The number of lessons and tips from this book that directly mapped to leading teams of engineers was eye-opening. Do you have a non-traditional leadership book to recommend? Drop me a line. I’d love to compare notes.

This is the first of a series of posts where I discuss the book Small Unit Leadership: A Commonsense Approach by Col. Dandridge M. Malone, USA [retired], and how it relates to engineering team leadership in software development companies. Disclaimer: I have never served in the armed forces. These observations come from my 10+ years in the software development industry at various levels of leadership in various organizations.

---

Why a book about Army leadership?

This book was a great recommendation from a couple of former colleagues. In a nutshell, Small Unit Leadership covers specific, time-tested, and (I believe) very applicable strategies and guidelines for leading small teams of any type. The book was written by former US Army Colonel Dandridge M. Malone for “company-level leaders”. In my opinion this level of advice translates extremely well to software engineering team leads, as they seem to operate at a similar level of responsibility. Col. Malone gives a great immediate summary of what it means to be a small-unit leader.

As a small-unit leader, you should only be doing one of two things:

• LEADING SOLDIERS AND SMALL UNITS DURING BATTLE
• PREPARING SOLDIERS AND SMALL UNITS TO FIGHT THE BATTLE

If you substitute BATTLE with DEVELOP SUPPORT AND EXTEND CODE, this fits quite nicely with a team leads responsibilities, with the exception that not all companies do a great job of preparing engineers. Future chapters and posts will talk about exactly how to achieve these two things. But first, what does leadership really mean and how does that fit into the bigger picture of company goals?

Leadership: the big picture

Before talking about specific leadership strategies, there is a great overview of what it actually means to lead a small-unit in the US Army. The book breaks this big picture into three straightforward elements. Tasks, Conditions and Standards.

Tasks:

As a small unit leader you are ultimately responsible for leading your team in the completion of concrete tasks. The types of tasks are obviously extremely different in software and the Army, but in my experience engineering teams work best when they are given a clearly defined task. This shouldn’t imply a waterfall management approach. A perfectly valid concrete task is “find out what technology will suit our plans best” or “prototype this new app to see if customers like the idea”.

Conditions:

The best analogy I can draw for conditions are how the team operates and handles changes and challenges while completing their task. To me this speaks to code review policies, team management processes (scrum, kanban, etc.) and retrospectives.

Standards:

This is by far the most interesting to me, as it’s something software companies don’t always think about ahead of time. Col. Malone again gives a great definition of what standards allow for:

THE SIMPLE, SURE KNOWLEDGE THAT EACH SOLDIER AND EVERY CREW IS HIGHLY TRAINED, AND THAT THEY ALL BELONG TO A SOLID, FIRM, COMPETENT, WELL-TRAINED OUTFIT THAT KNOWS WHERE IT’S GOING AND WHAT IT HAS TO DO.

This is exactly the type of engineering team I’d be proud to be a part of. Standards are a delicate balancing act with software teams. More generally than specific standards (e.g. coding standards or code review policies) I think holding a team to a high standard and finding unobtrusive ways to measure against those standards holistically is extremely valuable. I have found scrum demos and retrospectives very useful here. One obvious difference with software standards is the relationship between Engineer and Company vs Recruit and Army. Both demos and retros are best when they come from the engineers themselves.

The book goes into some detail about a few general leadership standards. One leadership standard which I have found companies almost always violate at some level is “HE KNOWS A GREAT DEAL ABOUT THE JOBS OF HIS SOLDIERS”. I think this is an interesting one because I have worked with many non-technical managers and things always go less smoothly than with a fully technical management structure. One of the many challenges of software development is the way it forces us to bring together many different skill sets. If you find yourself responsible for people who’s job you don’t fully understand, educating yourself about how they do their job might be the best way to strengthen the link with those you are responsible for leading.

Organizational support

After covering the basics of what leadership looks like, the book goes into the supporting organizational framework for the small units. This starts with a bottom up approach by talking about the fighting doctrine for winning the land war:

1. Forces and weapons must be brought together and concentrated at the critical times and places.

2. The battle itself must be directed and controlled to achieve the maximum effect of fire and maneuver at decisive locations.

3. And, at the cutting edge of that battle, soldiers must employ their weapons with the skill to […] win. They must fight smarter and better.

These three edicts translate exactly into levels of the chain of command. What’s more, these three edicts correspond very closely with the requirements for the organizational support of software teams.

Generals: concentrate forces

In many ways this level is analogous to the typical responsibilities of development directors. Organize and hire engineers, provide all necessary resources and make sure there is a clear direction for the engineering teams. The direction itself may not come from the development directors, but they must make sure there is a well-defined direction, otherwise the teams will flounder.

Colonels: direct the battle

This level is responsible for battle strategies at a cross unit level. Fitting units to terrain and responding to new threats. I would argue this is a combination of development directors and team leads. The leads coordinate the “battle” within the code. The directors coordinate the separate teams and make sure they have enough engineering power.

Captains: in the trenches

Described as “using skill and will to deliver firepower”, this is where the day-to-day coding lives. I would argue this is a combination of team leads and senior engineers. Those in the code day-to-day are in a much better position to make most technical decisions.

I think this clear definition of responsibility is also extremely valuable in software development. Software companies usually don’t have such well-defined boundaries and responsibilities, which can lead to ambiguity and dropped responsibilities. The key is that each level has a very specific responsibility and is held accountable for achieving their goals. Before you hire for a position, particularly in management, know what you expect them to accomplish and what they will be held responsible for.

Organizational leadership

To be effective as an organization, whether the Army or a software company, all the levels of responsibility need to coordinate closely. The book calls this “organizational leadership”. One team doing well doesn’t help if all the others are falling behind. A weekly scrum-of-scrums meeting has been extremely valuable with the sideways communication in my experience, but is something companies too often let fall by the wayside. When coordinating up and down the chain of responsibility, 1:1s and project kickoff meetings are extremely helpful in maintaining communication and making sure everyone understands where they are going and what the team is building.

Looking forward

All this and the book has only just started. This introductory overview of the supporting organization for small-team leadership really made me appreciate its importance. I think we can all relate to times when the support structure wasn’t there and how difficult that made things at the team level. In the next post we’ll look at the qualities of a small-unit leader, and start reviewing specific strategies for becoming a better team leader.