How to Extract Leadership Gold from Any Domain

Why and how you should study 80 year old books and army field manuals

I like to read across a broad range of topics
Management. Leadership. Coding. Origami. Marketing. Parenting.

I like to read books that stood the test of time.
One of my favorite books is the 80 years old book, "How to Read a Book."

I like to read small books like Sun Tzu's "The Art of War."
And I like to read huge books, like Clausewitz's "On War."

So when Mario Caropreso wrote an article about management and positioning, I was intrigued. At first I thought it was positioning from a branding perspective. Then I realized it's positioning from the realm of military leadership.

There is so much to learn from military leadership.
There are so many things to avoid transferring into out lives.

In this post, I'll walk through where Positioning fits into military planning, what we can learn from this as engineering managers, and share general advice on how to effectively learn from adjacent fields.

SMEAC and Other Acronyms

Most Western armies have a standardized process for planning military activities, called the Five Paragraph Order. Here's how this looks like in the US Marine Corps: SMEAC.

If there's one field that likes acronyms even more than tech, it's the armed forces. So let's break it down:

1. Situation

2. Mission

3. Execution

4. Administration and Logistics

5. Command and Control / Communication

The structure is pretty simple:

1. Situation: Where are we right now? What's "point A."

2. Mission: What do we want to achieve? What's "point B."

3. Everything else: How do we achieve it? How do we get from point A to point B.

This structure brings a lot of clarity. I also love the way it puts the most weight on the How, while still placing it last in the ordering.

Positioning goes in the last paragraph. It details where the Commander will be at each stage of the tactical operation. Because leaders can lead from the front, and they can lead from the rear. Marco's post explores one aspect of these tradeoffs in detail. There are other aspects, such as morale.

What Does it Mean to Me?

Marco's post is worth a read to see how to translate Positioning into Engineering Management. There's a time to dive deep into the details and a time to take a step back and look at the bigger picture. Every great manager knows that you need a mix of both, with the balance shifting based on the situation. Jeff Wilke did a great job teaching this skill.

There's much more to learn from the 5-Paragraph process.

It's a simple process that brings clarity to a complicated organization that needs to move thousands of humans towards a common goal in a short amount of time.

The structure itself is worth learning from. If you're familiar with the STAR¹ format from your interviewing days, it should look pretty familiar. The only difference is the ordering: Situation, Result, Task, Action. This is because the Five Paragraph Order is a forward-looking narrative structure, whereas STAR is backwards-looking.

Don't discount the importance of narrative structure in your management role.

I can go on for several hours on what you can take just from this version of the Five Paragraph Order. The full version has much more details and carries many other lessons.

But I want you to take a step back.

Why should we learn from Military Leadership in the first place?

The answer should be simple.
Military Leadership is like Engineering Management, just a 100 times harder:

• The pay is lousy.

• The risk isn't being fired, it's death.

• There's no 9-5. Not even 996. It's 24/7. Literally.

• Your competitors are trying to kill you and play dirty.

So it makes sense that there's a lot to learn here.

How To Learn

Except that it doesn't make sense at all to learn from Military Leadership.

If the people on your team don't like you or the job, they can just quit. That's not really an option during war.

Military leaders have to think about so many things that you just shouldn't waste your time on. Your offices have working bathrooms, for example.

So what am I saying?
I'm saying that you need to do Transfer Learning.

Say you want to build an app that takes photos of cars and tells you what they are worth. You need a classifier model that identifies which car it is. Training such a classifier requires a lot of data. If you're wise, you'll cheat.

Instead of training a model from scratch, you'll train an existing model. You'll take a model that can classify cats, and train it on cars. This is called Transfer Learning.

This works well because some layers of the cats-model do work that's relevant for all vision models, like detecting edges. Other parts of the neural network are not relevant, and they will diminish in weight through the (re)training process.

This is exactly how you should approach learning from other fields.

The more in common that the adjacent field has with engineering management, the more you can take away.

You just always have to be careful to identify what is not relevant for engineering management.

Summary

Early career engineers often ask me if they should be generalists or specialist. The right path depends on the individual, but my general bias is towards being a generalist, at least early in your career. The more fields of software engineering that you get to experience, the deeper understand you'll have of engineering overall.

And it doesn't have to stop at engineering.
Your existing experience, from your hobbies to your past career, are valuable.
Spend the effort to figure out what learnings are valuable in your new career.

You'll be surprised how much learning is transferable.

1. Situation, Task, Action, Result