In 2020, I presented a talk at FrOSCon titled No, we won’t have a video call for that: Communications for distributed teams. In early 2021 I put together a full-length writeup of that talk, and published it here. And for no apparent reason that article then made it to the top of Hacker News on one day in September 2021,1 and apparently resonated with quite a few people.

And after that, I got a fair number of questions along the lines of “okay, what you talk about is a spot-on description of how I want to work, but how do I get there?” In other words, what can you do in order to transition from a team that’s stuck in meeting hell, to one that actually goes fully distributed and embraces asynchronous communications?

Note: I use the shorthand Meeting Hell for a situation in which people are forced to
be in unnecessary and unproductive video meetings2 for an unhealthy fraction of
their work time.

This is admittedly a mere symptom of not having adopted asynchronous and
distributed ways of working, but it’s such a tell-tale sign thereof that it counts as a
dead giveaway. Thus, I think it’s okay to say “I’m stuck in meeting hell” when what
someone means is really “I work in an organization that’s failing badly at
distributed and asynchronous work.”

After No, We Won’t Have a Video Call for That, which covered how productive distributed teams operate, and the Getting out of Meeting Hell series, which focused on how you as an individual can get to being a member of a functional distributed team, let’s zoom out a bit.

Let’s discuss a slightly larger, organizational picture, just in case you ask yourself this question: “Why isn’t my organization distributed and asynchronous? And, as companies bleed talent right and left because competent people run for the competition that does get distributed work right, why don’t they wake up and become like that? Can someone please make my company more distributed and asynchronous?”

For additional context, let me interject the following observations from Kris Köhntopp, who posted them in German on Twitter (I am taking the liberty to translate here; emphasis mine):

What’s funny is that [what matters to being successful as a distributed company]
are all learnable skills — written communications, sensible meeting prep and
follow-up, correct definition of objectives and tasks, etc.

That’s a craft.

But it appears that organizations prefer to bleed their teams dry by attrition, rather
than to learn, or to hire people that can help teams to write things down,
professionally maintain a wiki, and teach and drive communications.

And further downthread, Kris says (again, my translation and emphasis):

This is all definitely feasible, after all there’s remote-first companies of substantial
size and they work.

They must have built themselves somehow, they didn’t get to where they are by
pure chance.

I agree with all of that (obviously), but things are complicated. So let’s drill into this a bit.

I use Git on a practically daily basis, and although it comes with just about everything including the proverbial kitchen sink, there are a few bits of functionality that I only wish it had. Luckily, Git’s functionality is almost indefinitely extensible via the use of aliases.

So, here are some that I define in my ~/.gitconfig file, with a brief explanation of what they’re good for: