How to Get Better Results when Outsourcing Early-Stage Tech

Five years ago, I’d just raised some funding to build a new mobile app. With money in the bank, I felt the pressure to move as quickly as I could, but I was faced with a dilemma: should I build a tech team in-house or should I outsource the technology to an agency?

The benefits of hiring an agency seemed obvious. I could get started far more quickly by working with a ready-made team and access cheaper talent by choosing an overseas agency. It was certainly easier to find an agency than a seasoned CTO.

Learn new skills every week ->

Plug and play

I decided to do both. I hired an agency while simultaneously recruiting an in-house technical team. Through my network, I found an Eastern European agency who were growing fast and had experience in developing mobile apps.

Their commercial director said all the right things; they liked forming partnerships with their clients and we would get a dedicated development team, a project manager, and regular communication throughout.

Our contract outlined what was in and out of scope and even included punitive provisions for late delivery. I remember the huge wave of relief that washed over me as we signed that contract. I had solved one of my biggest problems.

Or had I . . . ? 

The honeymoon period

We got off to a great start. Our regular communication sessions were productive. We went through wireframes and clarified exactly how the product would work.

A few weeks in, the project manager said, ’We have what we need, now we just have to give the developers time to do their thing. We’ll speak next week and let you know how it’s going.’

‘Great,’ I thought. ‘This will give me a chance to focus on other things. Out of sight, out of mind.’

For the next few weeks, we continued our weekly calls with the project manager. ’Everything is fine,’ she told me. And everything did indeed seem positive and reassuring.

At least it did until a couple of weeks before launch. That’s when our problems started.

Trouble in paradise

The product was nowhere near ready. Entire sections were incomplete and the existing sections looked different from the original wireframes. The team started to crunch in a valiant attempt to meet the deadline, but despite long nights and stressful meetings, we missed the launch date.

That’s when things got even worse.

Worms kept coming out of the woodwork. The development team had been working from the wrong wireframes and they were using different technologies to those they’d said they would use in the first meeting.

I discovered that team members had rolled off and been replaced by sub-contractors located in India. Then, a month after our launch date, I received an email from the project manager explaining that the lead developer was moving on to another project.

The late penalties that were supposed to motivate on-time delivery were leading to a growing sense of resentment from all parties. Communication became tense, then aggressive, and ultimately it broke down altogether.

As I went back to my investors to explain the delays, I felt like an utter failure.

An early-stage founders’ guide to outsourcing tech

I realise that my attempt to move fast by hiring an agency backfired, but it turns out that this isn’t an uncommon experience. Many founders have shared shockingly similar stories with me.

Are we to believe that all agencies are bad or is something else going on here?

When I finally brought on a CTO, I witnessed a dramatic turnaround. Within a month, we released the first version of our product. And in the process, I learned some of the secrets of working with outsourced tech teams.

Learn new skills every week ->

1. Choose agile over waterfall

My interim-CTO convinced the development team to abandon their waterfall process and adopt an agile process.

Waterfall development is characterised by fixing a scope of work and moving systematically through the design, implementation, and testing phases before launching at the end. In contrast, agile consists of short iteration cycles that accommodate regular reprioritisation.

The scope that we’d fixed at the beginning of the project was causing all sorts of problems. We’d locked in features that we didn’t need, and missed out others that were critically important. We learned faster than we could build and whatever scope we set was destined to go out of date fast.

As Mark Twain famously said:

“I didn’t have time to write a short letter, so I wrote a long one instead.”

The same is true of building a product: it takes time and a lot of iteration to arrive at something minimal and simple.

We needed to throw away the old fixed-scope approach and replace it with its agile cousin, ‘user stories’, with the expectation that we’d be reprioritising the backlog on every single sprint as we learned.

This required some operational and commercial changes on the agency’s side. Most agencies are set up for waterfall development (even ones that claim to be agile) since it’s easier to sell a fixed-scope project than an agile one. So, we set up new commercial agreements that paid the agency on time-spent instead of on a fixed scope.

2. Keep the Product Owner role in-house.

One of the main roles of our project manager was to manage communication between us and the development team.

Product Owners have a very different remit. They are tasked with researching their customers, forming a deep understanding of their needs, and translating those needs into user stories and acceptance criteria.

They are involved throughout the agile development process and are constantly clarifying questions during sprints. They prepare the backlog to focus on the highest-value initiatives.

Unless you expect your assigned project manager to have a deeper understanding of your customers than you do, it’s not a good idea to delegate product ownership to them. It’s unlikely that you’ll be satisfied with the results.

If you aren’t an experienced product manager, or you haven’t hired one in, it’s a great idea to invest some time in training, both in agile product development and modern product management.

3. Schedule in a lot of time for communication.

In my experience, a 30–60-minute weekly meeting is nowhere near enough to align a development team at the start of any project. It’s a false economy to spend less time communicating in the hope of moving faster, yet many developers avoid direct contact with clients because of the distraction it can cause.

Agile mitigates this distraction by limiting status updates to 15 minutes a day (known as the ‘daily standup meeting’). All other meetings are sandwiched between development cycles to reduce disruption during the sprint.

In these meetings, work from the previous sprint is reviewed and the next sprint backlog is defined. It’s important that Product Owners participate in these meetings and have direct contact with developers. The benefits are deeper than just keeping the team aligned.

Many founders completely underestimate the role that developers can play in creating simpler products that are easier to build. Unlike anyone else on the team, they know exactly what’s possible given the specific technologies used.

As I set out in How to Use Mantras to Align Your Team, part of leadership involves investing time in repeating what’s important. If you’re not communicating enough, any associated issues are down to you. 

4. Work on intrinsic, not extrinsic, motivators.

It’s so appealing to set due dates with penalties for late delivery at the beginning of a software development process. You’re pretty much guaranteeing success, aren’t you?

I have never seen due dates and penalties work well in practice. In fact, research has shown that extrinsic motivators work very poorly when it comes to creative tasks and can often lead to worse results.

The secret to building great software and motivating high-performing teams is to focus on intrinsic motivators. Humanising any problems, creating a safe and rewarding working environment, and shipping code to real users can provide far more motivation and satisfaction than penalties.

Speaking as a developer, there is nothing more demoralising than working on features that never make it into daylight . . . and few things are more motivating than real customer feedback.

Learn new skills every week ->

Out of sight doesn’t mean out of mind

If you want to use agencies to create great products that delight customers, you need to treat the agency just as you would treat your own team. This means investing time in building relationships, cultivating an agile culture, and taking an iterative approach to product development.

As tempting as it is to believe that an agency will be a panacea for all of your problems, unless you put in the time to build a great technical culture, you’re likely to make the same mistakes that I — and countless other founders — have made. 

Continue reading about early-stage startup development: 

• Are you struggling to run a technical company? Here's why you should hire a technical co-founder to help you.
• Are you sure you need a rebuild? Find out why tech rebuild projects might not always be necessary.  
• Struggling with managing your projects?  Learn about agile project management techniques to help your teams get things done.

Originally published Apr 30, 2019, last updated Apr 9, 2024