Strategic decision-making for engineering managers

Photo by Kelly Sikkema on Unsplash

Beyond technical know-how, a key differentiator for you as a manager is your ability to develop, implement and lead strategic decisions that transform ideas into real software products

Having technical expertise or good ideas is not enough to be a really effective manager. Those are important, but the most difficult skill is the ability to make strategic technical decisions, especially if you want to move from an execution enabler to a decision-maker at the big table. While before you were mostly brought in to answer how things should be built, now you’ll be invited to share your view on what should be built and why.

Making strategic decisions requires you to gain a comprehensive view of how technology can drive revenue for the business, an awareness of emerging technology trends, and the ability to differentiate between passing fads and potentially lucrative ideas. Above all, you need to show a keen interest in customer satisfaction and competitor actions to ensure your strategy’s success.

In this article, I’ll discuss the fundamentals of strategic decision-making, including balancing the portfolio of engineering work and gaining cross-functional support to put contentious work on the roadmap.

Outline

1. Understand the impact of your work
2. Classify engineering work clearly
3. Define principles for making trade-offs
4. Make trade-offs
5. Storytime: the fallacy of speed

1. Understand the impact of your work

Effective engineering work doesn’t happen in isolation. It needs to be aligned with the company’s strategy. This requires a clear process for validating work before, during, and after its execution. This process will challenge hidden assumptions and clarify the impact of your and your teams’ work.

Going through this process will also boost everyone’s belief that they’re doing meaningful work, which is a crucial component for work satisfaction and high performance.

To demonstrate your ability to establish alignment between engineering and other functions, you should be asking the right questions about the value delivered to customers and the business, along with the trade-offs, risks and costs.

Below I am listing a bank of questions that you can use to engage with your product counterpart. You can also use these to coach your engineering team on how to develop a stronger product and business mindset.

Ideal Customer Persona/Profile (ICP)

1. Who are the power users of our current product?
2. Who are the power users of our competitors’ products?
3. Who are non-users with similar demographic and psychographic profiles to our power users?
4. Are our users also customers with the final decision-making power?

Valuable problem to solve

1. What hinders our users’ jobs to-be-done?
2. How severe is their problem?
3. How does the customer think about the problem?
4. Why is now the right time to build this?

Problem-solution fit

1. What is the ideal solution?
2. How does this solution create customer delight?
3. Have we tried to build similar solutions in the past?
4. Have our competitors tried to build similar solutions?
5. How does this solution protect or enhance our competitive advantage?
6. (For a new feature) How will this strengthen our existing product and business impact?

Business value

1. What is the expected revenue impact of this product/feature?
2. How are we getting this revenue from new and existing users? (acquisition and retention)
3. What are the monetisation opportunities?
4. How does this compare to where the business is today, are these conservative or outsized numbers?
5. What is the realistic horizon time to achieve this?
6. How do we increase growth without damaging existing business operations and negatively impacting revenue?

Validation process

1. What data and unique insights do we have to justify the customer and business value?
2. How do we define a hypothesis and document your validation?
3. What are the expected interim outputs?
4. What touchpoints should we set in case we need to course-correct?
5. Who are the final decision-makers on this validation?

Caveat: validating work like this faces the Goldilocks dilemma. If you do too much of it, you may experience decision paralysis. On the other hand, if you don’t validate enough, you may not fully comprehend the impact of your and your team’s efforts. You’ll also not know why things failed and how to improve them.

During my previous roles, I created a streamlined validation and alignment template for engineering using product insights from The Experiment Map, Lean Canvas and Value Proposition Design. This template was accepted by my cross-functional teams and used prior to new product/feature work. I’ve included it at the end for paid subscribers.

2. Using unambiguous language for engineering work

I used to categorise engineering tasks into two groups: feature work and maintenance work, also referred to as “tech debt”. I also witnessed the struggles caused by this language. It inevitably leads to an unbalanced portfolio of work which neither satisfies business objectives nor keeps engineering engaged.

To ensure that essential engineering work is included in the roadmap, you must clearly convey how these tasks align with the company’s overall objectives.

