[HN Gopher] Writing an Engineering Strategy
___________________________________________________________________
Writing an Engineering Strategy
Author : kiyanwang
Score : 94 points
Date : 2023-02-19 17:53 UTC (5 hours ago)
(HTM) web link (lethain.com)
(TXT) w3m dump (lethain.com)
| sublinear wrote:
| Isn't this usually called business process management?
| officialchicken wrote:
| 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?
| thenerdhead wrote:
| Engineering teams, leads, and directors that are clueless as to
| what they are building and why. For engineering leaders to
| practice actual "leadership".
| norrsson wrote:
| 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.
| claytonjy wrote:
| 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?
| jk3000 wrote:
| In that context, I can recommend reading 'Technology Strategy
| Patterns: Architecture as Strategy'
| msoad wrote:
| 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 wrote:
| Well, in my view the leader you described is a manager and not
| a (servant) leader that is supporting his team.
| ketzo wrote:
| 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.
| [deleted]
| simonw wrote:
| 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.
| bcherny wrote:
| This is a cool document! I love when fields overlap like this
| -- project and product management aren't completely different
| in tech vs. TV shows.
|
| That said, the 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.
| jfoutz wrote:
| 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.
| thenerdhead wrote:
| 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 wrote:
| 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.
| valenterry wrote:
| 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 wrote:
| Taxonomy is tricky but I agree that this is a level in between
| strategic and tactical. In the military this level is called
| operational.
| [deleted]
| underwater wrote:
| 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.
| trashtestcrash wrote:
| Ugh another leader with their "resource allocation".
| webosdude wrote:
| 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 wrote:
| 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.
| kodah wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| You could read that ratio as a limit on infrastructure overhead
| that one should have. Unless you're in the IaaS business, I
| guess.
___________________________________________________________________
(page generated 2023-02-19 23:00 UTC)