The Engineering Executive's Primer: June 26: Chapter 3

To check:

Appendix E - Stripe, balancing tech standardisation and exploration

Strategy document

Constitutional document for running Engineering

Should define:

According to Richard Rumel, strategy is composed of three parts:

Diagnosis: nature of the challenge: For example: high WIP is preventing us from finishing projects, so we are increasingly behind each sprint.
Guiding principles: policies that address the implicit and explicit trade-offs. For example: only hire fro the most urgent team with the most urgent need. Do not spread hires across all teams.
Coherent actions: directed by a policy to address the challenge.

Most written strategies are a vision of how things could ideally work, rather than how they work today.

Be a historian and document what is
Write five design documents and pull the similarities out
Commit to writing it yourself
Focus on writing for the Engineering teams’ leadership (senior managers and senior engineers)
Identify the full set of stakeholders you want to align the strategy with
Identify 3-5 stakeholders who will provide early feedback
When writing the diagnosis section: start with the current roadmap, competitive pressures, and financial plan. Incorporate data from surveys, and one:ones.
When writing your guiding principles, same as above plus incorporate feedback from working group and private feedback from external Engineering executives.
Share with the full set of stakeholders
Write down coherent actions: iterate with the working group
Lastly, partner with your working group to identify individuals who might disagree with the strategy → then go and spend time with them. Goal is to make sure they feel heard and that you understand their feedback. If it is useful, incorporate their feedback in the strategy, but be careful not to compromise in order to make the strategy popular.
Then share with the Engineering org: schedule a meeting to share the strategy and rationale behind it. Answer questions and establish one week to taking feedback.
Finalise the strategy, send out announcement, and commit to 2-month review

You should push to have a strategy written within the first six months of starting a new role.

We need to understand the other strategies before starting to write the Engineering one
Focus on Business and Product strategies

Questions to explore:

What are the cash-flow targets?
What is the investment thesis across functions (e.g., sales and marketing, research and development, general and administrative)?
What is the intended role of mergers and acquisitions?
What is the business unit structure? How do the business units support one another? How are costs expensed across business units?
Who are your products’ users, what do they need, and how are you prioritising in relation to those users?
How will other functions evaluate success over the next year?
What are your current distribution mechanisms, and how are you trying to change them?
What are the most important competitive threats?
What about the current strategy is not working?

Each should:

Be applicable: it can be used to navigate complex, real scenarios, particularly when making trade-offs
Be enforced: team will be held accountable for following the guiding policy
Create leverage: create compounding or multiplicative impact

Three major categories:

Enforcement: how will Engineering’s rules be maintained?
Escalations: how should folks constructively argue that a guiding policy doesn’t work or doesn’t apply to their case?
Transitions: How do we transition between current state and the new state? (examples re-org, or a migration…)