Recently, I shared the Engineering Strategy Framework, a tool developed based on Richard Rumelt's insights, designed to assist engineering leaders in crafting strategies for a +1 year horizon.
The framework outlines the components of an effective strategy:
The Diagnosis involves understanding the current situation and pinpointing the organization's critical challenges.
The Guiding Policy outlines the general approach to tackle these challenges.
The Coherent Action involves a series of coordinated actions intended to implement the guiding policy.
The framework also outlines several steps to construct it:
Collecting Input: Gather data about strengths, challenges, opportunities, and other aspects related to your team, the tech stack you manage, or problems presented by the organization.
Here, I recommend using Signals of Information For Engineering Leaders.Strategic Blocks Grouping: Categorize all the input using components from Rumelt's book, such as leverage, proximate objectives, or the weakest link in the chain.
Build Strategy Kernel: Based on the collected and categorized information, formulate the Strategy Kernel—Diagnosis, Guiding Policy, and Coherent Actions.
Iterate and Refine: The process of collecting inputs, grouping them, and defining the strategy kernel undergoes multiple iterations. As the strategy is implemented, new information is gathered, some problems are resolved, and new ones arise, prompting future iterations of the strategy.
In today's article, I want to explore a few Strategic Blocks from Rumelt's book "Good Strategy/Bad Strategy" and how to use them to build a long-term plan as a software engineering leader.
Here’s the complete list I recommend adopting from the book:
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 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.
Today, we’ll delve deeper into Leverage Objectives, Proximate Objectives, the Weakest Link in the Chain.
Leverage Objective
The Leverage Objective involves identifying and focusing on elements that will have a disproportionate impact on the overall strategy. It’s about finding pivotal points where the right amount of effort and resources can lead to significant gains.
Leverage typically arises from your observations—identifying what is most critical and pivotal in a situation and then directing all possible efforts to make it happen.
Examples from the Industry
AWS: Amazon realized that its expertise and infrastructure in handling large-scale e-commerce operations could be leveraged to offer cloud services to other businesses. This insight led AWS to become a leader in cloud computing, transforming how companies deploy and manage software. Such leverage not only created a significant revenue stream for Amazon but also strengthened its position in the industry by leveraging its existing capabilities in large-scale computing and network management.
Open Source: Companies like Red Hat and MongoDB embraced open source as a key part of their strategy, recognizing that support for and contributions to open source could lead to greater adoption and community engagement. These companies benefited from community-driven innovation, collective intelligence, faster adoption rates, and a strong, loyal user base.
Examples from Software Engineering
Here are a few examples from engineering teams—more local, yet often pivotal changes to the team or the entire tech organization:
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."
's DevEx framework.
Flow state is a critical factor in Developer Experience. Read more about it onInvest in Automation: Investing in CI/CD, testing automation, building automatic scripts, and more. Identify tasks that take hours per week for your engineers—e.g., manual testing or deployment—and develop solutions that can complete these tasks within minutes or seconds.
Invest in Tools/Teams: This is one of my personal examples. When Macbook M1 chips were released, their performance reduced building times by tens of percent in one of my teams. Following the hype is not always a good idea, but in this particular case, we could realistically save hours of work for software engineers per month, and the investment would return in the first few months while significantly improving the work environment. In another project, a similar improvement was achieved by migrating our testing solutions to the cloud.
What is Not a Leverage Objective
Archimedes said, "Give me a lever and a place to stand, and I will move the earth." However, even with a lever billions of kilometers long, Archimedes could only move the earth by the length of one atom.
When considering leverage, you must remember not just the outcome but also the effort required to achieve it. Simply rewriting a complex monolithic system into microservices without a good plan and valuable middle steps is not leverage; it's just a significant amount of work.
Adding cutting-edge features (e.g., blockchain, AI) without understanding user needs can lead to resource drain, increased complexity, and no clear value for customers. Before heading in this direction, you should first weigh both internal capabilities and potential outcomes.
To be successful here, ensure you have sufficient sources of information, as described on:
Proximate Objectives
The concept of Proximate Objectives involves setting goals that are achievable with current resources and capabilities. It is about defining clear, short-term goals that move the team or tech stack towards its larger ambitions.
The role of a leader here is to translate complex problems into simpler ones that are solvable by the organization. A leader also takes responsibility and potential blame when solving ambiguous problems.
It's easy to say, "Here are 45 requirements we need to specify before the team even starts working on the project." It's harder to take responsibility for a few acceptance criteria and deal with the rest of the ambiguity on our own.
Example from the Industry
SpaceX & Travel to Mars: Before aiming for Mars colonization, Elon Musk set a proximate objective of developing a low-cost, reusable rocket. The successful development and launch of Falcon 1, Falcon 9, and Falcon Heavy were crucial to achieving the longer-term goal of reducing space travel costs and enabling Mars colonization. None of these steps were immediately achievable, yet they were feasible enough to set them as proximate objectives, leading to bigger goals.
Examples from Software Engineering
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 them could be a proximate objective on its own.
In the past, I have described two stories that were decomposed into such proximate objectives:Strangler Pattern: Instead of rewriting monolithic, "big balls of mud" all at once, there is a concept called the Strangler Pattern, where the team ports existing functionalities into a loosely coupled system only when necessary.
Proximate Objective Anti-Pattern
Proximate objectives should be immediately achievable goals that are steps toward a larger strategic plan. Spreading the workforce too thin across multiple features, rather than focusing on a single core thing, is not a proximate objective; it's "short-termism." This can lead to several negative consequences, such as feature bloat or technical debt accumulation.
To avoid this, leaders should ensure that even short-term goals are steps towards a coherent long-term plan. You can achieve this by regularly revisiting and aligning strategic objectives and ensuring that each short-term win builds towards a larger, more sustainable competitive advantage.
Introducing at least basic goal trackers can assist you in this endeavor. You can find more inspiration here: Practical solutions to track your goals
Weak Link in Chain
In any system, performance is limited by the weakest link. It means that strengthening the other links does not strengthen the chain.
As a leader, you should focus on identifying the weakest links so that your efforts are not merely local optimizations but true improvements to the entire system. Your work is also about connecting the dots—identifying what the chain is so its links aren't managed separately.
Example from the Industry
Apple Chips: Apple’s recent focus on chip development for its devices recognized that its devices' performance and energy efficiency were becoming limiting factors. The company decided to develop its own chips to continue improving the capabilities and battery life of their products.
Example from Software Engineering
Improving Collaboration Between Teams: You may have the strongest team in the organization with the best engineers in it. But sooner or later, they will need to cooperate with other teams. If for some reason this skills imbalance is intentional (e.g., focus on the hardest problems), you must ensure that other teams can at least learn from the high-performing one. One practice is building engineering guilds, where people working in different feature teams exchange experiences and ideas on a wider forum and thus build cross-team alignment and collective intelligence.
Technical Debt: Classifying technical debt is a true weak-link-in-chain game. There is always something to work on—system decomposition, library update, 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.
Weak Link in the Chain Anti-Pattern
The idea of the weak link in the chain is to identify and address the most vulnerable or least efficient parts of a process or system. However, too much focus directed at a weak link results in overcompensation, neglecting other areas that may also require attention or improvement.
While addressing weak links, it is crucial to continuously evaluate all parts of the system or process to avoid creating new weak links. This can be facilitated by regular reviews, cross-departmental feedback, and adopting a holistic view of organizational processes.
End Words
In this article, I explored only a few strategic blocks—Proximate Objectives, Leverage Objectives, and Weak Links in the Chain. But even with these, you can see that building a strategy is a complex initiative.
You can identify and invest in a weak link in the chain, which can become a leverage objective for your system, processes, or team. However, overinvesting can weaken the rest of the chain. This means you should focus on a few other links, which in turn can dilute your focus.
And what if the weakest link is also super expensive to improve? Then you need to set a bunch of proximate objectives, so you achieve your goal in steps. But this may lead to multi-month, if not multi-year, projects. This means you must constantly evaluate your current state and often revisit the strategy.
This can be a time-consuming and effort-consuming process. But as another article said, Bad leaders execute, good leaders improve, and great leaders compound. To compound, you must have a plan.
When writing this article, I found no better tool for building such a plan than the Strategy Framework built on top of Richard Rumelt's wisdom.