Hire Fast & Build Things · 2020-04-06 · Hire Fast and Build Things 4 First things first—what, exactly, is a distributed team? Some call them remote, others call them virtual

Hire Fast & Build ThingsYour Guide to Assembling an A+ Team of Distributed Engineers

Hire Fast and Build Things

PART 1

IntroductionIntroduction 2

First things first—what, exactly, is a distributed team? 4

Why build a distributed engineering team? 5

Who benefits from distributed engineering teams? 6

PART 2

Distributed IQTeam structure 9

Development process 14

Building a shared infrastructure 21

PART 3

Taking the plungeOvercoming common concerns about online work 25

Hiring and working with remote developers 27

Development…and beyond 38

The takeawayTop tips on creating a successful distributed engineering team 40

Examples and case studiesAutomattic 42

Chess com 45

Trillamar Webcraft 48

Table of contents

PART 1

Introduction

2Hire Fast and Build Things

IntroductionAre you the founder, CEO, or engineering lead of an innovative company searching for tech talent? How do you find the skilled people—all those developers, designers, test engineers, data scientists, and architects—you so desperately need to start or grow your company?

Chances are you have tried every method imaginable to locate qualified developers but haven’t had much luck You’re not alone

In one year, Stanford University trains around 150 computer science graduate students In that same year, Google alone will try to hire more than 1,000 tech graduates But consider this: Thousands of developers graduate from excellent universities around the world annually The quality of their code would blow you away, but their local opportunities may not be particularly plentiful, inspiring, or well paid

So why limit your search to your own backyard when there’s a world of talent hungry for opportunity? What if you could build a team of the very best developers, regardless of location? Thanks to brilliant collaboration, technology, and global broadband, tapping into an Earth-size talent pool to create distributed technical teams is a smart and viable option

I’ve seen firsthand a “distribution solution” taking hold Open source communities have always been fully distributed, developing the best practices that make today’s remote teams run like well-oiled machines Now businesses are catching up—and your company should too Not because distributed work is nice to have, but because it gives you a competitive advantage

In this ebook, I will share some of the best practices we learned as Upwork grew from two engineers to 200 My hope is that our experience will help you find and work with the very best tech talent in the world

Stephane Kasriel

Advisor, Upwork

Part 1 · Introduction

The essence of great recruiting is to fish where the fish are.John Sumser, CEO of HRExaminer


First things first—what, exactly, is a distributed team?Some call them remote, others call them virtual We call solutions composed of on-site and off-site talent “distributed teams ” In this new hybrid model, on-site and remote employees join forces with independent professionals to tackle projects big and small

You can build your distributed team to suit your needs, choosing to hire employees or independent professionals depending on your needs and applicable laws Laws vary by country, so be sure to consult with legal counsel or work with a company such as Upwork to meet compliance standards



Why build a distributed engineering team?

Unlimited access to talent

When you can work with anyone from virtually anywhere, you suddenly have access to the best developers in the world, whether they are in Singapore or Los Angeles There are prestigious universities outside the U S that rival Stanford or MIT, and their graduates are often looking for opportunities beyond local job markets Even within the U S , there are many talented developers located far from major tech centers By building a distributed team, you get access to the very best talent Period

Mutually beneficial work relationships

When a full-time team member leaves, that skill gap can bring critical projects to a grinding halt With a mix of traditional and distributed talent, you can avoid this scenario altogether

Give people the opportunity to work on projects they care about and the flexibility to work when, where, and how they want, and most will call that a dream job This is why distributed team members tend to form work relationships that stand the test of time Compare that to a typical Silicon Valley start-up in which recruiters are constantly trying to poach your engineers

Lower overall cost

As more and more businesses compete for local talent, engineers in the U S (and especially in the Bay Area) are commanding higher pay than similarly skilled international engineers So for the same budget, you may be able to afford many times the engineering talent remotely than you would locally Depending on your funding situation and your profitability goals, this may be a big decision factor

However, the axiom “you get what you pay for” applies here Given the cost savings, we would advise that you work with only the best remote engineers, even if they are significantly more expensive than the average You can afford the “10x engineers,” the “unicorns,” so take the opportunity!


6Hire Fast and Build Things Part 1 · Introduction

Who benefits from distributed engineering teams?If you’re reading this skeptically and thinking, “This approach really isn’t for me,” you wouldn’t be the first It’s a fairly typical first reaction—until you experience working with a high-functioning distributed team for yourself People quickly discover that online work suits a variety of scenarios, and they see how valuable it can be

Companies looking to grow quickly

Let’s assume you need to scale quickly—either because you raised money or have seen a sudden increase in demand for your product or service How would you do it? It can take weeks to find a single candidate using the typical approach of asking around or searching job boards—and in the meantime, your business is losing ground

Now consider that 25 percent of job posts on our online talent marketplace are filled within 24 hours and the average time to hire is three days There’s no way to find help that fast locally through traditional sources

Teams with skill gaps

Organizations can struggle to find a specific skill set, especially when it comes to technical talent Perhaps the project demands a specialist, or you’re looking for a highly experienced, top-quality professional Either way, going distributed allows you to engage these experts, quickly closing any skill gaps on your current team


Companies starting something new

Whether you’re launching a company or product or building a team from scratch, engaging distributed developers allows you to get up and running in a very short period of time

Companies in need of fast and flexible scaling

One of the greatest advantages of distributed teams is the ability to quickly ramp up or down as your needs change Trying to do this while hiring locally is time-consuming and stressful, whereas distributed teams are flexible, expanding or contracting quickly and easily

Pro TipIf your organization falls into any of these categories, chances are high that a distributed team model is a strong solution for you.

Part 1 · Introduction 7Hire Fast and Build Things

PART 2

Distributed IQ


