6 ms·

Individual contributors don't avoid strategy out of stupidity, we do it out of respect for the person whose job it is. Strategy is the ultimate bikeshed: the p

Individual contributors don't avoid strategy out of stupidity, we do it out of respect for the person whose job it is. Strategy is the ultimate bikeshed: the prerequisites for having an opinion are very low, so everyone has one. Don't mistake avoidance of scapegoat duty for not having an opinion. Everyone has an opinion. Unfortunately, the evidence never unambiguously points to a single course of action and paying everyone to daydream and argue about the big picture is wildly inefficient, so the key to getting anything done is to delegate the decisions to a single person per team, give them time to cultivate big picture knowledge and political connections, and then to respect those decisions even if you privately disagree. It would be awfully nice if that respect were reciprocated, but this article is an exercise in the polar opposite: it's a declaration that "management rules, labor drools," complete with a childish "descent into failure" diagram. Don't make the mistake of actually getting things done! You might out yourself as a stinky engineer and NEVER make it up into management! Mind the Peter Principle! Maybe next week they can blogspam on how management compensation is about leveraged value creation, not Rules for Rulers.

say_it_as_it_is 5y ago
you clearly were not swayed by the watershed metaphor
sadadar 5y ago
Strategic thinking isn’t just the generative idea creation of a “strategy”. It’s also about savvy execution within a strategic context. In every project a thousand decisions are made by “drooling labor” and the better each of those decisions ladders up to the strategy the more meaningful the impact of the work. Watching people proclaim no impact on strategy but thinking they deserve tons of credit for their code is a failure mode I’ve seen with engineers. Watching people get frustrated not being promoted when “idiot peers” get credit was often more about their own idiocy. Don’t dismiss the impact you have in every role, it’ll hurt your career and the actual impact you have.
- jjoonathan 5y ago
  Oh, absolutely. On both counts: strategic decisions that have been delegated to you are important to get right, and relentless self-promotion is the single most important skill inside and outside of any workplace. It's also important to recognize it for what it is, though, and TFA, well, is what it is.
rramadass 5y ago
Thank you for articulating something sane. The article is pure "Management/Leadership Speak" nonsense complete with contrived/farfetched analogies and blaming of Engineering/Engineers for actually delivering something but which may have been "Strategically Wrong" because somebody else made that decision. Engineers are told to "Execute" and not "Strategize" (which means everything and nothing). Given the responsibility, most Engineers are fully capable of Strategizing/Prioritizing/Executing on an Idea/Customer requirements so this insidious idea that Engineers are incapable of "Higher Managerial Functions" needs to die.
- MattGaiser 5y ago
  > Engineers are told to "Execute" and not "Strategize" Complete these questionably specified tickets and when you are done, come back for more tickets.
  - chmorgan 5y ago
    If this is what your job is encouraging then just wow. The engineers that I've seen be most productive are the ones pushing the design approaches and identifying gaps in the approach and tasks etc.
- amelius 5y ago
  However, most software engineers are bad at creating user-friendly products unless someone with product design skills tells them exactly what the UX should look like, or perhaps unless someone gives the engineers time to think about it.
  - rramadass 5y ago
    >However, most software engineers are bad at creating user-friendly products unless someone with product design skills tells them exactly what the UX should look like Absolutely Wrong!
    - amelius 5y ago
twblalock 5y ago
I actually liked the "Downward Strategy Spiral" diagram, which I think is the one you are referring to. It's one of the few things I liked about the article. I've seen a lot of engineers and SREs (especially SREs!) get stuck in the execution mindset: get the job done, no matter what it takes. Ultimately this leads to a situation where, instead of questioning why tools and platforms and processes suck, people apply shortcuts and workarounds without thinking about how they fit into the big picture. These workarounds accrete, eventually causing serious problems. One example: a CD system has a very rigid definition of what an "environment" is, and it's not possible to run more than one version of a given software package simultaneously in an "environment" in order to do performance tests or canarying or things like that. The "execution mindset" approach to that situation is to create new "environments" in order to just get the code deployed and close your ticket. Pretty soon the org ends up with dozens of these, some of which are only used by a single team, e.g. "prod" and "teamA-prod-sandbox" and "teamB-prod-perf-test." The "strategy mindset" approach is to say, hey, wait a minute, this "environment" design is not working well, people are hacking around it by creating new "environments," so let's fix that design so people don't need to do that anymore.
- MattGaiser 5y ago
  Is that them not thinking of it or just realizing that anything that requires greater time investment will be a fight? As much as many of us (myself included) are socially clueless, we do notice when people are annoyed with us and that is often when there is a problem (something SREs would need to deal with a lot if prod goes down). I have binned a lot of improvement proposals simply to keep management happy and not having the desire to fight for the required time/resources. Half the time I might share it with a fellow rank and file dev for interest sake, but it dies there. People like fire fighters. The fire inspector is broadly considered annoying.
  - whakim 5y ago
    > People like fire fighters. The fire inspector is broadly considered annoying. I don't think it's a binary. I've also shelved a lot of proposals that I believed in, not because I didn't want to fight for them, but because a smart strategist picks and chooses their battles. Fight fires by all means, but use some of the capital you accumulate that way to point out and resolve the causes of future fires.
