Tag Archives: Murph

Turing Distinguished Leader Series: Darren Murph Head of Remote at GitLab Part II

Turing Distinguished Leader Series: Darren Murph Head of Remote at GitLab Part II

Turing Distinguished Leader Series: Darren Murph Head of Remote at GitLab Part II | DeviceDaily.com

 

Hi, everyone! Thank you for the great response to our Distinguished Leader Series!  Here’s the second part of my talk with GitLab’s Head of Remote, Darren Murph.  If you missed part 1 of this conversation where we dig into how GitLab runs a multi-billion dollar remote-first company — you can find it here

Jonathan Siddharth:

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

Darren Murph:

Time zones are the bane of any company’s existence. Unfortunately, time zones are hard for co-located companies as well. If you’ve ever worked at a co-located office in Seattle with colleagues in Singapore, you know what I’m talking about. The solution is to shift work to asynchronous workflows wherever possible. And so, if there’s anything that can be reduced to a document and written down and ingested at a time that is more suitable for a wide array of time zones, make sure that you do that. 

You’re going to need to be clear with your direct reports on ways of working. Empower and enable them with the right tools to collaborate asynchronously across time zones. And although email is asynchronous by nature, it’s not a great tool for asynchronous work because it’s inherently siloed. It’s tough to get transparency on email. 

At GitLab, we use the GitLab Platform to collaborate company-wide. If you’re a leader, make sure that 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 in your toolkit do you recommend for people to shift 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 entire organization. Dropbox Space is an excellent, centralized hallway. Miro and Mural are phenomenal tools. Figma is another one for those looking for tooling design and collaboration space. If you’re trying to stand up a company handbook, Almanac.io is a fantastic tool because they have structured approvals, which is very similar to the merge request. Try to simplify your tool stack as much as possible. 

At GitLab, it is written in our handbook that every work meeting must have a Google doc agenda attached in the inbox. So the meeting organizer has to draft up the agenda, the attendees’ overview, and expected outcomes, and then send the calendar invite. This way, if you’re not attending the meeting, you’re able to at least immediately click on the document, add context, add your questions, and then someone can verbalize that question for you and document the answer. This way, you’re able to contribute asynchronously, even to a process that may usually be synchronous. 

Jonathan Siddharth:

Speaking of GitLab, it sounds like you can use it for various use cases that go beyond code collaboration and co-host. Can you share a bit of the primary use cases that you use GitLab for in the company for collaboration?

Darren Murph:

Yeah, we use it across the company. So, even though our designers don’t design illustrations in GitLab, they would share those in something like Figma. But we would still start a GitLab issue within the design team to collaborate on Figma links. And that enables transparency.

Even those who don’t work in design or demonstration 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 recognize that it becomes advantageous outside of engineering. We want to work to remove silos actively, and a great way to do that is to choose a collaboration platform like GitLab and funnel your work through it.

Jonathan Siddharth:

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

Darren Murph:

Yeah, it has to be a combination of both. We use Zoom. It’s a pretty boring solution, but it scales well. And so if we do have a company all-hands and we need 1300 people on a Zoom call, it will stand up to that. But speaking of using common tools in uncommon ways, if we have to have a work-related meeting, we will have the meeting as either 25 minutes instead of 30 or 50 instead of 60. 

Now Google calls these speedy meetings, but this kind of goes back to how we use it. We cut the meeting after 25 minutes instead of 30 so that you aren’t back to back with the schedule. You will undoubtedly meet someone experiencing Zoom fatigue, and it can be as simple as adding five or 10 minutes here and there to give folks a breather. I think we’re in the earliest of innings, so watch the space. Some amazing innovations are coming out of that.

Jonathan Siddharth:

That sounds great. And earlier on, you mentioned how you like to set up these coffee chats with people within the first month to help new joiners get fully onboarded. Are there any tools or products that you found that solve that use case well?

Darren Murph:

If you want to randomize it, Donut is a great solution. But I would also say, create a community or topical channels if you’re a leader and have access to administrative space within Slack. If you create spaces like hiking or cooking, or location channels, you’ll find that people join sub-channels relevant to them. And then, once they’re in that sub-community, it becomes easier to set up coffee chats and make connections.