Team structureThe Upwork engineering team has been distributed from day one, when we were known as oDesk Today our engineering team comprises 13 product managers, 25 engineering leads, 150 developers, and 40 test engineers The team is split into 15 Agile “vertical teams” and also has a few “horizontal teams” that focus on things like database services, test frameworks, and development operations

PRODUCT MANAGER

PRODUCT ARCHITECT

AGILE TEAM

Horizontal Infrastructure Team


Agile vertical teamsFor the purposes of this book, we assume a basic awareness of the Agile development process and methodology If you need more information on Agile, we recommend reading The Art of Agile Development by James Shore and Shane Warden

Every Agile team has a product owner in charge of both the customer development cycle and the product development cycle In the customer development cycle, the product owner has frequent interactions with customers, does a lot of data analysis, and needs to think three months ahead In the product development cycle, the product owner works with developers to make tactical decisions during the two-week Agile sprint cycles

Each engineering lead acts as a scrum master for an Agile team and coordinates projects using five to seven developers Our scrum masters—or, as we call them, product architects—actively contribute to the team by writing code and bring additional skills to the table according to their strengths

Our product architects act as:

• Architects—making technical design decisions and managing technical debt

• Team leaders—assigning projects, setting milestones, reviewing code, and answering questions

• Engineering leads—sourcing and organizing talent through our online talent marketplace

Our Agile teams are full stack Some members may have stronger front-end or back-end experience, but each team has the right mix of skills to operate independently and deliver their portion of the product road map

Interteam interactions: minimizing dependenciesYou never want one team to be dependent on another team to complete work before they can move forward This is even more true in a distributed environment, where intrateam coordination is already complex and interteam coordination adds further friction

Part 2 · Distributed IQ


Each team is responsible for a specific part of the overall code In designing our 15 Agile teams, we were careful to minimize dependencies between them We looked at typical past features and pressure-tested the proposed code ownership structure to verify that, for most features, teams would be able to act independently

While autonomous teams are highly efficient, you do run the risk that they could progressively diverge and stop communicating with each other To guard against this, we have weekly alignment meetings during which teams share their latest technical designs and what they’ve learned, as well as any improvements they’ve made to their tools or operating processes

Collaborating in a distributed environment: technical requirementsAll of our on-site meeting rooms are equipped with videoconferencing equipment, including HD cameras, microphones, and two LCD displays (one for screen sharing and one for seeing remote participants) All remote developers have excellent internet connectivity and professional-grade webcams and headsets for quality conferencing

Typically there are two good times for teams in the U S and Europe to connect: in the morning and late in the evening (U S time)

Overlapping time helps teams synchronize communication and collaboration During those times, we make extensive use of Google Hangouts and Upwork Messages

Pro TipFor developers located in other time zones, we do our best to align on availability to communicate.

11Hire Fast and Build Things Part 2 · Distributed IQ


When availability does not overlap, teams can collaborate using these products designed for asynchronous communication:

Google Docs for collaborating on documents

Take a look at our documents and you’ll find lots of inline threaded conversations in the form of Google comments Some documents are worked on daily by dozens of contributors

JIRA, Confluence, and GreenHopper for project assignments and coordination

Every Agile team has its own JIRA project, and everything a team works on is a JIRA issue Team leads use JIRA to create and assign tasks to their developers Developers can also create their own tasks to provide visibility, and other team members keep a close eye on JIRA issues and comment on them, which leads to a fairly rapid decision-making process We also find the GreenHopper boards to be invaluable because they provide a visual of each team’s progress along the project’s road maps

Upwork Messages for team communication

Frustrated with the limitations (and cost) of popular communication applications, we created our own Developed internally over the past year, we decided to release it—free of charge—to anyone in need of a simple, streamlined app for real-time team messaging and group chat The content is easily searchable and conveniently organized into team rooms


Technologies you may need:1 Videoconferencing equipment or systems

2 Document collaboration systems

3 Project/task coordination software

4 Screen-capture or image-sharing tools

5 A communication and file-sharing infrastructure



Collaborating in a distributed environment: cultural best practicesTo be successful with a distributed team, you have to completely embrace the concept If you treat your remote team as low-value, outsourced labor, then that’s what you’ll get—subpar work with little documentation from a generally unmotivated workforce However, if you treat your distributed team members as important, meaningful contributors, they will respond in kind with high-quality work and enthusiasm

Because they can’t be physically present, you need to consciously avoid a “throw it over the wall” mentality when working with distributed team members Go the extra mile to include them in relevant project communications, meetings, and events This means thoughtful communication on your part

(We’ll talk much more about how you can communicate with a distributed team in a way that fosters collaboration and trust later in the book—but because it is so important, we’re planting the seed now )

Get together, hack together, hang togetherNothing replaces face-to-face time for team building and hackathons At Upwork, we organize occasional in-person get-togethers, sending all members of an Agile team to a single location for a few weeks at a time Similarly, many of our remote team members travel to our headquarters in Silicon Valley, usually once every 18 months or so These visits are extremely rewarding, building close connections within our distributed teams while fostering collaboration and improving team dynamics



Development process

Agile scrumWe use a fairly classic Agile scrum methodology—small Agile teams with dedicated members In keeping with this methodology, these team members make decisions and operate independently with relatively little executive oversight Teams break the work down into features called epics, which they then break down into small, incremental chunks called user stories These Agile teams operate in synchronized biweekly sprints

Agile Development Cycle



While each team adapts scrum to their needs, we follow these standard rituals:

• Daily 15-minute standup meetings. These quick get-togethers are the cornerstone of Agile communication Team members explain what they achieved the previous day, what they’ll do that day, and any roadblocks they’ve encountered, which are usually then taken offline We’ve learned that it’s beneficial to have at least four hours of aligned availability so that teams can continue communicating after the daily stand-up

