7 ms·

Writing an engineering strategy

305 points by kiyanwang 4y ago

valenterry 4y ago
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.
- sorokod 4y ago
  Taxonomy is tricky but I agree that this is a level in between strategic and tactical. In the military this level is called operational.
- underwater 4y ago
  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.
- deleted 4y ago
  [deleted]
- Msurrow 4y ago
  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”
- shsbdncudx 4y ago
  Strategy and tactics are layered.
sublinear 4y ago
Isn't this usually called business process management?
- Aeolun 4y ago
  That’s much lower level than this. It would describe how things like the ‘Escalation process’ mentioned in the article work.
officialchicken 4y ago
For those contemplating this, it would be helpful to understand who is the audience? And in one sentence, what is the purpose of this document?
- norrsson 4y ago
  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.
- thenerdhead 4y ago
  Engineering teams, leads, and directors that are clueless as to what they are building and why. For engineering leaders to practice actual “leadership”.
- ravagat 4y ago
  +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.
trashtestcrash 4y ago
Ugh another leader with their "resource allocation".
_ktx2 4y ago
> 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.
- threeseed 4y ago
  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.
- andrewem 4y ago
  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.
- layer8 4y ago
  You could read that ratio as a limit on infrastructure overhead that one should have. Unless you’re in the IaaS business, I guess.
- lopkeny12ko 4y ago
  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.
thenerdhead 4y ago
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.
- Spartan-S63 4y ago
  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.
webosdude 4y ago
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.
- Terretta 4y ago
  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.
- ravagat 4y ago
  What you described is as close as possible to product strategy and not engineering strategy.
msoad 4y ago
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.
- seb1204 4y ago
  Well, in my view the leader you described is a manager and not a (servant) leader that is supporting his team.
- ketzo 4y ago
  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.
- simonw 4y ago
  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_showrunning_nice_version.pdf 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.
jk3000 4y ago
In that context, I can recommend reading 'Technology Strategy Patterns: Architecture as Strategy'
- evanmoran 4y ago
  The Amazon link for the curious. To my surprise it was an O’Reilly book: https://www.amazon.com/Technology-Strategy-Patterns-Architecture/dp/1492040878 https://www.amazon.com/Technology-Strategy-Patterns-Architec...
claytonjy 4y ago
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?
jschveibinz 4y ago
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.
- ravagat 4y ago
  > Strategy needs to be tuneable* Yes yes yes!
a_c 4y ago
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.
k__ 4y ago
The definitive guide: https://learnwardleymapping.com/book/ https://learnwardleymapping.com/book/
ravagat 4y ago
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.
- ktownsend 4y ago
  Any example(s) you can point to?
  - moremetadata 4y ago
    https://www.scotland.police.uk/spa-media/2vpgv5cl/armed-forces-personnel-sop.pdf https://www.scotland.police.uk/spa-media/2vpgv5cl/armed-forc... https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN30101-PAM_700-107-000-WEB-1.pdf https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN30101-PAM_70... https://safety.army.mil/Portals/0/Documents/ON-DUTY/AVIATION/FLIGHTFAX/Standard/2020/Flightfax_93_September_2020.pdf https://safety.army.mil/Portals/0/Documents/ON-DUTY/AVIATION... https://www.globalsecurity.org/military/library/policy/army/atp/atp3-90-90.pdf https://www.globalsecurity.org/military/library/policy/army/... https://www.chemeurope.com/en/encyclopedia/Standing_operating_procedure.html https://www.chemeurope.com/en/encyclopedia/Standing_operatin... https://clik.dva.gov.au/sop-information/guide-using-sops https://clik.dva.gov.au/sop-information/guide-using-sops https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3056180/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3056180/ https://info.publicintelligence.net/ANA-7-10-2.pdf https://info.publicintelligence.net/ANA-7-10-2.pdf https://www.cdc.gov/vhf/ebola/pdf/air-ground-patient-handoff.pdf https://www.cdc.gov/vhf/ebola/pdf/air-ground-patient-handoff... Take your pick....
  - ravagat 4y ago
    Absolutely, though my examples are older as I found the language used far more eloquent compared to recent documents. On Brevity, a personal favourite and a classic W.S.C piece: https://policymemos.hks.harvard.edu/files/policymemos/files/churchill_memo_on_brevity.pdf?m=1602679032 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%2851%29.pdf 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-22-100-Aug99.pdf 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.pdf 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--us-army-special-forces-medical-handbook/st_31-91b-_us_army_special_forces_medical_handbook.pdf 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 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 https://archive.org/details/military-manuals The Manual Library Collection: https://archive.org/details/manuals https://archive.org/details/manuals Edit: formatting and one more resource: Army OE Program: https://armyoe.com https://armyoe.com