Jonathan Siddharth:

That’s super helpful. Can you share your advice to founders running distributed teams today? For example, how do you pull off a happy hour with a globally distributed group of people in different time zones?

Darren Murph:

Yeah, so I’ll give you an example of a 24-hour virtual pizza party. So, as a celebration for a certain team, we had a 24-hour virtual pizza party. We had our employees enjoy pizza with their families, bill it back to the company, and share their pictures. It’s a straightforward solution, but it reinforces that groupthink global demeanor. Instead, we should celebrate the differences among us, including the best in residence in geography.

You don’t have to plan a virtual happy hour, especially a synchronous one every week, to feel like you’re bringing your team together. This practice is a bit paradoxical, but the more you let go of your team and empower your people to go out in their communities and then share those videos and photos with the team, the closer the individuals on your team will get because they see each other’s real personalities, and what makes them unique. 

Jonathan Siddharth:

That sounds great! Do you use Slack for messaging, or do you use some other tool?

Darren Murph:

We use Slack, but we expire all of our Slack messages after 90 days, and this is a very simple forcing function so that we don’t do long-form, deep work in Slack. When we realize incubation is happening in a Slack channel, we create a GitHub issue and port the conversation so that the work continues over there. Slack is just a medium to share different GitLab links to ensure that we continue to work in the most transparent way possible. 

Jonathan Siddharth:

And what is the repository of knowledge at GitLab?

Darren Murph:

It won’t surprise you that we use the GitLab Handbook. And we use the merge request functionality so that anyone in the company can propose any page in the company handbook. So for companies already using GitLab, it is possible to build your company handbook. Also, as I’ve mentioned earlier, Almanac.io is a great place to start.

Jonathan Siddharth:

That’s good to know. Regarding one-on-ones that happen between managers in a fully distributed team, do you have any best practices for managers on how to conduct them?

Darren Murph:

Yeah, so every one-on-one has a Google doc, an ongoing agenda. And what’s great about this is it allows topics that you didn’t get to cover to stay there still, and then you’re able to move it up to the next date so that things don’t just fall away. 

A side note here is that our team does async weeks where we decline all internal meetings, and we move everything async every six weeks. We do this with one-on-ones as well. 

The last thing I’ll mention here is to make sure that the one-on-one is the direct reports meeting. I see many leaders have one-on-ones where they direct the entire game, which goes back to being a director. So they see a one-on-one as an opportunity to list out all of the to-dos for their direct report. But the problem with that is it doesn’t give the direct report a medium to voice their challenges or ask questions or talk about career development.

So the manager has to be very careful not to override the one-on-one. Instead, the manager should see it as an opportunity to unblock instead of just loading someone up with to-do tasks.

Jonathan Siddharth:

That’s super helpful. Have you seen any good tools that people use for recording and transcribing meetings to make a synchronous meeting count some of the benefits of an async meeting, or do you intentionally avoid doing that?

Darren Murph:

There are some tools. Firefly is one. Then there is Otter, of course. I know many sales teams use Gong, an excellent tool for analyzing those calls and helping sales teams make recommendations for changes in their behavior. I’m in favor of leveraging technology to make lives easier. However, some of those tools can be a bit finicky because they are just raw transcription tools. So sometimes they miss the context or create sentences that didn’t happen, so they’re not perfect, but they’re certainly better than no documentation at all.

Jonathan Siddharth:

As many companies think about their post-pandemic work strategy, what is your advice for previously office-centric companies? Now they’ve remained distributed. Their teams, probably a majority of the people at the company, prefer to be the work from home—work from anywhere culture. What is your advice for leaders at those companies on how they think about their post-pandemic work strategy?

Darren Murph:

So I mentioned a few points here, but before I do that, I would say go to allremote.info and download the remote playbook. That is the blueprint for making this transition, and we recently refreshed it specifically for the use case you just mentioned. 

We want to help leaders build long-term sustainable remote work environments. A lot of leaders are keeping some office space, and they’re attempting to go hybrid. There’s this thought that hybrid is going to be the best of both worlds. But without a lot of intentionalities, it can easily become the worst of both worlds. 