I saw much better reception once I started classifying engineering work into three distinct and unambiguous types.

1. Product work

This work focuses on adding features, increasing user growth and expanding to new markets.

2. Scaling work

This type of work ensures the same or better quality of experience as the product expands.

Unfortunately, too many companies wait until things begin to fall apart before addressing scaling issues, which can have negative consequences for both employees and customers.

3. Risk work

This sort of work addresses operational, security or regulatory risks in the product.

Surprisingly, very few engineering managers think about an underrated but expensive operational risk: poor team well-being. It causes attrition and low productivity, which can severely impact business operations. This risk often arises when leadership lacks allocentric management and charisma. Warning signs include a lack of diversity in upper leadership, punishment of divergent ideas, lack of empathy for other functions and levels, and an inability to inspire the team.

3. Setting principles for making trade-offs

The final requirement for strategic decision-making is a set of principles for making and communicating trade-offs. I follow three guiding principles:

1. Document decision-making

Good decisions can lead to unexpected bad outcomes, while bad decisions can have surprisingly good results because of other factors. Written decision-making provides transparency, traceability, and dynamic execution.

2. Commitment over consensus

This avoids decision paralysis and finger-pointing via transparent accountability.

3. Flexibility over consistency

“Speed and growth win”, they say. While moving fast and breaking things might work in the beginning, winning companies outcompete struggling competitors by recalibrating this reactive strategy. In other words, leaders need to mature with their companies.

4. Making trade-offs

I often apply these principles to the two most common trade-offs in engineering: buy vs build and negotiating time, scope and team. To better analyse each type of trade-off, it’s helpful to break it down into specific factors.

1. Deciding whether to build or buy

When deciding between developing in-house versus using a third-party vendor, hiring an engineering team versus short-term contractors, I consider four factors:

1. Strategic alignment

I assess how the decision fits within the company’s strategic goals and how the new functionality will contribute to revenue generation or create a sustainable competitive advantage. I often use the questions provided in part one.

2. Available capabilities

I evaluate what technology, team or knowledge the company can leverage to create and maintain the new functionality.

3. Cost

I consider whether it’s more expensive to build in-house or outsource.

As a CTO and startup advisor, I observed that business leaders often underestimate the future costs associated with maintaining and updating a codebase over time. They may also fail to account for the complexities of regulations, integrations, or handling large volumes of data, which can impact financial projections.

4. Vendor risk

I assess whether the reliability and compliance of a third-party integration are controllable factors.

In my own startup journey, I used this factor to partner with other financial vendors rather than building in-house payment processing and KYC capabilities.

2. Negotiating scope, time, and team

The most common causes of mismatch between what the engineering team delivers and what the business expects are setting ambiguous outcomes and treating engineering estimates as hard deadlines. These often lead to finger-pointing and blame-shifting.

The best way to avoid this mismatch is to convey the estimated work complexity early and frequently through execution. You should be empowered to provide three types of recommendations:

1. A conditional Yes with additional work or buy-in from key stakeholders
2. Disagreement with a commitment to move forward nonetheless or
3. Strong opposition and seeking external mediation.

Negotiating scope

I’ve successfully used the questions in part one to encourage reflection and negotiation, such as prioritising customer profiles, reducing feature complexity, and exploring alternative solutions.

Negotiating time

These are the trade-offs associated with moving launch dates, shifting some work post-launch or reducing testing and validation time. It’s important to remember that different stakeholders tend to rank risks differently.

For example, during my time as an engineer, I hesitated when asked to reduce test time, because of my work ethic and my company’s performance objectives demanding it.

As a result, I empathise with my teams and create a safe space to voice their concerns and ask questions. When faced with a business opportunity that requires a faster approach, we may consider less rigorous testing or a stealth release, but only if it aligns with the company’s goals and gets commitment from other functions like marketing and customer support. We should empathise with these colleagues who may face the consequences of these decisions and offer them time and support to adapt their own communication and strategy accordingly.

Negotiating team

Team capacity negotiation is often the last resort, and it’s a seductive misconception that adding people to a project will result in faster delivery.

