Searls of Wisdom for July 2024

Last month I talked about the power of pressuring yourself instead of letting the world do it for you. This month, I can report that I followed my own advice and managed to get a metric shitton of work done on the app I'm building. Sure, I fell behind on other goals, I only left the house a handful of times, my to-do list has become a stress-inducing mess, and I can't say I had much fun. And I'll admit, there were times I questioned what the hell I was doing with my life. But think of the productivity! I successfully stimulated my work ethic gland and I hustled hard.

Maybe a little too hard. This was the least blurry of all three pictures taken of me this month:

Looking at my GitHub contribution graph and there was only one day in July that I didn't commit any code. And I apparently averaged 580 lines of code changes every day. Is that a lot? It felt like a lot. My wrists hurt.

Of course, as has been observed for decades, metrics like lines of code indicate approximately nothing about the software being written. Even reading the code itself can only tell you so much—scarcely more than an IKEA assembly manual can tell you about the PÄRUP sofa it describes. You might think this is prelude to an exhortation that rolling up your sleeves and actually using the software is the only way to truly understand it, but no: that doesn't mean much, either! What the user sees is just the tip of the proverbial iceberg.

Alas, the only way to deeply understand what the hell is going on in the vast majority of software systems is to talk to the people who made it. The pointy-haired boss who sponsored its creation to solve a problem or seize on an opportunity. The analyst who had to translate what the business wanted into requirements. The designer who drew pictures of buttons and form elements. The developer who ignored those requirements and that design and instead programmed whatever the system ended up becoming. Yes, you can perform a useful forensic analysis without direct access to any of the humans involved in the creation of a software system, but ask any detective: it's way less work when you can convince the perpetrator to lead you to where the bodies are buried.

As a career-long consultant, I had to get really good at extracting information from stakeholders like these. I might only have 30 minutes or an hour of someone's time, so I had to make the most of each question I asked. Complicating matters, many people—the vast majority, in my experience—aren't very good at explaining complex topics to an uninitiated dumb-dumb like me. Especially if they've been steeped in that complexity day-in, day-out for years on end. My success or failure often depended on rapidly transforming these people into expert explainers.

Years ago, I added a tool to my consulting toolbox to aid me in this task: making bad analogies.

Imagine, if you will

First, let's set the table a bit. Let's suppose that the success of your next project depends largely on a half-day discovery session with the creator of a system that you're inheriting. (I'll refer to them as "the expert" from here on.) They're moving onto some other job and they've graciously offered some of their time to help you come up to speed on what they've built. Here are some obvious-but-inadvisable ways you might choose to spend your precious time together:

• Ask them to present an overview for you. This puts the onus on the expert to guess what information will be most helpful to you. It may even encourage them to do some preparatory work (pull examples, draw flow charts, build slides) in advance. Suppose 30 seconds into their presentation you realize it's not going to give you what you need—what then? If you interject to say their presentation is off-the-mark, you'll be (1) telling the expert that you know better than they do, (2) devaluing the prep work they did for your sake, and (3) dealing with the emotional fallout of having just undermined their pride of authorship
• Bring other people to the meeting. If the primary goal is for at least one person to be able to deeply understand the system moving forward, then you'll have better odds putting all your chips behind one person (e.g. yourself) to acquire that understanding than to hedge your bets by putting multiple people in the room and hoping that enough knowledge will stick to at least one of you. Experts are often primed to be defensive about their work and will be more likely to obfuscate perceived areas of weakness in proportion to the sense of threat they experience. And make no mistake: being asked to defend one's work before a group of three, four, or twenty others is a far more threatening dynamic for most people than a one-on-one setting. Besides, it's usually a waste of time: your coworkers probably aren't as good at this as you are and because you're so polite, you'll burn daylight trying to ensure everyone gets equal question-asking time in order to feel included
• Come equipped with a litany of detailed questions. If you already thoroughly understand the big picture, then by all means feel free to dive into the weeds, but that's unlikely the situation you're in. The beginning is the moment you know the least, so any questions you prepare are likely to be based on low-confidence assumptions and ultimately rendered irrelevant. Moreover—supposing that peppering them with highly-specific questions manages to not trigger a defensive reaction—detailed questions will invite responses at a much deeper level of detail than you're prepared to grasp at this point

Each of the above three scenarios achieves the exact opposite of what you want. Instead, these would be my priorities:

1. You're the one whose success depends on this meeting, so you need to be in the driver seat, not the expert
2. You'll get more out of someone who feels safe, understood, and valued, so optimize the environment for their comfort, not yours
3. You know your destination but not how to get there, so focus on learning enough about the expert's journey so far in order to pivot the conversation towards potential paths from here

With these goals in mind, there are countless ways to proceed and innumerable right answers. Fun!

The power of the analogy

I start simply enough. For each topic to discuss, I ask my high level question (How does this software make or save money? How does data flow through the system end-to-end? Why is the color scheme green-on-taupe?) and then do my best to shut up and listen until I have a loose grasp of what's going on and why. Call it an 80% level of understanding.

