Best practices for working with outsourced software development companies
Best practices for working with outsourced software development companies
Earlier on in my career as head of engineering, I was vehemently against working with external software engineering companies. Outsourcing any part of my product was a no-no. I had posited that the quality would be sub-par, the motivation lacking and the risk of IP leakage far outweighed the benefits of incremental software development bandwidth.
I was wrong.
Engaging with outsourced software development companies can be a strategic move for software engineering companies. Applying some best practices and care in selecting the right firm for the right project can accelerate software development efforts.
The right project
The first, and arguably most important step, is in identifying an appropriate project to engage a third party firm with. My approach to the this selection process is to find a project that satisfies the following criteria:
Is not in the core, or critical areas of your product. You would never file a patent from this work.
Has no dependencies on other teams or any ongoing software development efforts.
Has a constrained blast radius.
Choosing a project outside of the core areas of your product is absolutely critical. It prevents any core IP from leaking outside of your company and reduces the risk of errors introduced into this critical code path. The lack of dependencies facilitates smooth project management and can accelerate delivery times. I actually strongly - to the extent possible - prefer that projects worked on by third party companies be hosted in a completely separate and isolated repo. This stipulates that the only interface between this project and the rest of the product is an interface/API layer. Finally the blast radius is concerned with quality and risk. The third party software company should work on a constrained area of your product. Therefore, if what they work on fails, the failure is limited to small surface area of your product. Let’s walk through an example.
Consider Network Securitas - a software company that develops network observability products. The company is evaluating two projects to outsource to a third party firm. The first is to augment how their product captures networking traffic and rely on eBPF. The second is to build a Splunk, or SIEM adaptor.
The eBPF project is absolutely core to the company and suffers from a huge blast radius. It’s also highly unlikely that this work can be done outside of the product in an independent manner. On the other hand, the SIEM adaptor is well constrained and can be worked on independently. Should the adaptor suffer from bugs, those will be limited to just this piece of functionality. The choice should be to go with the SIEM project over the eBPF one.
The right firm
Outsourced software companies usually specialize in a few areas. You want to choose a company whose specialities intersect with the skills required to succeed in the project you selected. Always get references and review some of the firm’s previous work to ascertain their expertise.
There are other factors to consider beyond areas of expertise when selecting a firm to work with. The firm’s geographic location, or more specifically the location of their software engineers, can be a factor. Working with an outsourced development team that is 12+ hours away is vastly different than one that is within a reasonable or same timezone. Another overlooked area is testing - which is a general observation on the state of software development. Aligning on testing at the outset will reduce the risk that you end up receiving code that compiles but barely runs 🙂
The firm’s engagement model should also be evaluated. Some firms charge by billable hours whereas others bill based on scope and deliverables. I err on the side of working with firms that bill for an entire project versus hours worked. There are exceptions to this rule though.
The right structure
When setting up a new project that will be worked on by a third party firm, I usually assign the following roles to the team
An overall Project Manager for the entire project. This should be a person from the outsourced company
A Technical Lead from within my team
A Product Manager, also from within my team
The Technical Lead and Product Manager are responsible for setting up the project. This means they are responsible for sharing requirements, design constraints, coding and testing standards with the outsourced firm. Their engagement extends throughout the project. The Project Manager, on the other hand, is responsible for the overall success of the project. They share KPIs, track progress, flag risks and so on.
There have been cases where the outsourced team will also have members of my software development team embedded on them. This depends on the scope of the work and is definitely an option. Having members of my team who are actively developing side-by-side with the outsourced firm does take bandwidth from my team, but on the other hand it can accelerate timelines, fosters better collaboration and increase the overall quality of the delivered work.
Finally, I establish a regular meeting cadence to review progress, which isn’t dissimilar from how I engage with other teams within my organization. This meeting, typically weekly or bi-weekly, is meant to review progress, flag new risks and so forth. Again, not any different from a regular sync with a software development team.
One important thing to note. Working with outsourced or external software development firms isn’t free. Every engagement will take some resources from your team, hence there is some overhead that is introduced when working with these firms.
Engaging with outsourced software development companies can be a strategic move for software engineering firms, provided that best practices are followed. We’ve seen how these sort of engagements can add incremental bandwidth to a software engineering organization.
There is another intangible benefit to these engagements too. Recall how I preferred that these engagement be done “outside” my product, meaning relying on some public interface or API. Succeeding in an engagement whereby a third party software firm, or developer, is able to build integrations or applications, using your APIs can be of huge strategic importance. It can bootstrap an ecosystem of third party applications that work with your product and it also gives concrete evidence of the utility of both you product and APIs.
Things of interest in my inbox
Last week witnessed Instacart’s much awaited IPO. This most excellent analysis by the grand master of valuation unpacks Instacart’s business model and highlights the conundrum facing a lot of pre-IPO tech firms: the price is too damn high
I am a big fan of the movement to deconstruct the monolithic data warehouse and the move to cloud data lakes as the backbone of the data platform. It was therefore great to see the Tabular team, the brains behind Apache Iceberg, raise a series-B
A couple of years ago I wrote two articles on Centaurs, or how humans and AI will work together. Recent research which was summarized in this post shows the benefits of these Centaur-like engagements
“There is a ton of important and useful nuance in the paper but let me tell you the headline first: for 18 different tasks selected to be realistic samples of the kinds of work done at an elite consulting company, consultants using ChatGPT-4 outperformed those who did not, by a lot. On every dimension. Every way we measured performance” Source:
