Successfully building a distributed engineering team
- select the contributor at the end of the page -
Upwork CEO Stephane Kasriel shared insights for building a distributed engineering team at this year’s hack.summit() conference--a virtual event bringing together top programming experts and thought leaders from around the globe. Here are some highlights from the fireside chat, moderated by hacks.summit() Founder, Ed Roman.
hack.summit(): Why did you decide to build a distributed engineering team at Upwork?
Stephane Kasriel: We quickly realized as we were building our engineering team, that there was simply no way we would be able to hire all the people we needed in just Silicon Valley. Though it’s a mecca for techies, Stanford University only trains around 150 graduate students in computer technology each year. Google alone will try to hire over a thousand tech graduates this year and are willing to pay just about any price to attract them. In order to access the best talent, we knew we had to think outside our own backyard. We have since grown from utilizing two engineers to engaging with over 200 engineers spread across the globe.
hack.summit(): How should you make the decision between hiring a full-time local staff to build a software project, versus outsourcing it?
Stephane Kasriel: First, let me say that what I’m recommending--what Upwork does--is not outsourcing. Outsourcing is not a direct relationship and quality of work is questionable. I’m a proponent of people working together directly.
When making the decision to hire, it’s important to consider the skills you need and determine the best model for engagement. If the services required are one of your company’s core competencies, then it’s best to keep the work in-house. However, if you need a specialized skill for a particular project such as PHP development, it makes sense to contract to a freelance professional.
hack.summit(): How can aspiring engineers look to advance in their career?
Stephane Kasriel: The #1 thing I would say to a young engineer is think about your engineering degree as a license to learn. You’ll learn new languages and new frameworks every couple of years, and you need to be able to expose yourself to these new changes. This is especially true if you decide to go into business for yourself. As a freelancer you have to be able to sell yourself and your skills regularly. You need to understand where the demand is going to be coming from and teach yourself those skills. If you decide to become a freelancer, you’re an entrepreneur. You not only need to be a really good engineer, you need to be a really good engineer who knows how to build their reputation, how to market themselves and how to sell themselves to a client. It’s a combination of being agile in learning new skills and understanding where the market is going, and manage yourself as you would manage a start-up. As a freelancer, you are a start-up and your reputation is everything.
On the flip side, there are a number of positive benefits to becoming a freelancer. As a freelancer, you have control over when and where you work, and can opt to work on projects of your choosing based on what you’re most interested. For many highly-skilled professionals whose expertise is in short supply, like most engineers, they’re better off as freelancers. Extremely productive workers (2x, 5x, 10x types) don’t get salaries that commensurate with their value when employed by a single company. As a freelancer they can let a free market set their rates based on what they’re actually worth.
hack.summit(): What are some best practices for making a distributed team work?
Stephane Kasriel: First, hire the best talent. You can afford to and there’s no reason not to. As more and more businesses compete for talent, engineers in tech hubs such as the Bay Area, may not be available or affordable for some businesses. For the same budget, you may be able to hire 3-5 times more engineers outside your local market. At the same time, the increasing cost of living may make living in the Bay Area less attractive to some skilled talent who prefer to live and work elsewhere. To build a highly effective distributed team, we would advise that you look outside your local market to hire some of the best remote engineers. You can find the “10x engineers,” the “unicorns,” so take the opportunity.
Second, be sure to communicate clearly. With distributed teams, it’s important to define clear tasks up front to ensure your remote workers are successful. Create a spirit of open-dialogue with each of your remote team members. Regardless of location, take pains to make sure remote workers are included in all relevant project communication.
Finally, always make an effort to treat remote workers as valued members of the team. Take the extra steps to ensure your distributed team knows your company’s mission and has what they need to be successful. When a freelancer or employee works hard on a project and never hears about its impact on the company, it can be difficult to feel engaged with the team. It’s important to celebrate achievements and recognize key milestones, so they feel empowered and want to work with your organization.
Watch the Q&A in its entirety, including questions from the event’s worldwide audience of programmers. And for more best practices on how to successfully build a distributed engineering team, download Stephane’s ebook, Hire Fast and Build Things