How to Build Engineering Strategy
A Guide for Engineering Leaders at All Levels
—
If you read the theory behind frameworks for setting goals (e.g., OKRs), you will usually find that strategy and objectives should be cascaded down. This approach starts with the company’s mission and key metrics (KPIs), moves to the company’s objectives, and then translates into product strategy. The strategy then breaks down into granular objectives for teams or divisions.
Yet, the reality differs from the theory. Product strategy is often just a list of product features to implement. It doesn’t include things like tech debt or maintenance, SDLC processes and automations, or ways of working. In some organizations, as an engineering leader, you are the only person who knows what needs to be done to improve overall product quality, time to market, and underlying software architecture. You know when the support ends for your framework version or that your datastore solution doesn’t scale well and needs migration.
In my personal experience, as a Tech Leader (the first-level manager in a company), I owned mobile app platforms. Even though the company’s management knew what product they wanted to deliver, only my team and I knew how to take care of the platforms we built upon (maintenance, architecture, automation etc.).
Being an engineering leader means that you don’t just ensure the execution of product tasks handed to your team. It’s also about building a plan that compounds the outcomes of your team’s work. And for that, you need to have a good plan.
In this article, I will explore tools and techniques to help you build a long-term engineering strategy. Some work best at the organizational level, where Product and Technology collaborate on their challenges. Some can also be successfully applied at the team level and can inspire the rest of the organization from the bottom up.
The Greatest Leaders Have a Plan
Bad leaders execute, good leaders improve, and 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”.
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.
What Is Strategy?
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.
The strategy framework, built on these aspects, focuses on three things critical to our long-term plans (Richard Rumelt calls them the “Strategy Kernel”):
- The Diagnosis: Understanding the current situation and identifying the organization’s key challenges.
- The Guiding Policy: Setting out the overall approach the organization or team will take to address its challenges.
- The Coherent Action: Involves a series of coordinated actions designed to implement the guiding policy.
How to Build a Strategy
Here’s the short version — the process involves four steps:
- Collecting Input: Gathering information about strengths, challenges, opportunities, bottlenecks, current initiatives, and distractions. This information could relate to your team, the tech stack you manage, or problems presented by the organization (stakeholders, management, etc.).
- Strategic Blocks Grouping: Classifying all the input from the previous step, considering the components of strategy from Rumelt’s book, such as leverage, proximate objectives, using advantages, among others.
- Build Strategy Kernel: Based on the collected and classified information, formulate the Strategy Kernel — Diagnosis, Guiding Policy, and Coherent Actions.
- Iterate and Refine: The process of collecting inputs, grouping them, and describing the strategy kernel can take weeks, during which you should modify these boards and share them with the team and other stakeholders until everyone agrees that the strategy makes sense.
For a more comprehensive guide, I recommend checking the content on Practical Engineering Management, where I explore this process in detail: Engineering Strategy Framework.
PEM’s subscribers also get access to a FigJam whiteboard that can help you build an engineering strategy:
Input for Our Strategy
If you seek inspiration and examples of strategic blocks, I also recommend using Richard Rumelt’s wisdom, which lists these points:
- Leverage Objective: A pivotal objective that focuses on what is most critical.
- Proximate Objective: An objective close enough to be feasible despite ambiguity and complexity.
- Weakest Link in Chain: The limiting factor that needs to be addressed first.
- Power of Design: Deciding whether to couple or decouple resources and efforts.
- Using Advantage: Leveraging your strengths and opportunities.
- Riding the Wave of Change: Identifying and assessing early signs of significant shifts in the industry and environment.
- Understanding Inertia and Entropy: Building awareness of:
– Inertia — the resistance within organizations to making change.
– Entropy — the tendency for systems and organizations to move towards disorder.
Examples of Strategic Blocks
Here are a few examples from software engineering practices:
Leverage Objective / Fixing Distractors
Removing obstacles that prevent engineers from entering a flow state. This can include noise-canceling headphones in open-space environments or reducing noise in alerting systems so that people aren’t notified by dozens of false alerts per day. It might also involve rescheduling the team’s calendar so every engineer has at least a 4-hour block each day for focused work, or limiting work in progress — “stop starting, start finishing.”
Side note: Flow state is a critical factor in Developer Experience.
Read more about it in Abi Noda’s DevEx framework.
Proximate Objective / Transforming SDLC Processes
The ultimate goal — true continuous delivery or deployment — is often too ambitious to tackle at once. First, you must decompose it into achievable steps, such as good testing practices, rollout and rollback solutions, good monitoring and alerting, software stability, etc. Each of these could be a proximate objective on its own.
In the past, I have described two stories that were decomposed into such proximate objectives:
- Quality Assurance and Software Delivery Processes in Frontend Engineering
- The Evolution of Apps Quality Assurance at Azimo
Weak Link in a Chain / Technical Debt
Classifying technical debt is a true weak-link-in-chain game. There is always something to work on — system decomposition, library updates, refactoring. Your primary job here is identifying the pieces that slow you down the most. For such classification, you can use Ten types of technical debt.
For more examples from the industry and software engineering practices, as well as antipatterns of Leverage Objectives, Proximate Objectives, or Weak Links in the Chain, I recommend checking my article: Example Strategic Blocks for Engineering Strategy.
Your Sources of Information
You can use countless sources of information when building your strategy: 1:1s, people’s feedback, product strategy context, classified technical debt, and more. For inspiration, I recommend checking these articles from Practical Engineering Management:
Signals of Information for Engineering Leaders — sources of knowledge can be classified into three categories: possessed knowledge (what you already know), external sources (what you can observe outside the company), and internal signals (your company’s data, insights, dashboards). Your job as an engineering leader is to a) build a solid base for capturing internal signals and b) use this data to drive your decisions and long-term strategies.
Mastering the Feedback — feedback is a special source of knowledge. It’s not always empirical facts but often just opinions, beliefs, and individual’ perceptions. Even though this information isn’t always quantitative, it is often as insightful as data from your telemetry and product dashboards. It doesn’t mean there’s nothing to change if you’re not receiving feedback. It means there is no space to share it with you. As an engineering leader, you must be comfortable with both, giving and receiving feedback.
Structured Sources of Information
DevOps Culture
The tech industry, despite being ever-evolving, has decades of accumulated experience and best practices from thousands of successful organizations worldwide. Although most tech organizations consider themselves unique, they often tackle classic and well-known software engineering problems. This implies that many proven practices can work in your organization as well — rather than reinventing the wheel, we can adapt existing industry standards to meet our needs.
To build your long-term plan, you can use the DevOps Culture, a mindset that fosters collaboration and shared responsibility among engineering and other teams to deliver high-quality software quickly and reliably.
Here are a few factors of the DevOps culture worth assessing in your team:
- An environment focused on a high-trust culture and collaborative learning.
- Development practices with automation, CI/CD, and telemetry.
- Team structure & processes focused on independence and long-term goals.
- Predictable deployment & release management.
- Organizational resilience with everyone owning the quality.
- Orientation on outcomes, rather than tasks.
If you want to do a full self-assessment of the DevOps culture so it’s easier to build your engineering strategy, I recommend checking these materials and templates on Practical Engineering Management: DevOps Culture Checklist.
Tech Debt Classification
Some companies, like Google or Thoughtworks, have developed their classification of technical debt. Using their frameworks should help you find the right blocks for your software engineering strategy.
Here are ten types identified by Google:
- Migration is needed or in progress
- Documentation on projects and application programming interfaces (APIs)
- Testing
- Code quality
- Dead and/or abandoned code
- Code degradation
- The team lacks necessary expertise
- Dependencies
- Poorly executed or abandoned migrations
- Release process
Subscribers of Practical Engineering Management have access to a detailed classification and tools for investigating tech debt. You can get them from here: Ten Types of Technical Debt.
End Words
Building a good engineering strategy for your team and technology is one of the most challenging and time-consuming efforts. Yet, having such a plan allows you to become a truly impactful leader who can make a significant difference.
In my career as an Engineering Director, Head of Engineering, and Engineering Manager/Tech Leader, I developed multiple strategies. The most successful ones took full advantage of the lessons learned from the book “Good Strategy/Bad Strategy” by Richard Rumelt, which I highly recommend as the most comprehensive guide for building strategies of any kind.
I hope the materials shared here inspire you to build your long-term plan and become a leader who compounds their impact.
You can also explore more content for engineering managers on practicalengineering.management. You will find there practical strategies for effective engineering leadership.
Join the community of impactful leaders to bridge the gap between inspiration and implementation with actionable steps that empower your team, boost trust, and drive real-world results.
If you would like to discuss any of your challenges, don’t hesitate to reach out to me at mirek@practicalengineering.management.