How to Leverage Distributed Teams to Accelerate your Business

Submitted almost 5 years Ago

Share This Post

I didn't used to be a fan of distributed teams, where people are based in various locations and time zones. In fact, I was firmly in the "everybody here in one location during business hours" camp for quite awhile.

Over time, by necessity, I began being part of and leading distributed teams. This started for other reasons: expertise, availability, or budget. But what started for other reasons I learned can be a competitive advantage if done right and now I'm a big fan of the distributed model. In fact, it's my go to setup for any team I work with.

Here are some tips on what I have learned in practice to make distributed teams be a competitive asset to growing a business. Specifically, ways that it can drive faster time to market, higher quality, and faster time to recovery in the event of problems.

Here are the tips:

1) Have a senior level employee in place at the main business location, as leader for the distributed team.

Make sure they are a permanent part of the team, and this is not an outsourced position. Make sure they are senior enough to have a voice in major decisions - CTO, COO, etc. This person is the single point of responsibility for making this team run well (in a larger organizations, they will appoint sub-leaders). They have responsibility for interfacing with the other senior leaders of the HQ departments, and making sure the team has the resources they need to be successful, and that their contributions are made known.

2) Make the time differences work for you.

Especially for technical teams, you can make team members being located across time zones benefit you and each other.

a) Roll the DevOps workload to avoid employee burnout. Move around the DevOps (software development operations) oversight responsibilities based on the time zones of the team. The last thing you want to do is to have one person responsible for devops all the time every hour every day including holidays. This leads to burnout. Instead, have one person on a team in each time zone rotate onto the schedule. Does a server need to restarted? Can the new build be deployed to staging to suss out any issues?

b) Roll the development and code review process across time zones. Have a primary and secondary point person for each major feature or element in your application. Ideally, these people are in different time zones. For example, Mary is primary in owning the email alert updates. She is in New York, eastern time zone. Joe is secondary on the email alert updates. He is in San Francisco, west coast time zone. Mary makes the needed changes for the release, commits her code, and assigns the PR (pull request) to Joe at the end of her workday. Joe picks this up request and reviews the code (it is still afternoon for him), adds some comments, which are ready for Mary to address and update in the morning, while Joe is still sleeping. The process has been accelerated.

3) Make sure there is overlap in primary work hours of the team by at least 4 hours each day.

A few times I have made the mistake of doing a distributed team arrangement that looked really good on paper (i.e. for budget reasons) then in practice was a disaster. "We can do the daily standup at 3am your time, right?" If you even start a phrase with this conversation, do not pursue this arrangement. Don't. It won't work. Teams need overlapping work hours ideally by a minimum of 4 hours per work day. If they don't have this, questions will go unanswered for too long, items will get blocked, and production slows down.

4) Make sure there is a quarterly meeting in person with the entire distributed team at least once every 4 months.

I know you don't have the budget for this. You need to make it happen, in person, for at least two days, including social activities, three times a year. Knowing how your team members interact in person, their mannerisms, and their personality, goes a long way towards becoming more effective the rest of the time. Why is this? First, there is the obvious team building dynamic. Teams that know each other and have spent time with each other work together better. Also, I have learned there is the phenomenon that subtlety is often lost when communicating with other team members online (and my jokes are not usually funny, which is quite possible). The better you know someone, the more you can pick up on these nuances.

5) Figure out a drumbeat communication that works for your stage company and size of team, and stick to that, even when things get busy.

The default is to do an agile setup with the typical daily standup meeting: what you did yesterday / what you are planning to do today / anything blocking you. Then, short sprints to release. Use all the tools for this that you can find and try them out. Slack and ScreenHero and GitHub are some defaults. Then, do a debrief learning session after each major release: what went well, what needs to be improved, suggestions to do this.

You can start from there and see if your team needs more or less. Less can be a daily or weekly update submitted on the team messaging channel. More can be specific steps and gates for quality and completeness and evening handoffs. The important part is to experiment, try, and iterate with open feedback and discussion.

6) Display the team's accomplishments to each other and the broader company.

Some of my favorite days have been internal demo days, where the team ideally engineering and product management together, demos the most recent release for the entire company. Explain what is new, why it was included, customers using it, and benefit to these customers, anything new or cool from a tech standpoint. Then show a demo! Then adjourn for an all hands party, you've earned it!

These are a few ways to make distributed teams - especially technical teams - work in your favor as a way to accelerate your business, while also boosting quality and efficiency.

Share This Post

Like this post? Star it on GitHub

Star It

See All Blog Posts