• Backlog grooming. During the sprint planning meeting, product owners prioritize the backlog of work and developers estimate the work using story points The output of this meeting is a commitment by the team on the payload they will deliver during the up-coming sprint This meeting is, by itself, a great team-building exercise

• The end-of-sprint demo. This is a great time for other interested parties (the “chickens” in the “pigs and chickens” metaphor) to see what the team built during the sprint and to provide input for future backlog items Developers present their demos using Goo-gle Hangouts’ screen-sharing capabilities, allowing everyone to follow along no matter where they are

Are you a chicken or a pig?Basically, if you’re working on a proj-ect where you’ve got skin in the game, you’re a pig. Those who are interested—but not mission-critical—are chickens.

Hire Fast and Build Things 15

Hey, Pig—let’s open a restaurant!

How about Ham and Eggs?

Sure, What should we call it?

No thanks You’d only be involved, but I’d be committed


Source code repository and version controlWe moved from Git to Bitbucket (Atlassian’s augmented version of Git) to take advantage of certain benefits:

• Bitbucket offers a good code review tool, which is essential for our product architects to perform code reviews, often while the developer is in another part of the world sleeping

• Pull requests have proven to be invaluable in the open source community, and they re-ally help with collaboration in our highly distributed environment We use them for code reviews, when developers submit their code changes for approval to their team leads, and for cross-team collaboration When an Agile team needs to make changes to code owned by another team, that team submits their changes for approval using a pull re-quest, which is typically a lot more efficient than waiting for the other team to find time to do the work themselves

• Bitbucket is tightly integrated with JIRA, and this makes collaboration in a distributed environment much easier Every development task is a JIRA issue, and every commit that corresponds to a particular task gets linked to the JIRA issue, making it very easy for every Agile team member to track progress, review implementation decisions, and generally understand how things are going



Our software testing methodologyIn the past, we had a long development cycle with a full week of code freeze and manual testing While having a team of about 30 manual testers in Eastern Europe, Asia, and Latin America wasn’t prohibitively expensive, it quashed quick iteration, causing our product teams to increase the scope of their features beyond what we’d learned about lean development best practices

Today our testing infrastructure is mostly automated, allowing us to complete a full suite of unit tests in less than an hour and a full suite of parallelized functional tests in about six hours This level of confidence in the quality of our product is essential in a large, distributed team and liberating for much smaller teams

After researching various solutions, we chose Jenkins as our continuous integration server On every commit to the master branch, Jenkins runs the entire unit test suite, notifying committers of any issue and providing everyone with a visual board that highlights any failing test plan Additionally, every night a new build is deployed across two staging environments Jenkins spawns Selenium clients on new EC2 instances, and then Jenkins runs several thousand test cases in parallel

The whole process is heavily parallelized The system notifies test owners when tests fail, and team leaders can track site performance over time Theoretically, the main branch of our code base should always be ready for production, and we try to keep the Jenkins team dashboards constantly green

On the unit testing side, we have set specific SLAs on test coverage and we run all functional tests after any code is merged back to the main branch Some of our Agile teams have also moved to test-driven development (TDD) The primary benefit of TDD for us is that it forces us to construct code in a way that makes it more easily testable, which in turn reduces the amount of rewrite that is otherwise needed when it’s time to write unit tests



(RE)WRITE A TEST

CLEAN UP CODE

WRITE PRODUCTION

CODE

REPEAT

CHECK TEST

RUN ALL

TESTS

SOFTWARE DEVELOPMENT CYCLE

Test Fails

Test Succeeds

Test Succeeds

Test(s) Fail

On the functional testing side, we built a fairly complete framework that uses some of the best tools available such as TestNG, Selenium, PhantomJS, Sauce Labs, and Jenkins as well as our own page templating language, which allows test engineers to write tests against existing and new pages or to write full flows while centralizing any changes made to the pages’ UI The regression tests are broken down into prioritized test suites: P0, P1, P2, and P3 P0 tests take the least amount of time (about 15 minutes total), and are reserved for only the most critical business flows, like account creation P3 tests take a few hours because, in these tests, we test some of our more time-consuming functionality



Now developers own the quality of their code, and test engineers are there to build the test automation that allows us to release more frequently with fewer production issues.

Developers run a project’s full unit tests and the P0 functional tests before merging any code to the master branch They also run the relevant unit tests before they ask their team lead to perform a code review (something we’re in the process of automating through a Git hook)

On the organization side, we have progressively moved from a centralized QA team to a model in which most test engineers work as Agile teams This ensures that the test engineers can always know what’s going on and are able to adapt existing automation tests to work with new features and to write new tests as needed

This testing methodology has also dramatically changed our engineering culture Traditionally developers would write code, throw it over the fence, and expect QA to find the bugs Now developers own the quality of their code, and test engineers are there to build the test automation that allows us to release more frequently with fewer production issues

We still have a small, centralized QA team responsible for our performance testing and staging environments, as well as for continuous improvement of our testing automation framework That team also operates as an Agile team

Part 2 · Distributed IQ 19Hire Fast and Build Things


Software development cycle and continuous deploymentDevelopment happens in short-lived feature branches At any time, each Agile team is working on a single branch that is not likely shared with other teams Teams are strongly encouraged to rebase frequently to minimize the disruptive surprises that can happen with merge conflicts and to merge back to the main, always releasable, branch at least once per week Before merging to the main branch, developers must run all unit tests, as well as the P0 functional tests (a subset of the overall functional test suite that runs in less than 10 minutes)

We created our own library for feature flags (heavily inspired by Etsy’s), which enables merged code to be exposed in production only to internal or alpha users This is critical in ensuring that feature branches are short-lived, and it dramatically reduces release risks, since we always release big features in small batches

