In the past few years, most companies advocate the myth of outsourcing as a way to cut costs on engineering. One myth advocated by people in business strategy and operations to justify why it is better to outsource from an expensive place to a less expensive one is that only the specifications of the product input leading to the outcome of the product matters and not the quality of engineering. The problem with that view is that you pay peanuts to get monkeys, i.e. you pay less to run an engineering team because it affects your profits and loss (P&L) but you end up giving a lower quality software engineering product to your customers. That explains why a lot of companies, particularly in Asia cannot take innovation to the next level. With the evolution of the product manager to lower the quality risk, does that mean that there is no room for in-house engineering? Here are some thoughts on the management myth about in house and outsourced engineering.
The Management Theory on Outsourced vs In-House Engineering till Today
Here’s how a business owner justify engineering costs:
- Engineering is a cost structure that is incurred to produce an output that has positive input to the business: That’s obvious and that’s why we have corporations and startups putting tonnes of money paying for engineering (be it software engineering or others) to move towards a business outcome, i.e. revenue.
- The engineering teams are a loss leader in the cost structure: As sales are the only revenue generator for the company, there is an imperative need to justify the trimming of engineering teams or outsource the engineering to a lower quality place. The extreme argument given by some Asian managers is that we should just outsource to country X by one ten of the price so that we can achieve economies of scale
- The quality of the engineering does not matter, but the specifications that lead to the outcome matter: This is the strongest argument used by business people. You just need to define the technical specifications and mapped out the business requirements clearly to the technology product. It sounds simple, but from my experience, most business owners have no clue on how to map the features to the product, or justify to themselves that they should build more features or introduce scope creep so that they can get more revenues. In most realistic cases, adding more features accelerate the downfall of the product.
- The product manager as the interface between the business and engineering teams: Of course, the management theory about outsourcing has evolved across the decade. One method of mitigating the quality risk is to have a product manager sitting in between the technology & business teams and map the requirements between both worlds. This improvement has taken the argument further to why we should outsourcing the engineering teams out there rather than have in-house teams within cities with high labour costs.
The best description of technical debt came from Jeff Atwood aka Coding Horror:
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
Clayton Christensen wrote an interesting anecdote on how Dell lost its competitive advantage by outsourcing engineering to its vendors such as Asus, and ended up in tears when the vendors leapfrogged them in technology competency. Samsung is most well-known for producing a critical component of technology for a particular industry (for example, solid state drives for mobile phones) and then use that as a way to figure out the roadmap of their competitors who outsourced the components from them. That’s why they gave Apple a run of their money.
Here’s the first message that I want to spread: the management theory about outsourcing engineering in the last decade without the product manager is actually wrong, because it fails to regard technical debt as a crucial component that will bring about the downfall of the company. Think about it, the more you lower the quality of engineering you outsource, you end up bringing in more technical debt, and till you grow big and large, you are unable to innovate because your foundations are of a lower quality.
With the evolution of the product manager, does it mean that there is no justification for in house engineering teams anymore for major corporations?
What successful companies have taught us about In-House and Outsourcing Engineering
What have we learned from successful companies like Google, Apple and Amazon? A few things, first, they don’t outsource their teams and keep it at the heart of where the innovation are. Amazon took a step further by spinning out their engineering resources into Amazon Web Services (AWS) so that the startups and corporations out there (who pay for their cloud computing services) end up “subsidising” a portion of their large engineering costs. It means that the engineering teams in Amazon are generating revenues and at the same time, lowering the costs for the company. In all three companies, the quality of engineering is really important and the focus is to ensure that you do not end up outsourcing your core competency to your competitors out there. To do that, you need an in-house engineering to continuously build and iterate on your core products.
Given the evolution of the product manager to lower the friction in solving the risk of quality in outsourcing, is there really no justification for in-house engineering? Here are a few thoughts which we can learn about for startups and corporations:
- You can outsource non-critical components: If technology is the core focus of the company, you should not outsource the core competencies elsewhere. For startups, if engineering is not a core function, then outsourcing it and build on other competencies such as business development, sales and marketing, it’s perfectly justified as well.
- Can we justify the existence of in-house teams?: You can have a good product manager who takes the core competencies and outsource it elsewhere, the outsourced team building on those requirements may not have the vision or core knowledge to improve the product to the next level and make the next big leap forward. Imagine if Google outsourced its entire search team out there, will the outsourcing team have the capability or the expertise to improve the search algorithms? The answer is no because the outsourced team neither have the core cultural DNA to build these core components. Yes, you can justify the in-house engineering team because they possess the cultural DNA to innovate.
- In-house engineering teams are required to resolve the innovator’s dilemma: An interesting question about corporations is that you should minimise operational costs and maximise profits. However, this creates the innovator’s dilemma within a corporation, which I have earlier shown how Dell lost its competitive advantage as a result of outsourcing. How do you get corporations to innovation from within? The answer is the evolution of the in-house engineering teams, and how to transition them such as they can turn their engineering value to create new business value is an interesting question to explore for the future. How are we able to extract that innovation?
Author’s Note: The author thanks his colleague, Byron Fuller for interesting feedback and comments that further refines the arguments and ideas about what this post is about.