As with most things, the first 80% is a lot easier than the last 20%. Left to their own devices, many experts will answer a question well enough to convey that basic understanding before—in the face of breaking down such a complex thing—meandering down any number of conversational paths that might spring to mind. But you don't care about those paths. Of course, it's possible their subsequent rambles will get you closer to the understanding you seek, but there's not enough time to leave it to chance. Instead, grab the steering wheel.

Of course, taking charge and asking probing follow-up questions is a valuable skill when you're on a fact-finding mission, but it can be counter-productive if you're looking for the Big Idea behind a thing. Asking an expert a follow-up question will almost always cause them to delve deeper, and—at least in the early goings—depth is the enemy of understanding. You need more forest and fewer trees. (I can't tell you how many times I've had to politely tell a client I don't want to see their backlog of user stories, the 80 page RFP they drafted, or the thirty pages of Figma prototypes they commissioned.)

Here's what I do instead of asking questions at times like this: I get kinda bored and then I make shit up.

Specifically, and under the guise of testing my own comprehension, I think up an analogy to whatever the expert just explained to me and offer it up for their appraisal.

Real-life examples that come to mind:

• "So, in your mind, the assets on the electrical grid topology are like hexagons in a strategy board game, and placing game pieces on them will confer different effects on load, voltage and, current?"
• "Am I right in thinking that ordering custom steel coils is more like ordering a pizza online and less like identifying the right screw from the 30 little bins at Home Depot?"
• "If I understand you right, is the cannabis cultivation app you're describing similar to this iPhone app for dog breeders to log traits over subsequent generations?"

This approach has several nice qualities:

• Analogies throw the expert off balance, potentially getting their creative juices flowing. As much as people purport to hate wacky analogies, they nevertheless seem to love finding ways to build on them. ("Actually, similar to ordering a pizza well-baked, customers can trade off hardness and stability based on hotter or cooler furnace temps")
• It's a way to pull the conversation out of the expert's domain—where they have you at a tremendous information disadvantage—to more neutral ground where both parties can communicate fluidly without getting mired in term definition and asides. ("Current is based on the state of the pieces on the board but has the same value everywhere, so it's more like a status condition off to the side")
• Rhetorically, proposing an off-topic, irreverent analogy as a way to summarize someone's work is highly provocative—as in, literally likely to provoke a strong response. Nothing elicits a good answer faster than proposing a bad one first, so you'll learn in a hurry if your silly analogy is way off base ("It's nothing like dog breeding, it's more like how Pokémon breeding was way harder in Gold and Silver but made easier with the Destiny Knot in X and Y." Okay, dude)

This all comes fairly naturally to me, because I can't help but talk when I feel nervous. It may be possible to solve the same set of problems by, say, "being a good listener," but that was never in the cards for me. Your mileage may vary!

The benefits of bullshitting

Crafting hypothetical analogies based on context you and the expert both share—importantly, context which resides firmly outside the domain being discussed—means that when both parties reach consensus that a particular analogy is apt (affixed with however many if's and but's are needed to make it work), you can be pretty satisfied that you understand the concept well enough to move onto the next topic.

There are additional knock-on benefits to this method of prisoner interrogation:

• The conversation will be easier to recall later, because stories and visuals that connect to other memories and experiences are stickier than unfamiliar abstractions and obscure facts
• By taking the expert in directions they didn't anticipate and wouldn't otherwise associate with their work, there's a chance you'll challenge the preconceived story in their head they use to understand that work. (And that's valuable! Whenever I've had to explain the same thing multiple times, I'll find myself thoughtlessly reciting the same speech rather than critically reexamining the words coming out of my mouth)
• If, like me, your next step after this conversation is some version of, "figure out how to build custom software that does this," then congratulations! You already have a rich collection of metaphors upon which to draw inspiration for modeling everything from data to behavior to user interfaces

Neutral, just-the-facts information exchange, robbed of any emotion and mechanized through compartmentalized roles and automated processes is often treated in business and technology circles as inherently virtuous. But, in my experience, receiving a written specification or a JIRA ticket thrown over the fence by some product manager isn't half as educational as a spirited debate over whether their desired UI refresh for a robot vacuum's room map is sorta like setting up invisible fence zones for a dog's shock collar.

More broadly, whenever one party has the other at a significant information disadvantage, communication will be constrained until you can find a way to level the playing field somehow. When I'm talking to someone who knows more than me and I'm struggling to understand them, they may not know how lost I am; even if they do, they probably don't know how to fix it on their own. There are countless ways to overcome this kind of information gradient, but one reason I like proposing bad analogies until we eventually settle on a good one is that improving my own understanding is my job and this approach gives me more agency in the task of completing it.

Okay, that was probably enough thought leadering for one month. I'm gonna take this opportunity to make like a VC and exit. 📈