You do not want to foster an environment where a subset of your organization works office-first. And a subset works remote-first. You want everyone working remote-first because that makes your company more resilient to future crises. And if you do maintain an office, you want to make sure that it’s not the epicenter of power. You don’t want people going there to rub shoulders with the right people or advance their careers. I realize this sounds crazy, but if they go to the office, they should only go there to work remotely from the office and treat it more like a coworking space. 

The last piece of advice I want to reiterate to leaders is if you are reopening an office, I would advise you not to go back at all, and definitely don’t be the first one back in the office, because it sends the signal that the office is still the epicenter of power. And if you have spent the last 18 or 24 months building remote muscle through the pandemic, all of that will evaporate if you send the signal that everyone needs to be in a physical space, else they are risking their career. So leaders need to be mindful of the signals they are sending.

Jonathan Siddharth:

And what have you seen so far, Darren, regarding companies that run surveys in their team? I’m curious what you’ve seen from your vantage point about what the employees prefer. And is that any different from what management tends to choose in a choice like this?

Darren Murph:

We just surveyed almost 4,000 people globally. You can search for GitLab’s Remote Work Report and dig into all sorts of data, but I want to call out a few points here that I think are pertinent to this conversation.

One in three people said that if their work refused to allow flexibility coming out of COVID, they would just find another job. And I think this number will only increase as we move out of the pandemic. People at large already enjoy the freedom and autonomy of remote work during the worst of times. 

So from a talent acquisition and retention standpoint, there’s no going back for many people. Organizations are going to have to answer the question as to what is their stance on workplace flexibility. 

The other thing is this disconnect between people saying that they love remote work and saying that the organization hasn’t yet built the infrastructure to support them. So people are raising their hands and saying: “I love remote work,” but they’re also saying: “My company feels disorganized and unprepared for this change.” So I think this is an excellent opportunity for leaders to acknowledge where people generally want to go and build proper infrastructure for them to work in a remote setting.

Jonathan Siddharth:

Based on what you just said, what can a company do to be best in class to prepare for a remote-first workforce?

Darren Murph:

Honestly, the first thing you can do is hire a Head of Remote or put someone in charge of the remote transition. There’s nothing more important to the company than signaling that this is a serious and long-term consideration. Most importantly, if someone is in charge of the transition, they can then be responsible for going around the organization and pressure testing, all of the things that we mentioned earlier.

The other element I would recommend here is to invest in L & D. You have to remember that not everyone will know how to work well in a remote setting. Not every manager fully understands the nuances of managing in a remote environment. And for some of these people, you will have to upskill and teach them. So L & D organizations are spinning up things like editorial workshops to teach people how to communicate well through the written word. In a remote setting, that’s a critical skill. So the organization will be on the hook for upskilling employees, which will be setting them up for success when the future is remote.

Jonathan Siddharth:

That’s super interesting. When you hire global talent worldwide, people come from different cultures and backgrounds; there are societal, cultural norms for people growing up in other countries. Is there something GitLab does intentionally to bridge that cultural gap to get people more comfortable with a particular way of working?

For example, in some cultures, people are not comfortable speaking out against a manager’s deadline. They don’t feel comfortable debating and disagreeing with an idea and brainstorming. Is this something that you observe, and if so, is there anything you do at GitLab to bring together people from different cultures to do a more standard way of working?

Darren Murph:

There are two things you can do here. The first is to be explicit in powering, recommending, and encouraging things like dissent. We have a sub-value that’s titled ‘The Value in Dissent.’ So we write down that you are empowered and encouraged to show disagreement. I understand that having it written down for some cultures isn’t enough because perhaps the employee has worked in an organization where dissent was encouraged. Still, when they tried to do it, the outcome wasn’t so positive for them. So now they’re a bit hesitant to believe what’s written down. 