mgh2 5y ago
I think you are missing the point of the article, as an ex-engineer shifting to business and strategy, one key mental model change comes from focusing on the "hows" to the "whats and whys" - mentioned at the start of the article. Even if you master data analysis skills (ie. as an analyst), which is completely different than what engineers are trained to do, this is only the "hard skills", which are the least important when it comes to management. Don't underestimate "soft skills" seen in many non-technical PMs. Keep yourself humble, keep learning - if you conquer both hard and soft skills, you are better guaranteed to succeed - evidenced by many ex-engineer CEOs in tech. Advice: https://www.youtube.com/watch?v=xlmzMbbKHgQ https://www.youtube.com/watch?v=xlmzMbbKHgQ
nandhinianand 5y ago
i liked the water shedding idea because it is new to me. But otherwise, the blog makes me ask the question, so if engineers get trained early to focus on executing solutions who is training? Are you just blaming them on the degrees? But don't we know lots of graduates are not job-ready? The point here being there are systemic problems here. Just like there is with so many other issues and that's getting ignored.
civilized 5y ago
> the key to getting anything done is to delegate the decisions to a single person per team, give them time to cultivate big picture knowledge and political connections, and then to respect those decisions even if you privately disagree. I don't agree with this in general. I've been forced into too many projects that were obviously bad from my perspective, but the Fearless Leader didn't care about anyone's input. I wasn't held accountable when those projects failed, but it was still depressing to have to do them. I get the impression that corporate drones hate having to debate a decision, and they structure their organizations to absolutely minimize the need for it. But personally I enjoy a spirited debate -- one focused on the merits, and with rational, civil people. I wish there was more deliberation in the workplace and less "do stupid things as fast as possible in the hopes that one of them will not be stupid". But there aren't enough people like me to sustain an organization, and that's why most orgs are top-down command-and-control hierarchies.

say_it_as_it_is 5y ago

you clearly were not swayed by the watershed metaphor

sadadar 5y ago

Strategic thinking isn’t just the generative idea creation of a “strategy”. It’s also about savvy execution within a strategic context. In every project a thousand decisions are made by “drooling labor” and the better each of those decisions ladders up to the strategy the more meaningful the impact of the work. Watching people proclaim no impact on strategy but thinking they deserve tons of credit for their code is a failure mode I’ve seen with engineers. Watching people get frustrated not being promoted when “idiot peers” get credit was often more about their own idiocy. Don’t dismiss the impact you have in every role, it’ll hurt your career and the actual impact you have.

jjoonathan 5y ago
Oh, absolutely. On both counts: strategic decisions that have been delegated to you are important to get right, and relentless self-promotion is the single most important skill inside and outside of any workplace. It's also important to recognize it for what it is, though, and TFA, well, is what it is.

rramadass 5y ago

Thank you for articulating something sane. The article is pure "Management/Leadership Speak" nonsense complete with contrived/farfetched analogies and blaming of Engineering/Engineers for actually delivering something but which may have been "Strategically Wrong" because somebody else made that decision. Engineers are told to "Execute" and not "Strategize" (which means everything and nothing). Given the responsibility, most Engineers are fully capable of Strategizing/Prioritizing/Executing on an Idea/Customer requirements so this insidious idea that Engineers are incapable of "Higher Managerial Functions" needs to die.

