Thread by @mipsytipsy

I was just editing the o11y book chapter on build vs buy and ROI, and this sentence jumped out at me:

"High-performing organizations use great tools."

It's true, right? Behold all the FAANG engineers who leave their cushy perches and are shocked by the amount of tooling they had come to take for granted. It's almost like having to learn to engineer all over again

Big companies know how critical good tooling is, and pay for it.

I'm going to say two very contradictory things, both of which are true:

1) Tools are getting better and better, and you should try to keep up

2) Switching tooling is hard, and you should only do it when the gain is ~an order of magnitude better than what you've got.

Engineering cycles are likely the scarcest resource in your organization, so it's truly astonishing how wasteful most places are with them.

I guess it's easier to hire another eng than it is to thoughtfully pay down tech debt and reclaim cycles. ¯\_(ツ)_/¯

There are some tools where spread and variety is all fine and good. Take editors -- to each her own, it doesn't matter.

There are other tools where consolidation and consistency of use are so critical that deviation would derail the team, like git. And plenty in between.

Then there are the tools in the middle, where some conventions may be required, but mostly intra-team. Like ... pagerduty, or feature flags, or the whole suite of debugging, observability, and monitoring tools.

Do some teams perform worse because they lack the tools to do better, or do they lack the tools to do better because they are worse teams?

My vote is generally the former. But even for engineering orgs that don't fall down the BYO hole, tooling can be a major source of drag.

Consider just a few of these tooling questions:

* new tool is LOADS better for some teams, only minorly so for others. should you make them (needlessly, to their mind) switch?

* you just finished rolling out the new tool, and you already regret your decision. UGH. what to do?

* you've never bothered to standardize in the past, but it's becoming a nightmare. there are at least eleven solutions running internally ... that you know of.

* in 👆 situation, one engineer is a committer to the open source solution and says they will quit if another is chosen

* your team LOVES one solution -- unanimously! the problem is, you're a RoR shop and this is a java solution. should you maintain all these servers and configs *just* for this tool?

* your teams LOVES one solution, but you have to stop using it for compliance reasons.

* you have standardized on one tool, but there are many workflows, and each has their passionate proponents. also you have no decision-making authority, only influence. what to do?

* you have one tool, but 50 different versions in use. people SAY they will upgrade, but never do.

* the bootstrapping guide has become a 30 page monstrosity. someone needs to figure out how to automate it, image the setup and manage the laptops. you're too small to hire an IT person. which lucky engineer gets the short stick?

You get the point (and I'm sure you all have hair-raising stories of your own!).

The point is, tooling decisions are incredibly important. Especially considering how ...let's say "lightweight".. the evaluation process often was in the first place. 🙃

There's no rule book. Sometimes variance is fine, sometimes not. Sometimes it's worth bearing down on folks, often it's not.

It takes a lot of good judgment, experience, and political/interpersonal skills to guide these decisions to a good outcome.

I'll just say -- if you asked me, "what's the best way to sabotage an engineering org, to frustrate them and force them to spin their wheels, hate each other and stop producing much of anything at all?"

I'd reply, "sell them on some bad tools." 😈