This week I was honored to speak as part of a panel moderated by Corinne Sawers, Co-CEO of Turing Talent, on building remote tech teams. Joining me on the panel were Emoke Starr, VP of People at Benchling, Martha Bitar, Director of Business Development at HoneyBook.
I primarily build remote engineering teams since product development, R&D and engineering is what I tend to do most – but the themes discussed apply to other types of teams as well. Remote teams have become a reality for many tech companies– and will only become more prevalent as the competition for local labor increases, the range of hourly rates for global tech labor continues to widen, and companies of all sizes increase their global footprint.
Building a remote team may seem like an affordable option, or even the only option available. At the same time, outsourcing technology development, especially when offshoring, brings a whole host of additional challenges and risk factors. Frequently, the results are rather less “affordable” than originally envisioned, and sometimes they are downright disastrous.
Collectively (and individually), my co-panelists and I have experienced all sides of this – including successes and failures. Some of the practical topics we discussed included the following.
How Did it Come to This?!
OK, that sounds a bit dire. But, really… how did you end up with remote teams? How did your decision making evolve to cause you to build a remote team? It’s not always obvious. Reasons I heard articulated by our panelists included:
- We couldn’t find enough local talent – there’s fierce competition for tech labor, after all.
- We couldn’t afford local tech talent – especially here in Silicon Valley (or “here” in [pick your favorite expensive region])
- Our CTO is originally from […] – and looking there for talent was a natural fit.
- We were part of a multi-national company / collaboration, so it was a given that we’d have distributed teams to build and manage.
- We were expanding into a new market and needed local (to that new market) talent to support our growth.
- It just kind of grew organically.
I’m sure there are other reasons, but this list already shows a fair amount of variety!
Of all of these, perceived affordability may be the most tricky, since cost alone is rarely an ideal justification – and you may have some unhappy surprises if that’s your reasoning.
Challenges / Lessons Learned
What are the biggest challenges / lessons learned in managing a remote team for success? Communication is huge. As a manager, over-communicating is a must-do. Be as transparent and clear about your expectations as you can possibly be – and require the same level of clarity in what comes back to you.
Martha spoke to cultural sensitivities and having to adapt some of her own personal style to mesh well with her remote team in a way that sounded frustrating at first and then developed into a great success.
Develop relationships, not just an expectation of deliverables. This is in fact part of what happened in Martha’s inspiring example – much deeper relationships were formed because she was willing to adapt her personal style. People work harder and produce more / better results for others with whom they have a positive working relationship. Don’t just be the source of income and expectation of output that exists out there in the ether.
Don’t expect fancy tools to do the hard work of creating a functioning team. That’s still your job.
Don’t assume that when someone else tells you something, that you really understand it. Depending on the cultural (mis-)match, they may in reality be telling you (or not telling you) something entirely different.
Em took a very pragmatic approach and addressed the very practical challenges of time zone differences – where one’s days can start at 4 AM and go into the evening. Is your work schedule resulting from managing remote teams sustainable?
Be very careful about how you calculate the total cost of getting the work done by the remote team. It’s a whole lot more complex than, gee here engineers cost $X/hour and there they cost $X/5 per hour (or whatever). That does not mean that the entire project will cost you 1/5 as much! Cost savings may happen, or it may not, regardless of how attractive the local labor costs may seem. Do your homework.
Does the remote team have the same understanding of deadlines and deliverables as you do? If not, you must find a way at the outset to account for those differences.
Do you recruit for different qualities when you know it will be a remote set up? No matter what, for anyone working remotely, highly functional communication skills are required. Then again, that’s something I look for in most people I hire, because it’s part of the job. But in remote teams, it takes on an additional level of urgency.
Beyond that, this is a pretty nuanced question. The remote setup can vary, and the different qualities you may take into consideration may vary based on which setup we’re talking about. To be more specific:
Everyone remote (e.g., working from home but maybe mostly in a similar geographic / cultural region) is a different sort of remote set up than, for example, higher level management in one location (country) and developers and engineers in another country but each all in a single building.
If team members are “remote” because they are individually working from home (or the local coffee shop or wherever they choose to work), then a high level of autonomy and self-discipline are really helpful, as is the ability to focus and tune out distractions. And do they have the tools and setup, or can I provide them, to be successful working in this manner? If it’s not successful, was it that I recruited badly or that I didn’t set them up for success?
If teams are “remote” because they are collectively housed in a building that is located in another country from where, say, you as the manager or product owner are located, that’s a different story. In that case, I’d say the adaptation to the “remote” part is largely on your shoulders. I’d still be hiring for the same technical and basic interpersonal skills in the engineering / developer team as I would in a local team. Also, I might either be hiring individual people or “hiring” a company to provide a team.
I would not recruit with the expectation of finding people “just like me” in that other country / culture in the naïve belief that I will duplicate a culturally similar team that happens to be physically located somewhere else.
I would, however, specifically look for qualities in the primary points of contact at the remote location, that would enable them, together with me, to bridge the communications and cultural gaps that exist. Do they have experience with that? Are they open do that – and recognize that this is a required part of their function?
Em made another excellent point in saying that really, recruiting for remote teams is the same as recruiting for local teams – in that all of the same qualities matter. The difference is that the consequences of doing a poor job of it may be greater with remote teams. As Corinne put it quite eloquently, managing remote teams requires you to step up your management game. Yes! Not fundamentally different, but it requires more of you!
Very much as a backup, I’m also especially careful about contracts. These will never replace the working relationship, but they are a useful backup and are a very useful tool for spelling out clearly expectations and deliverables. The process of developing them is as important as the product.
How do you ensure some consistency of company culture across a new location and / or distributed team? Ensuring consistency of company culture is a challenge faced by team leaders and managers regardless of whether teams are distributed or in a single location.
I would add a second, related question to this and ask, how do you handle differences in culture across a distributed team? It’s not only about a consistent company culture – which is something you need to build even with a team in a single location.
Separate from having a consistent company culture, there is the need to work with either varied cultures (multiple locations) or simply one single but perhaps unfamiliar culture (managed from “HQ” but with “all” of, say, the developer team members in another location and with a different culture).
A diverse team consisting of people with multiple backgrounds is a different scenario than, for example, one part of the team “here” and one part of the team “there” – which is really set up more for the risk factor of us vs. them. If you have one outlier, the challenge is bringing that one outlier into the existing (for better or for worse) company culture (whatever it may be – that’s a separate issue). If you have the here-and-there sub-teams scenario, then you have to deal with the reality that, within each team, they will operate consistent with their existing culture. It’s less about inclusion and more about bridging the gap between two (or more) teams that each have a critical mass of their own cultures layered on top of what overall company culture you’re building.
Em brought another incredibly practical example to the discussion, where there were issues with regard to how certain individuals were treated in the remote team, in a way that had initially been considered acceptable behavior in that region but was unacceptable by US standards and clearly in violation of company culture. A great example of a case in which company culture was applied to override local (remote) culture – and eventually to bring along the folks there to help conclude that maybe their original behavior wasn’t particularly respectful of some of their team members and had no place in the workplace.
What are some tips & tricks for effective relationship building across geographies?
- Nothing beats some in-person time together, which can then be effectively followed up with virtual interactions.
- Next best is video-conferencing in some form. Humans form trusted relationships when they can directly interact with and especially see others. I’m pretty sure that statement is based on valid research; it’s certainly been my experience.
- Beyond that, by all means, use all the electronic tools and apps available, whether for email or messaging or virtual white-boarding or… Just don’t confuse those tools with the fundamentals of relationship building.
By far the most important theme in this portion of our discussion was Martha’s point that it requires intentionality in developing and nurturing those relationships.
To me, this translates as –
- Take a genuine interest in the people on your team, regardless of where they’re located.
- Develop a real curiosity about them, both as individuals and as representatives of another culture (if they are that) and learn about them.
- Use those differences to establish areas where you can learn something new and interesting!
I hate small talk as much as lot of engineers do… but I can get very genuinely interested in the real details of what makes people on my team tick, what is important to them, and how their lives are unfolding. The key here is “genuine” – if you’re really not interested, don’t fake it; then again, don’t expect fantastic remote team results, either.
I believe the event was video-recorded, and Turing Talent will post it on YouTube. When I receive the link to it, I will update to post it here as well.
All the best with building and managing your remote teams! It is fun, productive, and challenging, and as Corinne said, it forces you to step up your game. What’s not to love about it?! If you’re struggling with any of it, feel free to contact me – I’m always happy to share any of my experiences with it, should that help you.
Finally, it strikes me that Turing Talent may be a great resource for companies looking to build remote tech teams within Europe – and, no, I do not have any relationship with Turing Talent but am impressed with what they seem to offer and with how thoughtful Co-CEO Corinne is.