Experts share their tips for mixed distributed and fully remote startup teams.
Remote teams have become more common, particularly in the tech industry. Companies that want to add remote capabilities to their process can learn from teams that have built successful remote cultures. There are unique challenges to consider, such as:
- What are the best tools to use?
- How do you create a sense of collaboration, despite the distance?
- How do you make remote team members feel like they’re truly part of a team?
We took these questions to three technical leaders who have extensive knowledge of leading remote teams.
Spiro Roiniotis is the SVP of Technology at SocialCode, leading all aspects of product and engineering for the company.
Reuben Firmin is the CTO at ExecVision, where he runs a 100% distributed tech team. Operating as a virtual CTO previously for multiple startups has exposed him to a wide array of tech stacks and team structures for early-stage startups.
Ansel Teng is the CTO at BoodleAI. After earning his Ph.D. in Computer Science from the University of Maryland, he jumped into the startup space during the .com boom of the mid-’90s and has been managing technology ever since.
They each have unique remote situations: from a central location with a few offshore employees to one hundred percent distributed with no physical office.
What they have in common is a proven track record of leading remote technical teams for software startups. We asked each one to share their experiences and provide tips to others who are in a similar position.
The conversations below have been edited for length and content.
How is your team distributed? What are some of the positives and some of the pitfalls of having team members in different locations?
Spiro Roiniotis – SVP, Technology
Our team is in a mixed distributed model, a position that a lot of companies find themselves in over time. We have three main offices where our engineering and product people are clustered: Washington, DC, San Francisco, and New York City. But we also have folks who are working remotely across the United States and abroad. We initially evolved into that structure because various team members moved due to family or personal reasons, but continued working for the company. At this point, about one third of the team is remote.
There are a ton of pitfalls to this model and we’ve probably stumbled over every one of them throughout the past ten years. But we’ve learned a lot through the process.
To me, the most challenging aspect of a mixed remote and in-office model is the active effort in ensuring everyone feels like they are part of a team, as opposed to a disbursed group of people just working together.
Making the time for at least a couple offsites a year to align on the strategic thinking of the company and to reestablish the longer-term roadmap is one tool we’ve employed with success. It also has the added benefit of everyone being part of defining the type of team they want to be.
If there’s no direct connection, at some point, you see where the team starts eroding. Realigning on the bigger picture pays dividends when everyone across the team feels the same passion for what they’re building.
This idea applies to offshore teams too who are doing core development. I’ve worked with offshore teams that only interacted with our teams in a remote context, as well as having offshore team members join for our offsites. You have to take the company’s budget into consideration, but the times we’ve flown team members in, the cost of the airline ticket and lodging more than paid a return on that investment. Working together and asking things of the remote team becomes much easier when that connection is established and both teams are aligned under the company’s vision.
Reuben Firmin – CTO
I can start from my history with distributed teams. I founded a company back in 2013 that helped early-stage startups. I staffed it with freelancers initially, so that’s where I started getting experience with distributed teams. I was running several different remote teams, each dedicated to a particular project.
The advantage for me at that time was that I didn’t need an office. I could essentially do everything out of my home and run all of these various teams.
My experience with remote teams flowed naturally into my work at ExecVision, where I currently manage a distributed team.
There are a few advantages to managing a distributed team. One is the flexibility you gain when not restricting your search to just local developers. You can hire people who have the skills, no matter where they are.
The exception is making sure everyone is working in fairly overlapping time zones. I’ve been on teams in the past that were in completely different time zones, which became a nightmare. Trying to sync up when the teams only have one hour to collaborate is a nonstarter in most cases. I think it’s important that the business day is mostly overlapping for people on the team.
With that limitation on the side, I don’t have any geographical restrictions, which gives me a lot of freedom to hire people for skills rather than geography.
When it comes to pitfalls, I’ve found that partially distributed teams, with most people in the office and one or two working from home, have an added difficulty. It can be easy for the remote team members to feel isolated. They’re not part of the casual conversation that happens around the office. They can’t chat with people at the water cooler. Socially, you end up with the people in the office who are very tightly connected. Then, the two or three people who are working remotely end up being lone wolves.
If you are working in that partially distributed structure, it’s important to be aware of the little things you can do to improve the dynamic. For example, when the team is meeting, everyone in the physical conference room can come with their own laptops. So instead of having one camera for the entire conference room, you have everyone in the zoom conference as if they were remote. That makes it a little easier for the remote people, so they don’t feel like they’re the only head on the screen and everyone else is just sitting and looking at them.
Ideally, I think it’s important to have a “remote first” culture. This means the entire communication setup of the team is geared around a remote workstyle. That’s how our technical team at ExecVision has structured things. We do have some local people, but they use the same communication mechanisms that we’ve set up for the remote team.
Ansel Teng – CTO
Something that’s very unique about this position is that I have a 100% distributed team.
I’ve previously had an office environment where the majority of people were in one location, or at the very least, there were clusters of teams at a few offices.
In my current role, however, everyone works remotely. There are no central locations. But I think that’s wonderful now that I see how it’s working and how we continually refine the way we work together. I really think this approach is the future of software development, and probably for other lines of business as well. And the future is pretty much now. You can actually do it now.
In previous roles, we have offered telecommuting but always struggled when only some team members were remote. I’ve found that the most effective way to work is either you’re all in one location or you’re all distributed.
I think that the middle ground is actually the worst. When you have most people centralized and a few people working remotely, the remote team members can start to feel like they’re a second citizen. Like they can’t get their point across. As a result, the remote team members often just wait until they’re in the office to have important discussions and communicate their perspectives.
But when everyone is distributed, you have to live with that. That is your reality. There’s no reason to wait until tomorrow for better communication. You just do it now.
When everybody is remote, everyone is equal. You don’t have that feeling that a few people are the core of the team and the remote people are peripheral.
So I actually love that arrangement where everyone is remote.
Not to mention the benefit that now you don’t need an office, you don’t need a centralized computing environment. All the tools we use are in the Cloud. It’s amazing how mature things are these days to facilitate remote working for software development.
What are the specific mechanisms or tools that you’ve found helpful in managing a remote team?
Spiro Roiniotis – SVP, Technology
We make use of the usual cloud-based tools: Slack for chat communication, G Suite for video hangouts and shared documents, and JIRA and GitHub for code collaboration. The team has enjoyed using Notion for its wiki and document template features, and we use Zeplin to collaborate on design.
I think it’s important having a team all-hands once a month to celebrate milestones, and showcase the great work and values of the team. We also have Demo Days at the end of each iteration: this allows for almost everyone at some point to present to the team. We also have separate engineering-focused monthly meetings to talk through the technical architecture, and align on the technical roadmap.
Reuben Firmin – CTO
Nothing too exotic. We use Slack to establish a general “in-office” presence. During the workday, everyone on the team is online and available in Slack. We also have a chat that shows whether people are on their computer. Basically, if you step away to go to lunch, you punch in what time that you’ll be back. We don’t really micro-manage people in terms of time. But the nice thing about the channel is that it helps the team know who’s around and who’s not.
However, it’s important to have actual communication as well, such as voice or video conversations. We do all our scrums over video conferencing. We also do one-hour weekly meetings where we do demos for each other and walk through code.
Then of course, it’s important to have a robust version control system that has full request and code reviews. Also, a good wiki system so you have strong code and process documentation. I would say those are the essentials.
Ansel Teng – CTO
I think there are a few key ingredients to make this work.
One is your development tools, like JIRA and GitHub, to manage your workflow and manage your source code. They’re in the Cloud.
You also need the communication tools like Slack and G Suite for constant communication throughout the day. Video conferencing is an important piece of it. Make sure everyone has the proper equipment setup and build a culture of turning on the camera so you get that face-to-face communication.
The final frontier is a virtual whiteboard. This is still a gap. The one thing I miss the most about working in an office environment is that I can get a few team members together to whiteboard our ideas. We use Miro as our virtual whiteboard. It has decent drawing and collaboration capability, but drawing with mouse clicking and dragging is just not as quick and fluid as freehand drawing. I hope someone can invent a solution that allows people to draw with their hands on the screen.
Want to learn more about these tech leaders and startups? Check out the BoodleAI and ExecVision company pages to learn about their company cultures, products, and more!
