An Outsourcing Success Story

Problem

My team was working at full capacity but there were other opportunities to bring in a big return on investment, if only we could take them. We didn't have the headcount but we did have money that we could use. So how could we go about doing more with these restrictions in place?

Actions taken

"A chose a project that required us to do a new integration that could lead to a lot of new registrations for the company. I thought that if I made an index of specifications for the functional and nonfunctional requirements, I could outsource it. Against all wisdom, I followed through with this plan."

I identified a developer that had worked a lot in that particular domain and with the platform where we needed the integrations. He is quite popular and very successful so I reached out to him. I acknowledged and praised his expertise then gave him the requirements.

I outlined both functional and nonfunctional requirements. Defining the functional requirements was simple, nobody really has a problem with those. The problem was making satisfying nonfunctional requirements. For example, I want this code to have this degree of unit testing, and I want integration tests to be included and to test in such a distribution that we have a healthy test pyramid. Or, I want the code to be reviewed by one of my engineers and I want the pull requests to be incremental and small. So I made a list of all my functional and nonfunctional requirements for the project and presented them to this person. He understood them very well and agreed to build for us.

He was making very good progress on the project, and not just technically. He understood the business domain, he was making very good product decisions, and I really began to understand his maturity level as an engineer. Yet, there was something missing. I wanted this developer to feel like he was connected to what he was building because he was helping us build something very important. So I invited him to join us at the office for a few days. I arranged the tickets and flew him from his country to ours. He met the person who was making his reviews, worked with the team, saw how we worked, and experienced first-hand our company culture. On his side of the table, he had a lot of knowledge on the business space that he was helping us in. It was a new space for us so we didn't have much expertise. He brought a lot of insight about the behaviors of the customers, consumption behaviors that he sees in this space, and he worked with our engineers integrating the build that he had done for our platform. It was a wonderful experience that allowed him to feel more connected and committed, and it expanded the trust between he, I, and the company at large.

Lessons learned

• Finding a good outsource provider is key. I feel like I won the lottery on this project. I hear so many stories of outsourcing going bad. Trust your intuition when selecting outsourced developers.
• All projects have three angles: time, quality, and cost. The one that I care most about is quality. In this particular case quality was of utmost importance because our company would have to maintain this system after the provider built it. I was clear that if it needed to take a little bit more time, I didn't mind. If it needed to cost a little bit more, I didn't care. What I cared about was that the quality was such that it enabled speed for us in the long-term. I think he understood this very well and delivered something that was very high quality.
• Bringing an outsourced provider onsite isn't obligatory. For instance, this piece of software that the developer was working on was outside our perimeter. It used public web APIs and didn't use anything internal to our infrastructure. Therefore, he didn't need to use internal tooling, be ramped up in complex areas, or have to be connected to other teams. However, I felt that it was important to make that connection. It turned out to be an advantageous experience for all parties involved.