Know yourself

Sun Tzu advocated: Know yourself. When leading an engineering project, it is imperative that you know the people on your team and their abilities, and you build a team with the capabilities to get the job done.

A modern army corps consists of several different types of divisions -- infantry, armor, cavalry, artillery, and support (here I use the term "division" fairly loosely. While infantry and armor are typically full divisions, artillery and cavalry may be deployed in battalions or regiments). Each division has its own abilities which complement and support each other. While we all know the importance of the tank in modern warfare, no army would be able to function if it consisted of only armored divisions. Without infantry, cavalry and support, armor would be bogged down, run out of fuel, and be easy targets.

A software engineering team is not unlike an army corps. The team must consists of people with a wide set of skills which compliment each other. In my experience, I have found that most engineers fall into one (or maybe two) categories analogous to army divisions. Creating a team with all of the right divisions, that is, the right combination of talent, is a critical responsibility of the team leader.

The following describe the types of engineers you would normally find on a functional software project team.

Corps HQ

No army corps would function without Corps Headquarters -- Corps HQ. HQ gives out orders, assigns objectives, and makes sure the corps consists of the right mix of cavalry, armor, infantry and support groups. Without HQ, an army corps would lose direction, and would degrade to a group of indipendent divisions, rather than as a coherent army corps.

In a software engineering project, the project leader is typically HQ; however, that isn't always the case. I've seen many cases where the team direction and leadership comes from an engineer, rather than the person designated as the leader. In those cases, the project leader may play a more administrative role, documenting decisions and plans, and allowing another person to give orders and assign tasks. This approach can work, as long as there is general cooperation among the people involved. Even an army HQ is not a single person -- it is a set of people who work together to lead the corps.

Sometimes the HQ role moves around during a project, for example, when the project leader takes vacation, or needs to temporarily work on a different assignment. The person on the team who steps up to fill that HQ role during a leaders absence is usually someone who will do a good job as project leader of the next project.


The armored cavalry regiment (ACR) in the US military is specially organized for reconnaissance and surveillance. They are generally equipped with armored vehicles. Being lighter and quicker than an armored division, the ACR can move quickly, find the enemy, and move on, allowing the armored divisions to prepare and engage the enemy in force.

On the other hand, the cavalry is not designed to engage the enemy on a large scale. They are lightly armored and if forced to stand and fight for a long time against a heavily armored enemy, they may be decimated. The cavalry must be kept on the move to be effective.

In engineering, the cavalry is the person who quickly spins-up on a problem, identifies the critical issues to be resolved, and perhaps figures out a prototype solution. These people are usually the first ones selected for "tiger teams" (which, after all, are basically ACRs) to address critical problems. Everyone knows the cavalry; there's usually a line of people looking for help outside their office. People go to the cavalry because they know they don't need to invest a lot of time explaining the problem; usually just a few words and a vague description of the problem, and the cavalry is off working on a solution.

While cavalry engineers are important to a project team, they must be used correctly to be effective. These engineers are best suited to short-term, high priority, and high pressure projects. When they are assigned large-scale development work, they can become bored, unfocused, and bogged down in details, and lose effectiveness. You might even find them going off looking for ways to help others in a crisis, rather than delivering their own work. A cavalry engineer, when not properly lead, may get labeled "renegade" or "loose canon;" those labels usually indicate poor leadership, not a poor performer.


Armored divisions, with perhaps 200 tanks and 200 armored fighting vehicles, are the workhorse of an army. An army corps might have three armored divisions, compared to one infantry division and one cavalry division or ACR. The armored divisions pack a strong punch, and can stand up to enemies for long periods of time, and often won't give up until success is achieved.

The armor on an engineering project are the people who produce the most. Given a clear set of goals, they analyze problems, write specifications, produce well documented and well tested code, and continue to do so for months, years at a time. They typically love working on projects from start to finish, and in their wake they leave a trail of high-quality products. These people aren't easily discouraged by problems -- problems are just more challenges to attack and overcome. Every successful project I've seen has a majority of armor on its staff. They might not spin-up on a task as quickly as cavalry, but they have staying power to see the fight through.

But tanks can't do everything. Some terrain cannot be crossed by tanks -- rivers are a serious obstacle, and require the engineer corps to build bridges. Advancing a tank column takes skill and planning, and cavalry can provide the critical intelligence to help plan their path.

