The Art of Technical Due Diligence
Whether you are investing, involved in a merger and acquisition, evaluating a partnership, or considering joining the leadership or board of a tech startup, you might find yourself in the puzzling situation of having to assess a group of people developing some sort of technical artifact. Be it a spacecraft or an IoT toilet, this technical “thing” is probably a black box for you, although you need to know more in order to discern if it’s just snake oil or something worth investing in, or joining to help it grow.
The good news is that, whatever a random engineering team appears to be creating, the underlying technology is more or less known. Unless you are so lucky—or unlucky, I’m not entirely sure—to be dealing with a bunch of Thomas Edisons, chances are they are not reinventing the light bulb but crafting something out of existing technologies and methods. Regardless of how spectacularly marketed, it surely boils down to the same old fundamentals. How to proceed then? How to gauge the collective technical effort of people you just met? Ignoring for now obscure things such as “product/market fit”, and also leaving financial matters to the experts (i.e., how well or badly funded they are), we will strictly focus on some more technical aspects and do a quick but reasonably thorough inspection to see if what you’re dealing with is worth relating to, or if it’s better to let it pass.
If I were you, I would pay attention to these few fundamental factors, which I will expand individually:
The Social Fabric
The Prototype vs Product Factor (aka The Gossamer Gap)
The Charlatan Factor (aka The Mardas Gap)
The Métier
The Founder Factor
The Choices
The Social Fabric
Sounds like a cliché, but it’s still painfully true: developing technology is about people getting along. Therefore, also for tech endeavors, you need to scan the social scene. How? Well, there’s no chatGPT possible here, but an elementary, old tool: conversation. But to talk about what exactly?
Teams, like many things around us, are interconnects of nodes; a network, or a graph. In any network, although the overall performance is the result of the contribution of each and every element, not all nodes have the same role or relevance. In networks, there are elements that are very well connected (have a high degree centrality), others that might not be as well connected but are critical to integrate distant parts of it (have high betweenness centrality), some others that might be influential (have high eigenvector centrality) and some more which are rather irrelevant and peripheral because they lack all the former.
In any organization, there is the org chart showing the “official” network, and then there is the informal network which is nothing less than the nervous system of the organization. In this informal network, many private “subnetworks” exist which are made simply of people liking and trusting other people and talking frankly and safely about whatever they want. Those subnetworks are formed on affinity, convenience, or a combination of all that, and are ubiquitous, and they evolve in real-time.
If you’re evaluating a tech collective, and if you have the chance to inspect their social fabric—even more if you are considering joining in a leadership position—you must gauge the true social scene. Talk to the foot soldiers, the worker ants. Gauge how many “empires” have been built there, who are the emperors and empresses, and who connects the empires together. Gauge the cliques, the alliances. Venturing yourself to lead a social fabric you know nothing about is, to say the least, reckless. Chances are the informal network will chew you up and yeet you sooner than you would expect. And you could be hardly surprised should that happen.
The Prototype vs Product Factor (aka The Gossamer Gap)
A human-powered airplane. That was the challenge set forth by Henry Kremer in 1959. For 18 years, nobody could do it. But within six months of trying, Paul MacCready built and flew his Gossamer Condor (see below). The difference was in his approach: While others needed a year’s worth of effort for each test flight, he created a plane that he could fly, fix, and fly again in a matter of hours.
The story of how MacCready won the prize is interesting. While other teams had more people, time, and resources, which enabled them to make sophisticated aircraft, that didn’t get them close to winning the prize. He said, “That proved that those approaches were not very good”. In fact, MacCready felt his inexperience and lack of resources was actually a strength. “Each other team had a specialist for every discipline, and so the wing structure was constructed starting from conventional structural design by an excellent structural engineer from the aircraft industry,” he said. “I have no background in aircraft wing structure. Thus, in my naiveté, I started from first principles (with some insights left over from building indoor model airplanes in the 50s and hang gliders in the early 70s), pretended I never saw an airplane before, and came up with the Gossamer Condor approach that permitted a 96’ span vehicle to weigh only 30 kilograms. The other engineers also knew about indoor models and hang gliders, but they knew so much about their specialty that an easier approach was not apparent.”
A somewhat simple read of the story might lead us to the conclusion that the Gossamer Condor is yet another proof, and a particularly epic one, of the importance of combining naiveté, fast iterations, and incremental design. And that interpretation would not be wrong, although there’s another interpretation. First, ask yourself an important question: why aren’t we all pedaling through the air to our work every morning? Why aren't there hundreds of human-powered tiny airplanes parked outside railway stations in Amsterdam, Brussels, or Buenos Aires? The Condor was just a rough…prototype. It was unsafe, rudimentary and fragile, all inescapable traits of most prototypes out there. Prototypes are made only to prove something, make a point, and do it as quickly and cheaply as possible. Safety, compliance, ergonomics, accessibility, are never part of the thinking process during prototyping, although they become essential during production.
In time, MacCready and his team improved the idea and designed the Gossamer Albatross, with which they aimed to cross the English Channel.
Early in the morning on June 12, 1979, amateur cyclist and pilot Bryan Allen powered the Albatross to the rehearsed speed of 75 revolutions per minute and took off from a point near Folkestone, England. The Channel conditions and lack of wind were ideal for the crossing.
However, problems soon began to affect the aircraft and pilot. Allen's radio failed for a while and he was only able to communicate with the accompanying boats by hand and head movements. In addition, Allen's water supply had been estimated for a two-hour flight, but headwinds delayed the crossing and his supply ran out. Without adequate water, Allen suffered from dehydration and leg cramps. Tell me about UX. With increasing headwinds, concern grew that the flight would have to be called off. With the coast of France still unseen, an accompanying boat maneuvered in front of the Albatross to hook it to safety. However, for the hooking procedure, Allen had gone a little higher and found less turbulence, so he continued to pedal the aircraft and see if progress could be made. With a calming surface wind, Allen continued, and landed on a beach at Cape Gris-Nez in France. Allen completed the roughly 36 kilometers crossing in 2 hours and 49 minutes, achieving a top speed of 30 km/h and an average altitude of 1.5 m.
The Albatross was an undeniable evolution of the Condor, but still, it was nothing remotely near production level. Acknowledging the difficulty of human-powered flight, MacCready would eventually shift into solar-powered electric aircraft with the Penguin and then the Solar Challenger, early projects of what would then become AeroVironment.
Too many companies have nothing but prototypes dressed as products. But one thing is to come up with a rough strawman concept about something, and an absolutely different story is to productize that into, well, a product you can sell. Products are things that people—customers—pay for. And selling anything implies intricate liabilities, contracts and compliance involved. There are legal frameworks, certifications, safety regulations, environmental regulations.
The Gossamer Albatross involuntarily made a beautiful point when it struggled to cross the English Channel. Prototyping can help to prove a point, and it can be fun. But naiveté and rudimentariness will not provide enough thrust to cross an important gap—the gap between prototype and product which can only be named in one inescapable way: The Gossamer Gap.
Having a prototype does not mean having a product. There is a wide gap between the two. It’s essential to assess how far something that can be a good-spirited initiative sits from being ready to be produced in a reproducible manner and sold in a market. Too many people are almost literally pedaling in the air.
The Charlatan Factor (aka finding the ‘Magic Alex’ in the room)
Somewhere between 1965 and 1966, while checking out an art exhibit at the Indica Gallery, John Lennon became enamored with a man who had recently moved to London from Greece. He claimed to be an electrical engineer. His life before moving to London was —and still remains— unknown. But from that meeting onwards, Yannis Alexis Mardas became known as “Magic Alex.” Alex, when asked, described himself as thus:
“I’m a rock gardener, and now I’m doing electronics. Maybe next year, I make films or poems. I have no formal training in any of these, but this is irrelevant.”
With such an honest self-description, you couldn’t say he was trying to scam anyone.
Magic Alex’s electrical gadgets and contagious enthusiasm caused him to become a part of the Beatles’ inner circle right up to the last days of the band, and for the longest time, they trusted his every word. His ideas were revolutionary, after all. Wallpaper that could act as loudspeakers. A recording studio with multiple computers and a 72-track desk. Mardas gave the Beatles regular reports of his progress on the 72-track thing, but when they required their new studio in January 1969, during the Get Back project that became Let It Be, they discovered an unusable studio: no 72-track tape deck (Mardas had reduced it to 16 tracks), no soundproofing, not even a patchbay to run the wiring between the control room and the 16 speakers that Mardas had fixed to the walls. The only new piece of sound equipment present was a crude mixing console that Mardas had built, which looked (in the words of George Martin's assistant, Dave Harries) like "bits of wood and an old oscilloscope". Lovely. Unsurprisingly, the console was scrapped after just one session. George Harrison said it was "chaos", and that they had to "rip it all out and start again, calling it "the biggest disaster of all time".
If anything, Magic Alex’s raging incompetence left a great legacy: a phrase added to the English scientific language known as the ‘Mardas Gap’, which is used to describe the disparity between someone’s promise and what they can achieve.
Many startups have their own “Magic Alexes” in-house. Charlatans who act like revolutionaries, only to be mere “rock gardeners”. Some of them might be hard to catch, as they may camouflage behind intricate terminology and aggressive overconfidence (which tends to give them away). But they eventually crack under pressure. Go find them in the wild. If they exist in low amounts, that’s a good sign. A solid zero is extremely rare.
The Métier
Tech diligences tend to revolve around moats, defensibility, and intellectual property. But they sadly miss the point. The connecting point of all that is the métier.
Ah, the elusive métier, the mystical realm where companies find their true calling. Elusive for those doing tech diligences but often also elusive for those in the company.
Picture the métier as the company's secret sauce, the magical blend of skills, expertise, and savoir-faire that sets them apart from the average John Doe Corporation. It's like that one party trick they do better than anyone else, except it's not a silly card trick, it's their bread and butter. Their tech may not be revolutionary, but if a company knows its métier, its schtick, it’s a different animal to consider. A company's métier is their competitive edge in a dog-eat-dog business world, it's the thing they do so well that even their competitors begrudgingly nod in admiration. But finding it is no easy task. It's like hunting for a needle in a haystack, except the haystack is made of iterations, market research reports tireless data mining, customer surveys, and spreadsheets that could put you to sleep faster than a lullaby.
Once a company uncovers its métier, it's time to embrace it like a long-lost sibling. It’s a force multiplier. It's like proudly displaying a neon sign that says, "We're really good at this, so please don't even bother trying to take a piece of the pie."
But here's the kicker: a company's métier isn't set in stone. It's a living, breathing creature that needs to adapt and evolve. The business landscape is a fickle mistress, and what's hot today may be yesterday's news tomorrow. Successful companies don't rest on their laurels; they embrace change like a chameleon at a paint store.
In the end, a company's métier is their reason for existence. It's what makes them shine in a sea of mediocrity and keeps their stakeholders coming back for more.
No métier in sight? Better move on then.
The Founder Factor
Now, grab your pompadours and mind the treacherous world of founderitis, also known as founder’s syndrome. In all fairness, it affects organizations of all sizes and across all industries, but it’s particularly infectious in startups.
You see, when a regular soul catches the entrepreneurial bug, something strange happens. They start with a great idea, passion in their hearts, and a dream in their eyes. But, as they fall in the arms of the corporate world, they may morph into control freaks, unwilling to let go of their precious baby even when it's time to let it spread its wings.
Someone once said a platitude that goes something like, "If you work really hard and you're kind, amazing things will happen." Well, this person was right, but they forgot to mention that amazing things also happen when you don't hold on too tight. Founderitis breeds a toxic mix of micromanagement and ego, turning once-promising visionaries into paranoid autocrats who surround themselves with courts that act as itinerant echo chambers.
The symptoms of founderitis are easy to spot. You've got the "I'm the only one who can do it right" syndrome, the "I'll just bypass all established processes and make one more tweak" syndrome, the infamous "I must be involved in every single decision" syndrome, or the “rules apply to everybody except the founders”. It's like they're stuck in a never-ending, privileged loop of unwillingness to trust their team or delegate tasks.
Scan for founderitis. Good leadership realizes that success comes not from hoarding power, but from empowering others.
The Choices
In times of globalized supply chains, no one designs and manufactures up to the last screw. Whether the technical artifact is a hypersonic aircraft or some e-learning app, everything has a breakdown structure, a tree-like depiction of all that is needed to materialize the damn thing. Tech teams must decide how to make that breakdown come together, i.e., how to synthesize it. Regardless of the endless vertical vs horizontal integration argument (we’ll not go there as it may get a bit opinionated) every technical artifact out there exudes the decisions its designers took along the way. Any serious tech due diligence process must shed some light on these decisions and the dependencies they created, for the decision-making process could have turned the whole thing into a house of cards standing on top of a collection of single points of failure. Granted, to decide is to make bets about the future, but tech projects that only wager straight-ups in the roulette are a solid red flag.


Conclusion
Technical due diligence is detectivesque stuff in the corporate world. It's the hound that digs deep into the trenches, sniffing out any potential landmines or ticking time bombs that could blow your investment or your career to smithereens. Technical due diligence is performed to uncover the weaknesses, the half-truths, the pitfalls, the signal from the noise, and to separate the tech wizards from the overabundant charlatans.