What can software people learn from Navy SEALs? Plenty! If there is any organization that knows something about unit integrity, teamwork and operational leadership, it is the Navy SEALs. While I am not a SEAL, and I certainly would not claim their skills, I have applied some SEAL-inspired principles in the software domain.
I’ve always been a fan of the fiction and non-fiction of Richard Marcinko, Navy SEAL and the first commander of Seal Team Six. If you haven’t heard of Seal Team Six, these are the formidable warriors that conducted the Bin Laden mission. I had read his book “Leadership Secrets of the Rogue Warrior: A Commando’s Guide to Success” around the year 2001, and his “Ten Commandments” resonated so strongly that I adapted them for my own use.
I carry this list with me as a reminder of my personal mantra of leadership. Whenever I am playing a lead role on a team, or in particularly challenging projects, I quite literally read them to myself every morning before the events of the day:
Cory’s Commandments of Software Leadership
(as derived from Marcinko’s “Ten Commandments of SpecWar”)
- Always lead from the front, not the rear.
- Treat all team members alike – with support, respect, and firmness.
- Never ask any team member to do something that you would not do first.
- Instill clear, firm, high expectations with the team, so that when tested, they are ready.
- Help the team learn from their mistakes – because this is Doing It Right.
- There will be tasks that we do not like to do; do them anyway.
- Make efforts to Keep It Simple, Stupid.
- Do not make assumptions – but when you do, know that you do.
- Remember that in the end, it is about results.
- It is ok to break some of the rules.
- Lead, follow, or get out of the way….and try to know when to do each.
Yes, dear reader. There are eleven commandments and not ten. But the content is the important part, so let’s set aside pedantic concerns and move ahead.
Application of the Commandments
For the most part, I hope the commandments are self-evident at face value. But like anything else, all those words are worthless unless one takes action to implement them. I would never claim that I do it perfectly, but here are some of the ways I have applied these commandments when functioning in a lead role.
Always lead from the front, not the rear.
It is no accident that this commandment is at the top of the list. Leading from the front is about fearless leading by example, and being unafraid of making mistakes in the interests of achieving team goals. This is not easy to live up to, because it requires you to keep your wits about you when everyone else is losing theirs.
When my teams are faced with challenges like coding in a different language, working with unclear requirements, or dealing with conflict, I like to be there every step of the way. I will prototype things myself, run test cases, write requirements, or bring in outside expertise to help coach through challenges – whatever it takes.
Whenever possible, one must be diligent about not letting negative discussions bring down the morale of the team. I found that one negative personality can bring down the morale of an entire team. Negative statements must be acknowledged, questioned, and brought to a positive viewpoint quickly.
If my team has to work extra hours, I prefer to be there with them, even if I am not directly helping. I protected the team against intrusion by negative outside influences like distracting meetings and unnecessary bureaucracy, even if that meant that I would be the only development representative to attend to such things.
It has nothing to do with martyrdom; rather, it is simply giving the engineering team space and time to focus on the problems that require a solution.
Treat all team members alike – with support, respect, and firmness.
My version of this commandment was sanitized from Marcinko’s version, but the point is similar. In a leadership role, it is vital to treat the team in a supportive but firm and uniform manner. The expectation was that the team would get the work done, period. If my team members had family issues, I would support any necessary accommodations, but I would set the expectation that the work had to get done one way or the other.
If someone on my team brought in a problem, I made it clear that I wanted them to bring a proposed solution too. In this manner, the team became used to talking about solutions, instead of dwelling on the fact that there were problems.
I gave candid but respectful feedback to members of the team, and I expected the same for myself. I was honored to get exactly that via three-sixty reviews at the end of one particularly challenging project, where my team rated me four point five out of five. Not perfect, but that feedback remains one of the prouder moments of my software life.
Never ask any team member to do something that you would not do first.
It is all too common for managers to tell engineers to burn the midnight oil while they leave on vacation. We have all seen the application of redundant status reporting or needless meetings are pushed on development teams particularly when the schedule crunch is really on.
I worked hard as a development leader to deflect distracting issues from the team, usually by doing it myself, getting outside help, or delegating outside the team. In return, I got very good at dubious skills like writing status reports for high level management, while my team got very good at solving for the problem domain. It seems to be a worthwhile tradeoff!
If I expected a software engineer to help with something off their normal track, like system level testing, I had to be prepared to do it myself. In part, this sets the perspective that no work is less valid than other work, nor is it “beneath” ones role to help in other areas.
Instill clear, firm, high expectations with the team, so that when tested, they are ready.
Development schedules can get jeopardized for many reasons – unknowns, dependencies, risks, lousy estimation, and so on. Even a perfect timeline can be put at risk by a passive approach to early deadlines and best practices. When you are on a year long project, what’s a couple of lost weeks at the start, right?
My philosophy has been to be diligent early into the process, so that all team members are ready when crunch time happens. I look at the early milestones as litmus tests for the team – after all, if they cannot handle the early stages of a project, imagine what will happen later!
A couple examples: aggressive pursuit of testability practices and TDD up front, usually translates to easier days toward the later delivery stages. In-depth discussion of key concepts early in the process will only help the team to engage in a deeper understanding of the problem domain when those concepts come into question, or when the design integrity begins to erode.
This early attacking of the problem might seem odd to those that are used to the feeling of going through hell to get a software product out the door. However, I think the going-through-hell approach is not a positive approach for the health of the team and it should be regarded as a sub-optimal exception, rather than the norm.
Help the team learn from their mistakes – because this is Doing It Right.
The waterfall school of thought often encourages architects and system analysts to design entire systems up front; sometimes this goes from the highest levels of abstraction, right into the weeds of classes, interactions, and objects.
Today’s so-called agile processes have largely eclipsed that way of thinking, but there is one side-benefit of the agile approach that seems rarely discussed. By this, I mean the following: a team usually cannot absorb concepts simply by being handed a large design document, or a UML diagram, no matter how great the design.
Simply put, team must start building the system; they must get some of the concepts right, and they must be allowed to get some of them wrong; they must be led into refactoring of the concepts by the more senior people who understand the big picture.
I think of this full mental immersion as Doing It Right, because with this approach, the team will naturally build their own very deep familiarity with the topic, both conceptually and tangibly in the code. They will look at things from angles that the original designers might not have considered; they will understand the mapping of the technical domain to the related business concepts, and they will be able to calculate the impact of changes to the integrity of the codebase.
The down side? Subject matter experts find it extremely difficult to be around when this is happening. It tends to be uncomfortable to those that understand the larger picture and feel the need to guide things in a very low-level or hands-on manner.
There will be tasks that we do not like to do; do them anyway.
Not every activity on a software project is fun or glamorous. Sometimes, system-level testing has to be performed by developers; sometimes, you have to be the person that writes down the meeting notes if you want others to remember what was discussed.
You can try to deny that it goes with the territory; you can say that it is not your role; you can wish the problem did not exist; you can spend time fighting it.
Sometimes it is less painful to just do it. I have had many projects where I played the role of a business analyst in addition to my normal role, simply because I happened to have those skills, and it had to get done.
Make efforts to Keep It Simple, Stupid.
Usually, the most simple path is the direct path. My teams sometimes take initiatives to eliminate unnecessary complexity from the development processes, the management of requirements, and other items.
There is much more than can be said about this point, which I will discuss in another post. For now, I will rest the point with the legendary Miyamoto Musashi: “Do nothing which is of no use.”
Do not make assumptions – but when you do, know that you do.
I have posted about the evils of assumption, and I think that writing speaks for itself. The hard part is knowing when you are actually making assumptions. On this, my preferred approach is to take the high-risk items into the backlog earlier than later. In this manner, big problems would reveal themselves earlier.
Remember that in the end, it is about results.
I have written about the Definition of Done in my book “Must-Have Skills for Software Engineers.” Nearly every day, I would sketch out the business problem and the way we were solving it, so that the end objective was understood.
I’ve heard that it takes at least seven repetitions of a piece of information before someone internalizes the message that is being delivered. On a complex project, the message must be repeated at least that much or more, and I will often have others socialize the same message, so that it gets through to the team members.
Having the “big picture” in mind during the day-to-day decisions will help make those decisions better. This echoes a point made by Steven Covey: “Begin with the end in mind.”
It is ok to break some of the rules.
I have been on projects in which we didn’t have time for some of the non-value-add rules and regulations of the company’s delivery organization. So, we bypassed some of them in order to satisfy the criteria that allowed us to move to the next point of the project scope.
I’m not saying that it was always the right thing to do, but sometimes processes are in place for little other than a noble purpose. The trick is to understand when a process has value, and to whom. Sometimes there are risks involved in treating certain processes differently, refactoring them, or ignoring them completely. Depending on the culture of the company, it can sometimes be easier to beg forgiveness than ask permission.
At the end of the day, what matters is achieving the business goals in a sensible manner, for what you perceive as the good of the company.
Lead, follow, or get out of the way….and try to know when to do each.
This is one of the most difficult commandments. I had to step out of the way and follow on several occasions where I realized that the team had to find its own answers where I could not. It was very difficult to determine when the role of “taskmaster” was needed, versus the role of “gentle guide.” At some point, I just trusted that I had framed the situation and guided the team to the best of my ability, then I let them take the lead.
Giving up the lead doesn’t mean you disappear, it simply means that you don’t have to be operate in the mode of “control” so much. In the best circumstances, the team might actually detect when they need your guidance, and they will seek it out. Moving from the role of taskmaster to guide means seeing the team chart their own path both individually and collectively. I found this transition to be one of the more satisfying parts of the leadership experience.
Epilogue
I have applied this mantra on several difficult projects, and I grew immensely from the experience. Not to say that the projects were not also ugly, painful, and stressful – they were all of those things. But the results were achieved, in one form or another.
Many years, projects, and companies later, I still carry the same laminated card around every day. I still believe in these values when it comes to line-level leadership. Perhaps you will find some of these SEAL-inspired commandments useful for you and your team.