We love hearing when people outside of GitLab read our Handbook – it's totally public, after all, and it's pretty comprehensive (or a behemoth, depending on your frame of mind). It was even more exciting to hear from James Telfer, of UK Students for the Exploration and Development of Space (UKSEDS) that he read the handbook and had further questions that we'd left unanswered. In particular – what to do when you have neither carrot nor stick when managing remote volunteers?
UKSEDS, a student-run charity that operates around the UK, offering career advice and skills support to students interested in the space industry, borrowed a lot from our handbook when making their constitution.
The internal engagement problem grew after UKSEDS experienced a growth surge and a structural change earlier this year. Specifically, James said:
Project teams are interacting okay with their direct managers but interaction with the wider organization is little to none. While this doesn't directly impact work, we're concerned about the longer-term impact on volunteer enjoyment and retention, both of which are really important to us.
Eliran Mesika, our Director of Strategic Partnerships, agreed to jump on the phone with James to learn more about UKSEDS' particular case and the challenges they faced.
Here are some highlights:
- Having individual responsibilities somewhere public (even internally) is a useful accountability tool, and helps direct team members to the correct person when they have a question.
- Functional group updates presented to the whole company make teams talk more, which results in more organic collaboration.
- Keeping communication on a specific topic within the right issue is essential for keeping everyone on the same page – especially when working asynchronously.
Read on for Eliran's tips.
James: Our work involves hosting skills workshops and conducting outreach, which means traveling to schools and science fairs to tell kids that space is great and they should get involved. We recently restructured by creating a small executive group that meets every week, and allowing volunteer teams to grow larger and meet less frequently. We found that destroyed our ability to connect with the teams and we've started losing people; we've got quite a high attrition rate, which is normal for a charity. But I wondered how you approached this problem? Some of those things like the random Hangouts and the 1:1 chats work great as long as you can pay people for their work time. But with volunteers it's a different problem entirely.
Eliran: I'm actually working with Drupal, and I think your problem is more similar to an open source project, or an open source community behind a project. There is a major difference between volunteers and people who are being paid. Once you're paying someone, you have their attention. Perhaps learning what open source projects do to engage their contributors may be helpful in your case. For now, I can share a bit about what we're doing to keep people engaged and connected to the mission.
We're an open core product, and since its inception the whole behavior and culture of the company has also been open. This extends to everything the company does: from the very technical details of a new feature that is being repaired or created, all the way to our high priorities and strategy, and the actual procedures the company follows, is documented and publicly shared. It is shared within the whole company, and is available all the time.
James: How does that culture extend to individual responsibilities?
Eliran: Expectations and responsibilities are also public. I handle strategic partnerships, and it's pretty much just me doing this, but I can look at what anyone on our whole team is working on, without even having to ask them directly. On our team page, we have everyone's job description linked, along with any specific responsibilities. So if you have frontend developers, maybe one is responsible for the website, and others are responsible for a particular set of features of the community edition, for example. You can understand at a glance who the right person is for what you're interested in, and you can go into any repo and see what they're working on. For the most part when we're talking about procedures, we have the Handbook which describes everything about the administration and culture of the company. It goes into detail even about how to write a shared document that you work on. It also talks about what we do on a regular basis.
James: Can you elaborate a bit on those routine things, like the daily calls?
Eliran: Our daily calls have worked really well for us. They're optional, but we usually get maybe two-thirds of the company joining each day. We have functional updates, where we've divided teams into the various days of the week, and they give an update on what they've completed over the past few weeks, which gives the whole company insight into what the marketing team is doing, what the CI team is doing, and what they're working on next. It really connects you with the whole scope, rather than just seeing your team's goals and your individual goals in a vacuum.
James: So that's using what other people are doing to remind an individual person or team that the greater company exists – it's not so much that they'd be interested in the technical details, but it reminds them they're part of something bigger? Is that the key there?
Eliran: Yeah I think it's very important to give people insight into what other teams are doing, because it's remote. That's really key. Otherwise, it seems like when people are working remotely it's very easy to feel isolated. Having those functional updates forces you out of isolation and connects you with the bigger goal. And on a personal level, it connects you with other people's work. As you said, even if you're not a technical person, you'll still get a high-level understanding of the product or what the objective was. That's great for creating a more cohesive environment, and it's remained the same since I joined.
It's very important to give people insight into what other teams are doing – having functional updates forces you out of isolation and connects you with the bigger goal
We also have a second part of the call where people share what they did last weekend. So once a week you have an opportunity to talk about your personal life, we rotate so everyone shares their experiences. I think that's a very powerful tool to connect on a social level, even if you're not talking with people on a regular basis. Typically you're working with a team of 5-10 people, and you'll be part of a group that's maybe 30 people. So at best you'll know 30 people, and you won't talk to them on a regular basis. You know the regular few people that you talk to, and I think that's very narrow if you're part of a bigger group. But the way that we do these individual stories helps make everyone feel closer.
James: I can see one definite scope for improvement for us, because we haven't been very good at pulling the teams together. They're sort of sandboxed at the moment.
Eliran; I think you'll notice that once teams start talking about what they're doing, obviously all teams have touch points that they've been speaking with others about, but you'll have more organic collaboration. Just by talking about what they're thinking about doing, or trying to do. That's the best case scenario. At the most basic level, you'll get people to be aware of what's going on.
We also have a second type of meeting, which is an open meeting focused on a certain department or area. We have a kick-off meeting for a product, or for example we have a monthly release cycle, and anyone can come to those meetings to learn more about what's going on. Our marketing team also has those meetings for example, to talk about new efforts and past performance.
James: How else do people reach out to work together?
Eliran: We use Slack for communication, and I'm not sure how that would work in an environment like yours, without volunteers dedicating a certain amount of time every day. But we have channels for everything, and the whole team is distributed across channels. We have #whats-happening-at-gitlab, which is the channel Emily used to ask "Hey is there anyone relevant who'd like to help James and talk about remote work at his organization?" We also have a #questions channel, where anyone can ask anything from the most sophisticated to the stupidest. They just throw their question to the channel and people try to help them or steer them in the right direction for who to talk to. Another channel that's really important is the #thanks channel, and I feel that's an important part to offer gratitude to someone for helping you, and also receive that when you've helped someone. Because of the remote environment it's very powerful. Because GitLab's culture is built on asynchronous work – people in different time zones – you're not on Slack all the time because others will pick up your question whenever they become available.
One other thing that's working well is centralizing a process for working asynchronously. So, we try to make all the work and communication and discussion on GitLab by using issues. Someone will create an issue with a particular task or mission, and then the whole communication is available there. So people have access to information or decisions or a process on a specific area. Even if you're not involved, you can comment and say, "Hey I'd like to suggest a, b, c." So by virtue of being in different time zones, we were forced to use asynchronous methods of work, and issues work very well for that. Having the discussion tools integrated into that, and using it to keep everything in one work space dedicated to a specific topic, is great for remote teams. If you can't always set a time for everyone to sit down together, using issues is crucial to making work happen.
James: We do use Slack, because, as you may recall as a student you may as well be in different time zones, waking up at 9 am one day and 1 pm the next. Are there decisions made on Slack, or do you tell people, "No this is a discussion, take it to x issue"?
Eliran: We may have those specific discussions on Slack, but for the most part, maybe 95% of the decisions are happening within the issue. But we don't discourage people from talking, so there could be times when you have to talk to someone or a group of people, because there's only so much you can do over text. So you may make a decision over Hangout, but that is communicated back through the issue. Someone will go back and say "I had a discussion with Mark, and we decided the best way to move forward is x." That way everyone has the opportunity to get the takeaways from that meeting and give input. So some decisions happen away from the issues. But it's important to reinforce that we try to keep communication on a specific topic within an issue. We really push that, and it's part of the culture at GitLab. As you keep growing, the sooner you adopt changes in a working culture, the better it is for people to learn them later on.
Read more about how we stay connected as a remote company.
Tweet us @GitLab and check out our job openings.
