Sleep Well: The Greatest Horror Stories of Outsourcing and How to Leave Them Behind

Tips for making the remote work from Ian Gotts, CEO of Elements.cloud

Elements.cloud is the cloud application which helps Salesforce customers clean-up, document and drive adoption of their implementation.  The app covers the entire implementation lifecycle from requirements capture, business process mapping, documentation of configuration, through to end-user help and feedback.

As a passionate outsourcing advocate, Ian Gotts, CEO of Elements, stands for a remote-first approach to work. Despite this, he believes that outsourcing is not risk-free: it requires much dedication, time, and deliberate effort to get the results.

In his interview with YouTeam Co-founder Yurij Riphyak, Ian shares the biggest outsourcing myths debunking them with some objective truth.

If you want to stay away from outsourcing horror stories and sleep well at night, keep reading.

Yurij: How did the story of Elements begin? Do you remember what you were doing two weeks before you started Elements?

Ian: My experience with outsourcing started with the previous company — NimbusPartners — which was acquired. There were two of us in our 30’s and one developer in his 20’s — a classic startup. Together, we were building NimbusPartners from a bedroom in the UK.

The first challenge occurred when we realized that we needed some extra development resource. My standard answer for everything like this is, ‘We haven’t got any money, we have to do it in a clever way.’

I love hacking — not cheating — but doing things in a different way.

We divided the new application features into components — think of them as Lego bricks — and did the reverse auction. Then, we asked our developers from the Eastern Bloc how much building specific components would cost. Some of them answered, ‘I’ll do it for $5’. And we were like, ‘Well, okay’.

Result? Back at that time, it was more difficult getting the money to them than it was getting the code written.

Yurij: What time was that?

Ian: Somewhere between 1997 and 1998.

So we put up this post so people could apply to bid in the auction and develop components for us. As a result, we had 120 applicants in the first hour. Then, we vetted a whole bunch of those individuals. That’s how we started introducing the remote work.

When our new CTO joined the team and we needed to internationalize the product, we used outsourcing services in its classic sense. We had an onshore team and we had a team out in Ukraine which we outsourced big chunks of work to. That’s what NimbusPartners was all about.

Yurij: How did you come up with the idea to start Elements?

Ian: A couple of years after the NimbusPartners exit, I went back to our CTO, Adrian, for advice. He is a fantastic individual with a commercial mindset who bridges the technical and the architecture stuff perfectly well. In terms of technology, I trust him, not myself.

And Adrian said, ‘If we want to build something together, we’re going to build it from scratch, build it properly.’

Soon we realized that we can’t possibly do this cost-effectively in the UK or US with any team. We were fighting for a talented resource. Even with increased salaries, it would still be tricky keeping all the people in-house.

So we decided to go back out and have a look at Eastern Bloc [Ed. Note: the former Communist States of Eastern and Central Europe].

And that’s when we came across YouTeam.

Yurij: What made you decide to go for outsourcing?

Ian: When you lack the resource to get something done in a limited period of time, you outsource it. Often, it’s tactical.

We took the strategic approach: our core software development team was going to be all-in-one offshore. It meant we were outsourcing to the whole team, not to individual developers.

Yurij: So you decided to work with a remote team. Do you treat them as in-house workers?

Ian: When someone asks me how many people work for Elements, I think about our outsourced development team as employees.

Our remote team members have got company t-shirts. They are involved in e-communication with customers. When we have a Christmas party, we pay for them too because they are also part of the company.

Our remote team members from Ukraine signed very similar contracts in terms of intellectual property that all of our employees have. That’s why we think of them as in-house employees.

Yurij: How do you know that your remote team is truly dedicated to the project?

Ian: First, we have a specialist leading the team out there. Andrew gets paid via a different route, but he’s part of the Elements team. He ensures that our outsourced team is kept busy full time. He works closely with our CTO and Product Manager who are based in the UK but travel out to Ukraine every month.

Second, the team we have out in Ukraine doesn’t flip in and out of other clients’ projects. Once they come into the Elements office, they only think about Elements. If you’re passionate about something and excited about something, then it doesn’t stop once you close the door at five o’clock.

Yurij: Both you and your team should value this cooperation and do whatever possible to keep it smoothly flowing. Otherwise, outsourcing horrors may keep you awake at nights.

Ian: So what are the horrors?

Yurij: Basically, at least three of them come to my mind:
1. Remote employees might compete and sell your knowledge to a competitor;
2. They can try to do it themselves;
3. They might not give you access or ask for an additional reward for this access.

Ian: So the first one is probably the greatest risk, but it’s not different from every employee sitting here in our office in Salesforce Tower in San Francisco — the risk is exactly the same.

