Surplus rules of engineering strategy.
This is pruned from Engineering strategy.
While sharing my advice for writing an engineering strategy, my second draft had an extended section of “rules for writing engineering strategies.” I think these were all useful, but it was a piece that suffered for too many ideas, and I ended up removing most of them.
I think they’re useful, so I’ve included them here. For context, the rules that I kept in the original piece are:
- Start where you are (start small; start local)
- Write the specifics (stop when you want to generalize)
- Show your work (don’t make unsupported statements)
A few more to add to that list.
Every missing document is missing for a good reason
If you’re wondering why an engineering strategy doesn’t exist, it’s helpful to remember a variant on Lara Hogan’s Why Can’t They Just…?: every missing document is missing for a good reason.
It sure would be helpful if you had a clearly articulated business strategy before you started writing your engineering strategy, but every missing document is missing for a good reason. It sure would be easier to write your product engineering strategy if there was an engineering strategy or an infrastructure strategy written already, but–again for the folks in the back–every missing document is missing for a good reason.
Which brings us to the second surplus rule…
Don’t block on what you don’t know
An engineering strategy tries to address a broad, ambiguous problem space. There are more things you don’t know than you do know when you try to write this sort of document, and if you allow yourself to be intimidated by this ambiguity then you will simply never start.
As ambiguity mounts, invest less energy into the details and more into the direction. Focus less on perfection and more on using your provisional strategy document as a tool to drive clarity in the other missing documents. The more you’re able to brave the gaping maw of uncertainty, you’ll build the foundation for others to write their pieces as well.
That’s why you have to…
Fill the empty page
It’s easy to get caught up on trying to write something good or even great in your first attempt to write a strategy, but it’s far more important to write anything at all than to wait until you can write something good.
Once you’ve started writing something, other folks are able to join in and help improve your ideas. They may even hate what you’ve written so much that you unlock their ability to write a strategy of their own in protest of yours. When you’re getting started, momentum towards quality is far more important than initial quality.
Just start writing, but remember to…
Stick to what you know.
The negative framing of this rule is, “Don’t lie.” It’s tempting when you write an engineering strategy to talk about what you wish was true rather than what is true. You may hate your monolithic codebase and wish that your company was writing services for all new development, but if your company isn’t implementing new functionality in separate services, then you’ve not written a strategy at all, merely a trap for trusting peers.
There are undoubtedly more rules to writing engineering strategy, but hopefully these will be useful as you start your process.