There are many ways to feel like you’re living out the same workday over and over. Weekly, if you’re unlucky. Let’s talk about two in particular: failure to write it down, and failure to decide (on how to decide).
Write down the ways you didn’t choose, for God’s sake. Because otherwise you’re gonna run into… every approach has a problem and as soon as somebody runs into the problem they’re gonna say “oh, why didn’t we do it the other way?”
If you write down why you didn’t do it the other way they’ll look at it and be like “oh, right, right. Yeah, it sounded worse the other way” and they can move on. Otherwise the same conversation happens again.
— Kevin Ball and Kristján Pétursson, Creating Clarity From Ambiguity
Besides the general-purpose wisdom of “write it down”, this specific scenario hits home. Having to re-litigate a team’s decision every time a curveball comes along is both exhausting and a morale killer. Been there, would like to avoid that.
The alternatives-not-taken don’t need detailed write-ups. It works well enough to enumerate them, briefly describe the idea, and highlight the shortcomings or reasons that decision wasn’t taken.
Storytime: the last team I worked on that used MySQL had the “why didn’t we do it the other way?” problem every time a new developer was onboarded.
This was in the mid-2010s, when PostgreSQL and MySQL were reaching feature parity as single-host databases. PostgreSQL replication was just good enough to use in production. Further, it was several years into Heroku running PostgreSQL as a default, so many Rails developers had either not used MySQL or were unsure why one would choose MySQL.
Sometime in their first week, countless developers would ask or suggest some variation on “why don’t we use/why aren’t we moving to PostgreSQL?”. And every time, a bespoke reason was given, usually by a somewhat overworked/cranky person from the ops team. It typically rhymed with “this was the Rails default when we first built the app” or “migrating a database is an enormous effort with many second-order consequences and next-to-zero customer benefit, so here we are”.
If we had instead taken the time to document this in the onboarding material? Priceless, and one fewer interactions with cranky ops folks!
More talking. More translating. Action items are assigned, which gives everyone the illusion that progress was made. And we all return to our respective regional offices and wait until we have the same meeting again, where we attempt to communicate intelligently with each other. But all we really do is schedule meetings… when what we need to do is figure out who makes decisions.
— Rands in Repose, Bits, Features, and Truth
Same story, different tune. If a group (of leaders) can’t decide how to operate, collaboratively think, and make decisions, they’re doomed to repeat the same conversations and action items.
In my experience in this kind of ongoing and repetitive meeting, the root problem is failing to decide. Deciding how to decide is an important decision to make! If you come into a meeting not knowing how you’re going to get out of the meeting with closure, the meetings will just compound. It’s like interest-only payments at the beginning of your mortgage, slightly demoralizing but absolutely required per the (very) long-term contract you’ve signed.
My kingdom for software that makes it easier to collaborate, think, and decide than it is to schedule one more meeting. 🙄