They have access to a lot more money, have access to a lot more of the market they could go to, and they could take that knowledge and go and build it here. That is way easier than someone sitting in Ukraine, for example.

If that company is competing with me in Ukraine — fantastic. That’s 10 hours and 6,000 miles away. Is it really competition?

The only possible issue is they sell our idea to another company in San Francisco and they’re based in Ukraine.

Yurij: Okay, now I feel reassured. What about the second risk — when they can take your idea and build it themselves?

Ian: So they can sell it to a Ukrainian organization, or set their own company up.

However, building a company is not about a product. Instead, it is all around marketing, sales, contacts, and relationships. The product is a widget. Without a great product, it’s really hard. But just having the product isn’t enough.

Therefore, if those guys want to steal the code, and then go and run their own company, then it’s a lot more than just having got the code.

Yurij: Unless, you know, your key and only asset is some breakthrough technology. In that particular case, we wouldn’t recommend outsourcing.

Ian: Absolutely. If the only thing that makes you different is that very clever algorithm — that’s the thing you need in-house.

Yurij: Great. So what is about the last risk with the development team stop giving you access?

Ian: Part of that is the way you set up your environment and managed structure — where they’re posting the code, how often they’re posting the code, how will you pay them, how you manage the team.

The product is just a widget. Making it great is important. But having just a product is not enough.

So if you’re paying in arrears for work done, then you have the ultimate control. When the work doesn’t get done, you don’t pay.

Yurij: Okay. I think it checks all the boxes. So let’s talk about some other concerns. Like, for example, time zone difference. Did this feel like an issue or a challenge?

Ian: In the beginning, the time difference is a huge issue, but there are a few tactics I use to overcome this challenge.

You need time overlap. Due to significant time zone differences, I’m normally at my desk by 6 am. This gives me the biggest opportunity to work with my CTO in the UK.  He is only 2 hours difference from Ukraine, which makes it manageable.

Proximity matters. When you are early stage, changes in your specification happen regularly as you get customer feedback. That’s why you cannot do everything 100% remote. Fly over every 2-4 weeks to catch up with your remote colleagues and monitor the process. Whether your team is 600 or 6000 miles away, proximity matters.

Communicate everything. In the early stages of a product, the scope of what you are doing moves quite a lot. You need to have almost constant communication to keep your remote employees up to date on each minor change in your direction.

Yurij: What are some other things essential to keep in mind while managing teams remotely?

Ian: Know the team really well. If you’ve got a team of 15 people, you need to know their strengths or weaknesses, you need to know who to allocate particular bits of work to. Either you need to employ someone who’s a manager who really understands that on the ground, or you need to do it yourself.

Remember about proper time allocation. Our Product Manager is responsible for the allocation of resources. If you don’t start looking at the backlog and reassigning tasks to whoever is free, then someone in the remote team needs to do that. You need a management layer put in place.

Make quality hires. Making sure you’re pulling in good quality team members is critically important. There was a great article written a long time ago called “Nerd Herding”. It talked about the fact that every new person who came into the team got interviewed by every other member of the team to make sure the quality stays high. Today, you don’t have to do that yourself. You could rely on an outsourcer instead.

Yurij: I keep hearing from the founders who work with distributed teams is that one of the things you have to pay most attention to is establishing this human link, a cultural fit. You have to do a deliberate effort here. How do you manage to build your remote culture?

Ian: When we’re all going away somewhere to an event, we end up booking a big Airbnb. We don’t get six hotel rooms — we book a nice house with six bedrooms and facilities instead.

When remote workers are a part of a big house, they sit down, eat breakfast, do everything together. We keep the house for the weekend as well, for anyone who wants to stay on.

So there are plenty of things you can do to make life easier both for you and your remote team, building one common culture.

Yurij: So the last one from me would be: still, like if you ask 9 out of 10 founders in Bay Area, would they go for a remote team? The answer would be no. What kind of advice would you have for them?

Ian: Number one: go remote — for cost reasons. Okay, I can’t code. So if I want a product to be built, I have to pay someone to do it.

Number two: Hate wasting money. I don’t mind spending money, but I hate wasting money. So spending three or five X on a salary for someone here versus paying for the remote worker — I’d rather do remote worker if I think I can manage it.

Number three: Get multi-skilled teams. You can build the product, but you’re going to struggle to sell it, as you got to learn those skills first. I can hire a team to develop, I can put a team together to sell, and I can put a team to foster relationship building. That’s how I can handle the process.

Location, location, location: You don’t necessarily need to look outside the US. Now it could be a remote team inside the US. However, it’s getting harder and harder to find those because it’s pretty expensive living all over the US. For this reason, more people tend to go offshore.

Looking for a dedicated remote team to outsource your development to? Browse full-stack development teams on YouTeam, available to start within the next 2 weeks.