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.
Software development is not warfare. Developers are not soldiers, competitors are not enemies to destroy, and a missed sprint is not a battlefield loss.
The useful connection is strategy.
The central lesson of The Art of War is that preparation, positioning, intelligence, and an honest understanding of conditions matter more than force. The best victory is secured before the fighting begins because the leader has created circumstances where the desired outcome becomes likely.
That is exactly what good engineering leadership does.
You do not fix a struggling development team by demanding more effort from the same broken system. You clarify direction, understand capacity, respect the inherited platform, attack the real constraint, and build practices that make the correct behavior repeatable.
Good engineering strategy makes brute force unnecessary.
Strategy Creates Direction
The supreme art of war is to subdue the enemy without fighting.
When I worked at a systems control panel vendor, product direction followed the loudest customer.
The team would begin one feature. Another customer would become more vocal, so the organization would pivot. The unfinished work remained while the new request became urgent. Then a different customer would pull the company in another direction.
The team was busy, but the product was not moving.
No amount of developer effort could solve the absence of strategy. Working harder would only create more partially completed work.
I worked with the CEO to create a product roadmap and protect it from the next loud request. Customer needs still shaped the roadmap, but volume no longer determined sequence. The organization could finish work, release it, and then move deliberately to the next priority.
One of the first major investments was rebuilding the user interface and introducing an API layer. Customers received a faster, more modern product. The development team received a foundation that made later features easier to build and release consistently.
The strategic act was not writing more code. It was deciding which work deserved to survive long enough to finish.
Know Your Actual Capacity
If you know the enemy and know yourself, you need not fear the result of a hundred battles.
At a financial services SaaS provider, a six-person development team averaged 39% sprint completion across 25 sprints. Near the end of that period, completion had fallen into the 17% to 23% range.
The team did not lack talent. The planning system lacked an honest understanding of the team.
Stories were too large and estimated too low. Developers worked on islands, so one person’s blocker could not be absorbed by the rest of the team. Sprint commitments ignored PTO, meetings, support load, and the unplanned work injected after planning.
The organization knew how much work it wanted. It did not know how much work the team could actually complete under real conditions.
We began measuring the system: actual capacity, sprint completion, injected work, carry-over, and delivery trends. We right-sized stories, planned against available developer days, and rebuilt shared ownership so the team could respond when work shifted.
Completion reached 86% in the first sprint under the new practices. Across the next 11 sprints, the team averaged 85% while completing nearly twice as much work per sprint. Team happiness rose from 5.5 out of 10 to 10 within six weeks.
Measurement did not improve the team by itself. It replaced an imaginary planning model with an honest one.
You cannot develop a credible strategy for a team you have not measured.
Respect the Terrain You Inherited
The natural formation of the country is the soldier’s best ally.
At a healthcare SaaS provider, the system was living in the middle of a MongoDB-to-Postgres migration.
The organization had completed roughly half the move before reaching the difficult parts and returning its attention to new features. A bridge application shipped data from Postgres back to MongoDB so the legacy portions of the platform could continue operating.
That bridge became one of the most common sources of production trouble. It locked tables, got stuck, allowed data to back up, and halted downstream processes such as customer emails.
The migration had been started with a reasonable destination in mind. The failure was treating the difficult terrain between the old system and the new one as if it could be ignored.
The terrain included two databases, two operating models, a legacy Node.js 0.8 application, and production processes that depended on synchronization behaving perfectly. Every future feature had to cross that ground.
A clean architecture diagram could not erase the actual platform. A strategy that ignored the bridge, the legacy dependencies, or the migration cost would fail regardless of how attractive the destination looked.
Engineering leaders do not get to choose the terrain they inherit.
They do choose whether to understand it before moving.
Attack the Constraint
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.
At a marketing services SaaS provider, unplanned work consumed more capacity than the team committed during planning. In the first two measured sprints, injected work reached 145% and 142% of committed points.
The team could not solve that problem by spreading improvement work evenly across the codebase. The constraint was the stream of interruptions entering the sprint, especially customer issues and recurring data-integrity bugs.
We made the injection visible, then attacked its sources. Product management improved backlog preparation and reduced avoidable churn. Developers fixed the underlying data problems instead of repeatedly cleaning up the consequences.
By the fifth sprint, injected work had fallen to 19% of committed points. Feature work grew from 39% to 62% of sprint capacity.
The team did not become more disciplined through exhortation. The system became less disruptive because the dominant source of disruption was identified and reduced.
Strategy concentrates effort where the result can change.
Win by Building the System
The greatest victory is that which requires no battle.
Managers often become the enforcement mechanism for a weak development system. They chase updates, pressure individuals, mediate recurring confusion, and escalate whenever delivery begins to slip.
That is brute force management.
The better approach is to change the conditions that keep producing the same failure. Establish a roadmap that protects work from constant pivots. Plan against real capacity. Break work into shippable units. Make interruptions visible. Spread knowledge across the team. Write standards clearly enough that developers and AI agents can follow them without rediscovering first principles in every pull request.
Once those systems exist, the manager does not need to win the same argument every sprint. The team does not need heroics to overcome predictable obstacles. Correct behavior becomes routine.
This is the engineering version of winning without fighting.
The systems control panel vendor did not need another priority battle once the roadmap became authoritative. The financial services team did not need more pressure once planning reflected actual capacity. The marketing services team did not need developers to absorb endless interruptions once the sources of injection were reduced.
Good engineering leadership does not eliminate conflict, incidents, technical debt, or changing priorities. It creates an organization that can handle them without exhausting itself.
Sun Tzu’s language survives because the underlying lesson is larger than war: outcomes are shaped long before the moment of execution.
Choose the direction. Know your capacity. Respect the terrain. Attack the constraint. Build the system.
Then let the team perform.
Receipts
- Systems control panel vendor: A protected product roadmap replaced repeated customer-driven pivots. A rebuilt UI and new API layer improved the customer experience, accelerated later feature development, and made releases more consistent.
- Financial services SaaS provider: Sprint completion rose from a 39% baseline to 86% in the first sprint and averaged 85% across the next 11 sprints. Completed work per sprint nearly doubled, and team happiness rose from 5.5 to 10 within six weeks.
- Healthcare SaaS provider: A half-finished MongoDB-to-Postgres migration left a bridge application that locked tables, accumulated data, halted processes, and repeatedly caused production incidents.
- Marketing services SaaS provider: Injected work fell from 145% to 19% of committed points. Feature work increased from 39% to 62% of sprint capacity.
- Source text: The strategic principles are drawn from Sun Tzu’s The Art of War. English translations vary, so the short epigraphs should be read as familiar renderings of the underlying ideas rather than definitive wording.