Improve Productivity with Two Common Sense Rules for Remote Developers
No matter how much FAANG companies like Google, Apple, and Facebook clamor for their employees to head back to the office – remote work is here to stay. Whether it’s fully remote or a hybrid approach, employees enjoy working from home and eliminating their commute. The problem comes from managing these individuals effectively, especially software developers. Remote work makes supervision more difficult since you can’t easily see an employee's in-progress work.
To succeed in this new environment, it is imperative for technical leaders to implement procedures to increase their organization’s overall efficiency. At my company, Invene, we have employees spread across 10 states so we’ve had a lot of trial-and-error when it comes to managing software engineers remotely. Below are two rules I found that substantially increase developer productivity and collaboration.
1. Enforce Consistent Working Hours
This was a mistake Invene learned the hard way. A company must enforce reasonable and consistent working hours on developers. While it is tempting to focus only on output, that’s a bad idea. Development is a team-sport, especially as the company grows. You need your software engineers available to talk to internal stakeholders, customers, and their peers during normal working hours. If they don’t have defined working hours, it quickly becomes a mess to schedule anything or collaborate with the team. Their individual output might be high, but the project will suffer.
Setting hours, especially when employees are in multiple time zones, can be tough, though. We have developers in all four time zones of the US, and we have it easy compared to most companies! Some of our clients have employees in India, the UK, or Australia making coordination difficult.
Since my company is spread across time zones, the best approach I’ve found is to choose a time zone to centralize on. Our headquarters are in McKinney, Texas so we picked central time (CEO privilege!). We target a start time of 8 am CST plus or minus 2 hours. This means all employees should start work sometime between 6am to 10 am CST. This guarantees at least 4 hours of overlap, while allowing developers flexibility and a degree of control over their schedule. It’s not perfect, especially if you have a night-owl on the West Coast, but it’s the best solution we’ve come up with.
Leaders must proactively monitor your employees to ensure they are available during their set work time. I’m not talking about the small things like a doctor’s visit, picking up their kids from school, or running an errand. That’s the benefit of remote work! Developers can easily make up those hours by starting earlier, working later into the afternoon, or an hour extra on Saturday or Sunday. Rather, I’m talking about an individual consistently mismanaging their schedule and having limited availability during regular hours. Their output might be fine, but it could indicate a deeper problem. I’m speaking from experience here. It’s important to be proactive about these issues since you don’t have the benefit of seeing people in-person and catching the small social cues when something might be wrong.
As an executive, it can be tempting to ignore these working hours, but they’re critical to adhere to, no matter how high up you are in the organization. Afterall, leaders of the company set the example for their direct reports and skip-level reports. Employees won’t listen to management that doesn't follow their own rules. It’s okay to work more hours, but executives at least need to be available during reasonable work hours and not off skiing in Colorado (unless on pre-planned vacation).
There are also rare cases where I will make an exception to the rule. For example, one of Invene’s senior developers works from 2 pm to 10 pm CST every day. The only reason I allow this is because his output is phenomenal, he’s consistent about his hours, and if asked, he’ll join an earlier meeting. In my worldview, I think it’s okay to be flexible, but it must be earned first. I know other CEOs who have a no exceptions policy, but my preference has always been “people-first”. If I have a top performer, I’ll jump through hoops to make it work to maximize their output.
2. Use Proper Asynchronous Communication
Instant messengers (IMs) are a critical component of any modern company today. The two most common IMs are Slack and Microsoft Teams. Even though we do a lot of development in Microsoft technologies and products, I’m a huge fan of Slack and happy to pay for the software. For example, the new ‘huddle’ feature Slack rolled out allows my team to quickly hop on a screen share, while previously, we had to open a Zoom. Another feature I like is Slack Connect, which allows Slack to set up shared channels to communicate with each other, when both companies have the software. Slack is so great we rarely use email internally. The problem with IMs is setting it up properly so it’s a boon to organizational productivity, not a hindrance. A big part of this is having appropriate procedures around professionalism, notifications, and statuses.
Since IMs are like text, sometimes employees can forget it’s a professional environment. At my company, we require people to write complete sentences with proper capitalization and punctuation. We found this limits the amount of back-of-forth and streamlines communications. It also sets the proper tone of professionalism and ensures they’re building up strong habits that transfer over when talking to clients. It’s the same reason I’ve banned any memes in public channels.
Oftentimes, employees struggle with notifications and managing them effectively. They forget that IMs are an asynchronous communication platform. Keyword – asynchronous. If someone pings you on Slack, it doesn’t require an immediate response. If the situation needs an immediate response, a phone call would be made. It’s important to be responsive on IMs, though. I tell our employees to generally respond to a Slack request every hour or two. The reason is that engineering requires deep work. It’s impossible to write code when you’re being bombarded every 5 minutes with an IM. On top of this, notifications should be muted after finishing work for the day; it can wait until tomorrow. If it can’t, and it requires an urgent response, they will get a call. I generally ask that on Saturday or Sunday they check notifications once, to make sure they’re not blocking anyone.
The last issue with asynchronous communication is effectively utilizing statuses. They are a way to quickly communicate with others about what is happening. I’ve found the integration between Google Calendar and Slack to be critical for my business. The Slack status now has an icon next to the employee’s name showing when the meeting is done. Another good use of the status feature is for vacations. Even if employees tell their boss and peers when they’re on vacation, it’s easy to forget, which leads to confusion. To rectify this at Invene, we rolled out a policy that before heading on vacation, the person in question should update their status to “vacationing” along with the date they’ll be back. They are also encouraged to mute notifications. Once again, if something is urgent, they will get a call.
Conclusion
Whether companies like it or not, most developers will now work and be managed remotely. As a technology leader, it’s important to have strong procedures in-place to maximize their effectiveness. By enforcing consistent work hours and teaching your team proper asynchronous communication, you’ll increase your organization’s overall development output.
