Writing an Engineering Strategy
In a previous post, I reflected on the one year that I spent at my current employer -
During my early days at Volvo Cars, I took it upon myself to come up with an engineering strategy for the product area that I am currently the engineering lead of. I had to iterate over it a few times to get it to a stage where it has been sufficiently useful up until now (& hopefully for the next couple of years - we’ll have to wait and watch). I’ve come to realise that a strategy document can be a very useful tool to radiate your intent to the rest of the org, get feedback and alignment before setting out to execute. In this post, I share learnings from my experience writing an engineering strategy.
A plan is not a strategy
I couldn’t possibly explain this better than Prof. Roger Martin. Checkout this video. I can guarantee that it’s ten minutes very well spent -
Here’s an interpretation of the video, in my words -
When the landscape in which a business operates in starts to change, a business will make bets on how the landscape will change and where it will want to position itself in this new landscape. A strategy is where you want to be. To stupefy, if you are at coordinates (x, y) in a two dimensional plane and you have the possibility to be at (x1, y1) (x2, y2) or (x3, y3), then your strategy should tell you which of these coordinates the business would like to be at.
A business strategy is driven by market conditions. If you are writing a strategy, chances are you are executing a change that will allow your company to get to where it wants to be.
Engineering != Tech
Different strokes for different folks but I lean towards making a distinction between engineering and tech -
Engineering = fn(Tech, People, Org, Product)
I simplify, maybe more non-deterministic variables can be added to the equation. I make the distinction because when executing a change, you will likely be making changes to the talent in your team (up-skill or recruit new talent or a combination of both), make changes to the team-x-service ownership or even make changes to the org structure. It is also likely that when you propose an engineering strategy, you may end up not proposing changes to the tech stack at all. This is why I feel it is important to make a distinction between engineering & tech.
Engineering Strategy should be Product Driven
Depending on the scale and type of your org structure, your product function either IS the business or works very closely WITH the business. Either ways, your product function should have a strategy in place that can do a good job of explaining where the product is now and where it wants to be a few years from now (or whatever timeframe you are looking at). It is not uncommon for the engineering lead to contribute to a product strategy while simultaneously developing an engineering strategy. A good product strategy should be informed by the engineering strategy. A good engineering strategy should be influenced by the product strategy.
If you are drawing up an engineering strategy to execute on a major change - without that change being driven by the needs of the product, you are setting yourself and your engineering team up for failure.
Engineering Strategy should be heavy on diagnosis
Richard Rumelt’s book - Good Strategy Bad Strategy states that a good strategy consists of diagnosis, guiding policy & coherent action. You are welcome to read the book or find a well written summary here. In this section, I emphasise on diagnosis. In my opinion, it is supremely important to have a strong grounding in what the current engineering setup (people, systems, org structure, architecture, etc) looks like and be able to make an assessment if the current engineering setup will be sufficient to execute on the product strategy or not.
When it comes to communicating your diagnosis, it is easy to get carried away sharing innate details. But I have found that keeping the diagnosis succinct yet insightful and supplementing it with additional material as an appendix makes it easily digestible to a wider audience.
Taking inspiration from force-field analysis and extending it, I have found that structuring my diagnosis in the following way helps deliver the message effectively -
Where We Are - What is the current engineering setup at the moment.
Where We Want To Be - What would we like the engineering setup to look like in the future.
Restraining Forces - A restraining force is a force that needs to be overcome for a team to reach a desired outcomes. This section would list out all the forces stopping us from getting to ‘where-we-want-to-be’. Readers should look at this section and very quickly understand why the current engineering setup will not work.
Driving Forces - A driving force is a force that drives us towards desired outcomes. This section would list out all the forces us that are driving us to ‘where-we-want-to-be’. Readers should look at this section and very quickly understand why the proposed changes to the current engineering setup will drive us towards desired outcomes.
Environment - The environment in which we are operating.
Constraints - The hard constraints that should not be violated while executing the change dictated by the strategy.
Architectural Changes
I’ve come to realise that the thing most readers of the strategy would be interested in is -
How does this change impact the architecture
How much effort would it require to execute the architectural change
I have found using C4 diagrams to visualise the current architecture and the “target” architecture helps convey what you plan on doing effectively. The system context diagram helps convey the message to non-technical stakeholders too. For a more technical audience outside your own team, drawing up a container level diagram should suffice. There is no reason to offer to go into more level of detail when discussing strategy.
I have also found that documenting each major change between the now & the target architecture as an ADR using the template suggested by Michael Nygard’s here came in very handy when some of the more technical audience wanted to dive into more details. Note that the ADRs were supplementary material provided in the appendix. They were not core to the strategy document.
Strategy should be a live document
When you first come up with a strategy, you make decisions based on the state of the environment you were in. If you operate in an environment that is anything like the one I operate in, things keep changing, existing ambiguities no longer exist, new ambiguities may come to light, some assumptions you made might have been right, some may have been proved to be wrong. I firmly believe a good strategy keeps evolving as you keep executing. My experience so far with the strategy that I’ve come up with is that it needs to be updated to account for some new things that have come to light. It is better to have your strategy doc reflect the reality of your execution instead of your execution being guided by a strategy that it out of touch.
What has your experience been coming up with an engineering strategy? I would love to hear from you about your experiences - what worked well, what were some challenges or anything in about this topic in general. Thank you for reading this far. 🙏🏽
Again a very good article from Swaroop! The function defining Engineering is a good framework like ISACA COBIT. The explanation of difference btw strategy and plan is very clear. I like the author's suggestion that strategy should be a living document rather than a cast in stone. Very informative
Good article Swaroop. We can also discuss more on how distributed /dispersed teams impact the overall engineering management strategy . Thank you