MattGaiser 5y ago
> Engineers are told to "Execute" and not "Strategize" Complete these questionably specified tickets and when you are done, come back for more tickets.
- chmorgan 5y ago
  If this is what your job is encouraging then just wow. The engineers that I've seen be most productive are the ones pushing the design approaches and identifying gaps in the approach and tasks etc.
amelius 5y ago
However, most software engineers are bad at creating user-friendly products unless someone with product design skills tells them exactly what the UX should look like, or perhaps unless someone gives the engineers time to think about it.
- rramadass 5y ago
  >However, most software engineers are bad at creating user-friendly products unless someone with product design skills tells them exactly what the UX should look like Absolutely Wrong!
  - amelius 5y ago

twblalock 5y ago

I actually liked the "Downward Strategy Spiral" diagram, which I think is the one you are referring to. It's one of the few things I liked about the article. I've seen a lot of engineers and SREs (especially SREs!) get stuck in the execution mindset: get the job done, no matter what it takes. Ultimately this leads to a situation where, instead of questioning why tools and platforms and processes suck, people apply shortcuts and workarounds without thinking about how they fit into the big picture. These workarounds accrete, eventually causing serious problems. One example: a CD system has a very rigid definition of what an "environment" is, and it's not possible to run more than one version of a given software package simultaneously in an "environment" in order to do performance tests or canarying or things like that. The "execution mindset" approach to that situation is to create new "environments" in order to just get the code deployed and close your ticket. Pretty soon the org ends up with dozens of these, some of which are only used by a single team, e.g. "prod" and "teamA-prod-sandbox" and "teamB-prod-perf-test." The "strategy mindset" approach is to say, hey, wait a minute, this "environment" design is not working well, people are hacking around it by creating new "environments," so let's fix that design so people don't need to do that anymore.

MattGaiser 5y ago
Is that them not thinking of it or just realizing that anything that requires greater time investment will be a fight? As much as many of us (myself included) are socially clueless, we do notice when people are annoyed with us and that is often when there is a problem (something SREs would need to deal with a lot if prod goes down). I have binned a lot of improvement proposals simply to keep management happy and not having the desire to fight for the required time/resources. Half the time I might share it with a fellow rank and file dev for interest sake, but it dies there. People like fire fighters. The fire inspector is broadly considered annoying.
- whakim 5y ago
  > People like fire fighters. The fire inspector is broadly considered annoying. I don't think it's a binary. I've also shelved a lot of proposals that I believed in, not because I didn't want to fight for them, but because a smart strategist picks and chooses their battles. Fight fires by all means, but use some of the capital you accumulate that way to point out and resolve the causes of future fires.

mgh2 5y ago

I think you are missing the point of the article, as an ex-engineer shifting to business and strategy, one key mental model change comes from focusing on the "hows" to the "whats and whys" - mentioned at the start of the article. Even if you master data analysis skills (ie. as an analyst), which is completely different than what engineers are trained to do, this is only the "hard skills", which are the least important when it comes to management. Don't underestimate "soft skills" seen in many non-technical PMs. Keep yourself humble, keep learning - if you conquer both hard and soft skills, you are better guaranteed to succeed - evidenced by many ex-engineer CEOs in tech. Advice: https://www.youtube.com/watch?v=xlmzMbbKHgQ https://www.youtube.com/watch?v=xlmzMbbKHgQ

nandhinianand 5y ago

i liked the water shedding idea because it is new to me. But otherwise, the blog makes me ask the question, so if engineers get trained early to focus on executing solutions who is training? Are you just blaming them on the degrees? But don't we know lots of graduates are not job-ready? The point here being there are systemic problems here. Just like there is with so many other issues and that's getting ignored.

civilized 5y ago

> the key to getting anything done is to delegate the decisions to a single person per team, give them time to cultivate big picture knowledge and political connections, and then to respect those decisions even if you privately disagree. I don't agree with this in general. I've been forced into too many projects that were obviously bad from my perspective, but the Fearless Leader didn't care about anyone's input. I wasn't held accountable when those projects failed, but it was still depressing to have to do them. I get the impression that corporate drones hate having to debate a decision, and they structure their organizations to absolutely minimize the need for it. But personally I enjoy a spirited debate -- one focused on the merits, and with rational, civil people. I wish there was more deliberation in the workplace and less "do stupid things as fast as possible in the hopes that one of them will not be stupid". But there aren't enough people like me to sustain an organization, and that's why most orgs are top-down command-and-control hierarchies.