In that case, I think the only next thing you can do is reinforce it by leadership. It pretty much has to be top-down. Ensure that your senior leaders are open to dissent and open to that kind of feedback from people. Make sure that you share it as transparently as possible so that when other people see things like this happening, they’ll perhaps be more comfortable and more likely to read into it themselves. It’s critical from a cultural standpoint to lead by example. Because to your point, not everyone’s going to believe a document. 

Jonathan Siddharth:

I’ve seen you reference these written-down values a few times in our chat. So how does the company go about compiling this handbook of values?

Darren Murph:

It started a long time ago, and it’s a living, breathing document. We made hundreds of updates and iterations to the GitLab Values page in 2020. So for many companies, values were written one time by the founding team, and then they just collect dust in the corner.

I would encourage teams to build it with a tool like GitLab or Almanac and empower the entire team to contribute feedback to make it more robust. If it’s a living, breathing document, people are more likely to adhere to the values. In truth, culture is just a barometer of how well values are adhered to. So a lot of teams will wonder: “How do I create culture?”. Well, write great values, and the culture will be how well those values are adhered to.

Jonathan Siddharth:

I think that’s a great place to start, Darren. This conversation was super helpful and valuable for all leaders trying to think about building successful remote-first companies. Thank you so much for taking the time to have this conversation with me today. And what’s the place where people who enjoyed listening to you can learn more, where should they go?

Darren Murph:

Thank you for the forum. Thanks all for your attention. Be sure to check out allremote.info to download the playbook that I’ve authored for GitLab. You’ll find me on LinkedIn, Twitter, the usual places at @DarrenMurph.

Watch the complete interview.

Image Credit: provided by the author, jonathan siddharth; thank you!

The post Turing Distinguished Leader Series: Darren Murph Head of Remote at GitLab Part II appeared first on ReadWrite.

ReadWrite

Jonathan Siddharth

Jonathan is the CEO and Co-Founder of Turing.com. Turing is an automated platform that lets companies “push a button” to hire and manage remote developers. Turing uses data science to automatically source, vet, match, and manage remote developers from all over the world. Turing has 160K developers on the platform from almost every country in the world. Turing’s mission is to help every remote-first tech company build boundaryless teams. Turing is backed by Foundation Capital, Adam D’Angelo who was Facebook’s first CTO & CEO of Quora, Gokul Rajaram, Cyan Banister, Jeff Morris, and executives from Google and Facebook. The Information, Entrepreneur, and other major publications have profiled Turing. Before starting Turing, Jonathan was an Entrepreneur in Residence at Foundation Capital. Following the successful sale of his first AI company, Rover, that he co-founded while still at Stanford. In his spare time, Jonathan likes helping early-stage entrepreneurs build and scale companies. You can find him Jonathan @jonsidd on Twitter and jonathan.s@turing.com. His LinkedIn is https://www.linkedin.com/in/jonsid/

(49)

Turing Distinguished Leader Series: Darren Murph Head of Remote at GitLab

Turing Distinguished Leader Series: Darren Murph Head of Remote at GitLab

Turing Distinguished Leader Series: Darren Murph Head of Remote at GitLab | DeviceDaily.com

 

Hi, everyone. Thank you for the great response to the first round of Turing’s Distinguished Leader Series (with Henrik Hussfelt, Director of Engineering at Proxy).

Today I’m talking with Darren Murph, the Head of Remote at GitLab. Darren may be the first person ever to hold the Head of Remote Title at a top-tier tech company. GitLab has a reputation for excellence with remotely distributed teams. In the discussion below, Darren reveals many of the techniques GitLab uses to make remote work hyper-productive.

Darren Murph, Head of Remote at GitLab

Jonathan Siddharth, Turing:

Welcome to Turing’s Distinguished Leader Series, Darren. We are conducting this series to bring together leaders who are experts in building distributed teams.

So, Darren, you are the Head of Remote at GitLab, a 1300 person globally distributed company built entirely in the cloud. Could you share a little bit about how you became Head of Remote and got to embracing remote work and distributed teams?

Darren Murph: 

