In case you don’t follow me on Instagram: I don’t exactly live in a tech hub.
The Marilyns are low-key Internet famous
An odd thing happened recently: Someone asked me about my best practices for working remote. Doesn’t everyone know this stuff? I’ve never worked on a team without remote contributors. My first tech job was piloting the Durham office for a Toronto middleware vendor. Later, I ran a consulting project for a Texas client with contributors in Wisconsin, North Carolina, Florida, and Massachusetts. And I’ve launched startups where everyone worked from home. It’s like asking a fish how they deal with getting wet.
But the more I thought about it, the more I realized: This isn’t about remotework. It’s about all work. How do you collaborate and solve big problems? Well, in my humble opinion, it’s the same whether you share an office with a developer or a farm dog.
She couldn’t even diagram a B-tree in the interview. I don’t know why we hired her.
Write Well and In Detail
Regardless of profession: As soon as you leave an office or conference room, your ideas go with you. High-quality, detailed writing is the only way to stay present long after you’re gone.
I was once embedded in a partner’s product team as they worked with new offshore developers on the next release of their flagship software. Product followed the process they’d always used successfully: Frequent customer meetings leading to requirements which were discussed in regular conference with (English-Fluent) Development. However, no one stopped to consider that US Healthcare is weird and has its own vocabulary. E.g., a co-pay is not a co-insurance payment.
The features were wrong in strange, unpredictable ways. The release was pushed back an entire year.
Product didn’t know that Dev didn’t know what they didn’t know. Being in the same building five days a week wouldn’t have changed anything. There are plenty of American developers who have no idea how US Healthcare works. However, careful, detailed writing could have. Check out this comparison of detail between paragraph and a slide by Steven Sinofsky:
The whole thread is terrific, and he really breaks it down his annotated version. I highly recommend it.
If It’s Not Checked In, It Doesn’t Exist
Back when I was building a Sales Engineering team and rolling out sales support infrastructure, we had some growing pains.
First, some of our reps were always reluctant to use the CRM, preferring to store everything in unstructured MSWord documents on their laptops. They said things about being more comfortable or faster with their own system, but they also seemed worried about losing control.
I’m pretty sure that anxiety was misplaced. The CRM was configured to support and empower strategic selling. Our #1 Rep ‘[lived] in there’. Can you imagine the improvement in our pipeline if they’d all been on board?
Another issue was reps requesting collateral over email after it all went online. Sometimes they’d say, “Yeah, but is that one really the latest?” and I’m ashamed to admit we had to break ourselves from, “No, here’s the latest,”
Can you imagine Ops emailing, “So is the latest in Git REALLY the latest?” and Dev replying, “Oh, no, that’s a version back, here I’ve attached my local code to this email,” ––Madness, right?
Using a shared information repository (whether it’s Salesforce or Github or Confluence) isn’t about reducing autonomy, providing reliable storage, or preventing the loss of information. It’s about process quality. But everyone has to buy in for it to work. Say it with me: If it’s not checked in, it doesn’t exist.
Keep Your Meetings Sharp
Now pay attention, 007
People seem to pay better attention in physical rooms than they do on remote calls (or at least they pretend better). We’ve all had the experience of catching someone remote doing something else while dialed into a meeting.
That’s a symptom of unimportant, unfocused calls and not a sign that remote work is inherently distracted. Are your meetings making significant decisions and producing meaningful change? Or are you having meetings that just lead to more meetings? Are attendees limited in scope? Or are you inviting everyone who “might want” to be there?
Given the rich array of asynchronous communication tools (Email, Slack, Texting, etc.), it is more important than ever to treat synchronous meetings like the expensive things they are. Organizers should keep meetings uncommon and significant, while attendees should pay as much attention as they would to Q demonstrating a laser wrist watch.
Respond Quickly
People need questions answered and problems resolved. Early in my career, a mentor explained that the best thing I could do to supercharge a team was to keep no one waiting. “Get every request out of your court as soon as possible,” he said. A delayed response can halt an entire sale or sprint.
These requests come in a lot of forms: Emails, texts, calls, JIRA items, etc. This is less an endorsement of Inbox Zero, and more an exhortation for leaders in general (and product leaders, especially) to practice triage with the requester in mind. It’s one more email for you but it’s making quota and keeping her job for Jenny McSales.
The flip side is that relying on proximity as a responsiveness crutch hurts the organization. Bursting into someone’s office demanding an answer creates task-switching costs (Johnny delays Jenny’s answer) and fails to deliver the detailed writing people need. That’s why many impromptu office chats end with a request for a follow-up email as documentation.
Build a Self-Managing Culture
In my 20s, I ran an international organization devoted to thwarting evil.
OK, so it was a World of Warcraft raiding guild and not the Peace Corps. But look: It was a 200+ person all-volunteer organization scattered across three countries (US, Korea, Australia) and five time zones fielding a tightly coordinated 40-person team several nights a week. 100% distributed.
A 40-person raid, but not my guild. Source: Eight Years In Azeroth
We didn’t have the luxury of looking over anyone’s shoulder. To make things worse, Raids are so complex and demanding that they have little overhead for management (look at that screenshot!). We needed high competence and quick thinking from everyone involved. And we constantly gained or lost people (it’s a game not a job) so we had to onboard new people quickly.
We did a lot of things to make the guild successful. Most of it won’t fit here. But I’d note three things for the purposes of this post:
We recruited smart, friendly people who fit our culture.
We developed a peer-to-peer system of in-game training and coordination.
We promoted solely from within and kicked (i.e., fired) jerks ASAP.
Our goal was a self-managing culture. One that would achieve success with or without anyone, including ourselves. We taught good decisionmaking through discussion and by modeling it in our actions. The intent was to avoid overworking ourselves, but we were ultimately successful far beyond that: Long after we retired, they were still raiding.
(By the way, I never met 90% of our members in person.)
Visit With Your Team
When I was growing up (before cell phones), extended family often unexpectedly showed up at our door. They were in the neighborhood and came by in case we were home. Mom would tell me to stop what I was doing and come “visit with your Grandmother,” (or Aunt, Uncle, etc.).
If you look in the dictionary, ‘visit with’ is defined as a synonym for conversation, but that’s too broad. A conversation can have many purposes, but this kind of visit is specifically for renewing (and enjoying!) a relationship.
Steve Jobs famously wanted the Pixar bathrooms to be inconvenient to spur chance meetings. He didn’t get his way, but it’s interesting to consider: By renewing and strengthening connections, he hoped to generate novel ideas.
Whether you’re in an office or spread across the map, you need to visit withthe team. Chance meetings are OK, but intentional visits are even better. Here are a few things I’ve done in the past:
Ran a weekly seminar series on Healthcare for on-site Dev and TechOps where we discussed industry quirks while sipping Beers and EANABs
Met with our sales team quarterly to discuss pipeline status, product positioning, and upcoming features; i.e. How To Win.
Went on-site with our top customers to see our product in the wild and hear them talk about what worked and didn’t.
Organized a weekly ‘Fight Night’ for our World of Warcraft guild where players dueled to learn the game and practice their class.
There’s sometimes a sense of ‘I wish I could skip this’ but it’s always replaced later with ‘Wow, I’m glad I came’. That’s why successful 100% distributed companies like Buffer and Parse.ly hold regular in-person retreats at beautiful destinations. You’ve got to visit with people if you want to work well together.
You Know It To Be True
As noted earlier, I have never been on an all-in-the-same-office team. There were some years where all my developers were local, but then my boss was in Rochester and QA was in Boston. Remote work is just the background for me and it’s not a big deal.
It doesn’t have to be for anyone else, either. If you’re using best practices, it doesn’t matter if you work from an office, a barn, or a boat in the middle of the ocean. You can do great work from anywhere.
In spite of the view, Ivy found the ferry to be terrifying