IBM, Fix Your Remote Work Program in 3 Easy Steps
Ok, so we’ve made a fair bit of fun at the expense of IBM’s idiotic decision to get rid of remote work. But we understand that people having to leave their job is no laughing matter. So what we did was, we got in touch, we offered to make it work. There was no interest. We weren’t charging, either!
But the thing is, IBM isn’t doing this due to remote work not working. It’s only a stealthy, sneaky way to get shed some employees to reach a better financial position. So, of course, they aren't interested in our help. It’s not that they think that remote work can’t work. It’s that they don’t want to make it work. They’re joined by other tech giants rapidly approaching obsolescence.
Take Marissa Mayer from Yahoo! You know, the guys that are not Google. She sacked their remote work program. Why? To improve “speed and quality”. To enjoy the “decisions and insights from hallway and cafeteria discussions.” Several high-profile companies followed suit. Like IBM, they would rather sacrifice their employees than learn how to manage them.
We are still prepared to help. So here’s a sort of an open letter to IBM, detailing how to make remote work… work. We’ll go through three key points that any company looking to excel at remote work should focus on. And we’ll provide concrete examples of how to go about doing so. We’ll even recommend some apps that we use at Distant Job.
There should be no excuse for bad remote performance after reading this mini-guide. Unless you’re a corporate dinosaur that’s been flipped off by Steve Jobs. In that case, yeah, you might need to work at it a bit more.
Step One: Improve Communication With Your Remote Developers
And between them, too. Communication is one of the three basic pillars of successful remote work. The others being coordination and culture. They are intertwined, of course.
Sharing information that is complex or personal requires much more than words. You need to observe body language, hear tone and inflection, and be able to see what you’re talking about. For those purposes, video chat is the next best thing to talking face-to-face.
Then there are the small, non-urgent requests. These are best made via e-mail, instant messaging, or chat platforms like Slack.
This is not as common sense as you might believe. Many people instinctively default to their preferred method of communication. This leads to misunderstandings, conflict, and lost productivity.
So don’t leave this to personal preference. As Extreme Ownership author Jocko Willink is fond of saying: “Discipline equals freedom.” Give your employees structure so they can work freely within that structure.
Meetings need to be on video-chat. No exceptions. At Distant Job, we’ve used Skype for a long time. It works OK. But recent experiments with Zoom have pleased us and we’re switching to it.
Do anything that’s descriptive over video chat. Anything that requires discussing, too. Save Slack and e-mail for reports, touchdowns, check-ins, and close-ended questions.
“Do you want the homepage header to be Blue 1 or Blue 2?” is fine in Slack. “How should we organize the homepage call-to-action blocks?” requires a video conference. And screen sharing!
The frequency of communication also matters. Developers need to provide regular updates. They need to be fast in responding to messages. And they must be available at important times. This is especially true when colleagues are located in different time zones. Doing this reduces the likelihood of roadblocks and builds trust.
This is why we recommend that everyone work the same hours, on your company’s timezone. If you want to give your remote developers more leeway, that’s fine. That makes you a pretty cool boss. You have the Distant Job Seal of Coolness (TM). But make sure there’s significant time zone overlap.
Step 2: Managers Must OWN Coordination Between Remote Developers
For projects to be successful, everyone should be working in harmony. But people often don’t know what others are doing and how everything fits together into a larger routine. Actually, this happens in many co-located teams. But the danger is bigger when the entire team is virtual.
This is where managers must completely embrace the concepts of extreme ownership. Managers should articulate the mission in a clear manner, of course. Next, assign roles and responsibilities, create detailed project plans, and establish performance metrics. Now document it all in a repository that’s off site and easy to access.
Refer to our post about tacit knowledge within distributed development teams. The team must write everything down. Systems must be set in stone and adhered to. Same concept as we outlined for communication above.
Having processes isn’t enough. Managers must model and enforce them until they are completely assimilated. They also need to check how well team members adhere to protocol. Otherwise, they’ll revert to old habits.
If you’re a manager and you’re assigned a team with one or more remote workers, assume that the whole team is remote. Don’t slack like the dinosaurs at IBM. Own your management. Document everything, keep track of people and what they’re doing, connect all the dots. Performance will skyrocket.
We use Trello to make sure everyone is on the same page. We also keep core, always-updated documentation on Google Docs.
Step 3: Use Culture As The Glue That Holds Distributed Teams Together
Remote developers rarely meet with their teammates face-to-face. So they tend to focus on tasks and ignore the team. This works for a while. But it doesn't sustain performance over the long term. For this, you must develop a culture to foster engagement.
People need to trust each other. Addressing communication and coordination problems will promote trust based on competence and reliability. But affective trust is trickier to build. You know you can trust a team member to write awesome code; but would you trust him to go pick up your kid at school?
If you have the budget, one way to do this is to bring team members together for short periods of time. Automattic and Buffer do this on a regular basis, to great effect.
But we understand that it’s a minority that can afford this. Part of what makes remote developers appealing to businesses is that they are top talent at affordable prices. So instead, try scheduling regular informal calls — either one-on-one or as a group. Automattic’s Matt Mullenweg is a staunch believer in one-one-ones.
They aren't as effective as spending time together in person. But they have the same objectives. They let remote team members recognize each other as human beings. They let them understand how everyone is feeling, and learn about their lives.
It will feel awkward at first! But in the long term, building personal connections will lead to greater engagement. With this, comes better performance.
At Distant Job, we try to get into the interests of everyone on the team. We all have different tastes. Some are wannabe guitarists, others are video game freaks, and some enjoy reading a lot. We don’t get a lot of overlap, but we are all aware of what each other enjoys, and often banter about it. Our #general in Slack has more of the above than work stuff - that we keep in the specialty channels.
Remote Work / Distributed Development Is The Future, Adapt Or Lose Talent
Remote work is here to stay. It gives businesses access to top talent while saving massive amounts of money. And it gives top developers the freedom and quality-of-life they crave.
Companies like Yahoo or IBM are trying to reverse the trend. They would be better off reevaluating and addressing the issues that led them to ban remote work. Otherwise, they’ll go the way of the dodo. As they won’t be able to keep the talent they need to stay relevant.
Don’t let your business become an irrelevant dinosaur. Get in touch with us at Distant Job to learn how to hire and manage top talent today - at a fraction of the cost.