The 11 Principles of Leadership
A duty of a leader is to grow leaders, not create followers.
Most software engineers wouldn’t expect their day-to-day to have much in common with the military. Yet, some of the most enduring ideas on leadership trace back to a list drafted in the U.S. Army more than 70 years ago.
After World War II, the Army sought a simple, teachable set of principles to shape leaders at every level. These appeared in the 1951 field manual FM 22-10 Leadership and lived on for decades, later adopted by the Marine Corps, which still trains new Marines on them today.
And because leadership is not about setting - it's about people, these “11 Principles of Leadership” apply to any leadership situation. Leading engineers might not be under fire, but they are navigating pressure, uncertainty, and high-stakes missions. Let’s walk through each principle — reframed for the world of software engineering.
- Know yourself and seek self-improvement
Army wisdom: leaders need self-awareness. Engineering twist: ever pushed architecture you loved but your team hated? Leadership starts with spotting your blind spots. Run your own retros—ask your team what you should do more of, less of, and differently. Treat feedback like code reviews for your leadership style.
- Be technically and tactically proficient
Soldiers must master their tools; engineers must too. You don’t need to out-code the staff engineer, but you do need credibility. Jump into a PR once in a while, own a tricky migration, or write the postmortem after an incident. Technical fluency earns trust—and without trust, leadership is just a title.
- Ownership
Don’t just hand out tasks—hand out outcomes. “Ship the new auth flow and ensure a 0.1% drop in failed logins” is better than “write the login page.” Rotate responsibility across the team so everyone grows their muscles for ownership.
- Make sound and timely decisions
Indecision is a decision—and usually the worst one. Software leaders often drown in debates: tabs vs spaces, GraphQL vs REST, rewrite vs refactor. The trick? Time-box decisions, document them (ADR style), and favor reversible choices. In incidents, speed beats perfection—stabilize first, optimize later.
- Set the example
Your actions define the culture more than any “engineering values” doc. Want detailed PR descriptions? Write them. Want fewer Slack pings after hours? Stop sending them. The fastest way to change team behavior isn’t an all-hands—it’s modeling.
- Know your people and look out for their welfare
Behind every engineer is a human. Learn what motivates them: the junior who wants mentorship, the senior who craves impact, the parent juggling school pickups. Protect focus time, fight burnout, and advocate for promotions. Leadership isn’t just shipping code—it’s shipping careers.
- Keep your people informed
Ambiguity is expensive. A short weekly team update beats endless “what’s going on?” messages. Keep roadmaps transparent, especially when things change. During incidents, over-communicate—engineers would rather hear “we’re still investigating” than radio silence.
- Seek responsibility and take responsibility for your actions
Step up for tough problems. Own failures, loudly. If your team’s release goes sideways, your name should be on the postmortem—detailing what you missed, not who messed up. Engineers respect leaders who absorb blame and deflect credit.
- Ensure tasks are understood, supervised, and accomplished
The “just figure it out” approach is lazy leadership. Kick off projects with clear intent: “Here’s why this matters, here’s what good looks like, here’s where we start.” Then calibrate supervision: handholding for juniors, checkpoints for seniors. Following through is just as important as handing off.
- Train your team as a team
Strong teams aren’t born in hackathons—they’re trained. Rotate on-call so everyone learns the system’s guts. Run chaos game-days where services fail in controlled ways. Host “architecture katas” where the team redesigns systems under constraints. Cohesion comes from shared reps, not just shared Slack channels.
- Employ your unit in accordance with its capabilities
In the Army, this meant not sending infantry to do a tank’s job. In software, it means matching ambition to capacity. Don’t promise a greenfield platform rewrite when your team is already drowning in pager fatigue. If leadership asks for the impossible, respond with phased plans and trade-offs. A good leader knows when to push—and when to protect.
Why This Still Works
The military eventually moved on to newer frameworks like Be-Know-Do, but the essence remains timeless. These principles cut through industries and decades because they deal with fundamentals - clarity, trust, accountability, and care for people.
Software engineering may not be in combat, but its leaders still face ambiguity, high pressure, and the responsibility of guiding teams toward outcomes that matter. The “11 Principles of Leadership” remind us that while tools and languages change, leadership is still very much a human craft.