Tanks must also be allowed to fight like tanks, using their speed and firepower to defeat the enemy. In Desert Storm, the US Army lost four tanks to enemy fire. Three were lost in some of the largest tank battles ever fought by the American Army; one of those tanks was destroyed while guarding a group of prisoners. Forced to move at the slow pace of walking POWs, the tank was easy prey for an anti-tank missile launched by a couple of soldiers in a jeep.

Engineering armor must also be allowed to fight like tanks, to work hard and be productive. If they become bogged down, by leadership indecision or technical obstacles, they may lose momentum, and in the process, lose effectiveness. It's critical for project leaders, with the help of cavalry, to chart a clear technical path for the armor to plow through. Armor must be well supplied and equipped; you don't want simple issues like a lack of disk space or not enough test equipment to slow down their progress. And once the armor has passed through and the major work done, infantry must occupy the landscape.


The role of infantry in the modern army is to attack unarmored targets, occupy and defend territory, and patrol for the enemy. Infantry moves slowly; however, it is thorough and can engage in house-to-house operations where armor is poorly suited due to limited maneuverability. Infantry can move to fully control an area, once cavalry and armor have destroyed major opposition.

In software engineering, infantry plays a similar role or occupying, patrolling and defending the territory conquered by the armor. Infantry engineers are very detailed oriented. Some of the key missions for infantry in software engineering are: design and code inspections, development in a support role, test development, and bug fixing. Where an armor engineer will get the code 99% right very quickly, the infantry engineer will get it 100% right, albeit, a bit more slowly.

Without infantry, your armor must take over this occupation role. Having highly productive engineers working on minor bug fixing is not necessarily efficient. On the other hand, infantry can play a big support role in the middle of development. As an armor engineer conquores a major problem, pieces often can be split off for infantry engineers to code up and test.

In some cases, infantry can be the junior engineers; however, there is a breed of engineers that are perfectly suited to infantry tasks. These people are very meticulous and thorough, but have a problem seeing the "big picture."


An army would come to a standstill without its support groups. No food. No ammunition. No fuel. No mail. No hospitals. While the support groups are not intended to engage the enemy directly, without their active participation, the enemy would surely win.

Likewise, an engineering project depends heavily on the support groups, such as:

  • Laboratory facilities (locations for equipment, network connections, power, logic analyzers, etc.).
  • Physical facilities (office space, desks, lamps, computers, printers, etc.).
  • Information technologies (file servers, disk space, CAD/CAE tools, network infrastructure, etc.).
  • Training, for new technologies.

One Size Does Not Fit All

Divisions of an army corps are identified based on their equipment and their training. An armor division can not easily recast itself as an ACR or an airborne division.

In software engineering, a label is not so easy to pin on an individual. One person may act as the cavalry for certain periods of time, and do it well, but prefer the role of armor. Another person, nominally infantry, could step up and tackle work normally assigned to armor. Some people can play any role you want; you just have to tell them what you need from them.

The roles I describe above are not meant to be pigeon holes, or branded on a person for life. They are only meant to describe the role they play on the project team, at any particular point in time. And to show that a project team needs a variety of talent, just like an army needs a variety of divisions to be highly effective.

Building a Fighting Force

One of the early responsibilities of a project leader is to build a project team. That team will typically include cavalry, armor, and infantry engineers, and will reply on support groups from around the organization. A team which lacks cavalry may not foresee technical issues and could get bogged down in the middle of the project. A team which lacks infantry may produce a product that is generally good but has a lot of little, annoying bugs. But when the team has the right balance of force, it will be most productive and successful.

In practice, a leader does not label engineers in this manner. But a good leader will identify the strengths of each team member, and understand the strengths, and weaknesses, of the team as a whole. Good leaders will say, "We need a person like that on our team" -- a cavalry engineer to scout out issues in advance, an infantry engineer to work on details in order to free up someone else, or an armor engineer to plow through work -- without even realizing the gap their trying to fill.

In order to build a successful team, you need to know your team -- know yourself.

Clancy, Tom and Franks Jr., Fred, Gen, Into the Storm, New York, 1997
Copyright 2007, Robert J. Hueston. All rights reserved.

great post! however, they do raise more tough questions. Given a problem, how do you build the right team? How much flexibility do you have in choosing people? Does your team have the flexibility to change with the problem? Ideally, startups need people who are both ACR (mobility) and tank (firepower). Startups are usually small, often compete against a giant rival, and their survival counts on every single member of the team. So, how to build a team to handle such job?

Posted by startup on April 10, 2007 at 08:18 PM EDT #

Post a Comment:
Comments are closed for this entry.

Bob Hueston


« June 2016