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.
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”.
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.
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.
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.
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.
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.