Lessons on Outsourcing

By Tom Britton, Co-Founder, Syndicate Room 

You don’t hit full speed without coordination. Lessons from working with outsourced teams from large businesses to startups.

Usain Bolt is one gangly dude. He’s too tall, he’s too lanky, too this or that, up until he proved the doubters wrong there was no way someone of his build should have ran as fast as he did. But he did, and he won time and time again. The key to his success, and all great athletes success is coordination of movement and adaptation to what works best for your body, not necessarily what scientists believe to be the ultimate, but knowing through trial and error how high to raise your knees, how hard to pull your arms back, how quickly to increase stride length and speed. It’s a process that takes time, determination, and adaptation.

In many ways the lessons learned from running a race can be applied to running an outsourced team.

When we started SyndicateRoom we didn’t have the cash to hire a developer, let alone a dev team, so we decided to outsource the initial product development and would fund improvements as we could. As anyone who has outsourced a small project before will know, there’s a lot more to outsourcing a team than simply replying to one of the many Linkedin messages you’ll have received promising amazing websites, iOS apps, and #1 google ratings all in one.

Below are the rules of thumb I’ve learned, and the tools I’ve come to rely on that ensure teams not working in the same office still feel a part of the project and buy into to the same culture. Note, while much of this is geared towards younger companies, a lot of the same insights applied during my time spent working with a 200 person outsourced dev team at TheTrainline.

Without coordination …

When I first started in product management I was a bit clueless about how things worked. I was a bit too unselfish with my time yet selfish with my vision as I felt I should only offer it as needed, not interfering when someone tried to run with it in a different direction and take all the credit. I was young and a bit naïve and soon realised I’d created more work for myself than I could manage.

Because I didn’t focus on communicating my vision, every time a decision needed to be made I’d get an email or a phone call. Then another one, and another one, and soon I just spent my time answering questions and not getting around to thinking about the bigger picture of how those decisions impact each other. Soon enough products were built that vaguely resembled what I had in mind even though the micro decisions made were all correct.

Lesson learned, if the arms and legs aren’t in synch, even if the head things it knows where it’s going, you’re going to run in circles.

I’ve learned a lot from some great people along the way and have now I’ve devised a bit of a system   that works for me. Slack and Trello play a key role in keeping things organised and transparent with the teams but there are three rituals we especially adhere to that really make the team work together.

The Daily Stand-up

For those that use scrum you’ll be familiar with the daily stand-up. Essentially, every morning the teams gather to discuss what they completed the previous day, what they are working on that day, and highlight any blockers they have to achieving their goal. It’s during these stand-ups that I suss out how things are going and make sure everyone is working towards our common goal. Questions arise during the stand-up and are either resolved immediately (if they are quick yes or no style questions) or noted to follow-up with just after the stand-up. Chucking like this ensures the developers can get on with their day knowing what they need to and hopefully not hitting a blocker. And the great thing about a stand-up is that it can be used for any type of team, not just dev teams.

The Big Buy-in                                                          

It’s a misconception that outsourced teams are hired guns that should simply be told what to build and not why they are building it. If you treat them well but don’t let them share in the vision, you’ll probably get them to do some good work but you’ll be missing out on their best. Whenever we spin up a new team, regardless of it is outsourced or internal, I make time to take everyone through companies journey so far and then the vision. I pay special attention to taking them through how the work they are doing plays a key role in obtaining that vision.

When the hearts not in it, it doesn’t matter how strong or technically capable you are, you’re just not going to win.

The last ritual we adhere to, if you want to call it a ritual, is Empowerment

Empowering an outsourced team is probably one of the scariest decisions I’ve ever made, but it has also been one of the best.  Once everyone has bought into the vision and knows how important their role is, I ask them to challenge it. Not just there and then but every day. To come up with a way of making it better and to prove to me why that way is better. When you remove the customer / supplier barrier you open the door to a much more powerful relationship. Just think, your partner has likely worked on other projects so how amazing would it be if you could tap into all of that knowledge, those learnings, the experience, and benefit from it. This will only happen if you empower the team to challenge the very vision you’ve set out for them. And if you do, you’ll benefit ten fold.

Like Frank, sometimes you’ve just gotta do it My Way

Michael Johnson, the previous World Record holder for the 200m and 400m was always asked about his running style. People commented that he ran too upright. After one race, a race he won, he heard his competitors talking about how funny he ran. His reply to them “I noticed that you run funny, too. You run kind of slow.”

I’ve read the Lean Startup, I’ve read Google’s Sprint, I’ve read the Art of War, from Zero to One, the Hard Thing about Hard Things, all great books, all worth reading but they are not about you and they never worked with you or your team so keep that in mind.

Each team needs to define its own way of working. Personally, I stick to these three rules:

  1. I won’t work with teams where I’m only allowed to speak with a manager in the team. It should be clear from the top that I want the whole team’s buy-in and contribution to what we are doing so anyone who wants to work through an account manager is ruled out.
  2. No one’s vote counts for more than anyone else’s. If we are debating how to get something done or what we should be doing I won’t accept that someone in the team has a vote that counts for more than anyone else’s. A member of the team may differ if they are uncomfortable or feel uninformed about a particular topic but other than that, one person, one vote.
  3. Commit to a project (or product), not a time frame. While agile aims to develop in a way where things can be quickly released and in theory easily picked up by someone else, we had huge inefficiencies at TheTrainline with developers rolling on and off projects that were not completed. Yes, outsourcers want to keep developers happy and constantly learning but I won’t agree to having developers join for fixed time frames, I need them to work until a project or product is delivered.

While his last individual 100m race didn’t end in Gold, I’m not sure the records set by Bolt will be matched or bettered anytime soon. Think of it this way, the past two 200m world record holders have done things considered unconventional and won. Take the brief insights that I’ve shared above and adapt them to your own situation. What works for us at SyndicateRoom may not be right for you and that’s cool. Take the time to find what does work and, even if it’s a bit funny, go with it.