Yeah, so I’ve been working across the remote spectrum for over 15 years my entire career. And the last two years at GitLab are my first stint in an all-remote company. I remember when I first heard about GitLab. I learned it had absolutely no company-owned offices, and it was an intentional decision. I had to sit down and process this. I thought, how in the world has this company already invented a future that I always longed for? I felt like I was pushing the remote work rock uphill, and now COVID has greatly democratized that conversation. I’m excited that more of the world is eager to learn more about doing it well. 

I joined GitLab in July of 2019 as their Head of Remote. To my knowledge, this was the first-ever remote head anywhere in the world. And now, many other companies like Dropbox and Facebook are also hiring directors of remote work. Companies realize that this is a massive change in how they operationalize their company, convert tacit knowledge, and apply it to documented knowledge. So it’s been an enjoyable journey. I’ve worked across marketing, comms, and organizational development. I do a bit of all of that in this role. It’s very cross-functional.

Jonathan Siddharth:

What advice would you have for the founder who’s building her company in a remote-first fashion on day zero? What is something that they should think about? For example, let’s say this is a founder who has raised $ 2 million, currently based in the Bay Area, and they would like to go the GitLab route and go fully remote-first. What advice would you have for some of them?

Darren Murph: 

So step one would be to pressure test any of your company’s workflows and cultural underpinnings to make sure that they are resilient and work outside of the office. By default, a lot of workflows are office-first. If you have something you rely on, you should audit that and convert it to a remote-first workflow. There are plenty of excellent tools that allow you to do that collaboration digitally so that even if you choose to go into an office, you would still go about your work in a remote-first fashion. 

And this kind of ties into point two: trying to set the tone from a cultural standpoint. Things aren’t about the physical location; they’re about how and not where work gets done. I’ll share with you one other thing that we have seen work for us and has had beneficial compounding interest over the years: document early, create a company handbook, create a single source of truth. When you’re just two or three or ten people, you don’t need to document, but be mindful that it’s easiest to start this when you have a small team. It pays dividends down the road. 

Tacit knowledge is a fundamental part of building the company culture. In a remote setting, you can’t afford to have tacit knowledge. You have to document how you work with one another explicitly. So it’s not enough to just say we value collaboration at our company. You have to write down what collaboration looks like. GitLab’s values are open source, and they’re available online.

We explicitly say that we collaborate with short toes. This phrase means that anyone can contribute to anyone else’s domain without the fear of stepping on someone’s toes, as we all have short toes. This practice enables people who have never met face-to-face to gain a shared understanding of how you want to treat each other and how work gets done. 

By systematically documenting things, you can imagine how this would make even a co-located team have greater cohesion. You would need fewer check-ins by each other’s desks to get a status update even within the office. These principles make the transition seem less daunting. These are just great business principles, but a lot of it is part tooling and part culture. You have to have both of those tracks going in the same direction for maximum effectiveness.

Jonathan Siddharth: 

That makes a lot of sense. Is there any function or role that you found to be challenging to work within a remote context?

Darren Murph:

That depends on the industry. For example, sales and customer service cannot necessarily be negatively impacted by remote, but they have less flexibility than some of the other roles. For example, many of these customer service roles must require working from a particular hour to a specific hour, so there’s less ability for them to work a nonlinear workday. 

What I’ve seen in sales is that a lot of deals happen because relationships exist. Around the globe, there are some cultures where an in-person moment at some point in the sales process is critical in ensuring that the transaction happened. So certainly, there will be areas where in-person moments are beneficial.

I would offer this to companies who are all remote and don’t have any headquarters: make sure that you invest in travel and leverage appropriate touchpoints to ensure that those in-person elements are there. The goal here is not to create a company where people never see each other. The goal is to create a company where you empower people to do their best work around the globe and also invest in getting people together when it makes sense for the business.

Jonathan Siddharth:

It makes a lot of sense. Is there something that you would recommend to ensure that the people in the company formed the right relationships with each other?

Darren Murph:

You have to be very intentional about formal communication. There are a couple of things right off the bat that you should implement. One is an onboarding buddy. Make sure that every new hire is paired with someone that’s already in the company and knows a bit about what their role entails, and have them proactively set up coffee chats with key stakeholders.

