On Drafting an Engineering Strategy | Hacker News Reader

On Drafting an Engineering Strategy

paperplanes.de

72 pointsbrlnwest13 comments

This is s pretty great article by a seemingly thoughtful individual. I hope more technology leaders read it and understand if not embrace the ideas it promotes.

Too often, I've been in the situation where a new leader will step into a role and immediately start throwing out commandments with little context as it relates to the business. An Ivory tower is built with the help of minions, assigned unwillingly or willingly bought in to the Grand Plan. Not seeing the immediate business value of the project, most teams avoid it or do the minimum work necessary to satisfy the requirements. Literally every time this happens, after about a year the Ivory tower remains up but is depopulated, a forgotten relic of a distant past that nobody really wants to think about. The leaders move on to the next role, and when new engineers ask senior engineers why the Ivory tower exists they smile and say: "buy me a beer; t'is a long tale"

Omg, how can this guy not notice that he became an useless director as in 'bullshit jobs'? Here you see the inception of the stupid things you see in big companies: like determining useless 'objectives' sentences coming from nowhere.

Look at this for example: "Migrate core functionality pieces (including authentication, user data, shopping cart) to a micro services architecture that’s running independently of our main application"

To me it looks like the kind of stupid generic tehnical decisions that are imposed on teams. We have all lived that: some useless director that has no idea of the real technical stack or constraints of the system wants to feel useful and define a 'bullshit' strategy, so what it does is imposing the last trendy thing he heard at a conference without really knowing what it means.

Have you tried developing several applications which should work independently but share the aurh /profile info? Add a zero-downtime deployment requirement, and microservices start to look damn appealing. No, they are not a silver bullet, but other architectures are much worse in a situation like that.

To be clear, this example was not about the content. It can be a 'good' or a 'bad' idea. Just about the fact to come and say: I will do a strategy for my poor stupid software engineers because I'm a director. 'Do buzzword, buzzword, trendy generic statement, buzzword...'

What is the alternative? Assuming here there is such a thing as a correct engineering strategy, who should define it?

Or, maybe there should be no engineering strategy, at least not an explicit one written down?

A strategy shouldn’t dictate WHAT needs to be done, it should layout where the company needs to get to and achieve. So in this micro services example, it’d be more appropriate to have something like “increase team independence and throughput”, of which microservices is a _possible_ solution amongst many others.

In terms of roadmapping, I like to use the phrase “futures, not features” to remind folks of the proper content for them.

Sometimes a WHAT is important enough to because the strategy. It should be an architectural problem holding everything back though. For the most part strategy should sit back a level where lots of different whats all fit in, and sometimes a what is allowed to violate it for good reasons.

> What is the alternative? Assuming here there is such a thing as a correct engineering strategy, who should define it?

In companies where engineering strategy is done well, the person defining the strategy (a director or VP usually) knows the technology as well as or better than any of the people working for him - that is why he or she is in that position. And because of that, he or she probably has buy-in from rest of the people in the engineering organization.

> For deeper inspiration on how to draft crisp and actionable strategies, I recommend the book “Good Strategy, Bad Strategy.”

This piece of advice is good, but I don't see it applied. If you take the book's advice as useful (and I do), good strategy starts with diagnosis of a problem. The problem statements are much more important than the solution statements.

Set goals and let the people doing the work decide how to achieve these goals. once they have decided on a strategy then management should support them.

Reading the article myself, I did not get the feeling. This seems to be a person who was brought in a very senior role and begins by listening to other teams, reading documentation etc. It seems like he is doing the right things to me.

IMO, it is not a bullshit job.

Migrating to a microservices architecture is almost always a pointless technical exercise—you’re right about that.

But it’s not a pointless business exercise. It creates firewalls between parts of the product which allows teams to operate and scale independently.

It’s one way to create the conditions to grow from a 50 engineer org to a 500 engineer org, if that’s your business goal.

Whether that’s a good business goal is another question, but it’s not a technical question.

The examples provided are out of context of the business strategy they are meant to support.

What is your experience interpreting a business strategy and devising a technical strategy to enable it?

Reply on news.ycombinator.com