×
Advertisement

Turing Distinguished Leader Series

Advertisement

How would you advise managers with distributed teams to think about the time zone issue?

Advertisement

Darren Murph:

Time zones are a curse to the existence of any company. Unfortunately, time zones are tough even for co-located companies. If you’ve ever worked in a co-located office in Seattle with coworkers in Singapore, you know what I’m talking about. The solution is to move the work to an asynchronous workflow wherever possible. And so, if there is anything that can be reduced to a document and written and ingested in a way that is more suitable for a wider range of time zones, make sure you do that.

You need to be clear with your direct reports on how to work. Empower and enable them with the right tools to collaborate asynchronously across time zones. And although email is asynchronous by nature, it is not a great tool for asynchronous work because it is inherently silent. Getting transparency on email is hard.

At GitLab, we use the GitLab platform for company-wide collaboration. If you’re a leader, make sure there’s a tool in place, a central hallway where work can be done so that you break those chains of synchronicity wherever possible.

Jonathan Siddharth:

What tools do you recommend in your toolkit for shifting people from synchronous to asynchronous?

Darren Murph:

Of course, I recommend GitLab, especially if you’re already using it for engineering; Use it for collaboration across the organization. Dropbox Spaces is an excellent, centralized hallway. Miro and Mural are phenomenal instruments. Figma is another one for those looking for a tooling design and collaboration space. If you’re trying to stand out company handbooks, Almanac.io is a great tool because they have structured approvals, which is similar to a merge request. Try to simplify your tool stack as much as possible.

In GitLab, our handbook states that every work meeting must have a Google doc agenda attached to the inbox. So the organizer of the meeting has to draft the agenda, observations of the attendees and expected results and then send the calendar invitation.

That way, if you’re not attending the meeting, you can at least immediately Tap on the document, add a reference, add your question, and then have someone verbalize that question for you. Could and document the answer. This way, you are able to contribute asynchronously, even in a process that might normally be synchronous.

Jonathan Siddharth:

Speaking of GitLab, it looks like you can use it for a variety of use cases that go beyond code collaboration and co-hosting. Can you share some of the primary use cases of using GitLab for company collaboration?

Darren Murph:

Yes, we use it throughout the company. So, even if our designers don’t design illustrations in GitLab, they will share them in something like Figma. But we will still start the GitLab issue within the design team to collaborate on the Figma Details. And it enables transparency.

Even people who don’t work in design or performance can jump into the GitLab platform and have visibility into their team. In addition, this approach lets them provide input and feedback. And so, when you use it as a collaboration tool, we believe it becomes beneficial outside of engineering.

We want to actively work to remove silos, and a great way to do that is to opt for a collaboration platform like GitLab and funnel your work through it.

Jonathan Siddharth:

Do you have any best practices you would recommend for remote-first companies in their use of Zoom and similar video conferencing software? And it seems that for a lot of these; It’s not just tools; It’s also how you use them and what’s the scaffolding process around it.

Darren Murph:

Yes, it should be a combination of both. We use Zoom. It’s a very boring solution, but it scales well. And so if we have a company as a whole and we need 1300 people on a Zoom call, it’s going to live up to that.

But speaking of using common means in unusual ways, if we have to have a work related meeting, we will take the meeting as 25 minutes instead of 30 or 50 minutes instead of 60.

Now Google calls these quick meetings, but that’s kind of back to how we use it. We cut the meeting after 25 minutes instead of 30 so you’re not back to back with the schedule. You’ll undoubtedly meet someone experiencing Zoom fatigue, and it can be as simple as adding five or 10 minutes here and there to relieve people.

I think we are at the beginning of the innings, so watch the space. Some amazing innovations are emerging out of that.

Jonathan Siddharth:

that sounds great. And earlier, you mentioned how you like to set up these coffee chats with people within the first month.

Leave a Comment