Build vs buy, virtuoso writing

“Coverlet meshing” wrote some nice articles. One of them:
For those that want to get a taste before clicking the start of the article (I’m not going to neatly format the following, the real read is one click away :wink: ):

Build Vs. Buy: A Dangerous Lie
IT’s eternal debate sidesteps the complexities of a fragile talent ecosystem and creates a vicious cycle that ensures project failure.
There are no good “buy” options. Period. I’m not saying there aren’t any good products out there. There are. But given the complexities of fluid business conditions and the peculiarities of the internal processes that support them, the term “off the shelf” is a marketing gimmick.

“Buy” is never just “buy.” It’s actually “integrate.” So is “build,” which means they both require similarly skilled engineering talent. Therein lies the dilemma.

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

The space in decline experiences the opposite of gentrification. The allure of someone else’s “build culture” sucks out all the talent that matters, leaving behind non-technical project managers (the overzealous and process-focused) and technical order-takers (under-motivated second- and third-tier engineers). In the Mortal Kombat vernacular, that combo leads to a fatality because that diminished internal team simply can’t deliver what the business thinks it’s getting “off a shelf.”

[Don’t get too comfortable in middle management – instead, flatten the org. Read Career Advice From The Future.]

Note that I can’t stand those three words: off the shelf. They’re classic marketing misdirection, 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 engineering talent from your “buy” organization means that you don’t have a can opener. If you’re lucky, you have a hammer, and it’s somewhere out in Chennai. Most orgs-in-decline don’t even have that. They just have to learn to eat the can.

Enter senior management
The decline plays out predictably. That ripe smell of flop sweat, even before the buy engagement starts, causes senior management to overcompensate and hire an army of external professional servicers. But it’s already too late because the home team is no longer strong enough to support those occupying forces.

Ever-diligent about project optics (and their own career paths), senior management pivots and starts talking about the need for talent upgrades. Hilarities ensue, because it was their 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 faster and more chaotically than anyone expects.

The counterargument – 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 strategic competencies means that they’re being supported by your middlers and low performers, essentially giving your gladiators paper swords.

A good example – for which I’m sure I’ll get hate mail – is Human Resources IT. How can I say this politely? The market isn’t flooded with world-class engineering talent with a depth of HR IT experience. Management’s default buy options, i.e., PeopleSoft/Taleo, guarantee that this space remains IT’s talent backwater. This is ridiculous (this is me backpedaling) given the role that talent plays in the success of every business.


Reformatted the quote into a quote to make it substantially more readable without tons of horizontal scrolling. ^.^


Do you have a simple trick for that? It costs me far too much time.

I just hit my record button, hit > then space, hit my end-of-line key then the right key, then hit record again to stop recording and hit my macro’d key a few times, all-in-all it takes about 2 seconds (I love my keyboard ^.^).

Another way in markdown is just put > at the start of the first line then on every blank line there-after until the quote is done, so just a quick copy/paste, takes a few seconds.

Spoiler Alert!

> 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.

1 Like

I have seen that play out fairly often. I think there is a build/integrate tradeoff that can be made, but it has to be in the time dimension. Can I build it in a timeframe in which I could integrate it?

Buying is not always bad, but it almost always goes bad when you think it’s going to save money.

And another very simple way when using a graphical browser with JS activated is to mark the text that shall be formatted and then use the mouse and aim for the quotes (") icon in the toolbar just above the editor and use your primary mousebutton (the left one for right handed mouses, the right one for left handed ones) to click.

1 Like

I have the easiest way for long excerpts :003:

Just put [quote] at the start of the quoted text then [/quote] at the end of it :023:


My takeaway wasn’t that buying is always the wrong choice but that management often succumbs to the fallacy that a purchased solution can be successfully wrangled by a less capable (i.e. typically cheaper) workforce.


I recognize the downward spiral coverlet meshing names. I have worked for many years with a language that was originally a 4GL. Progress. They had a selfmade database also. Progress software the company is named. Management decided over the years to buy all kinds of products (and the companies) off the shelf. They bought a bpm company: savvion. They bought a rules-engine: corticon etc. etc. etc. Some of these were sold again. These products are mostly not easy to integrate. With savvion f.e. you suddenly not only needed the progress appserver on the backend for your application, but also a java jboss appserver. The whole product is written in java.
When your best engineers become demotivated and ultimately leave the company a lack of self-trust and self-esteem appears. We cannot build, so we must buy. This company could have chosen to build themselves a lot more too. Their core products, the language and the database, are loosing users now.
I for myself have positive reasons to come here too of course. :wink: “Moonshot engineering”, that was wat I was looking for: