Why your good Tech failed
Making Tech is like Riding the Bull.
This wasn’t your first rodeo.
You know how to build good tech. Your team has done everything from Six Sigma to Agile. They pair-program. They scrum. They “Red Team.” They watch for scope creep & they keep objectives small and measurable. They know that Tech project deadlines are like target practice: that you have to Aim High, since Gravity Sucks.
Yet still, despite all this, your good tech went south. Why?
Okay. Here’s what you did.
And don’t be surprised if you’ve done all these things. It’s OK, most tech teams do them all. These five things come with the territory when you’re doing Good Tech.
Your tech was misnamed.
The people you put in charge were too smart.
Your team talked about the Doing, to dodge talking about the Doers.
Your budget was too big.
For this particular project, you failed because failure was the best outcome.
So, from the top now. Here is what you did, one at a time, in detail…
1. Your tech was misnamed.
The parts of your project were misnamed too. You sometimes gave only a single name to two or three different things. In hindsight, clearly each one should have gotten its own name.
My cousins were killed in a tragedy that was partly caused by two cases of bad naming:
“Position and Hold.”
Until that evening in 1991, air traffic controllers would tell pilots to “Taxi into Position and Hold” at a certain location. After the fiery collision that took my cousins’ lives, controllers began to say “Line Up and Wait” if the plane was to be on an active runway. They would say “Position and Hold” if the aircraft were to stop elsewhere— not on a runway. The single phrase “Position and Hold” was doing double duty. It had been naming two distinctly different circumstances, on an active runway, but also off of it. Two different names were needed, not one.
Can you see the plane?
“Takeoff Lights”
The pilots of my cousins’ plane never saw the aircraft that was on their runway, waiting to take off. This is because that aircraft would only have turned on the “Takeoff Lights” once they were cleared for takeoff. When every person on that aircraft was crushed to death, the plane was nearly impossible to see, a dark shape on a dark runway at night.
Given the name “Takeoff Lights,” it made perfect sense to switch these lights on only once an aircraft had been cleared for takeoff! After all, those are “Takeoff Lights.” But naming lights after a single event or process like “Takeoff” was a bad idea. All the aircraft’s lights were named this way: Navigation Lights, Landing Lights, etc. This had obscured the need for lights called “Look at Me, I’m an Aircraft!”
Tech Naming is Not Normal.
How is this handled on things less technical than an aircraft? Cars have headlights. They’re not called Driving Lights, because normal people name things as “things,” not processes. This is a better way to name, since headlights can be used for many things, without having to call them “Tow a Boat Lights” or “Light Up the Parking Lot so I can Look for My Wallet Lights.” Car headlights do indeed say “Look at Me, I’m an Automobile,” without having to be named for that function. This “naming a thing after a thing and not a process” is called Self Naming, or Embodied Naming. It’s a wise way to name. And as the Chinese Proverb goes, Wisdom begins with Good Names.
Tech folks very predictably name things after processes and actions. This is Disembodied Naming, and the result is often bad names. Tuck folks are not bad people for doing this, because this behavior is very predictable from them. And, of course, you’ve now been warned. You’re welcome!
To this day, the parts of an airport where pilots and other vehicles can move freely without permission from the Control Tower, where there is lots of free and easy movement of planes and vehicles, is called—wait for it—the Non-Movement Area. This is the name chosen by groups of very smart people [cue the shark music].
So why, if Embodied Naming is so good, do tech folks resist it? And they sure do resist it! The tragedy that took my cousins’ lives did eventually lead to changing the name of the aircraft “Navigation Lights” to “Position Lights.” But this same exact problem with misnaming lights was implicated in the worst airline crash in history, on the island of Tenerife in 1977 when two Boeing 747s collided. Why wasn’t the naming problem solved then?
Because tech folks hold tight to their bad habits. More on that when we talk about the next reason your good tech failed.
NEXT TIME:Use Embodied Names instead of abstracted names.
Tech is a cultural solvent.
This means that tech actually dissolves the words that we use to describe our world. What day and night meant before Edison was a distinction that was in large part dissolved by electric light. The former stark difference between day and night no longer existed. The pill did the same thing to men and women, and the fax machine, and then the cell phone and then zoom conferencing did the same to work life and home life. The list is endless.
What does this mean for your good tech project? It means we are fated to name our tech with words that are themselves often dissolving in the face of the tech that we create. We’ve made such powerful tools to help secretaries, plasterers, wood turners and carpentry joiners, that those jobs—which used to be lifelong professions—have nearly vanished.
And the stronger our tech is, the more thoroughly it dissolves the culture we work within. Makes it tough.
Furthermore, our names for things are changing at different rates. Some of our naming is becoming more and more precise, while other names are much looser.
NEXT TIME:
Note the names for which your tech may be a solvent.
You might just cut off the branch you’re sitting on!
YouTuber Tim Dodd gives us a peek into a chat among Rocket Scientists including Elon Musk. As you might expect, there are some pretty advanced technical concepts, and even though Elon Musk takes a really strong stand against overly technical language, it gets pretty deep. Then they point to the Wingy Thingies—the fins/ailerons/rudders that encircle the base of the rocket.
Yes, the rocket scientists called them Wingie Thingies.
It’s subtle what they’re doing. Make no mistake: it’s done very much on purpose. And it’s brilliant. For mature concepts that have become precise and exact over time, like MECO [main engine cutoff] and SECO [second engine cutoff], they use precise and exact language. For new things—for innovation—their language is roomy & loose, ready to stretch to accommodate changes that are sure to come.
At a lesser company than SpaceX, Engineers, who suffer from the insecurity of the super smart, would use overly precise, overly exacting lingo, no matter what they were talking about, blurring the distinction between the pliable & new ideas, and the Tried & True ideas.
NEXT TIME:
Mark the names you use that are mature & fully precise, like MECO & SECO, and note the names that are still roomy & loose, like Wingie Thingies.
Expensive Blindfolds.
Very Smart Quants & Designers both have the tendency to excessive abstraction. We can take a bundle of elements that would be an incoherent mess to most people, and we’ll call the bundle by a shorthand that we think sounds cool—and we will imagine that the incoherent mess has actually BECOME cool, through our obscure name for it. “It’s Cool to be Obscure.”
But as that Chinese proverb goes, Wisdom begins with good names. That incoherent bundle is likely not one thing at all. The wise move may be to call the bundle by two or three names. Once we factor this bundle into its parts, our project might not fail next time.
Quants & Designers are prone to the pull of idealism as well. So, while normal folks see a headset and say “Is that for scuba diving?” or “Isn’t that one of those blindfolds to let you fall asleep?” we the Super Smart correct them, saying “No that’s an Apple Vision Pro—it’s for Spatial Computing.” And we will believe it. Cuz it sounds cool.
SmallCo sez:
Note the category names for which your tech may be a solvent.
You might just cut off the branch you’re sitting on.Mark the names you’re using that are mature and fully precise—like MECO & SECO—and note the names that are still loose and baggy—“Wingie thingies”
Use Embodied Names instead of abstracted names.
Beware of Strangely Idealized Names—Apple Vision Pro, Spatial Computing and the like—and stay in touch with the fact that most folks will think it’s a big blindfold.
2. The folks you put in charge are too smart.
Dr. Earle Haas was a brilliant inventor, and definitely a Quant. You can see it in the Numbers: it’s Quantifiable. His tampon design was objectively and measurably better than rivals in the market.
He knew how the thing worked—and he tried to sell the thing by talking about how it worked, like a Quant would. That didn’t go well.
Dr. Haas sold his invention to Gertrude Tendrich, who was definitely not a quant, and definitely was a brilliant marketer. She sold “freedom,” and never discussed the details of the device itself in her ads. The ads did say “no pins, no belts, no pads.” But the closest they came to describing the device was to say, rather obscurely, that they were “worn internally.”
Dr. Haas’ wholesale disregard of social niceties, allowed him to invent the tampon. For this he earned tens of thousands of dollars.
Gertrude Tendrich’s deft touch with social niceties allowed her to accomplish one of the great marketing coups of the 20th Century. Her company made billions of dollars.
It takes a certain kind of brilliance to disregard convention. Often that brilliance comes with real social awkwardness and even the autism spectrum. Inventors like Dr. Earle Haas, creator of the tampon, focus incessantly on QUANTITATIVE ADVANTAGE. Quants like Dr. Haas are gifts to human culture, even if they don’t always feel that they quite belong in human society. Yet Quants are usually worse than average at understanding the social dynamics of a team.
NEXT TIME: Don’t have Quants lead a team—except for v.1 of new tech.
Yapi Kredi Cultural Art Complex in Istanbul / Glass Front
We’re humans. We don’t need easy.
I fell in love with this beautiful building in Istanbul. Look at the photo, and you might love it too. The entire front façade is clear glass, and I can see the stairs within. Each stair landing is labeled: first the ground floor at lower right, with a Capital G, and then the first floor at left, the second floor at right, the third at left, etc. I found it so pleasing how the entire circulation flow of the building was visible to me before I even stepped inside. It made me smile.
Then I looked to the right and left, and saw many many other multi story buildings, some of them hundreds of years old. “Hold on,” I mused. “How did the millions of citizens of this ancient city ever understand how to use a multi-story building before this brilliant design?“
This made me smile again. I’ve liked to think that we Designers do good, with our focus on simplicity, elegance and “ease of use.” ‘I’ve been slow to grasp that by chasing these noble-sounding goals, we designers end up treating our clients like kindergartners.
And in a way, that’s even an insult to kindergartners. Think of all the older folks who ask their grandchildren to program their household tech for them.
Humans, even the young ones, don’t require ease of use. We require sensible designs that reward effort with a benefit for those we love. We’re looking not for simplicity, but for leverage.
To the extent that designers disrespect the intelligence of their patrons, they miss the target of their patrons' needs. And they swing and miss in a way that is even worse than the way Quants miss.
Designer sez we should live here.
But Designer lives here.
Why doesn’t he like us? Did we do something to upset him?
Quants don’t understand humans—but ignorance can be cured. Designers diss the humans—and arrogance is harder to fix.
NEXT TIME: Don’t choose Designers to lead a team.
Making great Tech almost always requires very smart people. But it’s usually a rotten idea to put very smart techies, whether they are Quants or Designers, in charge.
Smart Folks polish their prejudices. Good Leaders poke holes in their prejudices. The smartest among us can also be very stiff in their thinking. Stiff, and even stubborn. This is now confirmed by research that shows that the highly educated are often the most likely to hold onto their mistaken points of view, precisely because they are able to corral their intelligence to defend their false beliefs. With Super-Smart teammates, “confirmation bias” becomes an occupational hazard!
NEXT TIME: Don’t choose very smart people to lead.
So Who Should Lead?
Innovative tech projects require leaders who are able to understand the many points of view that they will definitely find on their teams. It’s great to have a really good person leading a team, but that person‘s skills are much more likely to be characterized in terms of breadth of understanding—across discipline—rather than deep knowledge of a subject area or deep fluency in specialized vocabulary. Indeed, specialized vocabularies are the enemy of successful tech projects.
SmallCo sez:
Choose leaders who can speak powerfully, with small words.
Quants can deliver new tech. But don’t have Quants or Designers lead teams until they’ve shown they can address their blind spots.
Don’t hire leaders who have ANY fear of looking stupid, or of asking a stupid question.
Hire leaders who can manage very fragile egos: ones who can listen carefully and smile and express gratitude for hard work, and then without blinking, deliver pointed criticism and demand that poorly argued points are reframed, argued better or conceded.
“We shall defend our Island,
whatever the cost may be.
We shall FIGHT on the beaches.
We shall FIGHT in the fields and in the streets.
We shall FIGHT in the hills.
We shall never surrender.”
Small words. Until ‘Surrender.’
3. Your team talks about the Doing, to dodge talking about the Doers.
The owner of the Patriots, and the coach he fired.
The New England Patriots football team had a disappointing year. Coaches are fired, including the winningest coach in Super Bowl history, and players are traded or cut.
On the other hand…
A tech team has a disappointing year. So they decide to pivot their project management from Critical Path to Critical Chain, or from PMP to PRINCE2. Fire people? Nope.
Tech folks already have a tendency to ignore or discount “the humans.” This is why there’s so much technical writing in passive voice. You know already that this makes for lousy writing. All of the actual players in the drama are discounted or left out, allowing inanimate objects to levitate around of their own accord.
NEXT TIME: Look for passive voice framing
The Disappeared
Here’s how the United States Federal Aviation Administration described the main fix for the crash that killed my cousins:
“Implement procedures that provide redundancy measures for position awareness”
“Position Awareness”? Position of what? And who exactly is to be aware of its position? Both the agent and the object have been left out of this writing. And who is to implement those procedures?
Here’s how it might have been written, removing passive voice and gratuitous big words, and naming the agents [the Doers] and the objects:
Traffic control managers should ensure that air traffic controllers, ground crews & other pilots have backup methods to keep track of aircraft, under challenging conditions such as darkness and inclement weather.
This is not just “better writing.” It’s clearer thinking. One of the reasons your good tech failed is that there is a pattern of unclear thinking in tech. These patterns are the recurring habits of people who do tech. Don’t kid yourself: you won’t be eliminating these habits. They are like the way a sports car steers in corners. It’s what you get when you decide to drive a sports car.
NEXT TIME: Be eagle-eyed in spotting “process talk” that hides the people
Granted, it can be a lot easier for us quants to write in a passive voice, because we get to leave out the confusing and illogical humans, with all of their hard-to-understand motivations that give us such fits anyway.
But this calls to mind the H.L. Mencken quote:
"For every complex problem, there's a solution that is simple, neat, and wrong."
In many ways, switching to a different project management process is not just like rearranging the deck chairs on the Titanic. It can be identical to that. Our beef is with the folks who sit in those chairs, and with the relations among them.
When a Tech project fails, the same “passive voice problem” occurs at the next level: this time not about our clients and patrons, but in reference to our own team.
We may say that we need to “implement a more rigorous risk management process,“ or that “the low resolution capture of use cases prevented better quality assurance.”.
What’s hiding in these tortuous utterances are the people who messed up.
Risk is Managed Here.
4. Your budget was too big.
Here is the same company, building two different projects.
Of all the reasons to love the original Apple Macintosh, cutting-edge hardware was not one of them. That first Mac boasted a tiny 9 inch black and white screen. It came with one floppy drive, when other personal computers supported two floppies and a hard disk. Not a single hardware subsystem was close to the bleeding edge. What was stunning & groundbreaking was the way all those elements came together as an ensemble with the software to create a charismatic and engaging character—a little minion willing to do our bidding.
Apple’s Vision Pro did it upside down and backwards. Every subsystem is either cutting edge or v. 1, from the dual inward facing outward facing screens to the accelerometers,from the ventilation system for each eye to the reinvented on-off switch. The demanding work of sticking the landing on these subsystems eclipsed the vision for the device as a whole. While the Macintosh had a wry and disarming personality, the Vision Pro comes off as anonymous, or mute, or even vaguely sinister.
Brilliant and expensive teams met their goals, like reducing weight, lengthening battery life and tweaking the new hand gestures. But other questions were left unanswered, like…
“Who is this thing for?”
“ What will it help them do?“
“ Why did the thing jump on their heads and cover their eyes?“
Once we go so far as to refer to a process of risk management, which is conducted in a corporate department called “Risk Management,“ we are all set to fail.
That’s because we are now primed to miss this point: managing risk is the responsibility for every individual person on our team. When risk is not managed, it means that someone on our team didn’t manage it!
If you read too many sentences like this, they will make you dull. You’ll read “the low resolution capture of use cases prevented better quality assurance” and you’ll miss the fact that “the low resolution capture of use cases“ cannot prevent a damn thing, because “the low resolution capture of use cases“ is not a person. It is our people, our team, who prevent or enable things.
SmallCo sez:
Spot “process talk” that hides the people.
Look for passive voice framing
Identify language that treats people like pinballs: “Impacted minority populations will be serviced by targeted outreach at the regional level.”
Speak in simple & direct language using the words You and Me.
Florida Brightline vs. HS2 from London to Manchester
1939 Volkswagen vs 1944 Volksjäger
5. Your tech was meant to fail, so you can learn the lessons that lead to great tech.
And no, this last one is not just putting a good face on things. Truly, the most valuable outcome for many bold and visionary tech projects is for them to fail—while we are watching with eyes wide open—so we can learn, and then try again. This isFailing Up, and allowing for it is one of the most powerful strategies in tech. Thomas Edison was a master of this, as is Elon Musk today.
When you’re building a new kind of rocket, you can learn a lot from the moment they blow up. Same thing when you’re…
testing the filaments for the first light bulb,
or when you’re figuring out how to make an augmented reality headset —
or when planes collide on a runway.
But you will learn best when you’ve had the foresight to install those black boxes to help you know what led up to that crash — in other words, when you’ve prepared to benefit from the lessons of failure.
SmallCo sez:
Just as your project moves forward with small measurable objectives, make sure that every point of failure is measurable as well. When you lose, don’t lose the lesson.
When you worked with small project budgets, you always imagined how wonderful it would be when you didn’t have to chafe against the constraints that a tight budget brings. You daydreamed about the great work that you would do with an unlimited budget.
Your daydreaming probably did not include the fact that all of your various team members had their own personal visions of the great things that they would do with a big budget. You’ve got a Tech Dream Team. But they’re used to having the budget to make their magic. And their dreams can easily compete with the shared dream of the project as a whole.
Big budgets do the same thing to projects as Super Smart Project Leaders, and the same thing as Misnamed Projects. They make it that much harder for the team to have a singular and truly shared vision.
The truth is, elegant design, the best tech, comes when a team is pushing against severe constraints. Creativity is nearly impossible without firm & unforgiving limits.
SmallCo sez:
Make sure none of your sub-projects is more inspiring than the project as a whole.