The Action-Planning Paradox: Balancing Execution and Strategy in Tech
How I learned to harness my "bias toward action" while avoiding its pitfalls
TL;DR: This post examines the balance between execution bias and planning in tech environments. I offer a decision framework based on project stage, team composition, and risk factors, with actionable strategies backed by real-world examples from Facebook/Meta and my personal experience leading teams.In the early days of my tech career, I received a piece of feedback that would follow me for years: "You're highly execution-oriented and don't plan much." This observation from my manager wasn't presented as entirely negative or positive—just a fact about my working style that I needed to be aware of. Over the years, this same feedback resurfaced from various managers and peers, sometimes framed as a strength, other times as a weakness.
This tension between action and planning reflects a fundamental dynamic in professional environments. Some call it a "bias towards action"—the tendency to prioritize doing over deliberating. It's a quality that's simultaneously celebrated and criticized in today's workplace.
The Double-Edged Sword
To think about it, in tech especially, the bias towards action can be incredibly valuable. Startups thrive on momentum. MVP development demands quick iterations. "Move fast and break things" became a mantra for a reason. Often when facing ambiguous situations, which do happen in every project I have been a part of, those who can make decisions without perfect information often push the projects forward while others who plan too much get riddled by the phenomenon called analysis paralysis.
But this same quality can lead to preventable mistakes. Without adequate planning, teams waste resources building the wrong solutions. Technical debt accumulates. Strategic missteps occur that more deliberate analysis might have avoided.
While Meta first started with the mantra → “Move fast and break things”, as soon as it grew bigger, it distanced itself from the slogan. And that is understandable.
As a small startup, Facebook's bias toward action was essential for growth and market penetration. Quick iterations, rapid feature deployment, and the willingness to accept some failures allowed them to innovate rapidly and establish market dominance, taking over players such as Myspace and Quora.
However, as the company scaled to serve billions of users, the cost of "breaking things" increased exponentially. A minor glitch that might have affected a few thousand users in the early days could now impact millions globally and cost millions of dollars by extension. The consequences of failures became too significant to ignore.
Finding Balance: Context Matters
What I've learned through my own career progression is that both action and planning have their place—the key is understanding when to lean into each. The appropriate balance shifts depending on:
1. Project Stage: In the early days of product development, speed often trumps perfection. Rapid prototyping and experimentation create momentum and visibility that can make the difference between breakthrough and obscurity. I've witnessed promising ideas fade into irrelevance simply because teams deliberated too long while the business and interest towards the product moved on.
As products mature, however, the equation changes dramatically. With an established user base, the methodical approach that might have seemed excessive early on becomes essential. You're no longer building on a blank canvas—you're evolving a system with real dependencies and expectations. The easy gains have been captured, and improvements now require deeper analysis and more careful execution.
2. Team Size and Composition: Small teams possess a natural alignment that often makes formal planning feel redundant. When five engineers share a single workspace, coordination happens organically through conversations and shared understanding. The overhead of detailed documentation can actually slow progress rather than enable it.
But, scale changes everything. What works with 5 people becomes chaotic with 50. Suddenly, feature guides, architectural documents, and clear roadmaps aren't bureaucratic obstacles but essential navigation tools that prevent confusion, redundant work, and misaligned efforts.
3. Stakes Involved: Not all systems carry equal consequences for failure. For low-stakes features—a UI enhancement or an experimental feature behind a flag—embracing action bias often yields the best results. The worst-case scenario is typically a quick rollback with minimal impact.
Mission-critical systems operate under different rules. A payment processing system failure means lost revenue and damaged trust. A security vulnerability in an authentication system could compromise user data. These high-stakes contexts demand proportionally higher investment in planning, threat modeling, and contingency preparation. The difference isn't merely about engineering discipline—it's about responsible stewardship of the systems entrusted to our care.
How I overall handle my Bias towards Execution
Over time, I've developed strategies to maintain my execution strength while addressing the planning weakness:
Time-boxed planning: Execution comes naturally to me, but I've learned to deliberately create space for thinking before acting. I now set aside dedicated periods—sometimes just 30 minutes, other times a full afternoon based on the feature or product—solely for consideration and/or research before writing a single line of code. This structured approach prevents me from bypassing critical thinking while also setting boundaries that keep me from falling into endless deliberation.
Documented decision-making: Rather than keeping my thought process locked in my head, I've developed a habit of continuously documenting key decisions and assumptions. My Obsidian workspace has become a living repository where each project has its own page, filled with evolving thoughts, considerations, and decision points. This lightweight documentation serves multiple purposes: it clarifies my own thinking, creates continuity when I context-switch between projects, and provides crucial context for team members joining later. Most importantly, it creates accountability for the reasoning behind decisions without creating bureaucratic overhead.
Balancing my Bias: Perhaps the most transformative strategy has been deliberately seeking out colleagues with complementary working styles. I now actively partner with more methodical thinkers who naturally question assumptions I might gloss over. While their cautious approach sometimes feels like it's slowing my momentum, I've come to appreciate how often these seeming delays prevent costlier detours. The tension between our different approaches often produces solutions neither of us would have reached independently—combining the thoroughness of careful planning with the momentum of decisive action.
Conclusion
I still consider myself action-oriented at heart. This isn't merely a professional tendency but a fundamental aspect of how I approach challenges and it is really hard to the point of impossible for me to get rid of this. My instinct to move, to build, to execute remains my natural center of gravity. Yet the journey through increasingly complex projects has taught me that this instinct, while powerful, must be channeled thoughtfully.
I've now learned to view planning not as the antithesis of action, but as its essential partner. The strategic pause—when well-placed—doesn't impede momentum but rather focuses it where it can have the greatest impact.
So, the answer is that: the professional landscape rewards neither the paralyzed planner nor the reckless executor. In a field where conditions shift rapidly, success belongs to those who can adapt—sometimes accelerating boldly into ambiguity, other times pulling back to carefully map the terrain before proceeding.
What's your natural tendency? And how have you learned to balance it with its complementary skill?
If you want to learn more about Machine Learning and the best practices, I would like to call out his excellent specialization, aptly named Machine Learning Specialization on Coursera. Do check it out.