In case you didn't know, the Serverless team brings new meaning to the word "distributed". All in all, we span 18 time zones, and our overlapping waking hours are slight.
Getting communication right is hard for teams who are all co-located, and at least 10x more difficult for remote teams like us. It's easy to feel disconnected when you can't interact in person—from not only your co-workers, but from the company vision, too.
One way we tackle this problem is by having bi-annual team retreats. Our most recent retreat was only a couple weeks ago, and communication was our key topic of discussion. How could we make it better?
So we got everyone in a room, and dug in. It made for some tough conversations, but gave us a huge amount of clarity and a stronger foundation for moving forward.
Here’s what we learned that might be applicable for you other remote teams out there.
Radical Candor was required reading for everyone before this retreat.
One of the core tenets of Radical Candor is that you need to meet people where they are, not where you assume them to be. This can mean lots of things, from asking people about their lives, to communicating the honest (hard) stuff in a way that can be best heard by that person. In fact, Radical Candor requires you to say the hard stuff.
The framework is all about honest and caring communication that will spur the company forward. When it came to Serverless as a company, this meant we needed to answer a basic question: how do we all actually prefer to communicate?
We chose to answer this question in a decidedly physical way: we drew a line across the floor.
The line spanned our entire meeting room. One end represented people who prefer asynchronous, written communication; the other represented those who prefer in-person meetings. We then stood on the line, each team member placing themselves roughly where they felt they sit in terms of the their communication preferences.
We each had a chance to say a few words about why we had chosen that specific place on the spectrum.
The results were amazing and intensely personal and humanizing. Hearing everyone explain exactly why they like a certain communication style—or don’t—was eye opening. So, too, was the sheer number of communication tools that we as as team are using (close to 10 on an initial count).
This exercise brought to a light a few epiphanies for us a team.
Communicate about which tools you use (or don't). Don't check the team channel on Slack ever? It's ok, but say it. This doesn’t mean you have to be draconian and land on 1 or 2 tools, just recognize that everyone communicates a little differently.
Assume positive intent (as our VP of Engineering Ganesh put it). Email go unanswered? Assume your colleague didn’t see it because they prefer a different communication mode, and don’t take it personally. Assume they really do want to hear what you have to say.
Communication tools = silos. It’s easy to assume that with every newfangled communication tool we’re all getting closer to communication nirvana. Slack will save the world! Confluence will make us organize our work more efficiently! Asana is flexible enough for all of our needs!
What came out for us was the exact opposite: each communication tool is an opportunity, sure—but an opportunity to create yet another silo that will add more friction. Your colleague who never replies to your emails? They’re a Slack fiend. Feel like you’re in an echo chamber on Github, with your PRs going unnoticed? It’s because your teammate turned off notifications going to their email.
Enact a two-way SLA. Along with positive intent, it can be useful to assume an unofficial two-way SLA policy. This means that if you ask a question, or post a comment and it goes unanswered, follow up in at least one different channel.
We too often use our communication tools to push out content, and we need to remember that they can be really efficient pull tools as well. “Hey, would you mind answering this question I asked?” can go a long way toward healthier communication and happier people all around.
Felix Desroches is a product designer at Serverless
guides-and-tutorials - 04.10.18
Here are some common mistakes people make when authoring Lambda functions with Node.js 8.10.
written by Yan Cui