Remote teams work from home, why shouldn’t Jedi?

Having built a remote team of software engineers in New York City a few years ago, there were several lessons learned about how to build a team that sits apart from the rest of the team and how to make them successful. A lot of companies have trepidation about starting a remote team outside of your headquarters, as they should. There are some serious pitfalls, but there are some nice benefits as well, one of which being it gives you a second base to interview and hire candidates into. There are several great articles on the pros and cons, this post focuses on how to do it well.

Here are four tips to make a remote team successful:

1. Give them a clear project to own, soup to nuts. The less they need the other office the better in this regard. Best would be to build on top of an existing, refined and documented API. This minimizes communication delays and back and forth between headquarters and the remote team. It also helps the team at HQ get used to a remote team. (Side note: Keeping them in timezones helps communication as well.)
2. Inject leadership from HQ. Sending a cultural & technical leader with depth of knowledge of the stack, team, and processes will help to keep them anchored to the team back home. This ties the culture and helps to make sure you hire to the same bar and that remote team members will get along with team members back at home.
3. Get your leaders early. Give a lot of leash to hire a great group of early engineers, and sprinkle in a handful of great consultants if you need to get the project flowing quickly. Having some key wins in the first few quarters is a key to the remote team feeling like they’re a part of a bigger picture. It also gives you enough people on the remote team that you can begin to formalize your team’s culture a bit more.
4. Hire local leadership. Backfill the cultural leader and start building a second team. Just as a team of one is not a team, an office with only one team is not an office (or at least not much of one.) People need the ability to switch teams, move between projects, and spitball on projects with people not on their immediate team. This also gives you a succession plan, flexibility for your leaders as the remote team continues to grow, and growth opportunities for leaders at your remote office.

With any successful business, you’re going to have to eventually have to learn how to have product, design, operations, development or other functions distributed into other teams. It’s only a matter of time before you’ll have to have two locations for development, so before you get to the point of needing a second center, get it spun up and firing on all cylinders.

As I’ve been a part of several fast growing Engineering teams I’ve seen a number of approaches to building out a Quality Assurance organization. Sometimes this has gone well, and others it has been less than effective, which will be the focus of this post. I talked about these in an Ignite style presentation today at DevOps Days Austin, but thought these would be good to share here as well.

The first anti-pattern is hiring a “pile of testers.” While manual testers have their place, and can be a useful at times, only having testers will not dramatically help you produce better quality software. The thought process goes that this is outsourcing work that otherwise your developers would be doing, which is in itself a good thing. However, simply having testers produces typically produces two things: test plans & manual tests. The bad news here is that this means that each release you want to ship the manual regression suite will grow, as will the cost of testing/number of testers required will increase. Also, my experience was that the detail oriented nature of testers produces a lot of miniscule bugs, minor UI issues, and not the more systemic release issues.

To lower these costs you can fall into the second trap, of outsourcing it to another team and/or another country. While your team overseas can be cheaper on the hourly rate, all of our validation showed that the total cost of ownership on this work amounted to an equivalent Senior Engineer based in the United States. Additionally, if you choose to outsource, they often don’t have the same level of commitment to your project. If you are just expecting a bolt-on team to add quality to your product, you’ll likely find that it doesn’t work.

The final anti-pattern is similar, throwing the process, tools, and responsibility for creating quality over to another team, whether your quality team or your DevOps team. The truth is that you need your entire company, and certainly your entire engineering team committed to quality. Engineers building software and throwing it over the wall to another team is an opportunity for confusion, frustration and lower quality.

I’ll cover some best practices in building out quality at scale in a future post, but this airbnb post provides some thoughts to get started with. I’m not so simple as to believe that you can boil quality down to only one thing, and of course your mileage may vary with these tactics above, but if I had to focus on one and only one thing it would be that every engineer owns every line of code they write.

Building a strong software as a service (SaaS) business you’re focusing on scaling your software, but simultaneously you’re inevitably needing more supporting personnel. You’re hiring account managers, support technicians, quality assurance, sales directors, and more folks to keep the business humming and growing. Each new client often means that more people will be needed to service that account. Of course as you grow you’ll need more of these people, and many other roles as well, but the question becomes does each new account linearly add some number of additional hires to your roadmap? Can you bend that curve and change the ratio of new accounts to new hires?

The great news is that if you’re team is building software then you’ve got everything you need to change that game. Using innovation and software to eliminate, be more efficient, or to fully automate some work will drastically change the calculations on how many new employees you’ll need. But first, you’ve got to get the baseline metrics on where your team’s time is going.

Metrics will rule the world

Knowing where the time is going will give you a true data driven approach to determine how much you can change the equation. If you find that all of your team’s time is in elements that have to be done manually or by a human, then you have to look for another area for improvement. If on the other hand you find large areas of opportunity to automate you’ve got your direction. Having at least one team dedicated to internal tools and process improvements will pay huge dividends over time in at least three areas.

1. Efficiency. Shaving off 10% of the work from a 10 person team is equivalent to giving them an extra hire. It’s not easy, but it’s a huge win that will pay off over the long term. Using the metrics on which type of issues have dominated the most of your team’s time will give you the prime targets to attack.
2. Automation. Creating software that makes some functions of the team’s work completely push button is a huge win. This is more than just a simple efficiency gain, it’s removing a whole slice of work they previously had to do.
3. Elimination. Once you’ve automated a piece of work it becomes much easier to move some of that work to your customers. Shadow work is a phrase commonly used to describe the work pushed to the consumer of a service which previously had been provided as a service. This is clearly the end goal for a lot of efficiency gains, giving your customer the ability to “self-service” their needs.

These things scale. Hiring more people to do these things for your customer don’t. Bend the curve by making the investment in innovation. It’ll pay off.