The main branch gets tagged and released to a staging environment daily There, our automation tests run 24/7, orchestrated by Jenkins This allows every member of the distributed team to get feedback on what broke the build and generally ensures that the main branch is always releasable

As a result, we routinely deploy to production about once a day or on demand We automate all deployment scripts using Etsy’s Deployinator



Building a shared infrastructureOne of the biggest risks faced by any decentralized team is the problem of reinventing the wheel—that is, creating something that, for the most part, someone else already created, thus wasting time and resources on duplicative work Another common problem is a lack of cross-team collaboration, resulting in various teams making technology choices that are ultimately incompatible with one another—more wasted time and resources We address these issues in two ways:

1 We host a regular meeting of all the engineering leads, during which they share recent projects, talk about design and architectural decisions, and collaboratively review all significant architectural changes that are complete or in process

2 A horizontal infrastructure team provides necessary information to the vertical Agile teams, ensuring that work can be done independently and effectively In a sense, these horizontal teams act as referees to the vertical teams, making sure they “play well” together

This horizontal infrastructure team owns the components the other teams use, such as central logging, application monitoring, queuing systems, the A/B testing platform, mail services, file uploading, and caching They also make decisions on which client and server frameworks we use

The front-end infrastructure team is in charge of defining that layer of our system We moved to a set of independent PHP+Symfony2 servers, each hosting a flow or a specific area of the site as an independent app These servers are held together via Composer and deployed increasingly on Amazon Web Services (AWS) via OpsWorks This layer uses our homegrown components library, though the browser code itself is more and more based on Bootstrap components and AngularJS (though we still use Backbone and even straight jQuery for some areas of the site)



The back-end architecture team provides a layer that allowed us to progressively move from our legacy monolithic RPC-based layer to a modern verticalized SOA We deploy this new stack on AWS and built it on top of a series of open source Java libraries and frameworks borrowed from companies such as LinkedIn, Netflix, and Yammer It includes:

• Dropwizard for its RESTful framework

• Thrift for its well-defined, language-agnostic, versioned service contract protocol

• Hystrix for fault isolation in an increasingly complex distributed environment that can otherwise have dramatically cascading failure patterns

• Eureka for service discovery and service load balancing

• Yammer’s Metrics library for instrumentation

• Guice for dependency injection

• Archaius for configuration management

• Jetty to allow a service (or an assembly of services) to run in its own process

The database architecture team owns our caching strategy and helps other teams make optimal database choices Our data layer is also progressively moving to AWS, leveraging Amazon’s own database technologies such as Dynamo in addition to our traditional PostgreSQL and MongoDB instances We also use Greenplum clusters for analytics, modeling, and reporting, which we have found to be sufficient for our big data needs and a lot less onerous to build, maintain, and use than the fancier Hadoop-based solutions

Agile teams typically use the same tools as the horizontal infrastructure team However, if they want to use other technologies, they are welcome to make a case for doing so



Operations and Amazon Web ServicesWhether or not to use AWS, and to what degree to be locked in versus having an easy out, is commonly discussed in the start-up community We use AWS—and it was only after the organization committed to be all-in that we started to see the true benefit

If you treat Amazon like another hosting service or want to build your code so you can walk out of Amazon at any point, then you won’t benefit from all the advanced tools AWS has to offer Basically you’ll be getting the worst of all worlds The true benefits come when, after having committed, you design your software with the requirements of the AWS platform in mind We adopted AWS for the same reasons others do: automatic scaling, the ability to fail over multiple availability zones, its accommodations for peaky traffic and intensive operations (e g , some of our machine learning models), and its ability to free up the team to focus on application-specific work rather than solving problems Amazon has already addressed

In addition to these mainstream reasons, there are specific advantages of AWS for distributed teams We used to host our development and staging environments in our local data center, resulting in high latency for developers For our new, AWS-based stack, developers can easily spawn environments that are closer to them and thus more responsive, and they don’t have to worry about the load they create on our servers or the impact they might have on other teams

Pro TipAWS is a powerful platform that empowers remote developers and further enhances the mentality that local developers should not have an advantage over remote developers.


PART 3

Taking the plunge


Overcoming common concerns about online work

“Outsourcing product development is a terrible idea.”We agree! Product development isn’t something you should outsource if, by outsource, you mean the traditional “throw it over the wall” outsourcing But there is a big difference between old-school outsourcing and building a distributed team Distributed work done right creates a well-oiled hybrid team of employees and independent talent who get to know and respect each other Traditional outsourcing, not so much

When you work online, your process should be the same as it would be with someone who lives down the block Interviewing, team coordination, open communication and collaboration, and everything else that goes into building a traditional team still applies This isn’t about finding the cheapest person and sending them tasks to check off (You wouldn’t take this approach with local talent—why do so when working with someone remotely?)

The bottom line is that if you treat distributed team members as important contributors, they will deliver better results Remember, you aren’t simply outsourcing—you’re building relationships

Distributed work done right creates a well-oiled hybrid team of employees and independent talent.

25Hire Fast and Build Things Part 3 · Taking the plunge


“The process is going to be too slow.”You might think that hiring online is too slow or tedious In reality, it is much faster than hiring through traditional sources On Upwork, that’s definitely the case—a quarter of our site’s job posts are filled within 24 hours, and the average time to hire is only three days Traditional hiring can take months With online hiring, you can enjoy the flexibility of meeting online, there is no commuting, and you can learn a lot by reading personal online profiles before you decide to contact a professional

“There won’t be any trust.”The issue of trust when working with a distributed team is one of the most common—and one of the most misplaced—concerns

When it comes down to it, an on-site worker can just as easily do bad things as someone working online Proximity does not guarantee integrity Hiring online often provides more transparency, since you can see feedback from previous clients and more easily “test-drive” your relationship If your ability to enforce IP rights and other legal aspects of the relationship is a concern, simply consider narrowing down the countries you work with or invest in legal services