dgb23 4y ago
To me the example reads more like a management strategy that is _about_ engineers rather than engineering strategy. 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
- SheddingPattern 4y ago
  No, but you misunderstood the audience for an engineering strategy, namely other c-level execs. User 'jschveibinz' describes it well.
julik 4y ago
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.

305 points by kiyanwang 4y ago

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.

sorokod 4y ago
Taxonomy is tricky but I agree that this is a level in between strategic and tactical. In the military this level is called operational.
underwater 4y ago
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.
deleted 4y ago
[deleted]
Msurrow 4y ago
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”
shsbdncudx 4y ago
Strategy and tactics are layered.

sublinear 4y ago

Isn't this usually called business process management?

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

officialchicken 4y ago

For those contemplating this, it would be helpful to understand who is the audience? And in one sentence, what is the purpose of this document?

norrsson 4y ago
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.
thenerdhead 4y ago
Engineering teams, leads, and directors that are clueless as to what they are building and why. For engineering leaders to practice actual “leadership”.
ravagat 4y ago
+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.

trashtestcrash 4y ago

Ugh another leader with their "resource allocation".

_ktx2 4y ago

> 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.

threeseed 4y ago
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.
andrewem 4y ago
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.
layer8 4y ago
You could read that ratio as a limit on infrastructure overhead that one should have. Unless you’re in the IaaS business, I guess.
lopkeny12ko 4y ago
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.

thenerdhead 4y ago

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.

Spartan-S63 4y ago
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.

webosdude 4y ago

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.

Terretta 4y ago
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.
ravagat 4y ago
What you described is as close as possible to product strategy and not engineering strategy.

msoad 4y ago

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.

seb1204 4y ago
Well, in my view the leader you described is a manager and not a (servant) leader that is supporting his team.
ketzo 4y ago
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.
simonw 4y ago
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_showrunning_nice_version.pdf 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.

jk3000 4y ago

In that context, I can recommend reading 'Technology Strategy Patterns: Architecture as Strategy'

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

claytonjy 4y ago

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?

jschveibinz 4y ago

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.

ravagat 4y ago
> Strategy needs to be tuneable* Yes yes yes!

a_c 4y ago

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.

k__ 4y ago

The definitive guide: https://learnwardleymapping.com/book/ https://learnwardleymapping.com/book/

ravagat 4y ago

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.

ktownsend 4y ago
Any example(s) you can point to?
- moremetadata 4y ago
  https://www.scotland.police.uk/spa-media/2vpgv5cl/armed-forces-personnel-sop.pdf https://www.scotland.police.uk/spa-media/2vpgv5cl/armed-forc... https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN30101-PAM_700-107-000-WEB-1.pdf https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN30101-PAM_70... https://safety.army.mil/Portals/0/Documents/ON-DUTY/AVIATION/FLIGHTFAX/Standard/2020/Flightfax_93_September_2020.pdf https://safety.army.mil/Portals/0/Documents/ON-DUTY/AVIATION... https://www.globalsecurity.org/military/library/policy/army/atp/atp3-90-90.pdf https://www.globalsecurity.org/military/library/policy/army/... https://www.chemeurope.com/en/encyclopedia/Standing_operating_procedure.html https://www.chemeurope.com/en/encyclopedia/Standing_operatin... https://clik.dva.gov.au/sop-information/guide-using-sops https://clik.dva.gov.au/sop-information/guide-using-sops https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3056180/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3056180/ https://info.publicintelligence.net/ANA-7-10-2.pdf https://info.publicintelligence.net/ANA-7-10-2.pdf https://www.cdc.gov/vhf/ebola/pdf/air-ground-patient-handoff.pdf https://www.cdc.gov/vhf/ebola/pdf/air-ground-patient-handoff... Take your pick....
- ravagat 4y ago
  Absolutely, though my examples are older as I found the language used far more eloquent compared to recent documents. On Brevity, a personal favourite and a classic W.S.C piece: https://policymemos.hks.harvard.edu/files/policymemos/files/churchill_memo_on_brevity.pdf?m=1602679032 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%2851%29.pdf 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-22-100-Aug99.pdf 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.pdf 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--us-army-special-forces-medical-handbook/st_31-91b-_us_army_special_forces_medical_handbook.pdf 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 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 https://archive.org/details/military-manuals The Manual Library Collection: https://archive.org/details/manuals https://archive.org/details/manuals Edit: formatting and one more resource: Army OE Program: https://armyoe.com https://armyoe.com

dgb23 4y ago

To me the example reads more like a management strategy that is _about_ engineers rather than engineering strategy. 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

SheddingPattern 4y ago
No, but you misunderstood the audience for an engineering strategy, namely other c-level execs. User 'jschveibinz' describes it well.

julik 4y ago

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.