The Make vs Buy Puzzle
One burning question most systems engineers out there face during the early stages of system design is: should I make this thing myself or should I get it elsewhere? This is perhaps one of the trickiest conundrums in the systems engineering realm: the (in)famous make vs buy dichotomy.
Disclaimer: this analysis is done from a startup-which-design-systems perspective. If you’re big enough to support complex subsystem designs end-to-end perhaps because you have to justify a large existing R&D org, or you are in a position you can acquire suppliers in order to go vertical and get all their production exclusively for you, your reality is different than the one presented here. Here’s about underdogs who have to design systems while short on money and reputation.
To turn things more complicated, the make vs buy question is recursive: no matter how complex the system is, the doubt cuts all across the hierarchy from system to subsystem to components. But as granularity increases, at some point the wondering mysteriously stops. There is a granularity threshold where a magical common-sense suddenly appears and a general consensus on the validity of going the in-house way (or not) is achieved. For example, if you are making a bicycle, you will not make the screws, nuts and bolts yourself. If you are making a flight computer for a drone, you will not make the System-on-Chips nor FPGA devices yourself. Nuts, bolts and integrated circuits do not seem to have much in common but when we say we will proudly get them from somewhere, no one bats an eye. How so? Strangely enough, such consensus is achieved on extremes: from something as functionally simple as a bolt, to something as functionally complex as an integrated circuit with billions of transistors. So different, yet somehow connected.
If we could capture the rationale why we *won’t* embark in the pain of making these tiny things ourselves, we could say:
For the bolt: I will not waste my energy in making something so readily available.
For the chip: I will not waste my energy in making something I couldn’t dream of making myself because I don’t have the expertise nor the facilities to do so; not now and not in decades… (Engineers know that making integrated circuits requires decades of R&D. What is more, it requires very specialized facilities to produce the wafers and the packaging. That’s a solid no-no.)
For basically anything else, dissensus kicks in and wheel reinvention goes brrr. Subsystems, components, even software tools, everything becomes a DIY target as a result of qualitative assessments plagued (as most qualitative approaches) with our own biases. And little, or none, actual data.
There are some factors that play in our engineering minds when it comes to creating things and the value we put on that; notably, the “Not Invented Here” (NIH) factor, and the IKEA effect.
The NIH factor1 states that, regardless of what we create, we tend to feel more confident and certain with things we have crafted ourselves. More than the thing itself, what matters the most to us is the fact *we* have created it. This can influence our decision-making when choosing if procuring from elsewhere or not: we own the system architecture hence we feel we must spawn all functional organs of our frankensteins.
The IKEA effect2 expresses that we put disproportionately high value on things we have only partially participated in. This is, we feel more “part” of the overall process if we can contribute to it, at least a bit. The effect is referring to the fact we feel more satisfied when we assemble furniture from the known swedish store (if you happen to have the IQ to understand the instructions) compared to furniture bought elsewhere didn’t assemble with our hands: we feel we did our bit there. For our fathomless engineering minds, procuring all the elements from a shelf is less rewarding and fulfilling, perhaps less epic, than having our fingerprints on them. Instead of “plug & play”, it seems we engineers are more fond of “design, build & suffer”.
Make vs buy calls are one-way roads at times, where decisions in one direction or the other are not easily undone. There is an inertia factor in in-house projects: what has started cannot be so easily stopped, even if all signs are indicating the decision was wrong. Managers and engineers who have, due to poor judgement or a different initial context, embarked in an in-house project only to realize later on they have picked the wrong path (things took too long, or they oversaw something they didn’t manage to see before, etc), will not call the project off but on the contrary they will stubbornly carry on, mainly to justify sunk costs and efforts. But, on the other hand, managers and engineers let architectures encroach with third-party choices and become highly addicted and difficult to change. More on this later.
Let’s explore the thinking process behind the “in-house” avenue. I am a system designer and there’s this one lousy subsystem I am not sure if going in-house or not, but I’m inclined for the homegrown option. Why do I believe in my head the in-house option may be better? These are my hypothetical reasons (not exhaustive):
What I need does not currently exist
It is cheaper
It is faster this way (as in, shorter lead time)
I can protect my know-how
I de-risk my supply chain (reduces vendor lock-in)
The current supplier sucks, I hate them!
What if the current supplier pushes up daisies?
It’s a cool thing to do
Let’s rewrite these remarks with some adversarial counterarguments (as you can see, I am talking to myself, yes):
What I need does not currently exist
Well if that’s the case, this is an invention then, different story, go patent it, you gonna be rich. Otherwise, how special are your specs that no one in the market can offer? Turns out, we’re all less special than we think (thanks Copernicus!). Chances are you are overestimating the uniqueness of it, someone must be having it sitting on a shelf.
Can’t your system architecture accommodate for a third-party option? Maybe your design has grown too entangled with the specifics and that is usually a red flag.
If all the existing subsystems or elements in the market offer lesser performance compared to what you require, and you’re suffering some technical bottleneck of sorts, it can be worth checking with suppliers about their future offerings: they may be already developing a product with the specs you need in a short time compared to what it would take for you to reach same maturity. They would most likely evolve their current know-how and expertise for the new specs, whereas you’d have to start from scratch. Maybe even accepting to be an early adopter for their new product could be a good option; often companies are giving stuff for free as a trial. I acknowledge this information may not be very available from suppliers, but worth doing the intel before kicking off a full in-house design.
2. It is cheaper
Really? Are we talking about BoM-cheaper? What data is supporting that claim? When and how are non-recurring costs of a full-on in-house development paid off? Are you including “black swans” margin for any surprises along the way? Typical black swans are regulations and compliance you usually take for granted when procuring. Before jumping to the in-house boat, check what level of compliance current suppliers are giving with their products.
Are you already having all the talent in-house to embark on it? Otherwise you must consider the additional cost for that as well. Recruiting houses are not cheap.
What about testing facilities? Is the cost model considering that?
Easily all these non-BoM costs can get really close to, a priori, expensive third-party things.
3. It is faster (as in, shorter lead time)
Connected to the previous bullet, most likely there is a learning curve to be navigated when developing something from scratch. Learning takes time, testing takes time, iterating takes time, manufacturing takes time, hiring takes tons of time. Hofstadter’s law states: “Everything takes longer than expected, even if you take into account Hofstadter’s law”. Are you sure faster means faster? In this context, faster usually means slower. And slower means longer time to get to market, which means a competitor potentially taking advantage.
And even once the development stage is over, production-level lead time may not look as attractive as initially thought compared to the existing option. If you're gaining a month or two, is it worth going for a full year of development work? Choose carefully.
4. I can protect the know-how
What know-how exactly? At subsystem level? Unless we’re talking about some sort of invention, if we’re talking about more mundane things such as embedded computers, or a software tool or library, you’re most likely reinventing the wheel. Your core know-how sits at the system level and its architecture, which is what you’re creating that is different compared to what exists in the world. Carburetors and spark plugs are undifferentiated items, the differentiating factor is the muscle car you can build with that, and that’s the thing to protect. In other words, identify what’s your muscle car and protect that with all your strength. All the rest, are pieces of the puzzle.
5. I reduce vendor lock-in because I make it myself
Vendor lock-in will still be present on the underlying components (spark plugs, bolts and chips) you will still have to procure from elsewhere. Vendor lock-in will always be non-zero. I would argue, when going in-house you’re exploding your supply chain granularity, and how that maps into supply chain risk can be tricky to assess. Say you used to procure the flight computer from Buggy Flight Systems Incorporated, and for X or Y reason you feel you’re too captive with them, so you “de-risk” and go in-house. Now you have a BoM with perhaps dozens of suppliers with products with individual lifetimes, and you start to pray the Tantalum capacitors will not go obsolete. What vendor lock-in you reduced again? Which used to be one row in a spreadsheet now it turned into hundreds. And you’ll start freaking out for things like worldwide resistor shortages, which are, you know, a thing3.
6. The current supplier sucks, I hate them!
Hate-based make vs buy choices are more frequent than we think. My advice? Breath twice, count to ten, carry on. Better a devil you know…
7. What if the current supplier pushes up daisies?
Well, it happens: companies go belly up, they succumb, expire, kick the bucket. Business is tough. Worse, they can still exist but can be acquired by a random company. Ugly truth: the system architecture must account for it. For example, the software architecture must be grown on top of decent abstraction layers. It’s easier to say it than to do it, sure, but an architecture which heavily relies on specifics in terms of components or elements becomes too entangled for a world where shit happens all the time. Goes to say, if someone in your supply chain going bankrupt is keeping you up at night, that’s a misleading cause for sleep deprivation. Your architecture is the actual thing keeping you up at night.
8. It’s a cool thing to do
Fair enough. If the thing is something interesting to work on, and just for the epic of saying you and your maverick team pulled it off, go for it. Noble, yet bankrupt-friendly.
Having been so contrary, let’s maybe write down some valid reasons why going in-house could be an option:
Enough data has been collected to support the conclusion that the current supplied options are overpriced and we have the capability (again, backed with data) to do it ourselves in a most cost-effective way, and in a schedule which, all things considered, provides a reasonable trade-off. Proper cost analysis has to be done and numbers need to be shown. In other words: show, don’t tell.
Reliability. The current supplied subsystem is technically unreliable and a key part of the system architecture. It breaks with failure modes that are not well understood and we cannot overcome this by accommodating redundancies or revamping fault-handling capabilities and understanding this is of paramount importance for the system performance and availability. Current supplier is blocking information and unwilling to compromise. Fair enough.
When the subsystem under consideration provides a key differentiating capability which cannot be obtained from third parties, and assuming analyses are not twisted to fit the epic narrative, it may be reasonable to develop it. A paramount factor is to mind where the differentiating focus for whoever consumes or uses your system is (single bold I’ll use in the whole article). Will the user or customers care/appreciate/pay for the fact you have developed a carburetor in-house? If they don't really care, and it doesn’t move any strategic needle, go find it from a shelf. Make your architecture off-the-shelf-friendly.
In conclusion, underneath the make vs buy question lies an uncomfortable matter for systems designers: how in control of the underlying architecture are you? Or is the architecture, in turn, controlling you?