Keep in mind that independent talent who use online marketplaces rely on great feedback, testimonials, and references to secure more work in the future They are professionals with reputations to protect and families to support They want to do a great job

Part 3 · Taking the plunge


Hiring and working with remote developersWhether you’re hiring through traditional sources or dipping into the Upwork marketplace to find the right developer, here’s a simple eight-step framework you can use to build a technical team:

1 Describe the work

2 Select a few potential candidates

3 Create a test project

4 Bring on the best engineering talent

5 Create goals and objectives and set expectations

6 Develop a communications plan

7 Create a collaborative environment

8 Adapt and iterate

Let’s go through these in more detail...



1. Describe the workWhen hiring for technical work, companies post two types of jobs:

1 Longer-term roles: These are the types of roles you would post on your website, give to your recruiter, or post on a job board

2 Projects: These are well-defined projects with specific deliverables or tasks that are, essentially, requests for proposals

As you write your work description, be sure to articulate which type of role you’re hiring for Include specific information about what the work might entail over time and the skills the candidate must have to be successful

Consider adding screening questions you want candidates to answer They can be technical questions or requests (“Can you send me a code snippet that does XYZ?”), questions relating to their experience (“Have you worked on similar projects in the past?”), or even simple questions about their availability

As you would for a local developer, you need to give online candidates a compelling reason to work with you Tell them what makes your company special, demonstrate your understanding of distributed teams, and share the importance of projects they will be handling

A word about ratesRates on online marketplaces like Upwork tend to be fairly efficient, meaning you get what you pay for. We typically only hire talent rated in the 90+ percentile for their skills. Read ratings and reviews from previous clients on Upwork’s talent profiles. These are some of the most reliable ways to gauge success. Again, if you want to develop a high- performing talent pool of top-notch engineers, penny-wise is pound-foolish.



2. Select a few potential candidatesDo you usually post on a job board or Craigslist—and then brace yourself for an avalanche of low-quality applicants that makes it difficult to find the few true gems? Or do you strategically search for high-quality talent on professional social networking platforms like LinkedIn?

These same search options exist when hiring online:

• Post and wait: Post your project publicly and wait for candidates to submit a proposal (Not our top recommendation, as the best developers are quite busy and usually only respond when invited )

• Post and invite: Invite carefully selected candidates to submit a proposal In searching for potential candidates, you want to use the full power of the platform’s search engine

• Use Boolean queries to narrow down the keywords that matter the most

• Search by country if you’d like to build a team that is physically close to other members of your team or in a certain time zone

• Look at their skills test scores, which are a quick, nonscientific way to assess a candidate’s skill level

As a rule of thumb, invite 5 to 10 developers to apply to your job On average, top-tier developers only accept about 25 percent of their job invitations, because they’re busy, they have a lot of options, or they haven’t been successfully sold on the opportunity

If you’re new to hiring online, going after tried-and-true talent will help make your first team-building experience go smoothly To do this, you can filter candidates using client feedback scores, number of hours worked, and other criteria, and budget for a higher hourly rate Once you’ve learned the ropes, consider hiring some newbies who may have great skills but aren’t as sought-after simply because they have yet to build up their reputations



The key qualities of a remote developerWhen you get to this stage, you have hopefully found developers who match your technical skills and specifications While that fit is crucial, you also want to make sure the person you bring on is a good fit for you and your team—and this means looking beyond technical ability Having worked with hundreds of developers, we’ve found that these are some of the most desirable traits:

Intrinsic motivation

One of the first things we look for is passion The person you choose needs to be excited about their work, your company, and the industry they work in Don’t go with someone solely for their skills Pick a candidate who is self-driven and motivated, especially since the person will work remotely Passion is critical in building a good culture for your team, regardless of where members are located

Culture and shared values

What kind of culture do you want to cultivate for your company and developers, both on-site and remote? You want to find someone who shares your team’s work philosophies For example, if you place a premium on collaboration, then a lone wolf won’t last long; regardless of how good their work is, their style will disrupt the team dynamic Whatever your company values are, make sure you bring someone on board who reflects them

Communication skills

When you have access to developers across the planet, English will not always be their first language It’s important to know that you can easily communicate and collaborate with your team via verbal, visual, and audio means For example, if a team member sends an email, will you be able to understand what they are trying to say? What about chat?

This is not to say their English has to be perfect, but you do need to make sure you can easily communicate Have at least one video interview with your top candidates—if you can’t communicate during the interview, you won’t be able to after the developer joins your team


Manage the flow of your applicants

Act fast when a qualified developer responds to your job post, because the best find work in a snap As soon as you get a great candidate, schedule a video interview using Skype or Google Hangouts This makes the interaction feel more personal, allows you to verify that the two of you can communicate effectively, and ensures that the candidate has the hardware and bandwidth required for successful videoconferencing and, ultimately, for working Of course, you also want to use this interview to test their skills, just as you would if you were engaging local talent

3. Create a test projectOne of the unique advantages of assembling a distributed team is that you can take developers for a “test drive ” Simply ask the best candidates to complete a small test project before offering a contract for the main job You will, of course, pay for the work, but the cost is minimal when you consider that this investment will dramatically reduce the likelihood of making a bad choice The test project should be something that can validate the person’s technical skills as well as show how the candidate collaborates and communicates with you to get things done

We offer our developers a two-week “boot camp” program during which we gradually provide them with more information and code access to test their ability to solve increasingly more difficult problems Those who do well become a part of the team


JOB POST


4. Bring on the best engineering talentBased on the test project, you may engage one or more developers At this stage, you will want to get any formal paperwork taken care of: background check, signed NDA, contract, IP agreement, and anything else your company requires If applicable, set up any systems you will need to start working together, such as Google apps, JIRA, etc

