One of the hardest learnings from managing distributed teams for several years is that there is no single “best” environment for everyone on the team. Offices will eventually reopen with every individual strategizing what comes next. Some can’t wait to be in a busy, humming office five days a week. Others are cutting the cord entirely, moving away from big cities, and going fully remote. Some prefer a mixture of several days of the week in an office, the rest elsewhere.
It’s a challenging situation because managerial decisions around work environments can favor some and upset others. So over the years of managing engineers all over the country and across multiple time zones, I’ve established three simple rules to set expectations around work. Obviously companies have their own policies, so consider these more idealized or preferred for when there’s flexibility:
I define core work as anything that directly affects an engineer’s output and velocity. This activity includes hands on development, technical architecture, code reviews, and meetings to discuss engineering strategy and team prioritization.
The right environment for core work is when everyone is on the same playing field as full time remote employees. That may sound awkward if almost everyone on the team happens to be in the same office. How is someone “remote” when they work from headquarters five days a week?
The mental shift is in treatment and planning. You no longer assume an environment where everyone is face to face but instead optimize for scenarios where engineers could be anywhere. Maybe that engineer is in the office today. However, we plan for a situation where tomorrow they won’t be.
Asynchronous tools have to be the sources of truth. Engineers should be able to access engineering content at virtually any time or location. Jira is already an industry standard, and is, quibbles with UI aside, the hub for every team I’ve managed to track engineering progress. Google Docs (or your collaborative note taking app of choice) is also important for meeting notes, decision making, agendas, and much more. With Figma or other coworking-based design tools, you can leave comments directly on designs to drive discussion and setup action items.
Meetings, while generally unpopular among most engineers, are still necessary to drive work forward. We cluster our meetings such that they are equally accessible by the largest share of the team during usual work hours for their time zone. For a team split across the U.S. or Canada, this means mid-morning meetings for PT and early afternoon meetings for ET.
We optimize a meeting’s structure to ensure remote participants are the priority. I’m a fan of “silent reading” sessions: everyone reads a centralized document and leaves comments to voice their opinion. After a fixed time or when comments taper off, a moderator starts a discussion based on the written commentary. Alternatively, individuals chime in by raising hands or virtually with a moderator setting the speaking order. Alternatively, we establish a rule so that when one person finishes they call on the next participant.
I’ve also seen teams force every meeting participant in a remote-first setup. Live office attendees dial into the meeting invite with their webcams and headphones. That may sound awkward on paper, but it effectively guarantees that all participants are on equal footing.
Avoid “free for all” meetings where anyone can jump in at any time. They greatly disadvantage those who aren’t physically in the meeting room as it’s hard to know when to interject over video. In the most extreme cases, remote attendees can effectively disappear from the conversation.
Even when everyone’s physically together, open ended debate can be good to avoid. Techniques that structure speaking time – silent readings, raising hands, moderation – can advantage those who wouldn’t feel comfortable speaking otherwise.
The environment outside of what I’ve defined as core work still has a large impact on an engineer’s morale and effectiveness. For example, day to day development may be “the same” in a bustling office or solo in a private office at home. But everything around the code – noise, a commute, small talk, social outings, meals, physical setup, face time with coworkers – varies widely.
Even though many companies can close the gap, the environment can never be the same in and out of a shared office. Some workers love virtual hangouts and social hours but, for many, the events are no substitute for meeting face to face. Furthermore, every environment has its pros and cons to which engineers can react differently. Some thrive off bonding from getting meals and drinks after work with their coworkers. Others would exchange that in favor of a shorter commute, a quieter desk, and more time around their family and friends outside of work.
So unlike with an engineer’s core work, my goal isn’t to flatten or otherwise replicate the same experience for the entire team. Background noise or drinks after work don’t get the same push for equality the way that code reviews or a development setup does. I like having “hangout” meetings on the calendar for the team to virtually socialize, but attendance is optional. I realize not everyone gets the same utility from these events. Likewise, I wouldn’t force coworkers on a casual in person lunch to include a virtual member in the mix via webcam.
Instead, I downplay strict equality in favor of empathy: I want my team to know that I genuinely care about them as people beyond developers and that they feel welcome around their coworkers. 1:1s are a critical space for this, where I stray off of purely work topics to check with them. I’ll ask about their weekend, family, friends, and hobbies. Work life balance is another good subject to cover, the regular hours worked and when it’s time to step away for a while. I also find the margins of team meetings (stand ups, all hands) when people join and wrap up the call can be a good opportunity for small talk.
Even though empathy is a good tactic, certain social events are tricky. Remote workers that aren’t able to participate live (or conversely, feel peer pressure to attend even if they’d rather not) might purport questions of fairness.
For me, there’s a dividing line between planned events set up and funded by the company versus those that happen organically. Coworkers breaking into small talk around an individual’s desk or grabbing drinks spur of the moment are a good example of the latter. It’s a natural byproduct of physical proximity and social norms. Empathetic rules fall into place here: those in a physical office will experience those more spontaneous events. Engineers who work outside the office won’t as much (though they may have their separate virtual hangouts to form connections), and that’s ok.
But holiday parties, team celebrations over a big launch, and offsites are different situations. Once the event involves significant company funding and setup, I like striving for equal treatment regardless of physical location. While business travel has budget considerations, it’s ideal to send everyone to a centralized location to connect face to face at least a few times a year. When budget or schedules can’t work, I like to switch to remote friendly events to maximize participation.
Regardless of where or when an engineer performs their job, their productivity is dependent on the right equipment. The fundamentals remain the same for engineers in or out of an office: fast hardware for coding and compilation, large external displays to maximize screen real estate, fast internet, and in most cases laptops over desktops to shuttle work across multiple locations.
However, equipment needs grow as a team shifts from working in one central location to many. Instead of having a desk, chair, and display combination in one location, there may have to be multiple sets. High quality headphones and external microphones or headsets become essential tools as in person communication migrates to video conferencing. Internet speeds and bandwidth have to ramp up to handle live video; one bad connection on a group call can torpedo an entire meeting.
The net result means companies (or individuals) will have to spend more readily on equipment for distributed teams to stay productive. Even with the optimizations I’ve talked about earlier in this post, good equipment is a baseline. You can have the best asynchronous sources of truth, but the wrong internet connection or desk chair will get in the way.
Then there’s the subject of proper background noise and privacy during a video chat. A lot of this is subjective, with some highly productive in an open floor plan filled with people while others require total silence. But there are universal norms: noise shouldn’t be a distraction for others on a call. Select projects can’t happen in public environments like cafes and coffee shops to expose company secrets or private information. Such norms may mean keeping work at home to a spare office, bedroom, or quiet corner of an apartment. A centralized office requires building up enough quiet spaces (conference rooms, phone booths) to make video calls easy. Alternatively, a change in etiquette is in order such that kicking off a call out in the open with the right headphones, mic, and low voice is ok.
I like giving engineers flexibility for their preferred work location, but bad equipment can be a forcing function for change. For example, someone may love working from home, but their slow internet connection makes video calls a drag. An obvious solution could be switching from wifi to a hardwired connection or paying more for faster internet bandwidth. If those tweaks don’t solve the problem, over the long run it may be necessary to find a different work location.
Alternatively, someone likes heading to the office but the open floor plan is noisy with few available conference rooms. The easy solution is a good set of headphones and office neighbors that don’t mind the occasional call. But if that doesn’t work, at least for meeting heavy days, it may be best to work from home.
My preferred guidelines have been tested and refined over several years, but not every practice will work for every engineering team. Furthermore, the transition from centralized to distributed work has a learning curve. For teams and organizations new to distributed work, it can be helpful to introduce new standards over time instead of all at once; engineers have to ease into their changed workflow. Nevertheless, regardless of the exact changes a team adopts, it’s essential to recognize that distributed work requires a large paradigm shift. Going back to “business as usual” won’t cut it; adoption of new rules and standards is essential.