Managing Distributed Developer Teams: Zenput's Case Study

Give credit where it’s due

It’s also important to make sure your reports have opportunities for career progression, to take on management or technical leadership roles. On the technical side, the work remote developers do sometimes doesn't get as much recognition. There are ways to address that, but it could prevent career progression. Remote developers often cap out early in their careers.

Being a remote developer is more challenging than showing up to an office every day. Depending on what the person is looking for in their career, they may need to take more difficult steps than on-site workers.

What is your best story in overcoming the challenges of managing a distributed developer team?

I had a great team member, a very strong engineer, and he decided he wanted to relocate. He left the office and started working full-time remotely. He had larger technical responsibilities on the team, and he managed to maintain them.

In time, he ended up taking on the management of the team. So, he had the reverse problem to me. He was a full-time remote manager with a decent chunk of his team being full-time in the office.

As you can imagine, the connection he had was different. It's usually the other way around, so he had to go to great lengths, with support from me and the engineering management organization. He managed to pull it off, but he had to work on it constantly.

How do you onboard remote engineers into a distributed developer team?

Have them meet the team in person

Managing a fully remote onboarding process is difficult, so we make sure people get together on-site semi-regularly, so they build connections and get to know each other. We have a team member in Portugal, and we have other team members who live an hour away by plane in the US. The difference in travel length and duration impacts how frequently a remote developer comes to the office.

So, the first thing I do is bring them on-site for a couple of weeks, and I have them spend time with the team. We put them in a hotel, have them come to the office, and go through onboarding. We set up the development environment, and they meet with everybody on the team, one on one.

We take them out to dinners and lunches, and we make them feel like they're wanted, and that everybody's happy to see them. We have a formal onboarding process that takes them through the product, our value proposition to our customers, our technical strategy, and ultimately our vision for the company.

Use documentation to smooth out the process

We have lots of documentation and a wiki that's kept up to date very well. That makes on-boarding a lot easier. We just say, “Why don't you just work through this? We have this onboarding document posted on our wiki.” It includes investing in automating the environment setup, so others won’t have to tinker.

Something always goes wrong anyway, but it’s usually one or two things as opposed to fifty. Of course, we have them update the documents; I think that's pretty standard. So, we automate a lot in getting them set up, to involve them in team rituals and processes as soon as possible.

Give them the initial wins

Have them meet everybody and get them involved in small things early on that are doable on their own. In this way, they won't have to spend too much time figuring out lots of different things to be able to solve a problem. It’s useful to get an initial set of wins you can say you've accomplished in the first few weeks. Ideally, you do this while they’re on site, as it tends to build engagement for remote employees.

On an ongoing basis, I tend to work on a 7-day, 30-day, 60-day, 90-day set of goals to keep them on track.

How do you keep a distributed developer team organized?

Regular team building

We get everybody together once a quarter. Everybody flies together, usually to San Francisco, because the bulk of our team is there. We also do an annual company retreat, when everyone goes somewhere together.

In January, we’ll be going to Cancun, Mexico. At these events, we do some team-building or vision and strategy meetings, where everybody contributes and thinks about how we want to grow as an organization.

Other times, everybody gets together on-site in the same office and works together, and we have hack days. Good rituals help set clear goals and show everybody what they’re working towards.

Use regular project and management meetings

We follow agile scrum, we get together every two weeks for planning, and we do regular retrospectives. We have daily scrum stand-ups, to make sure everybody is communicating what they're working on.

We use JIRA, though the specific tool is not that important. It could be anything; using some project management tool is the important part. It tells you what everybody is working on. I like to organize teams around a backlog of work that makes sense. So, I need to make sure everybody knows what that backlog of work is.

We're empowering them to work on things that have been prioritized, so they don't have to think about what's next. Then we do regular check-ins and one-on-ones. I meet with them regularly once a week; other team members get together semi-regularly. We have training sessions that different team members run once every few weeks to keep everybody in the loop on how things are developing.