Welcome them to the team with a warm introductory email Then double-check that they are added to the appropriate meeting invitations and distribution lists and have access to the right onboarding and project documents

5. Create goals and objectives and set expectationsSetting clear goals, particularly at the beginning of any work relationship, is a best practice—and it is even more critical when working with a distributed team Share your overall long-term goals at the beginning of the contract to get your new team member on the same page Avoid misunderstandings by articulating short-term goals on a daily basis

6. Develop a communications planSimilarly, whether you adopt stand-up meetings or not, you should check in periodically with your team If you have agreed on certain times of day when you are both available, now is the time to put that availability in practice by going over your task list (we use JIRA, but Trello, Asana, or Basecamp also work well)

In working with a distributed team—when time zones, languages, and cultural differences come into play—it is often better to overcommunicate This isn’t nearly as time-consuming as you may think In 15 minutes with each of your team members, you should be able to define clear tasks and review any blockers that impeded previous progress



7. Create a collaborative environmentAt this point, you should get into a daily and weekly rhythm If you have adopted Agile, collaboration can be as simple as holding daily stand-up meetings, retrospective and sprint planning meetings, and an end-of-sprint meeting for demos

Whatever development method you choose, remember to coordinate appropriately with your distributed team They don’t have opportunities for the casual hallway conversations local team members benefit from, so encourage people to chat over a virtual water cooler (IRC, Upwork Messages, a persistent Skype chat room, etc ) and remind them to keep the remote team members in mind at all times

Remember that this isn’t about old-school outsourcing—it’s about building and growing meaningful team relationships This means that regular collaboration on ideas, products, and services should be part of the program

8. Adapt and iterateAs things progress, you and your distributed team will have to adapt and make changes Sprint retrospectives are a great way for all team members to surface issues and offer solutions, providing for an environment of continuous improvement

This might include things like expanding a team member’s responsibilities as your priorities shift, using new technologies for communication and collaboration, adjusting meeting times, or anything else that comes up What’s important is that everyone understands that change is expected and the team simply needs to adjust accordingly



Focus on the relationshipHopefully by now you see the strengths of distributed team-building over traditional outsourcing The next step is to turn the relationship into a scalable one

We have engaged some of our developers and technical talent on and off for more than five years Our team leads have been able to maintain these mutually beneficial work relationships by following three rules of thumb:

1 Establish from the start that there is mutual interest in longer relationships

2 Take steps to make your remote team members feel valued

3 Focus on motivation and engagement

Identify mutual interest in longer relationships

This is a relatively simple thing to do and just requires being candid and up front about your intentions and expectations When hiring, find out if candidates are interested in building a meaningful work relationship with you and your company Of course, in order for them to make this decision, they need to be clear on your expectations and their role in the work Share as much information as you’re comfortable with to help them understand the project and give you an honest answer

Make distributed team members feel valued

Whether they are local or online, treat all of your developers as though they are equally valued players This means giving them the relevant information, sharing with them the same successes or failures, and collaborating with them throughout the project Rely on your collaboration technology to make this easy, and consider giving them certain high priorities or allowances to keep them engaged



As a rule, all meetings with our distributed teams are done via videoconference This gives us that “watercooler” vibe—people joke, get to know each other, and shoot the breeze in a way that can’t be replicated on the phone Remote team members always have the option to speak first, and only they can stop and interrupt a meeting while someone else is talking They are able to do this because they aren’t in the same room and can’t sense the dynamic the way those in attendance can

This is somewhat counterintuitive, but interesting nonetheless: We’ve found that meetings in which all or most members are remote via videoconference are the most productive Basically it puts everyone on a level playing field, as opposed to having six people in a room together and one or two on video


Remote team members always have the option to speak first, and only they can stop and interrupt a meeting while someone else is talking.


Focus on motivation and engagement

Your team members should want to work with you because they are motivated and inspired by the challenges they’re given Mentoring can be a great way to engage your entire team, and it requires giving them the necessary support they need to be effective at work It can also include everything from tackling a problem together to learning a new skill to helping them find a healthy work/life balance

Progression is another crucial component of motivation and engagement Is there an opportunity for them to take on additional responsibilities or work on other projects? Keep this in mind as your developers evolve their work and improve their skills

Finally, use rate increases to show appreciation for their work—this is a must if you want the relationship to last multiple years (Our developers get regular compensation increases ) And keep in mind that inflation and market rates may be increasing faster in the developer’s country than in your own market

Of course, money alone is not a good substitute for engagement and motivation, so use rate increases in conjunction with the other motivational factors Show them you value their input by asking for feedback and ideas and incorporating them when you can Limit “drone work” when possible and ensure that team members are a part of a strategic vision, not just the tactical one These are the most important factors when looking to build a meaningful work relationship

The next logical question is about scaling: How do you go about growing your team?



Scale your distributed teamAs your team requirements increase, you will need additional developers So how do you go from one distributed team member to two or five or ten? Follow these three tips to scale your team effectively:

1 Avoid being the hub

2 Use technology

3 Create teams

Avoid being the hub

In the beginning, you are naturally the hub through which everything passes Any piece of information or decision that needs to be made goes through you However, as your distributed team starts to grow, this structure becomes less and less scalable Eventually this will slow work down, create longer decision times, and put an overwhelming amount of stress on you This is obviously not what you want As your team grows, you need to empower other members to make decisions, whether they are product-related or about adding new members to the team

Use technology

Technology is the glue that holds your team together, especially as it grows and becomes increasingly distributed over time Whether you rely on videoconferencing, collaboration platforms, instant messaging, or software building tools, technology will enable your team to succeed Make sure to continually evaluate new technologies as your team grows

Create teams

