5 ms·

On Drafting an Engineering Strategy

72 points by brlnwest 7y ago

greatgib 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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?
      - richk449 7y ago
        > 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.
      - bpicolo 7y ago
        > 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.
      - dchuk 7y ago
        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 7y ago
        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.
      - Ididntdothis 7y ago
        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.
- iovrthoughtthis 7y ago
  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?
- pm90 7y ago
  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.
- erikpukinskis 7y ago
  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.
pm90 7y ago
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"

72 points by brlnwest 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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?
    - richk449 7y ago
      > 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.
    - bpicolo 7y ago
      > 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.
    - dchuk 7y ago
      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 7y ago
        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.
    - Ididntdothis 7y ago
      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.
iovrthoughtthis 7y ago
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?
pm90 7y ago
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.
erikpukinskis 7y ago
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.

pm90 7y ago

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"