Tactical Tornadoes vs. Strategic Sculptors
How to Get the Best of Both to Ship Fast and Design Well
Meet Tom, the “Tactical Tornado,” who churns out features at lightning speed. Tom’s code might be messy, but his ability to produce new functionality in hours instead of days makes him unstoppable.
Now meet Sam, the “Strategic Sculptor,” who takes the time to craft robust, future-proof software designs. Sam’s code is clean, readable, and built to last, but the pace can sometimes feel slower than expected.
Who would you prefer in your team? It’s a tough choice, isn’t it? As an engineer, I’d lean toward working with Sam for her thoughtful, maintainable software designs. However, as a manager in a fast-paced environment, having someone like Tom in the team to ship quickly could be a game-changer.
Many software engineering teams encounter these two archetypal developers at some point, and some believe you must choose either blistering speed or meticulous design. The good news is that you can have both.
By the way, the term Tactical Tornado comes from John Ousterhout’s A Philosophy of Software Design, a valuable book with some strong and controversial opinions I don’t fully agree with. I read it because of Gergely’s recommendation, and Dr. Milan offers another perspective. As for Strategic Sculptor, that’s my own witty creation to describe the opposite style.
So how do you ship fast while still producing code that stands the test of time? Let’s dive into it.
The Tactical Tornado: A Short-Term Focus
A Tactical Tornado thrives on rapid feature delivery, programming tactically to meet immediate demands. When a stakeholder needs a must-have update by the end of the week, the Tornado dives in without hesitation, relishing the adrenaline rush of solving urgent problems. Before others have finished their coffee, the Tornado has already pushed the code to production, prioritizing speed over long-term structure.
Why Speed Matters
Speed can be a startup’s lifeline. Early on, you need to prove viability, please investors, and impress customers. Quick results can energize the entire team and provide an edge in a crowded market. When a competitor is about to launch a similar feature, being fast might mean the difference between leading the pack and playing catch-up.
The Dark Side: The Weight of Mounting Technical Debt
However, sprinting ahead often leaves behind convoluted logic and complexity. Each shortcut becomes a technical debt—similar to a small loan you promise to repay. If ignored for too long, interest piles up, and you eventually hit a crisis. A codebase riddled with half-baked solutions can slow new development. When the team spends more time debugging than innovating, the initial speed gains evaporate.
“In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.”
― John Ousterhout, A Philosophy of Software Design
Managing Tactical Tornadoes
While their speed is invaluable in the right context, managing Tactical Tornadoes effectively requires balance and structure. Here’s how to guide them:
Set Clear Standards and Automate Processes
Define must-have criteria for every commit, enforce basic unit tests, and use linting tools to catch errors early.Encourage Collaboration
Promote quick peer reviews and constructive feedback loops to balance speed with quality. Provide concise pre-merge checklists to prevent oversights.Plan for Cleanup
Schedule dedicated time to revisit and refactor rushed code. Make this a routine part of the process to ensure shortcuts don’t become long-term liabilities.Support and Guide
Celebrate their speed but encourage thoughtful design. Offer feedback, define guardrails for acceptable shortcuts, and provide resources to refine their approach without sacrificing pace.
With these small but consistent steps, Tactical Tornadoes can deliver fast results while maintaining a healthy, sustainable codebase. Properly managed, they become a powerful asset—not just for meeting deadlines but for driving innovation at speed without sacrificing stability.
The Strategic Sculptor: A Long-Term Focus
Strategic Sculptors prioritize well-architected solutions, taking a deliberate and methodical approach to software development. They invest time in identifying core abstractions, designing cohesive modules, and rigorously testing edge cases. The result? Code that is stable, adaptable, and built to endure. Focusing on the future, Strategic Sculptors anticipate evolving needs and create foundations that remain strong under the pressure of growth and complexity.
Why Thoughtful Design Matters
Well-designed systems age gracefully, minimizing the need to overhaul large sections of code. Adding new features becomes smoother, with fewer regressions or tangled dependencies. A well-structured codebase also empowers future developers to onboard quickly, avoiding the frustration of navigating a maze of hacks.
“If you want to maintain a clean design for a system, you must take a strategic approach when modifying existing code. Ideally, when you have finished with each change, the system will have the structure it would have had if you had designed it from the start with that change in mind. To achieve this goal, you must resist the temptation to make a quick fix.”
― John Ousterhout, A Philosophy of Software Design
The Dark Side: When Perfectionism Becomes a Trap
While thoughtful design offers long-term benefits, it can lead to delays when speed is critical. Over-refining an architecture or endlessly polishing tests can push a team behind the competition, especially in fast-moving markets. In startups, missing a product milestone or critical demo might mean losing funding or partnerships.
Managing Strategic Sculptors
Strategic Sculptors excel at creating sustainable designs, but they must balance precision with the need to deliver on time. Here’s how to guide them effectively:
Encourage Iterative Progress
Promote shipping “good enough” solutions early to gather feedback and refine designs later. Break work into smaller, manageable increments to maintain steady progress.Set Boundaries for Design Phases
Define clear time limits to prevent over-engineering. Keep the focus on delivering functional solutions aligned with deadlines.Celebrate Usable Results
Recognize early wins to build confidence and reinforce the value of delivering tangible outcomes.Avoid Perfection Traps
Emphasize functionality and practicality over flawless design. Encourage balancing long-term goals with immediate business needs.
By guiding Strategic Sculptors to balance precision with pragmatism, you empower them to deliver thoughtful, high-quality solutions that align with business demands. With the right support, they can build systems that meet immediate needs while ensuring long-term scalability and resilience.
Doing Both: Ship Fast and Design Well
Look, you don’t have to choose between speed and thoughtful design. There’s a way to merge quick delivery with robust, maintainable code. The key is to take on technical debt intentionally and pay it back diligently.
Technical Debt as a Tool, Not a Trap
Technical debt is like financial debt: you take out a loan (shipping quickly with compromises) to seize an opportunity, such as meeting a client’s demand or staying ahead of competitors. Used wisely, this “debt” can secure deals or market share. But like any loan, it comes with a cost. Neglect repayment, and interest piles up—resulting in a fragile codebase, slower progress, and eventual breakdown.
Knowing When to Rush and When to Refine
Before diving into a task, ask these key questions:
Is this an emergency or a strategic opportunity? A quick proof-of-concept might be worth it if it helps you outpace a competitor or close a critical deal.
Will this code be central to long-term success? If yes, invest time upfront to ensure a solid design. It will save more time down the line.
Can you handle short-term instability? If the temporary chaos leads to substantial gains, like onboarding early adopters or impressing key clients, it may be a reasonable trade-off.
Building a Culture That Values Speed and Solid Architecture
Creating a culture that values both shipping with speed and building sustainable, well-architected solutions requires intentional effort and clear practices. Here’s how:
Make Technical Debt Transparent
Keep a visible and prioritized list of technical debt and shortcuts taken during development. Regularly review this list with the team to decide which items to address next, treating it like managing loan payments. Align everyone on the risks of unmanaged debt and the long-term benefits of tackling it systematically.Celebrate Adaptability, Not Styles
Recognize Tactical Tornadoes that take the time to revisit and improve rushed code once the urgency has passed. Similarly, celebrate Strategic Sculptors who release early iterations and refine their work based on real-world feedback. Show the team that adaptability is more valuable than rigid styles and that both approaches contribute to success.Prioritize Iteration Over Perfection
Encourage releasing prototypes early to gather feedback rather than waiting for flawless solutions. Adopt a “ship and learn” mindset, where early delivery helps uncover better ideas. Promote quick iterations to test and refine concepts, allowing teams to adapt and innovate with flexibility.Leverage Tactical Programming Wisely
Use quick fixes sparingly, only when they are necessary to meet immediate goals. Dedicate follow-up time to refactoring and stabilizing rushed solutions. Position tactical programming as a tool for short-term wins, with strategic programming ensuring lasting value.
By following these practices, your team can deliver features quickly and build a codebase that remains strong and scalable for the future.
Final Thoughts
Shipping features quickly and building solid software don’t have to be opposing goals. Like taking out a mortgage to seize an opportunity, it’s fine to accept technical shortcuts—so long as you have a plan to pay them down later.
The key is recognizing that you can achieve both—speed when it’s crucial and thoughtful design to ensure long-term success. It’s about making deliberate choices to deliver quickly without compromising on quality.
Make technical debt visible and track it openly as a shared team responsibility. Address it systematically by committing to reduce it once immediate priorities are under control.
Support Tactical Tornadoes with clear guardrails to prevent quick fixes from becoming long-term liabilities. Encourage Strategic Sculptors to focus on iteration rather than perfection.
When your team understands and respects the value of both approaches, you can ship fast while building software that lasts.
Execution eats strategy for breakfast, but execution without strategy leads to collapse.
— Rafa Páez
Enjoyed the article? Hit the ❤️ button and share it with others who might find it helpful. Subscribe to support my work and stay updated on future issues!
Well-balanced article and very well written. Some observations from my personal experience:
- the main difficulty here is often not technical but of values: Sam and Tom disagree with each other. They know the technics but usually hate them and find them wasteful and abusive. Often,they aren't even able to explain why they think their approach is better than the other one and in which context. They will cite books, articles, blog post... They can even bring data and metrics to prove their point, but it will very often be done without a good understanding of the base principles underlying them, and more importantly, a lack of alignment on the common values shared by the team. Our role as manager becomes one of facilitator, encouraging the conversation to go deeper, asking Tom and Sam to acknowledge the pros and cons on both side, and asking them to find a common path on how to reach the best of both worlds in a collaborative way (all things you mentioned already, I'm just adding the underlying quest for a shared alignment here).
- I found too that iterative and incremental software development is the best approach here. Unfortunately, even if that method is known for over 40 years, it is still badly understand. In particular, the heuristic aspect of it, where the amount of doc, design, test, development, etc is always changing for each iteration, is something where I found people having the most resistance too. Tom will want to always be in development mode, Sam will want to pass more time in design, and Rhena will complain that not enough time is passed on tests. But overall, the real obstacle here is the fear to not have a definitive answer, to have to use your judgement to figure when the amount of X is good enough, and to not be afraid to be wrong about it. And that requires psychological safety, trust and, more importantly, courage and humility.
In my experience we have seen both type of developers. The speed of hot fixes really matters for critical application support and maintenance. We use staggered approach to deal with tech debts. Have you seen MACH architecture ( https://machalliance.org/) style-it brings best of both worlds - specifically designed for commerce and content management domains.