I'm a bit confused, the strategy reads more like tactics to me. I had expected something a bit more high level, with "values" and "philosophy" and so on.
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”
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.
> Maintain 4:1 product engineer to infrastructure engineer ratio. This has been our ratio for the past several years, and it’s worked fairly well, so we intend to maintain it.
Really weird, as someone who works as a Software Engineer in systems. The number of infra programmers you have is not a ratio to be kept with product developers. It's dependent on the versatility, modularity, reliability, and performance of the platform you have internally. More plainly put, if you want only VM orchestration with very minimal features, that's a different head count that support virtual machines, FAAS, and container orchestration.
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.
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.
Whoever setup how you deploy to AWS, monitor, collect logs, etc is doing your infrastructure engineering. Many places don’t realize that the infrastructure engineering is just being left to random software engineers in a “whoever touched it last owns in” type setup.
You’re likely wasting resources or doing other dumb things (bad AWS role management) if you don’t have someone who owns that stuff.
Infra at large companies becomes platform engineering. Things like dev tools, internal tooling and deployments is the domain of infra. Using AWS is also not a get out of jail free card, you still need people who understand how to operate the services.
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.
I was commenting from the perspective of a large org, thinking of one big enough that would need a strategy. You don't differentiate product and infra spaces, because infra is part of the product. It's at least well known in SRE spaces that SREs don't scale linearly with product. You generally build teams around specific needs and productize things that enable that non-linearness.
Now that I come to think about it, I have never seen an engineering strategy document.
I think one of the key principles he’s trying to say here is that having a bad strategy is similar to no strategy. Aligned with Rumelt’s wonderful book.
The big challenge for said good strategy is how certain decisions have been made. Most people just see a resulting backlog and ask questions accordingly. But if you knew the underlying strategy going into these backlog decisions, you’d focus more time on assessing if that strategy matches with the business and product needs.
I think many groups would benefit from hearing about their engineering strategy from their leaders. Which seems non-existent in most places.
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.
I like Will Larson’s most of the articles but this one seems all over the place. Shouldn’t engineering strategy be defined by
1. Customer’s needs first and then
2. Internal stakeholders like developers, marketing, product, analytics etc. needs
3. Company values and principles could be the next guiding principle.
I think if you work backwards engineering strategy should become more clear. That’s the part I found strongly missing in that article.
I feel like these are the type of documents that are written to be written and not to be read. Naturally a "strategy" document is read (and more importantly followed) by everyone. But I've never seen something that happen in a large organization. Team do their own thing disregarding most of what the leader on top decided should happen. The leader is too busy to involve themselves with actual everyday work.
The only actionable item is resource allocations coming out of those strategy documents. The rest is pretty much fluff.
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.
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.
This advice is for a very specific situation: when there is time pressure to get something done, staff to do it, and the end product has to be thought through more upfront than iterated towards.
You’ll recognize this isn’t always the case in tech. Your startup may not know what to build yet and is simply exploring the problem space as quickly as possible; your team may not be staffed up yet; your team may be staffed and very senior, which requires a peer relationship instead of delegation; etc.
The skill of a good leader is to match their approach to the situation.
That is a fantastic doc. It's thoughtful and kind hearted. it puts the focus and responsibility for work right where it needs to be. You could almost say, it's just express the vision and delegate. But the devil is in the details, and there is a deep fear details are what kills you. This actually provides a path to responsibly delegate those details.
Great great write up. Obviously it's about making a tv show, but pretty much all of that is applicable to any leader.
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.
I'm glad to see this. I love Will's An Elegant Puzzle, but it's very clear when reading it that it's missing examples and guidance on how to write these documents he posits are so essential.
He says here that most companies/orgs don't actually write this stuff down, and he himself only did it at his most recent gig. Has anyone seen this done well in their own companies? Are there well-known companies with a culture of this kind of writing, that is generally agreed to be effective?
If someone asked me to write an “engineering” strategy, I would emphasize engineering planning, process and principles. Executive management (I spent years in this role) wants to know more about how, who, what, when and why: how will you manage engineering resources, what kind of engineering resources are required, what and when are engineers tasked from start to finish (established processes and standards), and why is all of this necessary and beneficial for the business and the customer.
Strategy needs to be tunable: with an understanding of all of individual parameters, it is possible to adjust strategy for different requirements. That makes a “boilerplate” engineering management/strategy document more useful. One size never fits all.
Context matters. How well your product is received, if it exist. How large is your team. How much money can your company bleed, for how long. How large your potential market. How many competitors.
It is like microservices. Looks nice on paper. Taken blindly and misery ensues.
One thing I'd add is that old military documentation especially SOPs are great references in how to write and implement well written and readable strategy documentation. There is an emphasis on brevity which is one thing that is both overstated and understated in the process of creating engineering (in relation to software & what I've experienced as swe) documentation. I think I may write something up and publish it here.
On leadership, the following manuals are very organised and written well even the prefaces by themselves are succinct and take into account organisational conditions that could similarly occur for an engineering-focused org.
On technical writing aimed at and for an engineering team, since our subject is engineering strategy. Similar to the manuals above, these are succinct and cover a lot of ground.
On technical writing, this is a medical manual thats detailed and limited in scope for good reason. Look through and you can that it primarily serves as reference with the assumption of limited yet enough competence to do any medical work.
This article gives me shivers (freshly appointed CTOs/VPengs trampling all over the existing team dynamics/stack choices and dosing fires with gasoline). If I learned anything - when you get to a situation when setting something like this think thrice whether you are doing empire building or actually solving a problem. Also it might be that you are the only person in the room seeing a problem or perceiving as a problem. I've also seen these strategies used as a tool to assert authority/present a nonexistent issue as existential threat to the CEOs.
53 comments
[ 2.7 ms ] story [ 109 ms ] threadThat said, the actions section does feel too tactical to me. Strategy would be more about the goals and targets.
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”
The article is to guide Executives on how to write a company-wide Engineering Strategy document for medium and large organizations.
Really weird, as someone who works as a Software Engineer in systems. The number of infra programmers you have is not a ratio to be kept with product developers. It's dependent on the versatility, modularity, reliability, and performance of the platform you have internally. More plainly put, if you want only VM orchestration with very minimal features, that's a different head count that support virtual machines, FAAS, and container orchestration.
Otherwise it really doesn't make much sense at all.
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.
You’re likely wasting resources or doing other dumb things (bad AWS role management) if you don’t have someone who owns that stuff.
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.
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.
I think one of the key principles he’s trying to say here is that having a bad strategy is similar to no strategy. Aligned with Rumelt’s wonderful book.
The big challenge for said good strategy is how certain decisions have been made. Most people just see a resulting backlog and ask questions accordingly. But if you knew the underlying strategy going into these backlog decisions, you’d focus more time on assessing if that strategy matches with the business and product needs.
I think many groups would benefit from hearing about their engineering strategy from their leaders. Which seems non-existent in most places.
I think if you work backwards engineering strategy should become more clear. That’s the part I found strongly missing in that article.
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.
The only actionable item is resource allocations coming out of those strategy documents. The rest is pretty much fluff.
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.
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.
You’ll recognize this isn’t always the case in tech. Your startup may not know what to build yet and is simply exploring the problem space as quickly as possible; your team may not be staffed up yet; your team may be staffed and very senior, which requires a peer relationship instead of delegation; etc.
The skill of a good leader is to match their approach to the situation.
Great great write up. Obviously it's about making a tv show, but pretty much all of that is applicable to any leader.
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.
> 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.
He says here that most companies/orgs don't actually write this stuff down, and he himself only did it at his most recent gig. Has anyone seen this done well in their own companies? Are there well-known companies with a culture of this kind of writing, that is generally agreed to be effective?
Strategy needs to be tunable: with an understanding of all of individual parameters, it is possible to adjust strategy for different requirements. That makes a “boilerplate” engineering management/strategy document more useful. One size never fits all.
Yes yes yes!
It is like microservices. Looks nice on paper. Taken blindly and misery ensues.
https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN30101-PAM_70...
https://safety.army.mil/Portals/0/Documents/ON-DUTY/AVIATION...
https://www.globalsecurity.org/military/library/policy/army/...
https://www.chemeurope.com/en/encyclopedia/Standing_operatin...
https://clik.dva.gov.au/sop-information/guide-using-sops
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3056180/
https://info.publicintelligence.net/ANA-7-10-2.pdf
https://www.cdc.gov/vhf/ebola/pdf/air-ground-patient-handoff...
Take your pick....
On Brevity, a personal favourite and a classic W.S.C piece: https://policymemos.hks.harvard.edu/files/policymemos/files/...
On leadership, the following manuals are very organised and written well even the prefaces by themselves are succinct and take into account organisational conditions that could similarly occur for an engineering-focused org.
The U.S. Army Leadership Field Manual FM22-10 (1951): https://www.bits.de/NRANEU/others/amd-us-archive/FM22-10%285...
The U.S. Army Leadership Field Manual FM22-100 (1999): https://www.armyheritage.org/wp-content/uploads/2020/08/FM-2...
On technical writing aimed at and for an engineering team, since our subject is engineering strategy. Similar to the manuals above, these are succinct and cover a lot of ground.
U.S Department of Army Engineer Troop Organizations and Operations (1965): https://ia802804.us.archive.org/13/items/FM5-11969/FM5-11969...
On technical writing, this is a medical manual thats detailed and limited in scope for good reason. Look through and you can that it primarily serves as reference with the assumption of limited yet enough competence to do any medical work.
U.S Army Special Forces Medical Handbook ST 31-91B (1982): https://ia800606.us.archive.org/18/items/milmanual-st-31-91b...
On documenting use case scenarios and instructions related to that specific scenario.
U.S War Department Technical Manual 6-Ton, 6x6 Truck TM9-813 (1944): https://ia600202.us.archive.org/25/items/TM9-813/TM9-813.pdf
Additional references to look through, courtesy of the Internet Archive:
U.S Military Manual Collection: https://archive.org/details/military-manuals
The Manual Library Collection: https://archive.org/details/manuals
Edit: formatting and one more resource:
Army OE Program: https://armyoe.com
Do I fundamentally misunderstand what engineering means?
I would have expected something along the lines of explaining the goals and how to measure things like:
- performance, latency and throughput, ball park estimations
- robustness and correctness, which parts are critical and prioritized, what kinds of bugs can or cannot be tolerated, when are they being fixed
- resource usage, devices/hardware, deployment targets
And secondarily perhaps topics like:
- protocols and standards to adhere to
- open source and dependencies
- automation and tooling
- dev environments, version control
- testing and feedback loops
User 'jschveibinz' describes it well.