Sun Tzu’s The Art of War has been applied to everything from business strategy to dating advice. Most of those applications are a stretch. But software development? This one actually fits.
Not because building software is warfare (though some sprint planning sessions come close). It fits because the core thesis of The Art of War isn’t about fighting. It’s about winning without fighting. It’s about planning, adapting, and leading so well that brute force becomes unnecessary.
That’s exactly what good software leadership looks like. You don’t ship great products by grinding harder. You ship them by building better systems around the people doing the work.
Here are nine principles from Sun Tzu, translated for the people actually building things.
1. Strategy Over Brute Force
The supreme art of war is to subdue the enemy without fighting.
Build the right thing, not just more things.
Every team I’ve worked with that was struggling had the same root problem: they were building fast but not building smart. Product managers or executives would pivot frequently, leaving a trail of unfinished work. The backlog wasn’t a prioritized plan. It was a graveyard of half-baked ideas and half-finished projects that nobody had the discipline to kill or the clarity to finish.
The fix isn’t more velocity. It’s better strategy. Solve the problem before the feature list. Understand what you’re building and why before you write a single line of code. A well-scoped story that solves the actual problem is worth ten that solve an imaginary one.
2. Know Yourself and Know the Enemy
If you know the enemy and know yourself, you need not fear the result of a hundred battles.
Know yourself: your team’s actual skills, your real velocity (not the aspirational number on the slide deck), your tech debt load, your capacity after meetings and support and PTO.
Know the enemy: ambiguity, bad requirements, shifting priorities, the stakeholder who changes direction every Tuesday, the legacy system that fights you on every change.
Most teams fail not because they lack talent but because they have zero awareness of either side of this equation. They don’t know their actual capacity, and they don’t have a clear picture of what’s working against them. Planning without this awareness is guessing. And guessing at scale is expensive.
3. Flexibility Is Survival
In the midst of chaos, there is also opportunity.
Rigid plans break. Good teams adapt.
When reality shifts mid-sprint (and it will), the question isn’t whether to adjust. It’s how fast you can adjust without losing the thread. Don’t force a failing plan. Pivot early. The cost of pivoting on day two of a sprint is a fraction of the cost of delivering the wrong thing on day ten.
This doesn’t mean abandoning commitments at the first sign of trouble. It means building a planning process that accounts for reality. Track injection. Measure unplanned work. Build slack into your sprints so that when (not if) something changes, you can absorb it without blowing up the whole plan.
4. Efficiency Over Endurance
There is no instance of a nation benefiting from prolonged warfare.
Long sprints, long release cycles, and long feedback loops are where good software goes to die.
Ship small and fast. Iterate often. Kill scope creep early, before it kills velocity. The teams that consistently deliver aren’t working longer hours. They’re working in smaller increments with faster feedback. They know that a story that takes three days is dramatically less risky than one that takes three weeks.
And manage your tech debt before it snowballs. Every shortcut you take today is interest you’ll pay tomorrow. The teams that ignore this end up spending 80% of their capacity maintaining the mess and 20% building anything new. That’s not a team. That’s a maintenance crew.
5. Terrain Is Everything
The natural formation of the country is the soldier’s best ally.
Your stack, your architecture, your infrastructure, your org chart. That’s your terrain. And you’d better understand it before you charge into battle.
A team building on a well-architected cloud-native platform has fundamentally different constraints than a team maintaining a legacy monolith with a single shared database. The practices that work for one will actively hurt the other. You can’t transplant Netflix’s deployment strategy onto a team running a 15-year-old .NET Framework app and expect it to work.
Respect the terrain. Respect the org culture. Know the battlefield you’re actually on, not the one you wish you were on.
6. Protect the Team
Regard your soldiers as your children, and they will follow you into the deepest valleys.
This is the one most engineering leaders get wrong. Your job isn’t to push the team harder. It’s to protect them.
Shield them from distractions and politics. Don’t let every stakeholder request become an emergency that derails the sprint. Clear blockers before they become bottlenecks. Celebrate wins (even small ones) because morale isn’t a soft metric. Morale multiplies velocity. A team that dreads coming to work ships slower, buggier code than a team that feels supported and challenged.
Developer experience matters. When developers have clear requirements, sane architecture, good tooling, and leadership that removes obstacles instead of creating them, they thrive. That’s not idealism. I’ve measured it across multiple team turnarounds, and the numbers don’t lie.
7. Use Intelligence
What enables the wise sovereign and the good general to strike and conquer is foreknowledge.
Don’t charge blind. Decide with data.
Your “spies” are your metrics, your logs, your retros, your customer feedback. They’re the signals that tell you what’s actually happening versus what your gut (or your stakeholders) think is happening.
Track sprint completion rates. Track injection. Track cycle time. Run real retrospectives where people actually say what’s broken instead of performing a ceremony. Listen to your customers, and I mean the actual users, not the product manager’s interpretation of what users want.
The teams that improve fastest are the ones that build a habit of looking at the data, confronting what it says (even when it’s uncomfortable), and adapting based on what they learn. The teams that stagnate are the ones running on assumptions.
8. Attack the Weak Points
An army may be likened to water, for just as flowing water avoids the heights and hastens to the lowlands, so an army avoids strength and strikes weakness.
Prioritize bottlenecks and pain points. Don’t spread your effort evenly across everything. Find the constraint and attack it.
If code reviews are taking three days, that’s your weak point. If deployments require a manual 47-step checklist, that’s your weak point. If one team member is a single point of failure for an entire subsystem, that’s your weak point.
Deliver visible impact early to build momentum. Nothing builds organizational trust faster than fixing the thing everyone knows is broken but nobody has prioritized. Pick the highest-pain, highest-visibility problem and solve it first. The momentum from that win makes everything else easier.
9. Win Without Fighting
The greatest victory is that which requires no battle.
This is the whole point.
Influence with clarity and vision, not with arguments and escalations. Align stakeholders so your teams never work on the wrong things. Build systems and processes that make the right behavior the easy behavior. When your planning process naturally produces right-sized work, when your architecture supports independent deployment, when your team has the skills and the context to make good decisions, you don’t need to manage them. You just need to point them in the right direction.
The best engineering leaders I’ve seen don’t win by fighting fires. They win by building systems where fires don’t start.
The Daily Application
This isn’t abstract philosophy. It maps directly to the work you’re already doing:
- Planning: Know yourself, know your enemy. What’s your actual capacity? What’s working against you?
- Stand-ups: Expose terrain and weak points daily. What’s blocking progress? Where is the friction?
- Retros: These are your intelligence reports. What did the data tell you? What will you adapt?
- Releases: Small battles won consistently equals the war won. Ship small, ship often, learn fast.
Sun Tzu wrote for generals commanding armies across physical terrain. But the principles endure because they’re about something more fundamental than warfare. They’re about understanding your environment, protecting your people, and winning through preparation rather than force.
That’s not just good military strategy. That’s good engineering leadership.