Don't Google Build vs Buy

There are no good “buy” options.  Period.  

I’m not saying that there aren’t good products out there.  There are.  And they all share a common approach-- an open architecture--  which is important because given all the tech decisions your org has made in the past, the idea that some new piece of complexity is “plug and play” is just a marketing gimmick.  

I’m looking at you, cloud!

“Buy” is never just “buy.”  It’s actually “integrate.”  So is build.  Which means that they both require similarly skilled engineering talent.  And therein lies the dilemma.

Culturally the word “buy” is a not-so-subtle signal of disinvestment in a declining, increasingly commoditized function/department/division.  And in a field that’s grown sensitive to short cycles of obsolescence, that signal creates a powerful, self-perpetuating downward spiral for top engineering talent-- an exodus of ambitious developers, ever vigilant about remaining relevant.

It's a vicious cycle.  The allure of someone else’s “build culture” prompts an exodus of top engineering talent, leaving behind project managers (the not-technical-enough; the “I used to be an engineer” type) and technical order-takers (more junior and many times under-skilled).  What remains is a diminished internal team that simply can’t deliver what the business thinks they’re getting “off a shelf.”

Note that I can’t stand those three words-- off the shelf.  They’re classic marketing misdirection, innocently implying “what could be simpler?  You have a can opener, right?  Well, we sell cans!”   Mmmm… deeeelish!   

The problem-- of course-- is that the flight of the best engineering talent from your “buy” organization means that you don’t have a can opener.  If you’re lucky, you have a hammer.  And most orgs-in-decline don’t even have that.  They just have to learn to eat the can. 

The Train Wreck in Slow Mo

The decline is not inevitable but when it happens, it plays out predictably.  That ripe smell of flop sweat-- even before the “buy” engagement starts-- causes a well-meaning execution team to overcompensate for a shallow engineering bench by hiring an army of external professional consultants-- what a previous boss used to call “masses of asses.”  But that decision is a cultural signal that the war might already be lost; that it’s already too late because the home team is no longer strong enough to support those occupying forces.

When the project starts to go pear-shaped, the conversation pivots to the need for talent upgrades.  Hilarities ensue.  Because it was the framing of the space as a commodity function that essentially caused its accelerated decline-- a self-fulfilling prophecy.

And that is why the perennial build-versus-buy discussions are so dangerous.  Sunsets lead to darkness, yes, but faster and more chaotically than anyone expects.   

The counter argument btw-- because it’s all really about talent, not whether you build or buy-- is that your best people should focus on your company’s core competency, the areas that differentiate your product or service.  But putting your top talent exclusively on functions that are strategic competencies means that they're being supported by your middlers and lower-skilled performers, essentially giving your gladiators paper swords.

The Answer: Set Your Engineers Free. Yes, Because You Love Them. (Skip to the next section if you’re not a leader in tech)

The best way to address a vicious cycle is to never let it start.  And the flight of your best never starts with a decision to turn a space into a potential backwater. Their departure is a symptom.  And the underlying problem is that they were taken for granted.  By you.  By your institution.  By your culture, your policies, your bureaucracy….

So the first best thing to do is to love them.  In some HR-appropriate way.  Please.

Soooooo… [that was awkward]... if you’re an engineering senior who is about to make a large buy decision-- and my guidance to “love” is too mushy-- consider this cleary-non-exhaustive list of more tangible suggestions:

1) Invest in your engineers.  Seriously.  Clear time for them to learn and make that learning substantive.  Stay clear of your future vendor’s training as that boxes engineers into a niche.  Focus instead on deepening integration strengths, for instance:

• Asynchronous data transfer between vendor and proprietary systems via Kafka or RabbitMQ or… if you’re knee-deep in legacy integration needs - MQ;

• Identity protection via OAuth frameworks-- i.e., Okta or SAML 2.0.

• Any open-source frameworks that intersect with your inbound buy-- i.e., Spring, Hazelcast, Camunda, etc.

• Or better yet, ask your engineers.  They know what they don’t know.

2) Reframe the upcoming buy as an opportunity to innovate around the integration.  Add some commercial ambitions around that innovation-- i.e., let’s build something so magical that we can sell it back to the vendor… or if they’re open to it, let’s co-create with the vendor.  The point here is that buy spaces are incorrectly framed as “innovation complete” when they’re ripe with opportunity for Mars shots.

3) Pay your engineers more.  And definitely more than the ones doing all that exciting, sparkly machine-learning/AI stuff.  Think of it as hazard pay.  Money isn’t a great motivator but it doesn’t hurt-- especially when you see the look on Mr. Blockchain’s face when he learns that the billing team makes more.  Keep chasing the hype Bob!

I’m sure you have a million better ideas. 

Focus on mastery, purpose, and authentic gratitude!  But most importantly, that first word: focus.  

As engineers, we have the tendency to focus all our attention on the north star (because we’re wired to be efficient maximizers).  

Let’s never lose sight of who we’re walking with on the path. 

The Original Ending To the Piece: Buying Failure

Look, the whole build-versus-buy conversation is older than tape.  And it inevitably turns into an esoteric philosophical debate.  The problem is that the collective wisdom around this process ignores the impact on (and of) in-house talent.  

Project governance as a discipline has effectively institutionalized Daniel Kahneman’s notion of intuitive heuristics.  We regularly make technology investment decisions that sidestep the real complexity.  We fail to consider how a “buy” culture exposes that one tiny loose thread on our nice sweater and we look the other way when the resulting talent migration ties that string to a passing bullet train.  

We should stop framing good financial stewardship as having answered the easiest possible question-- should we build or buy-- the kind of shallow exercise that can be mastered with a simple matrix.   And let’s discredit the management consulting bs that frames the right question to ask as “whether your business model can accommodate the risks and long term investment that comes with managing an in-house software development cycle.”

The honesty of it is that if your business model (and talent) can’t manage a “build” then you won’t be able to deliver a “buy.”

LinkedIn Tease:

I originally published this anonymously almost 10 years ago.  I’ve refreshed it here, cut-and-pasted like crazy and added an arrogantly-titled section called “The Answer” because when I re-read the original now, I think about how irresponsible I was admiring the problem without posing a solution-- a real failing given how much I value the Noah Principle.   

If you’re unfamiliar-- There’s no point to predicting more rain if you’re not building the ark.