How Savvy US Businesses are Managing Co Located Developer Teams
Curious about what it’s like to manage a remote developer team? We can tell you what it’s like from our end here at Jobsity, managing client-assigned co located developer teams on behalf of clients. But how have companies working with remote developer teams learned what success looks like, and what kinds of management structures do they use on their end?
We found thousands of comments from hundreds of companies about this topic, collected and published by Remote.co., a site that surveys and collects data on remote teams. Below is a curated selection of some good questions and answers, for anyone considering whether a remote developer team is the right choice to develop or scale their digital assets.
Why is remote development work important to your business model?
Hiring the best – we aren’t just limited to the best people we can hire who are also located within a 30 mile radius of our office. We can now hire the best candidates anywhere, period.
While working remotely isn’t particularly impactful on how we run, it has shaped how we think about and design our software platform. Attentiv was created with remote teams in mind, so how remote teams would use the tool has largely impacted the features, layout, and experience we’ve crafted with Attentiv.
[Free Guide] Building Distributed Teams through Staff Augmentation: Download the Guide
Pretty important. Not only does it make finding talent easier (covered in other sections), but having a remote team, across multiple time zones, allows us to provide better support. We also have a lot of customers that also have co located teams, and they appreciate that we are a distributed team.
We like to compete on customer service, so it’s very important for us to have both sales and tech support people spread around the world to cover more time zones. Being geographically dispersed also gives us the advantage of moving faster…the software gets tested while the developers sleep, for instance.
What do you consider the biggest benefits of remote developers and engineers for QA, Testing and other team functions?
Happiness, productivity and retention. People love having the flexibility to work this way, and because you don’t score points for sitting at your desk it’s impossible to pretend you’re working. Not being in an office greatly reduces office politics and employee conflict, yet our always-connected tools like Slack and Google Hangouts means that we actually know our co-workers better than many companies where people share cubicles in the same building.
When work doesn’t happen 9-5, in one building, a lot more work can get done a lot more hours of the day.
With the explosion of technological advances, we don’t believe that businesses today need a physical location to operate successfully. So we don’t view our structure as “integrating remote work”, but rather ensuring we create a business structure that focuses on supporting the initiatives that most benefit our clients. It is our responsibility and desire to have the best talent from around the globe, to have team members who understand the expat life from personal experience, and to focus our business spent on the areas that generate the most value for the client. We truly don’t believe that an office environment would allow us to do that.
A loosely “just in time” talent acquisition strategy, that lets us scale to the market and customer needs with relative fluidity. While we can take 4-6 weeks to onboard and train new talent, we can’t just bring in any software engineer and wait 6 months to a year for them to become productive, especially when we were much smaller and, having always bootstrapped the business, on a lean budget.
What lessons have you learned about effectively managing co located developer teams?
We are more organized now. You have to be extremely organized if you want to go remote because it’s easy to get lost in emails, apps, websites, etc. If you have file-heavy processes, the best thing you can do is come up with a virtual filing system with consistent naming protocols and easy search algorithms.
We have gotten smarter about the tools we use, better at documentation and checklists, better at reporting, and we’ve spent more time in-person periodically throughout the year to get to know each other better.
We developed a concept of core hours and started to avoid hiring from locations where the core hours are during the nighttime. We did this because we noticed that nobody wanted to ask a colleague to wake up from sleeping to have a meeting, and as a result, important meetings were not happening.
We added more steps to our hiring process to try to protect against hires that didn’t work out in the past. We added core value panels, reference checks for specific people, and questions to screen for harmony-breakers.
Meetings are more sophisticated: we have colleague-led fitness breaks, custom ice-breaker questions, and a “hive mind” like collaborative style that makes meetings feel efficient while still covering contentious topics.
The most noticeable change for me has been the size of the company and the effect that has on team (and inter-team) dynamics. When I joined GitHub in 2012 we had just over about 80 employees, and it’s been really interesting seeing that number almost quadruple in three years.
Since our teams are largely autonomous, the company’s growth has forced us to really level up the standards for how teams communicate—both internally, and also externally within the company at large. The tools and habits that work effectively at 80 people are radically different to what works at 300 people—your communication has to be far more regular, have more clarity, and requires much more forethought—and this is especially important when it comes to communicating organisational change. You have no choice but to evolve the tools you use and your habits around them in order to scale well.
How do you measure the productivity of remote workers?
We measure productivity the same way traditional office workforces measure it – we look at the results. Being a remote workforce truly shouldn’t be a large factor in measuring productivity. Some of our teams operate in the Agile methodology of project management and development, and the teams themselves are self-measuring. The accountability that members of an Agile team have to one another pushes everyone involved.
We are software developers, so we use a variety of tools to track objectives, milestones, and the resolution of technical issues. Our support team monitors email inboxes, social networks, and forums. It’s very easy for us to monitor productivity: if questions are being answered, bugs are being marked “fixed,” and customers are happy, we’re doing what we’re supposed to be doing.
We’re lucky to be in the development industry where there is a plethora of tools one can use for tracking, such as project management tools like JIRA where most development gets tracked in many ways.
Co located teams live and die by each person’s ability to keep things moving forward. It’s the only way to battle the timezone, communication and trust challenges that come with this setup. So although project management tools can be helpful in tracking productivity, you’ll want to be far more aware of each team member’s progress on a daily basis rather than waiting to find out in 2 weeks that deliverables are missing.
It goes back again to journaling and finding ways to have a deliverable every day, regardless of whether it’s something ‘tangible’ or a list of updates on progress made with some evidence to back it up. The more trust each person contributes by showing progress of moving things forward, the stronger the team will be and won’t have to worry so much about constantly tracking productivity.
Jobsity and Co Located Teams
At Jobsity, we act as the interface between you and your remote team. We recruit, onboard, train and house teams of developers and engineers and help clients assemble the right team from our available talent. The value we add is to remove all the administrative and HR burden, and the client gets a fully operational team with the right skill sets and functional knowledge, all ready to go on Day 1. Our developers and engineers have a broad range of talents in different coding languages and technologies (Drupal, Angular, React JS, Python, Php, Java, Wordpress and QA) so that we can assemble exactly the talent mix needed for a particular client’s team.