
On Drafting an Engineering Strategy - brlnwest
https://www.paperplanes.de/2020/1/31/on-drafting-an-engineering-strategy.html
======
pm90
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"

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

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

~~~
greatgib
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...'

~~~
Ygor
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?

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

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