At a certain point, your organization will grow so much that you need to form teams within your larger team You might have just a handful of developers involved in a variety of projects at the beginning, but eventually some team specialization will be required

For example, you may need a separate group to focus on front-end development and another one to focus on back-end development A good rule of thumb is that if more than three people work on a specific function or area, it might be a good idea to formalize that group as a team Setting up official teams is great because they can own their respective areas—and that allows you to scale without pulling your hair out



Development… and beyondAlthough we have primarily focused on building distributed development teams, the possibilities go far beyond the technical Using online staffing solutions such as Upwork, you can tap into a vast talent pool of marketers, writers, SEO and PR specialists, customer service experts, and even finance, legal, and bookkeeping professionals Whatever your business needs to thrive, chances are you can meet those needs by creating and scaling a distributed team

In conclusion: How we work is changing for the betterThere are more than 5 billion people worldwide over the age of 16, yet most of us desperately try to source the skills we need from our relatively tiny professional networks or a limited local talent pool We haven’t gone much further because that vast pool of talent has been impossibly difficult to access But that barrier to hiring is disappearing rapidly



Gone are the days when you had to do your best with whomever happened to be available nearby And gone are the days when traditional outsourcing was your only option if you couldn’t find the talent you needed There is direct access to the talent you need now On Upwork alone, millions of independent professionals are registered, offering thousands of skills (2700+ at last count) Among these skills, many are tech-focused and are often the rare, high-demand skills so difficult to locate otherwise

In fact, many people try Upwork for the first time because, when they simply can’t find the talent they need, they do a search for that specific coding language or programming approach, and up pops the perfectly matched independent talent on our marketplace

Talent is the next wave, and it’s already here in the form of distributed teams working together online The future of work is being reinvented by people just like you who are forming the teams that will shape tomorrow


Businesses have shifted their software to the cloud, as well as their files and their communications— so why not talent?

40Hire Fast and Build Things 40

THE TAKEAWAY Top tips on creating a successful distributed engineering team1. Find the best talent, and don’t focus only on cost.

2. Communicate and collaborate.

3. Be persistent and expect there to be a learning curve.

4. Create overlapping availability for your team to be online.

5. Use technology for asynchronous and synchronous communication and collaboration.

6. Make remote team members feel just as valued as on-site engineers.

Ready to get started?

Get Started

Find your web developer on Upwork

Hire Fast and Build Things The takeaway

Examples and case studies


Automattic is the company behind WordPress.com as well as other products and services including Akismet, Simplenote, Jetpack, Gravatar, and VaultPress. It is also one of the best examples of how a company can take full advantage of the benefits of distributed teams.

Acting as a distributed company from day one, Automattic has grown to around 250 people in more than 140 cities in nearly 30 countries. To get a better sense of how the company operates, we spoke with Martin Remy, who leads the data team.



How they work: communication and organizationAutomattic keeps in touch with an internal platform for instant messaging and videoconferencing it created called o2 (teams also use Skype, Slack, and IRC) They have weekly team video hangouts On average, people see each other in person two or three times a year, and the entire company gets together on an annual basis

At Automattic, ideas are generated within the team as well as across the organization One of the biggest benefits of being distributed is that there’s no more distance between teams than between team members, so there’s a lot of cross-pollination between teams Once an Automattic team takes ownership of turning an idea into a product, they embark on an Agile development process that usually begins with a squad of three to five people brainstorming with a designer to create initial product requirements and mock-ups

The squad then divides responsibilities and iteratively builds the project, checking in daily with each other and several times a week with the team lead Automattic makes products available internally to the company as soon as possible, and every developer is empowered to deploy code to production, which happens more than 100 times per day When a product or feature is shipped, the announcement is usually written by one of the developers

All team members at Automattic are remote For example, Martin’s team has 18 members organized as two subteams The subteam leads partner with Martin, but they also have common video hangouts where the whole team meets and discusses projects, socializes a bit, and talks about upcoming in-person meetups Engineers are encouraged to switch teams once in a while, which keeps teams from becoming static, fosters mobility, and encourages broad-based continuity of knowledge



How they roll: culture and collaborationBefore joining Automattic, everyone must go through a tryout period lasting a few weeks But once someone officially comes on board, they get full access to everything New members are welcomed by the HR team and go through a guided online tour of Automattic (appropriately called Welcomemattic), while an internal blog called the Field Guide to Automattic documents development and operations

Nurturing a collaborative and entrepreneurial culture is hugely important This is especially critical in a new teammate’s first few weeks while they are internalizing how Automattic works and collaborates It’s also a time when the company is especially receptive to new insights from fresh eyes

One of the fascinating things at Automattic is that everyone, no matter their rank, spends their first three weeks doing customer support This is done not only to help new coworkers become familiar with their products but also to learn who works on which products and features throughout the company and what makes their users tick

Automattic probably wouldn’t be where it is today without distributed teams The company recognizes that location-independent work means no commute, allowing people to spend more time with friends and family—which in turn makes them happier And the happier they are with how work fits into their lives, the more passionate they become about their work, which translates into productivity and innovation

Automattic probably wouldn’t be where it is today without distributed teams.

44Hire Fast and Build Things Examples and case studies


Chess.com lets people learn and play chess for free from the company’s website or mobile app. Erik and Jay founded Chess.com in 2005 after deciding they wanted to build an online home for chess players around the world. Jay built the back end, and Erik designed the front end. Today Chess.com is the largest online chess community with more than 13 million members worldwide, hosting more than one million chess games daily.



How they work: maintaining a face-to-face culture in a 100% virtual companyChess com operates with a team of 60 programmers, content editors, and support staff Its team is entirely virtual and located across 12 countries In addition to its team, Chess com pays world-class chess players, coaches, and professionals for top-level chess content