One of the most powerful things to keep your developer team organized is the daily standup in a scrum team. It doesn't have to be a 45-minute affair; it can be 10 to 15 minutes.

We have 20 people at one daily stand-up, and we still manage to get through it in 15 minutes. It’s about keeping everything focused, keeping everybody on the same page, understanding the bottleneck, and making sure that people get the help they need. It shows people can work effectively if the work stays organized and the team stays organized.

How do you balance synchronous and asynchronous work in a distributed developer team?

Make sure everyone overlaps with office hours

One of the greatest challenges we had was people being on opposite sides of the world. Looking back, we didn’t do a great job with it, and this was largely my responsibility.

The dilemma is this: team members being completely asynchronous and almost never speaking to each other versus synchronous work environment.

We have some general guidelines, where we try to ensure that most of the team has at least a four-hour time zone overlap. For example, we have a team member in Portugal; he tends to work in his evenings. So, he overlaps with most of the morning for the San Francisco team. He loves it this way.

We set up office hours to be 10:00 am, to 6:00 pm, Pacific time. We aim to have remote members overlap until about 1:00 or 2:00 pm on the morning shift side. If they're in another part of the world or traveling, they can work in the afternoon of the San Francisco office time zone.

We’re using this system for now, but it may change as the team scales. We use this time for synchronous work, remote meetings, brainstorms, and discussions.

Provide opportunity for focused work

For the rest of the day, we allow the team to work asynchronously and have focus time. We use tools like GitHub for pull requests and to minimize the need for real-time communication. We use Slack and JIRA tickets effectively, so people can keep up with the discussion.

I think it’s a good balance between the need to be synchronous while also being asynchronous at times.

What are the advantages of asynchronous work at a distributed developer team?

I see team members working outside office hours getting more time to focus. They can go deep on things because there are fewer distractions. It’s easier for them to get in the zone.

Offices tend to get loud and noisy, and people tap you on the shoulder, despite you wearing headphones. These things throw you off, and switching context is expensive.

I encourage my team to work from home often, at least once a week, just to be able to filter out all the background noise, so they can focus when they need to get things done.

There are tasks you need to spend six hours with and not have anyone bother you. Then you can get things done. This is one of the great things about remote work. You can set boundaries that allow you to focus effectively.

How do you manage distributed developer teams?

Keep an eye out for burnout

I try to find signs if people are disengaged, burnt out, or feel stressed because they've got too much going on. I try to judge what’s too much based on this. Sometimes, it also identifies whether their work isn’t enough. If it’s not challenging enough, they get bored, and they don’t work effectively.

I figure it out through one-on-ones and lots of conversations with the team to see what gets them excited. I try to find work that will engage them properly, or I take work off their plate so they aren’t overwhelmed.

Look at the team first

I focus on the team as a unit, as opposed to individuals. I'm not tracking the velocity of an individual team member during every sprint by looking at the number of commits they make or the number of tickets closed. That doesn’t create good behavior, and it doesn’t build team cohesion.

I look at things from the team’s perspective first. Are they performing well? Are the team members helping each other out? Are we meeting our goals for the sprint? Then, I see if there is a team member struggling and in need of some guidance and coaching.

Make sure you set realistic goals

Other times, team members are working 16-hour days, because they're trying to get everything done. That’s when we need to have a conversation with the rest of the organization about what can be done in a set time frame. With experience, people understand what they can and can’t do in a certain time frame, and they speak up about it sooner.

Sometimes, you have to accept that results are important and work just needs to be done, whatever it takes. I make sure that's never the general state of being.

Follow the activity

I like to have everything from comments to GitHub discussions, pull requests, and commits come to me as a stream in a Slack channel. I can click through and see what's going on. It isn’t to see what individual team members are doing. It’s more to make sure that people are talking to each other without me getting involved in everything. I don’t micromanage, but I give the team the freedom to get things done.

I can go into JIRA or GitHub and see if a member is contributing or if they may be struggling. When I see a pull request sitting there for two days with no action, I can step in and help out. I can see what needs to be done to see it through to completion.

