Building and Managing Distributed Tech Teams
With Andrew Schafer, CTO Entelo and Elbruz Yilmaz, Investment Director 3TS
In February 2020, we have launched a new podcast series together with 0100 Conferences. If you are not a big podcast fan or you are more of a visual person, below are the key messages in a form of a blog post.
In the first episode, 3TS Investment Director Elbruz Yilmaz discussed with Entelo’s CTO Andrew Schafer about what it takes to be successful in Building and Managing Distributed Technology Teams. Entelo offers a Saas platform used by recruiters and hiring managers to streamline and automate identifying, attracting, engaging and assessing new employees. Entelo is a 3TS portfolio company, formerly called ConveyIQ which renamed after merging with San Francisco based Entelo in 2019.
After the acquisition, Andy, then CTO at ConveyIQ, took the position of CTO at Entelo, and the San Francisco tech team was added to the existing New York and Serbia tech teams of ConveyIQ. Continue reading to find out more about Andy’s learnings and dos and don’ts on the management of distributed tech teams.
Q: To start with, how does your current team set-up look like?
A: We are in 3 locations, with teams in San Francisco, New York and Serbia. With ConveyIQ headquartered in New York, we also founded a team in Serbia which has grown from a small 8 people team to about 23 right now. It is a combination of engineering, architecture, QA and operations and we are now starting to on-board support there as well. In New York, we have a half of the product team as well as a couple of engineers. When we merged with Entelo, we added the San Francisco team, where there is a mix of engineers and data scientists, around 6 people in total right now.
Q: How does the location and time zone split affect your work?
A: The segregation actually helps to nicely organize the day. We can get a lot of work done in the morning in New York while collaborating and communicating with the Serbia team which has afternoon. In the NY afternoon, we can focus on other things that need to get done like coordination amongst the product management team, working with customers and working with the rest of the organization.
It works the same for San Francisco and New York. However, there is nearly no overlap between San Francisco and Serbia and this has been a challenge. We found a couple of hours sweet spot that we squeezed much earlier in the day in San Francisco and later in the day in Serbia to make sure the teams overlap.
Q: What tools are you using to ensure effective communication?
A: I think communication is usually the biggest challenge when collaborating across locations. First and foremost, we recognized that, and then put in several tools that helped with the process. Slack is being used very extensively, across all areas of the organization, both for one-on-one communication and for broadcasting news on general channels. We also use Jira and Asana to track work, which helps a lot to organize and prioritize information.
We practice daily stand-ups across the development team, so folks from all three different time zones join to talk through and review what people have been doing or will be doing that day. It gives everyone context to what people are working on. It has been very helpful to me with now a larger team in different areas, because it keeps me up to date without having to micromanage every little thing. We
also have regular design reviews and pre-grooming and grooming meetings, which are all standard practices in Scrum.
Q: What are some of the advantages of distributed teams?
A: There is no doubt that there are a lot of advantages. The first thing that often comes in mind is a lower cost of living in areas other than the company’s primary location or headquarter. This brings a lot of strategic value to the company in terms of speed and ability to deliver against the roadmap faster.
Also, a remote team can develop a culture around what they are trying to achieve while being isolated from the noise that happens in the rest of the organization and it provides them with extra focus and yields great results. This is the case for our Serbian engineering team which is very focused on technical development, while the US tech team is more responsive to the rest of the organization, like sales, customer success etc.
And last but not least, there is the cultural aspect of each country which brings in extra value to the team and work we do. I found particularly in Serbia that there is very much a focus on the intellectual process and how deeply they understand engineering and that focus that the team has had, has also helped us maintain the level of execution that we aimed for.
Q: Did you have to change your management style when the team became distributed?
A: One of the things that was important to me is where the leadership is located. I think a very top down or centralized leaderships style within engineering teams does not work well. We hired a lot of leadership in Serbia – we have the senior architecture, senior people management and our head of DevOps there. That helped the team feel like they had a critical role in the organization and they had their representation at all levels and it allowed pretty easy communication. It also allowed for those that were decision makers to be hand in hand with the team that was actually implementing and developing.
My role in that sense became more of a facilitator, ensuring that we are meeting the standards that we’re aiming for, setting the right objectives and goals and making sure that we have recourses aligned and assigned to achieve those in coordination with the rest of the organization. I think being able to step back, empowering the teams and giving them the autonomy they need is important. But I also think you need to have the experience necessary to know when things aren’t going right and it is time to get engaged and jump in before things get out of control.
Q: What would be your advice to other CTOs who are just about to build a distributed team?
A: It’s pretty important to get a team that considers themselves a part of the organization. They need to see that every day they come to work their investment is making the company better.
In the early days, there are two ways of going about this. One, you can engage a partner that supplies some early talent with the expectation that that talent will either eventually become employees or you agree on day one that they will be replaced by other people eventually. The other way is to define and hire the key leader(s) in the location and have them grow the team from there. I think both options are viable. What I’m not keen on is to hire an outside company to handle your development for you especially for a long-term basis and idolize them as partners.
Q: Before we end this chat, what content would you recommend to people on this topic?
A: I don’t have any go-to blogs I read every day, but I like the blog of Roman Pichler, who provides fantastic explanations about various issues on this subject. In terms of books, I really like “Creativity; Inc.” from Edwin Catmull, President at Pixar.