Adding new members to a team requires onboarding time, and productivity may decrease initially. There are certain situations where I wouldn’t recommend this option at all. For instance, when the project delivery is already late, when the codebase is monolithic, and there is no efficient tooling to help engineers manage code ownership, or when the project is in an exploratory phase, and a smaller task force with more autonomy is preferred.

The “speed wins” fallacy

It’s true that speed matters because timing is a bigger constraint than money for startups. This mantra leads to hyper-growth as the default, preferred, reactive strategy. Once companies reach a certain size, this strategy becomes unsustainable.

Struggling companies use short development cycles for quick wins. However, they soon hit a ceiling in growth and start experiencing diminishing returns. They compensate for their bad planning and delivery process with outstanding employees who always find a way to deliver. This model doesn’t scale, as people start to burn out. Attrition is costly because this type of worker is in smaller numbers.

Here’s where effective, high-performing companies differentiate themselves from struggling ones. They understand that they need to combine growth with “aggregation of marginal wins” or fast, small iterations. Their technical strategy includes an effective system of execution optimised for speed from the get-go. They accept that this requires an up-front investment in infrastructure, tooling, and automation, with visible outcomes only after the work is complete. They continually monitor the health of their execution system and optimise its processes. They constantly eliminate unwanted behaviours.

During my time as an engineering manager in a hyper-growth scale-up, I had to deal with these unwanted behaviours as well as with the difficulty of including scaling work in the roadmap. It required me to resort to data to identify the right business use cases, determine the most strategic outcomes, and calibrate the right thresholds to maintain these outcomes over time.

Upon joining the company, I discovered a concerning situation: its hyper-growth strategy heavily favoured feature work over scale work at the expense of customer satisfaction. Sprints were expanded to “include everything” leading to eroded trust and delayed delivery. Planned work was constantly disrupted to ensure that “crucial work is prioritised”. Too many non-coding tasks were added on engineers’ time, like answering cross-functional questions and unnecessary, poorly-planned meetings. Product discovery and the accompanied technical due diligence on around a hundred simultaneous initiatives led to too much work in progress. This disruption of flow was a clear sign of dysfunctional prioritisation.

This mismanagement led to multiple engineering teams drowning in reactive, unplanned work without any guidance from the top engineering leadership. Productivity had hit an all-time low, with engagement and work satisfaction taking a major hit.

Without too much time or adequate tools, I had to use a quick trick to tag and label work requests that were coming randomly from multiple communication channels. This allowed me to compute the hidden cost of this mismanagement.

Using my quick spreadsheet data, I collaborated with leaders across product, engineering and customer support to identify two critical objectives: maintaining Service Level Agreements to retain high-value customers and improving product stability and performance to increase customer satisfaction.

I quickly discovered that collaboration, personal charm and goodwill to negotiate and prioritise scale work began to give diminishing results. I then started advocating for the implementation of internal Service Level Objectives (SLOs) and Error Budgets to effectively monitor performance objectives for availability, latency and data processing throughput and correctness. Our team was able to create a DataDog dashboard that provided insightful and visible data. This data enabled our company leaders to accurately connect customer satisfaction and retention with the appropriate thresholds at an efficient cost and to eliminate guesswork when setting future objectives. Additionally, this made room for scale work alongside major product development on the roadmap. Once the workload became more balanced, everyone felt a significant improvement in engineering performance and work satisfaction.

In conclusion, to stand out as an effective engineering manager you need to sharpen your strategic decision-making. You can do so by implementing a transparent work validation process to reveal assumptions and misconceptions. You can use my guide as a starting point. You should aim to speak clearly about how current and future engineering work relates to impactful business objectives and outcomes. You should aim to maintain a balanced portfolio of engineering work to help the business maintain its strategic advantages at scale and speed. You should decide what principles to use for making trade-offs. You should make and communicate trade-offs and document them in writing to get commitment from other parts of the company.

Below, you can see the Notion work validation and alignment template I mentioned at the beginning article. It has examples of what type of content should go into each section. If you use another tool for project management, for example, Confluence, you can reuse the structure there. If you find it useful or if you have suggestions for improving it, please feel free to drop a comment.