The One Where I Convince the CTO Not to Outsource

By GrumpyOldDev

- 5 minutes read - 915 words

This was several years ago in grumpy old dev’s career back when he was still enthusiastic young dev. Someone above the CTO had signed a sweetheart deal with one of the large contracting companies to buy a fixed amount of development time and services each year. And so all the technology executives were scrambling to find useful work for the contracting house to do. (This deal also lead to The One Where I Lie To The CTO)

At the time I was leading one of the prestige projects in our division and so the contracting firm wanted a piece of that. They agreed they would dedicate a high performing offshore team to prove their worth and so the CTO told me to make that happen.

image of high performance team raising the flag on Iwo Jima

We had a high performing on-shore team, most of whom I had personally interviewed by sitting down and coding with them. Our cadence was such that I would give high level directives like “create a web service that does x” and one or two developers would sit down and make it happen pretty close to what I had intended with very minimal input from me. I normally farmed out work by hand to the developer or developers I knew would most enjoy solving the problem. We had very high velocity.

Side note: at one point the company launched an initiative to analyze how developers spent their time. They sat down with one of my teams and issued a report that said my developers spent 95% of their time writing code. The rest of the firm averaged 35%. I was proud of that, but too naive to realize that our executives probably didn’t care.

So, I got saddled with a hand picked team the contracting firm had selected as being “high performing” and I was not allowed to be involved in the selection process. So… I hatched a plan. I would be fair. I honestly felt if the contracting firm could choose developers better than I could, if their team could deliver, I could use them. Less work for me! Yay! Interviewing is hard! But if they just created mud pies, I didn’t want this project to be their Normandy beach from which they launched their invasion.

Remember, with my hand picked developers I could normally give a one sentence directive and have it accomplished pretty quickly. Everyone peer reviewed the code and we had high standards for maintainability. So I told the contract house they would have to follow our procedures and go through peer review just like everyone else. They agreed and I assigned their ~10 developers a web service to build.

I knew that communication would be a problem, not because they were offshore, but because throwing 10 bodies at a problem always makes it harder. I knew they would have to figure out how to use our tooling, our frameworks, etc. Onboarding one developer at a time, like I normally did, we could point them to the documentation and give them a little orientation. When they had the inevitable questions, the existing team could spread the load of answering them and it didn’t take too long for new people to become productive.

I did sit down and explain in detail the requirements for the project. Any questions they had I made sure to answer. In fact, I spent much more time holding their hands to explain what was needed than I did with any of my existing team.

I think after a month this team of 10 people still hadn’t figured out how to run our existing codebase. It was fairly complex, but we also had it fairly well documented. But again, one person diving into a functional team has an incentive to figure it out. Ten people all agreeing that it can’t be done gives a convenient excuse for none of them to do it.

However, after 2 months they were telling their management how great they were doing and their management was telling my CTO how great they were doing. Our vendor rep’s boss was positively glowing.

But they hadn’t actually committed any code.

After 3 months they finally committed some code in a feature branch and it went through our standard peer review process. And the existing team tore it to shreds. Not out of pique or prejudice. Just because the code didn’t actually work, wasn’t maintainable, and really didn’t add value. They had checked in random stuff and told their management “mission accomplished.”

mission accomplished meme

So our CTO called a meeting to ask how it was going and I showed him a deck with merged commits by team member. It looked something like this, but in powerpoint and a chart (not the real names):

  • John - 27
  • Tom - 32
  • Tim - 107
  • Brandi - 53
  • Sandra - 60
  • Ethan - 42
  • Onshore: 321
  • Vendor team - 0

The CTO looked at it and kinda laughed and looked defeated and said something like “ok, ok, i get the point” and we moved on to talk about other things. I’m not sure he even understood a what merged commit was. But he understood good numbers and bad numbers.

A few days later the vendor rep’s boss came to my office and told me that if I wasn’t going to commit to paying for these valuable resources he would have to move them to another project.

I told him that was OK, I understood.

And that’s how I protected my team and stopped the CTO from outsourcing.