When text-only communication worked

Way back in the mists of the 2000s, I worked on a project with a guy in Melbourne. Now, I used to get to the office early because I liked driving my Alfa Romeo fast before the traffic built up, and he tended to stay a bit later than usual in his office, but that still meant at best around an hour of overlapping collaborative time.

Yes, in the 2000s; before widespread video calling, before headsets and webcams were standard issue, before our office even had VoIP telephony so calling someone in Australia would require a business case and managerial sign-off.

What we got was an hour of text chat on Office Communicator, the version of MSN Messenger where you can't even put a bat emoticon in your name without HR telling you off.

And yet... it worked.

Using nothing more than a few kilobytes of text per day my Antipodean colleague was able to host and configure a new-to-them system and I was able to add the features he needed without running into chaos or some glacial schedule where one of us would get 20 minutes into the workday and then have to wait another 23 hours because we realised we needed something from our counterpart.

Hard Limitations

Try this today and you'll barely get a day in before someone is telling you, "pick up the phone" or "just get on a video call" as if high-bandwidth synchronous communication is the only successful way to transfer information humans have ever invented and all other options are inferior as opposed to, say, specialised for particular tasks.

But we didn't have those options. They were too expensive, too "this person is not in my time zone", or too doesn't-exist-in-wide-usage-yet.

So we figured out how to make that text-only window comprising 1/24th of the day work for us. Which went something like this -

Batch up all the questions before they become blocking.
Ask with context - "I'm trying to get the polygons loaded for the map display, right now I have the table of geographical units to aggregate areas exported but haven't gone any further, how do I run the polygon generation tool?" rather than just "how do I run the polygon generation tool?"
Look beyond the current problem - "I think I'm good with the steps listed after that, but I'm not sure how you then link the aggregated areas to the polygons associated with them"
Answer with the expected path - "you do x, y and z for getting polygons loaded, I guess next you'll be calculating the vehicle registration statistics?"
Share known pitfalls - "some people doing this run into problems with the input geography being too complex, if that happens you'll need to thin it by doing this."
Re-read everything. 3 hours later when you get a weird error is the time to go back and be reminded of that point about complex input geography, or when you're adding a feature to go back and remind yourself what the person is trying to do with it.

Those specifics don't really matter though, unless you're also working on a tool to process monthly-delivered vehicle registration figures into SVG maps because it was the 2000s and that sort of thing was state-of-the-art back then. What matters is that we were both aware we'd get this one hour then be on our own until the following day, and we needed to get enough knowledge exchanged to get through another seven hours apiece.

There was no, "I can just keep asking if I misunderstand this". We were both aware we needed to produce a little batch of text messages that would sit in our IM client and tell us everything we needed to know. It gave us a focus which is hard to match in an environment where 16/7 availability of people is assumed and there is no such thing as "already busy with something else".

One oddity from a modern perspective is that we were saving the questions for the time we were both online. I suspect this was our version of Communicator not allowing you to send messages until both parties were online rather than a conscious decision. It saved on the inevitable "how do you..." followed by "oh wait, nvm" followed by "actually, I do have a problem" of doing things live but I do wonder if we missed stuff having to batch questions in that way and only got through it because we were working in, "well, you either figure it out or you're out until tomorrow" mode.

Still, being able to refine questions over time did help us make good use of that hour where all we did was effectively Corporate IRC.

Dedication's What You Need

I can't overstate how important it was that this time was dedicated. IM tools in an office context were in their infancy, and so we weren't trying to do this while managing DMs from two separate people and being tagged in 3 different channels and also on a video call because hey, if you're just chatting with someone on IM that's a thing you can multitask, right? We were doing a conscious, present-in-the-room piece of deep work where my colleague was thinking "what do I need to know for tomorrow to succeed?" and I was thinking, "which of the things you're doing are going to need development work beyond what already exists in the system and what do I need to know in order to build that?"

Fail to do that and you've just wasted a day. There's no, "oh, but I can just ping them later if I missed something" because the person is not contactable and, in the case of one of those time differences, asleep.

This is how the synchronous communication part of otherwise asynchronous work should happen. Not, "I'm going to half-assedly reply to 5 different conversational threads with whatever gets the person off my back for the next few minutes while half-assedly trying to do whatever I can do of my day job while constantly distracted", but "we are going to spend a dedicated window of time on working out what information we need to transfer and the richest possible way to do that."

(The joy now is we have so many more tools to do that, from screen sharing to live coding environments, but the principle of setting aside dedicated time and really thinking about what would be the most effective thing to do is lacking.)

I'm not even particularly against video calls, indeed in a remote environment I think they're a vital part of building social cohesion and getting those rich non-verbal cues. However, I think their current use as a universal panacea of the "nobody ever got fired for suggesting two people get on a video call" variety is counter-productive. Especially when the actual problem is nobody ever thinking about what these tools are for and how they can be used beyond the surface-level addictive, "hey, I can interrupt anyone at any time and they'll probably respond!"

Long

Well, that was a long and pointless story which didn't go anywhere, although that Australian deployment was a success and we certainly improved the documentation and some of the unhappy path feedback from our tooling. Er, you should probably be thinking more about the full range of your communication tools, how they can be used, and whether "everyone available at every point" is truly effective, or just convenient. And really what I'm selling is people getting together to work on one specific thing without distractions, and in this case it just happened to be information sharing.