The company also relies heavily on independent talent for specialized skills and projects Since its launch, Chess com has worked with more than 120 independent talent in 29+ countries, sourcing talent from Upwork, the Chess com community, and other sources

Erik warns, “You may have a hard time finding someone in Silicon Valley who wants to work on your project because they’re either working for another great start-up or maybe working on their own thing ” That’s why he favors talent solutions such as Upwork: “It’s an amazing way to find really talented people all around the world who can scale your organization in a flexible way We’ve found that on Upwork, many of the developers are ahead of the curve ”

The company runs an unusually flat structure where Erik does most of the hiring and coordination Once talent starts, he trusts they will do their work Erik doesn’t micromanage time sheets or require screenshots because “I wouldn’t want someone doing that to me ”

Running a distributed company with such a flat structure creates a challenge: transparency in specific tasks For ease, Erik uses various thir- party tools that aggregate project updates into a daily report

Chess com stays connected with its team through the following technologies:

• HipChat for hanging out, introducing new talent, and collaborating

• Github as a code repository

• Email for nearly everything

• Skype for video chatting and international calls



How they roll: valuing work freedom and long-term relationshipsErik didn’t start Chess com wanting to create a distributed team He thought they’d grow to five employees at most As they got busier, he needed people Using independent talent became the quickest way to find more resources as specific projects arose Today the company engages many independent developers and is open to talent from around the world Erik’s interview process includes a Skype interview and a 2- to 10-hour test project For interviews, he looks for skills and fit Video chatting via Skype helps Erik validate the person’s skills

“At the end of the day, I have to work with this person,” he explains, “so I need to connect with them I want a video to see personality, so I know who you are It’s important even when working remote because we’re human We have to communicate, we have to collaborate ”

Erik keeps his distributed team connected by embedding it into the company’s culture This starts with mindset, where he searches for talent expecting a long-term relationship, and includes purpose-driven practices such as introducing new professionals “around the office” via a group video chat Encouraging conversations allows connections to take root

But nothing trumps face-to-face meetings Each year the company hosts annual meetups at a fun location such as Cancun, Mexico “After these events, everyone’s kinder and more helpful to each other at work,” Erik says “We end up liking each other as people, instead of being just a bunch of text on a screen ”

By fostering human connections, staying flexible, and establishing communication channels, Chess com continues growing while relying on a distributed team “At the end of the day, we want freedom to live our lives,” Erik says “Pay helps give people freedom Some of our people moved out of Russia Some spend winters in Thailand I’m a huge believer in the distributed workforce model I love how Upwork gives companies like Chess com freedom and how it allows our team the freedom to choose how to work ”



Lucinda Brown founded Trillamar Webcraft, a Los Angeles-based web design and development agency, more than a decade ago. Although launching as a solopreneur, Lucinda quickly realized she needed help and discovered Upwork’s online workplace. Today her distributed team has members in Germany, Bulgaria, Pakistan, and the U.S.



How they work: finding the right talentLucinda had varying degrees of success when she first started using independent talent But as she learned from her experience and improved how she chose and onboarded her team, online work became a backbone of her business She found that her most successful team members were those given a thorough work description, along with some supplemental video content about the business In addition, she limits her talent search to inviting specific people to the project instead of making it open for anyone to apply These two changes dramatically improved the quality of her candidates, which in turn led to more successful engagements

How they roll: communication and motivationBy making creative use of videos, Lucinda has found a fun way to show team members what her requirements are, burying a secret password in each video to be sure team members are paying attention This approach adds a personal touch while making it easier for members to understand the company’s needs

Lucinda works with her independent professionals individually, and although they know of the others’ existence, the team members don’t communicate She takes a one-on-one approach with each of them but expects this to change as her company continues to grow She also keeps the lines of communication open to make sure her team members are enjoying their work and are satisfied with how things are going

To foster healthy work relationships, Lucinda builds a bit of flexibility into her turnaround times, as most distributed team members are working on other projects simultaneously She expects her midlevel members to increase their rates by around $2 an hour every six months, assuming they are performing well (Those at the top of the pay scale will generally not go above market rate ) She also provides bonuses for certain projects For example, if she needs something done ASAP, she might promise the developers a 20 to 50 percent bonus if they can meet her deadline



About Stephane Kasriel

Stephane is an experienced engineering leader, but his expertise goes beyond engineering He has applied his knowledge to nearly every industry—from customer service to design to law

Stephane holds an MBA from INSEAD, a master’s from Stanford in computer science, and a BS from École Polytechnique in France Learn more about his perspective by viewing his keynote at MIT Technology Review’s EmTech Digital and his Q&A on Bloomberg View

About Jacob Morgan

Jacob is the principal and cofounder of Chess Media Group, a management consulting and strategic advisory firm specializing in the future of work and collaboration Jacob has worked with companies such as Sodexo, Safeway, Franklin Templeton Investments, Lenovo, and many others His latest book, The Future of Work, has been endorsed by business leaders such as Intuit’s CEO Dan Pink and Tony Hsieh, CEO of Zappos His previous book for McGraw-Hill, The Collaborative Organization, became an Amazon best-seller

Jacob is a judge for Gary Hamel’s Management Innovation Exchange and has been named by SAP as one of the top influencers on human potential He has been featured in media outlets such as the Wall Street Journal, USA Today, Inc magazine, CNN, and Fast Company, and is a popular contributor at Forbes, where he writes about the future of work Jacob blogs at TheFutureOrganization com and speaks at conferences and events around the world You can follow and connect with him on Twitter @JacobM

© 2020 Upwork, Inc. All Rights Reserved.

Upwork is the trademark of Upwork, Inc All other trademarks are the property of their respective owners

Documents

Hire Fast & Build Things · 2020-04-06 · Hire Fast and Build Things 4 First things first—what, exactly, is a distributed team? Some call them remote, others call them virtual