3 ms·
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
by 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 agoIs 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.
- twblalock 5y ago> People like fire fighters. The fire inspector is broadly considered annoying. Good engineering orgs don't think that way. However it's also true that you need to build credibility and trust, and have some communication skills and an understanding of the larger picture, in order to act as a successful fire inspector. Improvement work always has to be balanced against feature development, but if you can show that developer productivity and the reliability of the product are being impacted, good managers will tend to listen. (Conversely, if those things aren't impacted, then why is your suggestion important?) If they don't care, it's time to move on. Seriously: there has never been a better job market in software and if you aren't happy you should be looking for other jobs.
- eecc 5y agoYeah, the ultimate fix to that are prototype (or sandbox, or whatever you want to call them) environments. Every branch has its own full stack of services and dependencies dedicated to it; and it all gets torn down the moment the branch disappears.
- peakaboo 5y agoThe strategy mindset is impossible in large corporations because you don't have the power to change those things, and even if you did, it would become a project involving everyone and taking years. There is a reason why people go for the workaround mindset and that is because they are just tiny cogs in a machine.