Writing an engineering strategy

> Strategy needs to be tuneable*

Yes yes yes!

Any example(s) you can point to?

This point dovetails nicely with the idea of a "Commander's Intent." In this case, a strategy document is the intent being spelled out. If it's written well, a rank-and-file engineer can read it and understand why certain allocations are made, why certain priorities are pursued, etc without having to ask too many questions or feel like a cog in a machine.

No, but you misunderstood the audience for an engineering strategy, namely other c-level execs.

User 'jschveibinz' describes it well.

The Amazon link for the curious. To my surprise it was an O’Reilly book: https://www.amazon.com/Technology-Strategy-Patterns-Architec...

The only reason I can see you tying product engineers to infra engineers in that way is if the infra engineers are supporting them with DevOps activities. For example building CI/CD pipelines, assisting with deployments etc.

Otherwise it really doesn't make much sense at all.

A fixed ratio makes sense in the context of how a particular company operates at a particular time. Given the example strategy you're quoting is about one company (real or hypothetical), and it doesn't say that the infrastructure teams are going to gain or lose a bunch of responsibilities from what they currently have, it seems pretty clear. When you add in "Particularly we will avoid hiring that grows our current headcount." the result is that they're aiming to keep about the same number of total engineers, and therefore about the same number of infrastructure engineers.

You could read that ratio as a limit on infrastructure overhead that one should have. Unless you’re in the IaaS business, I guess.

I found this guidance odd as well. This implies that, in an organization with 500 engineers, 100 (!) of them would be working on infra.

What would those 100 engineers even do? For the longest time, we had ~10 sysadmin and devops staff supporting 300 engineers. Nowadays, everything is run by AWS anyway--there's hardly any real infra to manage.

I'll note, for the purpose of discussion, that this is put forth as part of an example engineering strategy document. The author does not recommend _the reader_ do this, at least not here.

With that said, yeah, I think "a static ratio" vs "a flat count based on desired features" vs something else is an interesting discussion! My experience is that more product means more usage of the breadth of infrastructure, and requires both more infra development and more support, but I haven't worked in large orgs, so I don't know how this nets out as size grows.

This makes perfect sense in my organisation, where everything is a bit more manual and custom than elsewhere.

If we didn’t increase the number of infra engineers with product engineers, we’d very soon be unable to deploy anything.

That’s less than desirable of course, but as long as it’s like that it may be good to have a fixed ratio.

According to the ratio we will need 12.25 infra engineers.

The tail shouldn't wag the dog.

But if you don't let the tail wag the dog you'll find you have a very disaffected tail.

Turns out putting those three circles at the same table solves this.

Much easier said than done.

What you described is as close as possible to product strategy and not engineering strategy.

Will Larson wrote two books about Engineering Management and Staff+ Engineers, based in part from articles from his blog. Now I suspect he's preparing something for Engineering Executives (CTOs and such).

The article is to guide Executives on how to write a company-wide Engineering Strategy document for medium and large organizations.

Engineering teams, leads, and directors that are clueless as to what they are building and why. For engineering leaders to practice actual “leadership”.

+1 I'd like to add that old military documentation especially SOPs are great references in how to write and implement well written and readable documentation.

That’s much lower level than this. It would describe how things like the ‘Escalation process’ mentioned in the article work.

Well, in my view the leader you described is a manager and not a (servant) leader that is supporting his team.

I think another, underrated benefit is having something to point at for new people.

When an engineer joins the team 6 months into the project, it's important for them to have context on why you're doing what you're doing.

Even if you have to qualify it with a bunch of "oh yeah, we're not doing X and Y, and we're doing a different version of Z," it's really nice to get an overview.

My favourite piece of writing about engineering management, bizarrely, is this: The Eleven Laws of Showrunning http://okbjgm.weebly.com/uploads/3/1/5/0/31506003/11_laws_of...

It's about running a TV show - which has to be one of the most challenging management exercises out there: you have a limited budget, a hard deadline, activist investors ("the network"), you need to recruit 100+ different people in a very short amount of time... and you're also expected to write the first and last episode of the series too!

The reason this document is relevant here is that the it talks about the importance of having a clear vision. If you can express a clear vision for the show, you can then distribute that vision amongst your lieutenants - who are then empowered to go and make good decisions without you having to micromanage every step.

To my mind, this is the value of strategy and vision documents: they're about helping people in your organization make good decisions independently of top-level leadership.

I dunno, I’d be happy to get some idea of the priorities of the people on top.

If I disagree with my management chain and know the CTO ultimately wants a specific thing to happen, then I can happily escalate until it reaches his desk.

Ideally they don’t need to be read, because they are lived and become the culture. But the document can help clarity of thought and bring in new hires.

Even in this article it feels like the author admits that this document needs to be written just because _somebody_ wants it

> Once you become an engineering executive, an invisible timer starts ticking in the background. Tick tick tick. At some point that timer will go off, at which point someone will rush up to you demanding an engineering strategy. It won’t be clear what they mean, but they will want it, really, really badly.

Taxonomy is tricky but I agree that this is a level in between strategic and tactical. In the military this level is called operational.

In my opinion values and philosophy would fit with a vision document.

That said, the actions section does feel too tactical to me. Strategy would be more about the goals and targets.

The author bases his Strategy on the book Good Strategy, Bad Strategy and in that respect he hits the correct abstraction level imo.

I can really recommend the book. It basically boils down to how to take Strategy documents from the classic high-flying, bla bla visions, values etc that employees (incl midlevel mgmt) read and forget about again because its too far removed from their actual work, and instead write a Strategy that is both based on what actual problems/threats are, and that communicates in a concrete but not too specific way how to execute the Strategy.

Writing Strategy documents that are actionable are important, I think, to try and deal with the old but very true “culture eats Strategy for breakfeast”

Strategy and tactics are layered.