The other thing is to consider getting teams together every quarter or bi-annually. So make sure that you invest in getting people together. The other thing I’ll mention here is the link between transparency in work and the sense of belonging. And so what we have seen is that if you provide greater transparency and visibility to work that’s happening, it’s easier for employees to feel like a part of a team. 

I try to look at everything through the lens of opportunity and abundance instead of scarcity and fear. And this is one critical example of a remote workplace being far more amenable in a co-located space. When everyone is on the same proverbial floor and just one click away, it is much easier to be transparent. 

Jonathan Siddharth:

That makes a lot of sense. And do you recommend having any kind of structured in-person meetups happening at a certain cadence, or do you kind of let it happen organically, where the understanding is, if you want to meet, the company will pay for travel transportation, etc.? How much of it goes bottoms-up vs. some top-down recommendations on bridging the remote, in-person development?

Darren Murph:

We’ve seen top-down set the tone, which fosters a lot of bottoms-up contributions. So I would recommend getting the entire team together once a year if at all possible. As your team scales, this will become more difficult, but do everything you can to bring people together, at least, optionally. It makes a big difference. You’ll find that a remote team’s in-person time is best used for cultural building and rapport building. 

You can certainly do some strategy work during those times, but make sure you leave a lot of open space for people just to do their thing. Especially in sales and customer support, who interact a lot together: try to get them together quarterly or bi-annually. You want to make sure that if someone asks you: “Hey, when’s the next time we’re getting together?” you at least have an IOU together. 

Jonathan Siddharth:

It’s great to hear that. What advice would you have for a people manager who will be managing a distributed team for the first time? What should she keep in mind to handle this globally distributed team spanning multiple times? What are some common pitfalls people usually encounter when managing a distributed team for the first time?

Darren Murph:

At GitLab, we have a substantiating value called ‘Assume Positive Intent.’ Remote managers must assume positive intent, no matter what. 

The second thing is to assume that the company is the issue. For many managers, if they’re sensing underperformance or maybe some apathy, it’s their default to believe that the problem is the employee. But in fact, you should assume that the company isn’t providing adequate documentation for adequate upskilling and workplace benefits.

The reason why I would recommend approaching it from the company-first angle is that, if indeed there is a void in documentation or the collaboration flow, if you solve it for one person, you now have solved it for the entire organization. So it is a much more scalable way to look at challenges. 

The last thing is, all remote managers should see themselves less as a director and more as an unblocker. First, you have to create a psychologically safe atmosphere where your direct reports are comfortable coming to you with challenges. And then, your goal is to unblock them as fast as possible so that they can run as fast as possible. There’s a fantastic book called High Output Management that you can refer to for the same. An unblocker as a manager seeks to unblock as many people as possible to create massive amounts of leverage for the people who report to them.

In Conclusion

My conversation with Darren Murph will continue with part two of this interview where we discuss how GitLab uses GitLab, the best way for remote-first companies to use video communications like Zoom, and how you should deal with the tricky issue of timezones. You don’t want to miss it!

The post Turing Distinguished Leader Series: Darren Murph Head of Remote at GitLab appeared first on ReadWrite.

ReadWrite

Jonathan Siddharth

Jonathan is the CEO and Co-Founder of Turing.com. Turing is an automated platform that lets companies “push a button” to hire and manage remote developers. Turing uses data science to automatically source, vet, match, and manage remote developers from all over the world. Turing has 160K developers on the platform from almost every country in the world. Turing’s mission is to help every remote-first tech company build boundaryless teams. Turing is backed by Foundation Capital, Adam D’Angelo who was Facebook’s first CTO & CEO of Quora, Gokul Rajaram, Cyan Banister, Jeff Morris, and executives from Google and Facebook. The Information, Entrepreneur, and other major publications have profiled Turing. Before starting Turing, Jonathan was an Entrepreneur in Residence at Foundation Capital. Following the successful sale of his first AI company, Rover, that he co-founded while still at Stanford. In his spare time, Jonathan likes helping early-stage entrepreneurs build and scale companies. You can find him Jonathan @jonsidd on Twitter and jonathan.s@turing.com. His LinkedIn is https://www.linkedin.com/in/jonsid/

(49)