How do you measure productivity in a distributed developer team?

I don't measure it specifically. It’s been a struggle, because the definition of productivity is a difficult one, particularly in the software engineering world. Is fixing a hundred bugs or implementing ten features better? What if none of those features affect the company positively?

Make sure your focus is right

Firstly, I start by making sure we're working on the right things. If not, I try to fix that, because all the productivity in the world working on the wrong things is not going to get us where we need to be.

Make sure you work it right

The next question: are we working the right way? Are we doing things that are going to cost us in the long run? This is a classic technical debt conversation.

Make sure there are no blockers

Do we have the infrastructure to support the team to be productive? Does the team have to overcome difficulties to demonstrate what they've done? I try to assess those things and remove the impediments. Then the team can focus on doing what they like, which is problem-solving, and building new things.

Look at individuals

When all this is sorted, I look at the individual level. There, I see that if they say they're going to do something , do they get it done? If not, why not? Sometimes, folks need to be held accountable for what they commit to.

Are they performing at least on par with their peers, or are other team members carrying the slack? This is difficult to measure but easy to sense, especially for an experienced manager. You can tell based on the updates they give based on the proverbial velocity of the team. You can see who's leading and who's lagging.

Have your reports give feedback to each other

You should build a healthy feedback culture and get the team to talk and give feedback to one another. This way, when team members feel like some folks aren't pulling their weight, it’ll be a team conversation rather than a management conversation. It’s better in the long run, because whenever someone has a productivity discussion with their manager, the first thought is: “Am I getting fired?”

We all have different energy levels at different times. Software development is a marathon, not a sprint, but even in a marathon, there are times you need to run faster or slower. You've got to manage your energy levels, and that's okay, because we’re focusing on the long run.

I look for patterns rather than one-offs. A concerning pattern is when a developer is disengaging, gets a lot slower, and it doesn't stop. Consistency is what I look for.

How do you give feedback at a distributed developer team?

There are different forms of feedback. Feedback could be a nudge, a small shift in approach. I try to do these as soon as possible. I mention ways they could have done this better or give an alternative way to consider the situation.

You need some patience

When it's more difficult, for example, when a developer is trending towards burnout, it can take a longer time to spot, and you must make sure it’s not a one-off thing.

Usually, the moment I notice it, I start thinking about it. As a manager, I want to have that conversation as soon as possible. If it was about me, I’d want to know right away, so I could make a change. When I have a problem, I want to talk about it, and it's hard to start that conversation, but someone else starting it for you makes it easier.

Go about it softly

You can always use the classic feedback form: “When you do A, it has P impact on me or the team, so I'd like you to do B instead.” It's a softer conversation, but you talk to them directly about it.

I like the traffic light model for performance. Green light: you're doing well; keep it up. Yellow light: you're doing okay, but there are a few things to improve, so let's talk about them. Red light: things are going badly, and we need to change this right away.

I don't have those conversations a lot, but often it's, “Heads up: right now, you are not meeting my or the team's expectations. Let's chat about it and see how we can get you back on track.”

How do you run meetings at a distributed developer team?

Daily stand-up

Daily stand-ups, where we get together, is a well-known structure. The only unique thing about it is we focus on the JIRA board. We put it up, and we have everybody talk through what they're working on and where they're stuck or need help. We make sure they’re not working on anything outside the board.

Each team has a sound, a theme or noise they make at the end of the meeting. There’s a “Go team!” or some woos to add some energy. We make cowboy sounds to get everybody in the right mood.

Open space

We have formal meetings as well, like the monthly team meeting. I'll solicit agenda items at least a few days early for whatever people want to discuss. We have a time schedule as well, to keep it more formal. It only serves to set some time constraints, so we don't go too far off the rails.

I am rather militant about not going over time and ensuring we're using these meetings and team time well. I found that good meetings can finish on time; in fact, good meetings should finish early. A meeting should only focus on making decisions.