 |
 |
 |
Managing Distributed Developer Teams: Zenput's Case Study (Interview with Tim Olshansky, VP of Engineering at Zenput)
Managing distributed developer teams poses an entire set of brand-new challenges never seen before. As a software engineering manager, it’s more likely now than ever before, that you’ll be managing a team where at least some developers work remotely.
This is why Fanni Karolina Tóth from Coding Sans interviewed Tim Olshansky on managing distributed developer teams. He’s originally from Australia, but he has been working in San Francisco for nine years as a prominent figure in the tech scene.
As current VP of engineering at Zenput, he has a boatload of experience managing both distributed developer teams and on-site engineering teams. Right now, he’s working on changing the food safety of the world. Prior to that, he was the CTO of Aconex, a publicly-traded construction technology company that was acquired by Oracle in 2018.
Since then Tim has returned to discuss creating a software engineer career ladder!
We’re covering:
- Challenges of managing distributed developer teams
- On-boarding into distributed developer teams
- Keeping distributed developer teams organized
- Balancing synchronous and asynchronous work
- Managing distributed developer teams
- Measuring productivity in distributed developer teams
- Giving feedback in distributed developer teams
- Running meetings in distributed developer teams
- Tools for managing distributed developer teams
What are the biggest challenges in managing distributed developer teams?
It varies by company, by stage, and by individual team.
Even the way we define remote or distributed teams can vary.
There was a recent blog post I came across. He did a great job of describing the way to categorize remote work: synchronous versus asynchronous, remote verse distributed. The problems for each of these areas of remote work differ.
At Aconex, our organization had about 250 people globally. We had teams in 8 different cities. Some team members were full-time remote and didn't work in an office; some were co-located in offices. But across all those time zones, it was difficult to get the whole team to work together.
At Zenput, our engineering team is currently just under 25. It’s ten times smaller, but we're growing. Currently, we're mostly co-located, which allows us to work more effectively for now.
Remote work is hard on some
We have distributed team members who don't work in an office. We also have team members who are based in different countries. Some of them go into an office together; some of them don't.
A lot depends on the experience level of the engineer, whether it's their first time being remote or they've been at it for a while. Remote work is exciting, but loneliness is often overlooked, especially for full-time remote developers. People often forget the social connection they need from their colleagues and co-workers.
Read this case study to learn how we turned into a remote company in one day!
Making distributed teams feel connected
A feeling of connectedness is a challenge to build. Making members feel like they're an important part of the team and company, showing them the vision, and that they can contribute to the overall goals often falls by the wayside.
A software engineer working from home can often miss how their work is connected to the big picture. So, managers need to stay on top of this. A manager with fully-remote developers should always explain why their report’s work is important to keep them connected.
Big projects or team management require a very nuanced approach in a distributed organization. When there's a large office presence but some people are fully remote, the manager has to be in the office. They act as an information conduit, keeping remote developers connected.
I’ve seen situations go wrong with a large office presence for the team and the manager being off-site. It's not impossible to do, but it's a challenge, and it takes a particular type of remote engineering manager to make it work.
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 on-board remote engineers into a distributed developer team?
Have them meet the team in person
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 on-boarding 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.
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, 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.
To learn more about handling burnout as an engineering manager, check out this guide!
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.
Check out this guide on how to make the transition from engineer to manager! (Podcast + Blog post)
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.
Knowledge-sharing meetings
Another great meeting we've introduced recently is a “learning and development” session. We have different team members give a talk on an interesting book they've read. It may be about domain driven design, our code base or what we aim to do with new architectural patterns.
It’s mostly regular meetings
Other times, like at a sprint planning meeting, we use well-known meeting structures for those rituals.
We record meetings and use transcripts
We record the meeting, so everyone can watch it later, even if they couldn’t attend. I also create a transcript of it, using online tools. Sometimes, you can’t listen to an hour-long video call, but you can flick through the transcript and see the topics. If something grabs your attention, you can dive in right there.
We use a tool, Rev.com, which allows you to scroll to the right point in the transcript and play the audio from that point. You can zoom in on the things that you're interested in. I’m not sure how much the team uses it, but it helps me a lot. We've had new team members listen to this session as part of the on-boarding process. It gives them context about our work more quickly and effectively.
We take notes as well at the formal meetings. When we need to make a decision, it’s important to have a record of how we got there. We rarely take meeting notes on learning sessions, brainstorms and open-ended meetings. In these cases, it’s easier to record it and generate a transcript. It’s still a great source you can come back to.
What tools do you use when managing a distributed developer team?
Management tools
We use JIRA for project management and Slack for communication, as most teams do. We use Zoom for meetings with the distributed developer team, and we have an etiquette in place about jumping on phone calls. Most of the discussion is on chat; for bigger topics, we get into a Zoom call.
Of course, we send plenty of e-mails for less important things that require more time. And we use Rev for meeting transcripts.
Developer tools
More on the developer side, Slack screen sharing is a solid tool. If people are pair programming remotely, Slack bought “Screen hero” which is already integrated. So, Slack has become the centerpiece of our work.
We use GitHub for version control and as an internal engineering wiki. Most of our documentation is there, and we use it for code review discussions. We integrated a tool called “Pull Reminders,” which integrates GitHub with Slack. It lets you know when your name is mentioned or when a pull request is assigned to you.
With all this, it’s easy to get distracted, but you can stay on top of everything.
Is there anything else you would like to add to managing distributed developer teams?
I think remote work is great, but its success depends on the culture of the organization. Remote may not work for one company, but it may work for another. It may not work for you at one company, but it may work for you at another.
Depending on the type of person you are, remote may not be for you. Some people prefer to be in an office with their peers. Sometimes, we're quick to jump onto new ways to work and advocate it as the best thing ever.
Being a remote but co-located team is a powerful model, where everybody can work remotely if they want to. They can work from Thailand for a month if they want to. There are also benefits to being together in person. It builds social connections, and your team may be more effective together.
What You Should Do Now
👉 If you are serious about becoming a great engineering manager, you should subscribe to our newsletter or download the state of software development 2020 report.
🚀 If you need developer help for your project then click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.