|
|
@@ -0,0 +1,877 @@ |
|
|
|
title: No, We Won’t Have a Video Call for That! |
|
|
|
url: https://xahteiwi.eu/resources/presentations/no-we-wont-have-a-video-call-for-that/ |
|
|
|
hash_url: 6c45b2e9a3bd7dc678d52e047a88cd1d |
|
|
|
|
|
|
|
<p>FrOSCon 2020 was an online event due to the COVID-19 pandemic, and |
|
|
|
gave me the opportunity to present an extended and heavily updated |
|
|
|
version of my <a href="https://xahteiwi.eu/resources/presentations/devopsdays-tel-aviv-2019/">DevOpsDays 2019</a> talk.</p> |
|
|
|
<hr> |
|
|
|
<p>I normally make my talks available as a video, and a slide deck with |
|
|
|
full speaker notes. In this case though, I consider it fitting to |
|
|
|
write the whole thing out, so that you <em>don’t</em> need to watch a full |
|
|
|
length video in 45 minutes, but can read the whole thing in 15.</p> |
|
|
|
<p>You’ll still find links to the recording and deck downpage, as usual.</p> |
|
|
|
<hr> |
|
|
|
<p>No, we won’t have a video call for that!</p> |
|
|
|
<p>Communications for distributed teams</p> |
|
|
|
<p>FrOSCon 2020</p> |
|
|
|
|
|
|
|
<p>This presentation is a talk presented at <a href="https://www.froscon.de/">FrOSCon 2020 |
|
|
|
Cloud Edition</a>. It is <a href="https://creativecommons.org/licenses/by-sa/4.0/">CC-BY-SA |
|
|
|
4.0</a> licensed, see |
|
|
|
<a href="/LICENSE">the license</a> for details.</p> |
|
|
|
<p>Hello and welcome, dear FrOScon people — this is my talk on |
|
|
|
communications in distributed teams. My name is Florian, this is the |
|
|
|
second time I‘m speaking at FrOScon, and you probably want to know |
|
|
|
what the hell qualifies me to talk about this specific issue. So:</p> |
|
|
|
<h3>Why am I talking here?</h3> |
|
|
|
<p>So, why am I talking about <strong>that</strong>?</p> |
|
|
|
<p>Or rather more precisely, why am <strong>I</strong> talking about that?</p> |
|
|
|
<p>I turned 40 last year, have been in IT for about 20 years now (19 |
|
|
|
full-time), and out of that I have worked</p> |
|
|
|
<ul> |
|
|
|
<li> |
|
|
|
<p>in 4 successive companies, all of which worked out of offices, |
|
|
|
for 11 years, </p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>in a completely distributed company, that I founded, for 6 years,</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>and now, for about three years, I have been running a distributed |
|
|
|
team that is a business unit of a company that has existed for 15 |
|
|
|
years and throughout that time, has only ever worked from a single |
|
|
|
office.</p> |
|
|
|
</li> |
|
|
|
</ul> |
|
|
|
<p>So I think I might have seen and become aware of some of the rather |
|
|
|
interesting challenges that come with this.</p> |
|
|
|
<h3>What changed since last time?</h3> |
|
|
|
<p>I originally wrote and presented this talk for the first time in |
|
|
|
December 2019. At the time, you probably had forgotten about SARS, had |
|
|
|
no idea what SARS-CoV2 or COVID-19 were, and many of you were probably |
|
|
|
working from offices.</p> |
|
|
|
<p>And then something like three months later, everything changed and |
|
|
|
suddenly, this talk became much more relevant to a much greater |
|
|
|
audience.</p> |
|
|
|
<p>And something else happened: a lot of people suddenly started talking |
|
|
|
about working from home and distributed teams, and a lot of those |
|
|
|
people who were talking very loudly, had themselves only been working |
|
|
|
with or managing distributed teams since March. And a fair amount of |
|
|
|
what you could about the subject then, and can still read now, is |
|
|
|
complete and utter bullshit.</p> |
|
|
|
<p>So there’s one point I actually <em>didn’t</em> make in the initial version |
|
|
|
of this talk, because I thought it was self-evident. But I have come |
|
|
|
to the conclusion that to a lot of people it is not, so to rectify |
|
|
|
this omission from last December — and with apologies for that |
|
|
|
omission to the wonderful DevOpsDays Tel Aviv crowd, who were my first |
|
|
|
audience for this talk, let me make this one thing very clear from the |
|
|
|
outset:</p> |
|
|
|
<blockquote> |
|
|
|
<p>Effective distributed collaboration is <strong>not</strong> pretending to be in |
|
|
|
an office while staring into a webcam all day.</p> |
|
|
|
</blockquote> |
|
|
|
<p>You will never be able to capitalize on work as a distributed team |
|
|
|
unless you kick some office habits. The key to distributed teams being |
|
|
|
effective is <strong>not</strong> that they happen to not be in the same place, as |
|
|
|
you’ll see from the remainder of this talk. So to expect success from |
|
|
|
the approach that you take the habits of an office, simply remove the |
|
|
|
element of locality, replace every face to face meeting with a video |
|
|
|
call and carry on, is ludicrous.</p> |
|
|
|
<p>The good news is that if you do it right, you’ll end up with a far |
|
|
|
better team than a local one would ever be, <em>and</em> everyone has a |
|
|
|
chance at far better work-life balance, <em>and</em> you don’t waste awful |
|
|
|
amounts of time and energy and fossil fuels on your commute.</p> |
|
|
|
<h3>What’s in this talk?</h3> |
|
|
|
<p>So you’ll find a few general themes throughout this talk:</p> |
|
|
|
<ul> |
|
|
|
<li> |
|
|
|
<p>What modes we have <em>available</em> for communications in teams;</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>Why distributed teams always collaborate <em>asynchronously,</em> and what |
|
|
|
communication modes lend themselves to that particularly well;</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>Why <em>written communication</em> is so important in distributed teams;</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>And why <em>meetings</em> (like video calls) are a mode of communication |
|
|
|
that effective distributed teams hardly ever need to use — except |
|
|
|
for very specific reasons.</p> |
|
|
|
</li> |
|
|
|
</ul> |
|
|
|
<p>But I do want to state one thing upfront:</p> |
|
|
|
<blockquote> |
|
|
|
<p>This is <em>not science.</em></p> |
|
|
|
</blockquote> |
|
|
|
<p>Nothing of what I am talking about is steeped in any scientific |
|
|
|
rigour. I present anecdotes, not evidence. I might be mistaking |
|
|
|
correlation for causation, or the other way round. It’s solely based |
|
|
|
on my personal experience, and the experience of others I have talked |
|
|
|
to, watched, or read. Everything I say here is subject to debate and |
|
|
|
rebuttal, or you can simply have a different opinion.</p> |
|
|
|
<p>But it’s definitely <strong>not</strong> science.</p> |
|
|
|
<p>Now with all of that said, let me attempt to give a definition of a |
|
|
|
distributed team, according to my understanding:</p> |
|
|
|
<p>A distributed team is a <strong>professional</strong> group whose members do not |
|
|
|
rely on proximity in order to <strong>routinely</strong> collaborate |
|
|
|
productively.</p> |
|
|
|
<p>Now this is clearly not an ideal definition, not least because it |
|
|
|
defines something by a negative, and an outside factor to boot: it |
|
|
|
defines a distributed team by what it <em>does not need</em> to exist to |
|
|
|
function. But it’s the best definition I’ve been able to come up with.</p> |
|
|
|
<p>Now there’s a couple of key words in here:</p> |
|
|
|
<ul> |
|
|
|
<li> |
|
|
|
<p><strong>Professional.</strong> I’m talking about teams that work towards a |
|
|
|
professional goal. This doesn’t necessarily mean that they all work |
|
|
|
in the same company. They could, for example, all work in different |
|
|
|
companies collaborating on a joint project, which is what frequently |
|
|
|
happens in open source software projects. But they’re not pursuing |
|
|
|
their hobby, they’re doing their jobs.</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p><strong>Routinely.</strong> I’m talking about teams that <em>habitually</em> work in a |
|
|
|
distributed fashion, not the work that goes on in an office-based |
|
|
|
team when one person is having a work-from-home day.</p> |
|
|
|
</li> |
|
|
|
</ul> |
|
|
|
<p>It is important to understand that that lack of proximity is not only |
|
|
|
spatial, it is temporal as well, because:</p> |
|
|
|
<blockquote> |
|
|
|
<p>Working in a distributed team means <strong>working asynchronously.</strong></p> |
|
|
|
</blockquote> |
|
|
|
<p>If your team is distributed, this is equivalent to saying that it |
|
|
|
works in an asynchronous fashion, that is to say, that people will |
|
|
|
work on things in parallel, and a capable distributed team will have |
|
|
|
just as few synchronization points as absolutely necessary.</p> |
|
|
|
<p>The reason for this is not just working in different timezones, but |
|
|
|
also the fact that everyone will have their own daily routine, and/or |
|
|
|
have their individual times when they are most productive. Which you |
|
|
|
<em>will not attempt to synchronize.</em> (Doing so would mean setting the |
|
|
|
entire team up for failure.)</p> |
|
|
|
<p>Now, this doesn’t come for free, nor does it fall in our lap:</p> |
|
|
|
<blockquote> |
|
|
|
<p>Being productive in a distributed team is a skill |
|
|
|
that most people must <strong>learn;</strong> it is not innate to us.</p> |
|
|
|
</blockquote> |
|
|
|
<p>People are not born with the ability to work in a distributed |
|
|
|
team. Humans function best in groups that collaborate in close |
|
|
|
proximity to one another; it is only very recently that technology has |
|
|
|
started to enable us to override that to an extent — giving us other |
|
|
|
benefits like the ability to work from home, or the ability to hire |
|
|
|
people residing anywhere, provided they have internet connectivity.</p> |
|
|
|
<p>So we now <em>can</em> work in teams despite being continental distances away |
|
|
|
from each other but we do have to acquire the skills to do that. And |
|
|
|
if we fail to do so, that has a rather grave disadvantage, which is |
|
|
|
that...</p> |
|
|
|
<blockquote> |
|
|
|
<p><strong>Nothing</strong> has as dire an impact on productivity as <strong>poor |
|
|
|
communications.</strong></p> |
|
|
|
</blockquote> |
|
|
|
<p>This is a truism that applies to both distributed and non-distributed |
|
|
|
teams. Having bad communications will wreck any project, blow any |
|
|
|
budget, fail any objective. Now note that the reverse is <em>not true:</em> |
|
|
|
having <em>good</em> communications does not guarantee success. But having |
|
|
|
bad communications does guarantee failure.</p> |
|
|
|
<p>And here is one thing to start with:</p> |
|
|
|
<blockquote> |
|
|
|
<p>A capable distributed team <strong>habitually externalises</strong> information.</p> |
|
|
|
</blockquote> |
|
|
|
<p>Information is generally far less useful when it is only stored in one |
|
|
|
person’s head, as opposed to being accessible in a shared system that |
|
|
|
everyone trusts and can use. If you take important information out of |
|
|
|
your own head and store it in a medium that allows others to easily |
|
|
|
find and contextualise it, that’s a win for everyone.</p> |
|
|
|
<p>And since we’re all technology people, we typically have multiple |
|
|
|
facilities to externalise, share, and then access information at our |
|
|
|
disposal. So let’s see how those compare.</p> |
|
|
|
<h2>Modes of communication in distributed teams</h2> |
|
|
|
<p>A distributed team will habitually use multiple modes of |
|
|
|
communication, relying mostly on those that make sharing, finding, and |
|
|
|
contextualising information easy, and avoiding those that make it |
|
|
|
difficult.</p> |
|
|
|
<p>In many teams, distributed or not, using chat as a default mode of |
|
|
|
communication is becoming the norm. Now with an important exception, |
|
|
|
which I’ll get to near the end of the talk, this is <strong>not</strong> a symptom |
|
|
|
of having a particularly dynamic or efficient team; it’s the opposite.</p> |
|
|
|
<blockquote> |
|
|
|
<p>Excessively using chat isn’t being efficient. |
|
|
|
It’s being lazy.</p> |
|
|
|
</blockquote> |
|
|
|
<p>It’s a symptom of the worst kind of laziness <em>(not malice!)</em>: in an |
|
|
|
attempt to communicate quickly and easily, for yourself, you are really |
|
|
|
making things harder for everyone, including yourself.</p> |
|
|
|
<table class="table-hover table table-striped"> |
|
|
|
<thead> |
|
|
|
<tr> |
|
|
|
<th></th> |
|
|
|
<th align="center">Share</th> |
|
|
|
<th align="center">Find</th> |
|
|
|
<th>Contextualise</th> |
|
|
|
</tr> |
|
|
|
</thead> |
|
|
|
<tbody> |
|
|
|
<tr> |
|
|
|
<td>Chat</td> |
|
|
|
<td align="center">🙂</td> |
|
|
|
<td align="center">😐</td> |
|
|
|
<td>🙁</td> |
|
|
|
</tr> |
|
|
|
</tbody> |
|
|
|
</table> |
|
|
|
<p>This is because, while <em>sharing</em> information in a chat is extremely |
|
|
|
easy, it is also a “fire and forget” mode of communications. Chat |
|
|
|
makes it difficult to find information after the fact. If you’ve ever |
|
|
|
attempted to scour a busy Slack or IRC archive for a discussion on a |
|
|
|
specific topic that you only remember to have happened a “few months |
|
|
|
ago”, you’ll agree with me here.</p> |
|
|
|
<p>It’s even <em>more</em> difficult to read a Slack discussion in context, that |
|
|
|
is to say in relation to <em>other</em> discussions on the same topic, days |
|
|
|
or weeks earlier or later.</p> |
|
|
|
<p>Let’s compare that to other communication modes:</p> |
|
|
|
<table class="table-hover table table-striped"> |
|
|
|
<thead> |
|
|
|
<tr> |
|
|
|
<th></th> |
|
|
|
<th align="center">Share</th> |
|
|
|
<th align="center">Find</th> |
|
|
|
<th>Contextualise</th> |
|
|
|
</tr> |
|
|
|
</thead> |
|
|
|
<tbody> |
|
|
|
<tr> |
|
|
|
<td>Chat</td> |
|
|
|
<td align="center">🙂</td> |
|
|
|
<td align="center">😐</td> |
|
|
|
<td>🙁</td> |
|
|
|
</tr> |
|
|
|
<tr> |
|
|
|
<td>Email</td> |
|
|
|
<td align="center">😐</td> |
|
|
|
<td align="center">😐</td> |
|
|
|
<td>😐</td> |
|
|
|
</tr> |
|
|
|
</tbody> |
|
|
|
</table> |
|
|
|
<ul> |
|
|
|
<li>Email makes it easy to share information with a person or a group |
|
|
|
from the get-go, but quite difficult to loop people into an ongoing |
|
|
|
discussion after the fact. Finding information later is just as hard |
|
|
|
as with chat, and it’s marginally better at contextualizing |
|
|
|
information than chat (because you get proper threading).</li> |
|
|
|
</ul> |
|
|
|
<table class="table-hover table table-striped"> |
|
|
|
<thead> |
|
|
|
<tr> |
|
|
|
<th></th> |
|
|
|
<th align="center">Share</th> |
|
|
|
<th align="center">Find</th> |
|
|
|
<th>Contextualise</th> |
|
|
|
</tr> |
|
|
|
</thead> |
|
|
|
<tbody> |
|
|
|
<tr> |
|
|
|
<td>Chat</td> |
|
|
|
<td align="center">🙂</td> |
|
|
|
<td align="center">😐</td> |
|
|
|
<td>🙁</td> |
|
|
|
</tr> |
|
|
|
<tr> |
|
|
|
<td>Email</td> |
|
|
|
<td align="center">😐</td> |
|
|
|
<td align="center">😐</td> |
|
|
|
<td>😐</td> |
|
|
|
</tr> |
|
|
|
<tr> |
|
|
|
<td>Wiki</td> |
|
|
|
<td align="center">🙂</td> |
|
|
|
<td align="center">🙂</td> |
|
|
|
<td>🙂</td> |
|
|
|
</tr> |
|
|
|
<tr> |
|
|
|
<td>Issue tracker</td> |
|
|
|
<td align="center">🙂</td> |
|
|
|
<td align="center">🙂</td> |
|
|
|
<td>🙂</td> |
|
|
|
</tr> |
|
|
|
</tbody> |
|
|
|
</table> |
|
|
|
<ul> |
|
|
|
<li>A wiki and an issue tracker (provided you don’t lock them down with |
|
|
|
silly view permissions), in contrast, both make it <em>very</em> easy to |
|
|
|
share, find, <strong>and</strong> contextualise information.<br> |
|
|
|
Note that “wiki”, in this context, is shorthand for any facility |
|
|
|
that allows you to collaboratively edit long-form documents |
|
|
|
online. That can be an actual wiki like a MediaWiki, but also |
|
|
|
something like Confluence, or even shared Google Docs.<br> |
|
|
|
Likewise, “issue tracker” can mean RT, OTRS, Jira, Taiga, Bugzilla, |
|
|
|
whatever works for you.</li> |
|
|
|
</ul> |
|
|
|
<table class="table-hover table table-striped"> |
|
|
|
<thead> |
|
|
|
<tr> |
|
|
|
<th></th> |
|
|
|
<th align="center">Share</th> |
|
|
|
<th align="center">Find</th> |
|
|
|
<th>Contextualise</th> |
|
|
|
</tr> |
|
|
|
</thead> |
|
|
|
<tbody> |
|
|
|
<tr> |
|
|
|
<td>Chat</td> |
|
|
|
<td align="center">🙂</td> |
|
|
|
<td align="center">😐</td> |
|
|
|
<td>🙁</td> |
|
|
|
</tr> |
|
|
|
<tr> |
|
|
|
<td>Email</td> |
|
|
|
<td align="center">😐</td> |
|
|
|
<td align="center">😐</td> |
|
|
|
<td>😐</td> |
|
|
|
</tr> |
|
|
|
<tr> |
|
|
|
<td>Wiki</td> |
|
|
|
<td align="center">🙂</td> |
|
|
|
<td align="center">🙂</td> |
|
|
|
<td>🙂</td> |
|
|
|
</tr> |
|
|
|
<tr> |
|
|
|
<td>Issue tracker</td> |
|
|
|
<td align="center">🙂</td> |
|
|
|
<td align="center">🙂</td> |
|
|
|
<td>🙂</td> |
|
|
|
</tr> |
|
|
|
<tr> |
|
|
|
<td>Video call</td> |
|
|
|
<td align="center">😐</td> |
|
|
|
<td align="center">🙁</td> |
|
|
|
<td>🙁</td> |
|
|
|
</tr> |
|
|
|
</tbody> |
|
|
|
</table> |
|
|
|
<ul> |
|
|
|
<li>Video calls are even worse than chat or email, because sharing |
|
|
|
information works but doesn’t scale — you can’t reasonably have more |
|
|
|
than 5-or-so people in a video call, and sharing the recording of a |
|
|
|
full video call is just pointless.</li> |
|
|
|
</ul> |
|
|
|
<p>So really, make your wiki and your issue tracker your default mode of |
|
|
|
communications, and use the others sparingly. (This isn’t meant to be |
|
|
|
a euphemism for “don’t use them”, as we’ll get to in a moment.)</p> |
|
|
|
<h2>Text chat</h2> |
|
|
|
<p>So. Let’s talk about text chat. These days, that frequently means |
|
|
|
<a href="https://slack.com/">Slack</a>, but what I am talking about also and |
|
|
|
equally applies to |
|
|
|
<a href="https://en.wikipedia.org/wiki/Internet_Relay_Chat">IRC</a>, |
|
|
|
<a href="https://mattermost.com/">Mattermost</a>, <a href="https://riot.im/">Riot</a>, and |
|
|
|
anything similar.</p> |
|
|
|
<p>Is text chat universally useful? No. Is it universally bad? Not that, |
|
|
|
either. There is a very specific type of situation in which text chat |
|
|
|
is a good thing:</p> |
|
|
|
<blockquote> |
|
|
|
<p>Use <strong>chat</strong> for collaboration that requires <strong>immediate, |
|
|
|
interactive mutual feedback.</strong></p> |
|
|
|
</blockquote> |
|
|
|
<p>Using interactive chat is a good idea for the kind of communication |
|
|
|
that requires immediate, interactive mutual feedback from two or more |
|
|
|
participants. If that is not the case, chat is not a good idea.</p> |
|
|
|
<p>This means that the only thing that chat is good for is communication |
|
|
|
that is required to be <em>synchronous,</em> and remember, in a distributed |
|
|
|
team <em>asychronicity</em> is the norm. So using interactive chat for |
|
|
|
communications needs to be an <em>exceptional</em> event for a distributed |
|
|
|
team; if it is instead a regular occurrence you’ll make everyone on |
|
|
|
the team miserable.</p> |
|
|
|
<p>For any interaction that does <em>not</em> require feedback that is <em>both</em> |
|
|
|
immediate and interactive, email, a wiki, or an issue tracker are <em>far |
|
|
|
superior</em> modes of communication.</p> |
|
|
|
<blockquote> |
|
|
|
<p>The only reason to use <strong>DMs</strong> for collaboration<br> |
|
|
|
is a need for immediate, interactive mutual feedback<br> |
|
|
|
<strong>and confidentiality.</strong></p> |
|
|
|
</blockquote> |
|
|
|
<p>Using chat direct messages (DMs) as the <em>default</em> means of |
|
|
|
communication is utterly braindead. In order for a chat DM to be |
|
|
|
useful, there is precisely one clearly delineated confluence of events |
|
|
|
that must occur:</p> |
|
|
|
<ul> |
|
|
|
<li>You need immediate feedback from the other person,</li> |
|
|
|
<li>you need mutual back-and-forth with the other person,</li> |
|
|
|
<li>you don’t want others to follow the conversation.</li> |
|
|
|
</ul> |
|
|
|
<p>I can’t emphasize enough that this combination is perfectly valid — |
|
|
|
but it is <em>exceedingly rare.</em> If you want just a private exchange of |
|
|
|
ideas with someone, encrypted email will do. If you want to work on |
|
|
|
something together with one person before you share it with others, |
|
|
|
restricted view permissions on a wiki page or an issue tracker ticket |
|
|
|
will work just fine.</p> |
|
|
|
<p>If you don’t need confidentiality but you do need interactive and |
|
|
|
immediate feedback, chances are that you’re working on something |
|
|
|
urgent, and it is far more likely you’ll eventually need to poll other |
|
|
|
opinions, than that you won’t. So just use a shared channel from the |
|
|
|
get-go, that way it’s easier for others to follow the conversation if |
|
|
|
needed — and they might be able to point out an incorrect assumption |
|
|
|
that one of you has, before you end up chasing a red herring.</p> |
|
|
|
<blockquote> |
|
|
|
<p>A chat ping is a shoulder tap.</p> |
|
|
|
</blockquote> |
|
|
|
<p>“Pinging” someone in a chat (that is, mentioning their username, which |
|
|
|
usually triggers a visual or auditory notification), is exactly like |
|
|
|
walking up to a person, interrupting what they are doing, tapping them |
|
|
|
on the shoulder, and asking them a question.</p> |
|
|
|
<p><strong>No matter whether it is your intention or not,</strong> they will feel |
|
|
|
compelled to answer, relatively promptly (the only exception is when |
|
|
|
you’ve done this so often that you have conditioned your colleagues |
|
|
|
to ignore you — congratulations).</p> |
|
|
|
<p>This means that you’ve broken their train of thought, yanked them out |
|
|
|
of a potentially complex task, forced them to redo what they did |
|
|
|
pre-interruption, or actually have them commit a mistake.</p> |
|
|
|
<p>So pinging someone in a chat is something you should only do if you |
|
|
|
are aware of exactly this risk, <em>and</em> you are convinced that whatever |
|
|
|
you’re pinging about is more important. Otherwise, to be very blunt, |
|
|
|
you’ll be seen as the asshole.</p> |
|
|
|
<blockquote> |
|
|
|
<p>Want people to hate you? Send naked pings.</p> |
|
|
|
</blockquote> |
|
|
|
<p>A “naked ping” is the action of sending someone a message consisting |
|
|
|
only of their username and a marker like “ping”, “hi”, “hey” or |
|
|
|
similar.</p> |
|
|
|
<div class="highlight"><pre><span></span><code><span class="mi">14</span><span class="o">:</span><span class="mi">00</span><span class="o">:</span><span class="mi">02</span><span class="n">Z</span> <span class="n">johndoe</span><span class="o">:</span> <span class="n">florian</span><span class="o">:</span> <span class="n">ping</span> |
|
|
|
<span class="o">[...]</span> |
|
|
|
<span class="mi">15</span><span class="o">:</span><span class="mi">56</span><span class="o">:</span><span class="mi">17</span><span class="n">Z</span> <span class="n">florian</span><span class="o">:</span> <span class="n">johndoe</span><span class="o">:</span> <span class="n">I</span> <span class="n">hate</span> <span class="n">you</span> |
|
|
|
</code></pre></div> |
|
|
|
<p>Don’t. Just don’t.</p> |
|
|
|
<p>Any person who is versed in the use of chat communications will, when |
|
|
|
subjected to this behavior, be inclined to flay you alive. Infinitely |
|
|
|
more so if it’s a DM. <strong>Do not do this.</strong></p> |
|
|
|
<p>Instead, always provide context. Always always always. Don’t say “can |
|
|
|
I ask you a question, instead, <em>ask the question.</em> If something isn’t |
|
|
|
urgent, say something like “no urgency.”</p> |
|
|
|
<div class="highlight"><pre><span></span><code><span class="mi">14</span><span class="o">:</span><span class="mi">00</span><span class="o">:</span><span class="mi">02</span><span class="n">Z</span> <span class="n">johndoe</span><span class="o">:</span> <span class="n">florian</span><span class="o">:</span> <span class="n">can</span> <span class="n">I</span> <span class="kd">get</span> <span class="n">your</span> <span class="n">eyes</span> <span class="n">on</span> <span class="n">PR</span> <span class="err">#</span><span class="mi">1422</span><span class="o">?</span> |
|
|
|
<span class="o">[...]</span> |
|
|
|
<span class="mi">15</span><span class="o">:</span><span class="mi">56</span><span class="o">:</span><span class="mi">17</span><span class="n">Z</span> <span class="n">florian</span><span class="o">:</span> <span class="n">johndoe</span><span class="o">:</span> <span class="n">done</span><span class="o">!</span> |
|
|
|
<span class="o">(</span><span class="n">was</span> <span class="n">afk</span> <span class="k">for</span> <span class="n">a</span> <span class="n">bit</span> <span class="err">–</span> <span class="n">sick</span> <span class="n">kiddo</span><span class="o">)</span> |
|
|
|
<span class="mi">15</span><span class="o">:</span><span class="mi">56</span><span class="o">:</span><span class="mi">58</span><span class="n">Z</span> <span class="n">johndoe</span><span class="o">:</span> <span class="n">florian</span><span class="o">:</span> <span class="n">np</span><span class="o">,</span> <span class="n">ty</span> |
|
|
|
</code></pre></div> |
|
|
|
<p>It should be self-evident why this is better than naked pings, but if |
|
|
|
to you it is not, then please read <a href="https://blogs.gnome.org/markmc/2014/02/20/naked-pings/">Naked |
|
|
|
Pings</a>, |
|
|
|
courtesy of Adam Jackson and Mark McLoughlin.</p> |
|
|
|
<h2>Video calls</h2> |
|
|
|
<p>(Zoom, Hangouts, BlueJeans etc.)</p> |
|
|
|
<p>Next, I’d like to talk about video calls. Doesn’t matter what |
|
|
|
technology you’re using. Could be Zoom, Google Hangouts, BlueJeans, |
|
|
|
Jitsi, whatever.</p> |
|
|
|
<p>And I’d like to address this specifically, given the fact that in the |
|
|
|
current pandemic the use of video calls appears to have skyrocketed.</p> |
|
|
|
<p>There’s a very good reason to use video calls: they give you the |
|
|
|
ability to pick up on nontextual and nonverbal cues from the call |
|
|
|
participants. But that’s really the only good reason to use them.</p> |
|
|
|
<p>Video calls have a significant drawback: until we get reliable |
|
|
|
automatic speech recognition and transcription, they are only |
|
|
|
half-on-the-record. Hardly anyone goes to the trouble of preparing a |
|
|
|
full transcript of a meeting, and if anything, we get perhaps a |
|
|
|
summary of points discussed and action items agreed to. So even if we |
|
|
|
keep recordings of every video call we attend, it’s practically |
|
|
|
impossible to discern, after the fact, what was discussed in a meeting |
|
|
|
<em>before</em> decisions were made.</p> |
|
|
|
<p>It is also practically impossible to <em>find</em> a discussion point that |
|
|
|
you only have a vague recollection of when it was discussed in a video |
|
|
|
call, whereas doing so has a much greater probability of success if |
|
|
|
a discussion took place on any archived text-based medium.</p> |
|
|
|
<blockquote> |
|
|
|
<p>Every video call needs an agenda.</p> |
|
|
|
</blockquote> |
|
|
|
<p>This is, of course, true for any meeting, not just those conducted by |
|
|
|
video call.</p> |
|
|
|
<p>A conversation without an agenda is useless. You want people to know |
|
|
|
what to expect of the call. You also want to give people the option to |
|
|
|
prepare for the call, such as doing some research or pulling together |
|
|
|
some documentation. If you fail to circulate those <em>ahead of time,</em> I |
|
|
|
can guarantee that the call will be ineffective, and will likely |
|
|
|
result in a repeat performance.</p> |
|
|
|
<blockquote> |
|
|
|
<p>Until machines get intelligent enough to automatically transcribe |
|
|
|
and summarise words spoken in a meeting, <strong>write notes and a summary |
|
|
|
of every meeting you attend,</strong> and <strong>circulate them.</strong></p> |
|
|
|
</blockquote> |
|
|
|
<p>Just as important as an agenda to set the <em>purpose</em> of the meeting, is |
|
|
|
a set of notes that describes its <em>outcome</em>. </p> |
|
|
|
<p>Effective distributed teams understand that the <em>record</em> of a call is |
|
|
|
what counts, not the call itself. It is not the spoken word that |
|
|
|
matters, but the written one.</p> |
|
|
|
<p>From that follows this consequence:</p> |
|
|
|
<blockquote> |
|
|
|
<p>To be useful, the write-up of a call <strong>takes more time and effort</strong> |
|
|
|
than the call itself.</p> |
|
|
|
</blockquote> |
|
|
|
<p>If you think that video calls are any less work than chat meetings or |
|
|
|
a shared document that’s being edited together or dicussed in |
|
|
|
comments, think again. The only way a video call is less work, is when |
|
|
|
everyone’s lazy and the call is, therefore, useless. Every meeting |
|
|
|
needs notes and a summary, and you need to circulate these notes not |
|
|
|
only with everyone who attended the meeting, but with everyone who has |
|
|
|
a need-to-know.</p> |
|
|
|
<p>Here’s the standard outline I use for meeting notes:</p> |
|
|
|
<ol> |
|
|
|
<li>Meeting title</li> |
|
|
|
<li>Date, time, attendees</li> |
|
|
|
<li>Summary</li> |
|
|
|
<li>Discussion points (tabular)</li> |
|
|
|
<li>Action items</li> |
|
|
|
</ol> |
|
|
|
<p>Putting an executive summary at the very top is extraordinarily |
|
|
|
helpful so people can decide if they</p> |
|
|
|
<ul> |
|
|
|
<li>should familiarise themselves with what was discussed, immediately, |
|
|
|
and possibly respond if they have objections, or</li> |
|
|
|
<li>only want to be aware of what was decided, or</li> |
|
|
|
<li>just keep in the back of their head that a meeting happened, that |
|
|
|
notes exist, and where they can find them when they need to refer |
|
|
|
back to them.</li> |
|
|
|
</ul> |
|
|
|
<blockquote> |
|
|
|
<p>Once you do meetings right, you no longer need most of them.</p> |
|
|
|
</blockquote> |
|
|
|
<p>The funny thing is that once you adhere to this standard — and I |
|
|
|
repeat, having a full and detailed record is <em>the only acceptable |
|
|
|
standard</em> for video meetings – you’ll note that you can actually skip |
|
|
|
the meeting altogether, use <em>just</em> a collaboratively edited document |
|
|
|
<em>instead</em> of your meeting notes, and remove your unnecessary |
|
|
|
synchronization point.</p> |
|
|
|
<h3>Video calls for recurring team meetings</h3> |
|
|
|
<p>There is one thing that I do believe video calls are good for, and |
|
|
|
that is to use them for <em>recurring</em> meetings as as an |
|
|
|
opportunity to feel the pulse of your team.</p> |
|
|
|
<p>Obviously, a distributed team has <em>few</em> recurring meetings, because |
|
|
|
they are synchronization points, and we’ve already discussed that we |
|
|
|
strive to minimize those. So the idea of having daily standups, sprint |
|
|
|
planning meetings, and sprint retrospectives is fundamentally |
|
|
|
incompatible with distributed teams. <em>Aside: in my humble opinion, |
|
|
|
this is also why using Scrum is a terrible idea in distributed teams — |
|
|
|
not to mention <a href="https://youtu.be/f-ULT_Ic4qk">that it’s a terrible idea, |
|
|
|
period.</a></em></p> |
|
|
|
<p>However, having perhaps one meeting per week (or maybe even one every |
|
|
|
two weeks) in a video call is useful <em>precisely for the aforementioned |
|
|
|
reasons</em> of being able to pick up on nonverbal clues like body |
|
|
|
language, posture, facial expressions, and tone. If people are |
|
|
|
stressed out or unhappy, it’ll show. If they are relaxed and |
|
|
|
productive, that will show too.</p> |
|
|
|
<p>Note that these meetings, which of course do follow the same rules |
|
|
|
about agenda and notes, are not strictly <em>necessary</em> to get the work |
|
|
|
done. The team I run has one one-hour meeting a week, but whenever |
|
|
|
that meeting conflicts with anything we skip it and divide up our |
|
|
|
work via just the circulated coordination notes, and that works |
|
|
|
too. The meeting really serves the purpose of syncing emotionally, and |
|
|
|
picking up on nonverbal communications.</p> |
|
|
|
<h2>Briefing people</h2> |
|
|
|
<p>Whenever you need to thoroughly <strong>brief a group of people on an |
|
|
|
important matter,</strong> consider using a <strong>5-paragraph format.</strong></p> |
|
|
|
<ol> |
|
|
|
<li>Situation</li> |
|
|
|
<li>Mission</li> |
|
|
|
<li>Execution</li> |
|
|
|
<li>Logistics</li> |
|
|
|
<li>Command and Signal</li> |
|
|
|
</ol> |
|
|
|
<p>This is a format as it is being used by many armed forces; in NATO |
|
|
|
parlance it’s called the 5-paragraph field order. Now I’m generally |
|
|
|
not a fan of applying military thinking to civilian life — after all |
|
|
|
we shouldn’t forget that the military is an institution that kills |
|
|
|
people and breaks things, and I say that as a commissioned officer in |
|
|
|
my own country’s army —, but in this case it’s actually something that |
|
|
|
can very much be applied to professional communications, with some |
|
|
|
rather minor modifications:</p> |
|
|
|
<ol> |
|
|
|
<li>Situation</li> |
|
|
|
<li>Objective</li> |
|
|
|
<li>Plan</li> |
|
|
|
<li>Logistics</li> |
|
|
|
<li>Communications</li> |
|
|
|
</ol> |
|
|
|
<p>Let’s break these down in a little detail:</p> |
|
|
|
<ol> |
|
|
|
<li>Situation is about what position we’re in, and <strong>why</strong> we set out |
|
|
|
to do what we want to do. You can break this down into three |
|
|
|
sub-points, like the customer’s situation, the situation of your |
|
|
|
own company, any extra help that is available, and the current |
|
|
|
market.</li> |
|
|
|
<li>Objective is <strong>what</strong> we want to achieve.</li> |
|
|
|
<li>Plan is <strong>how</strong> we want to achieve it.</li> |
|
|
|
<li>Logistics is about what budget and resources are available, and how |
|
|
|
they are used.</li> |
|
|
|
<li>Communications is about how you’ll be coordinating among yourselves |
|
|
|
and with others in order to achieve your goal.</li> |
|
|
|
</ol> |
|
|
|
<p>Note that people <em>always</em> have questions on what they’ve just been |
|
|
|
briefed about. They just might not think of them straight away. Give |
|
|
|
people time to think through what you’ve just briefed them on, and |
|
|
|
they will think of good questions. So always have a follow-up round at |
|
|
|
a later time (2 hours later, the following day, whatever), for which |
|
|
|
you <em>encourage</em> your group to come back with questions.</p> |
|
|
|
<p>Also, use that same follow-up for checking how your briefing came |
|
|
|
across, by gently quizzing people with questions like</p> |
|
|
|
<ul> |
|
|
|
<li>“by what date do we want to implement X?”, or</li> |
|
|
|
<li>“Joe, what things will you need to coordinate with Jane on?”</li> |
|
|
|
</ul> |
|
|
|
<p>This gives you valuable feedback on the quality of your briefing: if |
|
|
|
your team can’t answer these questions, chances are that you weren’t |
|
|
|
as clear as you should have been.</p> |
|
|
|
<h2>Pinching the firehose</h2> |
|
|
|
<p>Finally, I want to say a few words about what I like to call pinching |
|
|
|
the figurative firehose you might otherwise be forced to drink from:</p> |
|
|
|
<blockquote> |
|
|
|
<p>The amount of incoming information in a distributed team can be |
|
|
|
daunting.</p> |
|
|
|
</blockquote> |
|
|
|
<p>When you work in a distributed team, since everyone is on their own |
|
|
|
schedule and everything is asynchronous, you may be dealing with a |
|
|
|
constant incoming stream of information — from your colleagues, your |
|
|
|
reports, your manager, your customers. </p> |
|
|
|
<p>There is no way to change this, so what you need to do is apply your |
|
|
|
own structure to that stream. What follows is not <strong>the</strong> way to do |
|
|
|
that, but <em>one</em> way, and you may find another works better for |
|
|
|
you. But you will need to define and apply <em>some</em> structure, otherwise |
|
|
|
you’ll feel constantly overwhelmed and run the risk of burning out.</p> |
|
|
|
<blockquote> |
|
|
|
<p>Consider using the <strong>“4-D” approach</strong> when dealing with incoming |
|
|
|
information.</p> |
|
|
|
</blockquote> |
|
|
|
<p>(Hat tip to David Allen)</p> |
|
|
|
<p>There’s a defined approach for doing this, which I learned about from |
|
|
|
reading <a href="https://en.wikipedia.org/wiki/David_Allen_(author)">David |
|
|
|
Allen</a>’s <a href="https://www.goodreads.com/book/show/1633.Getting_Things_Done">Getting |
|
|
|
Things |
|
|
|
Done</a>. I |
|
|
|
don’t know if Allen invented the 4-D approach or whether someone came |
|
|
|
up with it before him, but that’s how I know about it.</p> |
|
|
|
<p>In his book, David Allen suggests to apply one of the following four |
|
|
|
actions to any incoming bit of information:</p> |
|
|
|
<ul> |
|
|
|
<li><strong>Drop</strong> means read, understand, and then archive. It’s what you use |
|
|
|
for anything that doesn’t require any action on your part.</li> |
|
|
|
<li><strong>Delegate</strong> is for things that do require action, but not from |
|
|
|
you. Make sure that it gets to the right person and is understood by |
|
|
|
<em>them</em>, and make a note for follow-up.</li> |
|
|
|
<li><strong>Defer</strong> means it needs doing, and it’s you who needs to do it, but |
|
|
|
it doesn’t need doing <em>immediately</em>. Enter it into your task list |
|
|
|
(to use a very generic term, more on this in a bit), and clear it |
|
|
|
from your inbox.</li> |
|
|
|
<li><strong>Do</strong> are the (typically very few) things that remain that need to |
|
|
|
be done <em>by you, and immediately.</em></li> |
|
|
|
</ul> |
|
|
|
<p>Following this approach does not mean that you’ll never be overwhelmed |
|
|
|
by the amount of information that you need to process. But it’ll |
|
|
|
greatly reduce that risk.</p> |
|
|
|
<h3>“Drop” rules</h3> |
|
|
|
<p>“Dropping” things doesn’t mean ignoring them. You still have to read |
|
|
|
and understand what’s in them, and be able to find them later. So:</p> |
|
|
|
<ul> |
|
|
|
<li> |
|
|
|
<p>Never delete things (except spam).</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>Only archive them in a way that that keeps them retrievable in the |
|
|
|
future.</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>If there something isn’t understandable to you, think it through and |
|
|
|
look for clarification.</p> |
|
|
|
</li> |
|
|
|
</ul> |
|
|
|
<h3>“Delegate” rules</h3> |
|
|
|
<p>Delegation obviously requires that there is a person you can delegate |
|
|
|
to. This is <em>not necessarily</em> someone who reports to you; indeed, it |
|
|
|
might be someone <strong>you</strong> report to. (You might be asked to deal with |
|
|
|
something that you have no control over, but your manager does.) So:</p> |
|
|
|
<ul> |
|
|
|
<li> |
|
|
|
<p>Find the right person that can get the task done.</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>Preemptively send them <strong>all</strong> the information that you think they |
|
|
|
might need (and that you have access to), rather than relying on |
|
|
|
them to ask.</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>Ask them to acknowledge that they have received what they need.</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>Make a note to follow up to see if they need anything else, and |
|
|
|
follow through by seeing the task to completion.</p> |
|
|
|
</li> |
|
|
|
</ul> |
|
|
|
<p>Within your own team, <strong>you only ever delegate tasks, not |
|
|
|
responsibility.</strong></p> |
|
|
|
<blockquote> |
|
|
|
<p>Tasks without follow-up and follow-through are a waste of people’s |
|
|
|
time.</p> |
|
|
|
</blockquote> |
|
|
|
<p>Do not delegate, or even define, tasks that you are not prepared to |
|
|
|
follow through on. If you handwave “everyone use encrypted email from |
|
|
|
now on,” and you’re not even prepared to make that work for your own |
|
|
|
email account, you might as well just leave it.</p> |
|
|
|
<p>And if you do proclaim an objective or rule and <em>then</em> you find yourself |
|
|
|
unable to see it through — <em>this happens,</em> and is no sign of |
|
|
|
ineptitude or failure — then loudly and clearly rescind it. It’s far |
|
|
|
better for you to visibly backtrack, than to be perceived as someone |
|
|
|
whose pronouncements are safe to ignore.</p> |
|
|
|
<h3>“Defer” rules</h3> |
|
|
|
<p>Deferring simply means that because something you need to do doesn’t |
|
|
|
need doing <em>immediately,</em> you can do it at a time that suits your |
|
|
|
schedule.</p> |
|
|
|
<p>This means that you’ll need to</p> |
|
|
|
<ul> |
|
|
|
<li> |
|
|
|
<p>add the task immediately to some sort of queue (for email, this can |
|
|
|
be a folder named “Needs Reply”),</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>make sure to go through that queue at a later time to prioritize |
|
|
|
(ideally, right after you’re done with your “Do” tasks, which we’ll |
|
|
|
get to in a second),</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>absolutely ensure that you make time to go back and actually do your |
|
|
|
prioritized tasks, at a time you consider convenient.</p> |
|
|
|
</li> |
|
|
|
</ul> |
|
|
|
<h3>“Do” rules</h3> |
|
|
|
<p>And finally, there’ll be your “Do” tasks — stuff that <em>you</em> need to |
|
|
|
do, and do immediately.</p> |
|
|
|
<ul> |
|
|
|
<li> |
|
|
|
<p>Tell people that you’re doing them, because you’ll want to be |
|
|
|
uninterrupted. Update your chat status, put some blocked time in |
|
|
|
your calendar.</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>Make sure you’ll be uninterrupted. For email, turn off all your |
|
|
|
notifications.</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>Plow through all the undropped, undelegated, |
|
|
|
undeferred items in your inbox until it’s empty.</p> |
|
|
|
</li> |
|
|
|
</ul> |
|
|
|
<h2>But what about the watercooler?</h2> |
|
|
|
<p>The entirety of this talk, up to this point, has focused on |
|
|
|
professional communications. And among people unfamiliar or |
|
|
|
unexperienced with work in a distributed team, it is often accepted |
|
|
|
that teams can communicate well “professionally.” </p> |
|
|
|
<p>However, they frequently ask, “what about watercooler chats? What about |
|
|
|
the many informal discussions that happen at work while people are |
|
|
|
getting some water or coffee, or sit together over lunch? There’s |
|
|
|
always so much communication happening at work that’s informal, but is |
|
|
|
extremely beneficial to everyone.”</p> |
|
|
|
<blockquote> |
|
|
|
<p>Office workers often don’t habitually externalise information. A |
|
|
|
distributed team that tries that won’t last a week.</p> |
|
|
|
</blockquote> |
|
|
|
<p>Firstly, many companies where information exchange hinges on coffee or |
|
|
|
cafeteria talk simply don’t give a damn about externalising |
|
|
|
information. Sure, if 90% of your company’s knowledge is only in |
|
|
|
people’s heads, you’re dead without the lunchroom. </p> |
|
|
|
<p>But if the same thing happens in a distributed team, it never gets off |
|
|
|
the ground. So, if you have a team that’s functional and productive, |
|
|
|
<em>because it habitually externalises information,</em> the absence of |
|
|
|
chit-chat over coffee has zero negative impact on information flow.</p> |
|
|
|
<p>However, you may also be interested in the completely non-work-related |
|
|
|
talk that happens over coffee, that simply contributes to people’s |
|
|
|
relaxation and well-being.</p> |
|
|
|
<blockquote> |
|
|
|
<p>People working in distributed teams are often introverts. Or they |
|
|
|
simply choose to have their social relationships outside of work.</p> |
|
|
|
</blockquote> |
|
|
|
<p>I know this might shock some people, but there are plenty of people |
|
|
|
who can make a terrific contribution to your company, but who dislike |
|
|
|
the “social” aspect of work. They might thrive when being left |
|
|
|
alone, with as little small-talk as possible, and ample opportunity to |
|
|
|
socialize with their friends and family, away from work.</p> |
|
|
|
<p>But if you do have people on your team that enjoy having an entirely |
|
|
|
informal conversation every once in a while, there totally is room for |
|
|
|
that even in a distributed team. All you need to do is agree on a |
|
|
|
signal that means “I’m taking a break and I’d be happy to chat with |
|
|
|
anyone who’s inclined, preferably about non work related things” (or |
|
|
|
whatever meaning your group agrees on). </p> |
|
|
|
<p>This could be</p> |
|
|
|
<ul> |
|
|
|
<li>a keyword on IRC,</li> |
|
|
|
<li>a message to a specific channel, or</li> |
|
|
|
<li>(if you want to get fancy) a bot that updates your group calendar |
|
|
|
when it receives a message with a particular format.</li> |
|
|
|
</ul> |
|
|
|
<p>However, as a word of caution, I’ve actually done this with my team |
|
|
|
before, and it didn’t catch on — for the simple reason that we almost |
|
|
|
never took breaks that happened to overlap. But that doesn’t rule out |
|
|
|
that it works on <em>your</em> team, and also there’s always the remote |
|
|
|
possibility that two or more people on your team might like to |
|
|
|
schedule their breaks concurrently.</p> |
|
|
|
<p>What you can <em>also</em> do, of course, is have a channel in which you can |
|
|
|
discuss completely random things that are not work related. And if the |
|
|
|
rule is that confidential or company-proprietary discussion topics are |
|
|
|
off-limits there, the channel might as well be public. It might even |
|
|
|
be Twitter.</p> |
|
|
|
<h2>The antithesis: ChatOps</h2> |
|
|
|
<p>I do want to mention one other thing for balance. There is a complete |
|
|
|
alternative framework for distributed teams working together, and it’s |
|
|
|
what people refer to as ChatOps.</p> |
|
|
|
<p>To the best of my knowledge, the first company to run ChatOps on a |
|
|
|
large scale <em>and talk about it publicly</em> was GitHub, <a href="https://youtu.be/NST3u-GjjFw">back in |
|
|
|
2013</a> in a |
|
|
|
<a href="https://www.rubyfuza.org/">RubyFuza</a> talk by <a href="https://twitter.com/jnewland">Jesse |
|
|
|
Newland</a>.</p> |
|
|
|
<p>If a distributed team operates on a ChatOps basis, the interactive |
|
|
|
text chat is where absolutely everything happens. </p> |
|
|
|
<ul> |
|
|
|
<li> |
|
|
|
<p>Everyone lives in chat all the time, and all issues, alerts and events are |
|
|
|
piped into the chat.<br> |
|
|
|
Everything is discussed in the chat, and everything is also |
|
|
|
<em>resolved</em> in the chat.</p> |
|
|
|
</li> |
|
|
|
<li> |
|
|
|
<p>Such a system relies on heavy use of chat bots. For example, if an |
|
|
|
alert lands in the channel, and the discussion then yields that the |
|
|
|
proper fix to the problem is to run a specific Ansible playbook, |
|
|
|
you send an in-chat bot command that kicks off that playbook, and |
|
|
|
then reports its result.</p> |
|
|
|
</li> |
|
|
|
</ul> |
|
|
|
<p>And this is of course very laudable, because it resolves a major issue |
|
|
|
with using chat, which is the classic scenario of something being |
|
|
|
discussed in a chat, someone else then going away for a bit and then |
|
|
|
coming back saying “I fixed it!”, and nobody else actually |
|
|
|
understanding what the problem was. </p> |
|
|
|
<p>If you make everything explicit and in-band, in becomes easy, in |
|
|
|
principle, to go back to a previously-solved problem that reappears, |
|
|
|
and replay the resolution.</p> |
|
|
|
<blockquote> |
|
|
|
<p>When does ChatOps make sense? Here’s a hint: It’s called Chat<strong>Ops</strong>.</p> |
|
|
|
</blockquote> |
|
|
|
<p>So can this make sense? Yes, absolutely. Under what circumstances |
|
|
|
though? I maintain that this is best suited for when your work tends |
|
|
|
to be inherently linear with respect to some dimension. For example, |
|
|
|
if your primary job is to keep a system operational versus the linear |
|
|
|
passage of <em>time,</em> ChatOps is an excellent approach.</p> |
|
|
|
<p>And keeping complex systems operational over time is the definition |
|
|
|
of, you guessed it, ops. So ChatOps may be a very suitable |
|
|
|
communication mode for operations, but it’s highly unlikely to be |
|
|
|
efficient as a generic mode of communication across distributed teams.</p> |
|
|
|
<p>And even then I posit it’s difficult to get right, since you’ll have |
|
|
|
to curb channel sprawl and threading and other things, but’s that’s a |
|
|
|
whole ‘nother talk and indeed a talk for another <em>speaker,</em> because I |
|
|
|
don’t lead an ops team.</p> |
|
|
|
<h2>To summarize...</h2> |
|
|
|
<p>So to summarize, here are my key points from this talk, in a nutshell |
|
|
|
— please make these your key takeaways.</p> |
|
|
|
<ul> |
|
|
|
<li>Distributed teams are better than localized teams — not because |
|
|
|
they’re distributed, but because they’re asynchronous.</li> |
|
|
|
<li>Avoid anything that makes a distributed team run synchronously.</li> |
|
|
|
<li>Use less chat.</li> |
|
|
|
<li>Have fewer meetings.</li> |
|
|
|
<li><strong>Write. Things. Down.</strong></li> |
|
|
|
</ul> |