Engineering Strategy Framework
Engineering Strategy Framework
Building Your Strategy as a Software Engineering Leader
In this challenging year for the software engineering industry, many companies have decided to flatten their organizations and reduce engineering manager roles. In my recent writings, I've explored one potential reason for such changes. Beyond cost calculations, reducing distractions, and narrowing the company’s focus, it sometimes comes down to the fact that engineering managers aren’t effective enough. It’s a harsh truth, but if their role is only to assign tasks, give orders, and read reports, it may bring more harm than the absence of such a manager.
You can delve deeper into my thoughts in these articles:
In today's article, I will explore one of the most challenging subjects, yet the one that differentiates great leaders from average ones. I want to give you tools and ideas for building a long-term strategy for your team and the technology you manage as an engineering leader.
The Greatest Leaders Have a Plan
Bad leaders execute, good leaders improve, great leaders compound.
Compounding is not about improvisation but a coherent set of actions in response to strategic challenges ahead. If you aim to build such a plan, there’s no better source of inspiration than Richard Rumelt’s "Good Strategy/Bad Strategy".
In his book, Rumelt discusses how successful organizations have constructed their strategies, detailing the key components of such plans as well as identifying poor strategy approaches.
All the materials I share below are based on Rumelt's principles and lessons.
Do I Need a Strategy as a First-Level Manager?
While Rumelt’s work primarily focuses on strategies for entire organizations, it is still relevant to lower-level engineering managers.
Even as a first-level leader (Tech Leader), I have applied Rumelt’s insights to create 12-18-month plans for my team and tech stack. This approach has enabled teams to rearchitect solutions, migrate tech stacks, reduce distractions, focus narrowly, improve quality, and more.
As an Engineering Manager or Tech Leader, you already oversee a portion of the tech stack, your domain, or possibly the entire product. You should have enough context to diagnose issues, establish policies, and choose concrete actions to move forward.
From my experience, here are some projects my teams and I have delivered as a result of strategic planning based on "Good Strategy/Bad Strategy":
Introducing Micro Frontends and Design System in an organization with monolithic solutions and multiple domain teams.
Redefining the role of QA engineering and rebuilding SDLC processes for frontend and mobile technologies. For more, see these articles:
Quality Assurance and Software Delivery Processes in Frontend Engineering
The Evolution of Apps Quality Assurance at Azimo - a multi-year project described in a series of articles.
Decomposing app architecture and building knowledge-sharing practices (e.g., engineering guilds) to transition siloed teams into cross-functional product teams.
It's crucial to note that these examples were not goals in themselves but responses to the most significant challenges facing the organization and engineering teams at the time. As I will demonstrate, a good strategy focuses not on outputs (e.g., building automated CI processes) but on solving the biggest challenges (e.g., enabling quick iterations over the product to deliver value to customers more often).
What Is Strategy?
Let's begin by defining what is NOT a good strategy:
Fluff Words: Vague, trendy jargon without real substance.
Set of Goals: Targets without a coherent plan.
Vision Without Execution: No feasible plan or clear guidance for overcoming obstacles.
List of All Problems: Diluted focus and too many objectives.
Strategy is not just about making decisions. In fact, as engineering leaders, we are seldom presented with few clear alternatives to choose from.
Usually, we are given challenges to solve, e.g., the app is crashing, or there is another customer's problem to solve (implementing new functionality is also the customer's problem we're solving), or the time-to-market is too slow, or the service's performance is too low. Or everything is broken according to your CEO - you deliver too slowly with questionable quality. 😉
A strategy is a designed response to the challenges ahead.
Good design, according to Richard Rumelt, incorporates three core aspects:
Anticipation: Observing and learning from the situation.
Premeditation: Preparing guiding policies so we don't just improvise.
Design of Coordinated Actions: Preparing a plan orchestrated in space and time.
Consider a slow time-to-market issue.
You might opt for improvisation, such as identifying and fixing bottlenecks in your build system. But is that really the core issue? Perhaps your engineers are too distracted, there are no clear acceptance criteria, priorities shift too often, or indeed, the deployment process is so time-consuming that engineers avoid it whenever possible.
Alternatively, you could start by designing a response to this problem. For example:
Anticipation: Collecting feedback from teammates, orchestrating the SDLC process, and listing manual steps in the process.
Premeditation: Not starting work until it's fully defined, not deploying until code is fully tested, ensuring build time does not exceed 1 minute.
Design of Actions: Rebuilding the team's calendar to ensure at least 4-hour blocks of undistracted work each day, setting KPIs for pickup time, automating some manual processes.
What Is a Good Strategy?
To formalize, here are the critical elements of a good strategy as described in Rumelt's book:
The Diagnosis involves understanding the current situation and identifying the organization's key challenges.
The Guiding Policy sets out the overall approach the organization will take to address its challenges.
The Coherent Action involves a series of coordinated actions designed to implement the guiding policy.
A good strategy must be diagnostic, actionable, and coherent:
Diagnostic: A good strategy is based on a clear understanding of the current situation. The organization must comprehend its challenges, strengths, weaknesses, opportunities, and threats.
Actionable: A good strategy is actionable, specifying specific actions the organization can take to address its challenges.
Coherent: A good strategy is coherent, aligning the organization's various actions with each other and the overall guiding policy.
How to Build Your Strategy?
Building a good strategy can take weeks or even months. And in reality, it's an ongoing process. Challenges change, as does the environment and available information. Old problems are resolved, and new ones arise.
What has helped me keep control of the situation is a large online whiteboard. Recently, I've been using FigJam, but Miro has also served me well in the past. I regularly check this board, adding new information as it arrives, and share it with my team so they can contribute and learn from it.
The process involves four steps: