Being good at it is the entry fee

In 1997, during the closing Q&A at Apple's developer conference, a man in the audience told Steve Jobs, in front of everyone, that on several counts he clearly didn't know what he was talking about. The subject was OpenDoc, a technology Apple had just killed. Jobs didn't defend the decision on technical grounds. He said people like that gentleman were right in some areas, admitted there were plenty of things he didn't have the faintest idea about, and then said this:

You've got to start with the customer experience and work backwards to the technology. You can't start with the technology and try to figure out where you're going to try to sell it.

I keep coming back to that answer. The question was deeply technical, and the reply was about the person on the other end.

I got to see this from an unusual seat. I was once involved in a fintech product built from the ground up, and it took a lot of market research and a long round of vendor benchmarking before anything was written. I was the technical point of contact. I sat through the sales pitches with the other leaders, then dug into each vendor's integration documentation to check whether the pitch held up. The final decision wasn't mine. My job was to analyse and bring my view back as clearly as I could.

The vendors with the best story weren't always the ones with the best product. Some were missing features the product needed. Some weren't ready for the responsibility they'd be taking on. And a few gave presentations so hard to follow that even I found them tiring, but when I read their docs properly, the product underneath surprised me.

Two vendors drawn as commit lines, split into the pitch and the docs. The best pitch starts with three clean green commits, but its docs show two hollow squares, labeled missing and not ready. The hardest pitch starts as a tangled grey squiggle, labeled tiring to follow, but its docs show five solid amber squares with nothing missing. Illustrative.

It's a rare position, sitting on the buyer's side of the table while still being able to open the hood. Most buyers can't, and those good vendors were being judged on a pitch that hid them.

I hear a version of the same complaint a lot: "I'm good at what I do, and nobody sees it." Often it's true. They're good, like those vendors. I think being good is the entry fee. It's what lets you take the job. What people remember, and pay for again, is how it felt to be on the other side of the table while you did it.

The mechanic who lets you in

Think about the last time something broke that you don't understand. A car, the plumbing, your own health. Take the car.

The first mechanic listens to the noise, says "CV joint, come back Thursday", and goes back under another car. They're probably right. They might be the best mechanic in town.

The second one walks you to the car, shows you the part, tells you what it does, why it wears out and what happens if you wait a month. By the end you know enough to ask something that makes sense, like "can I still drive it to work this week?" You have a little authority over what happens next, even though you couldn't fix it yourself.

The first mechanic may be more qualified. You go back to the second one.

Nobody expects you to become the expert. That one sensible question shows you understood enough to take part, and taking part is why you trust the repair.

Two git graphs of the same car repair. In both, an amber work branch with four commits, diagnose, order part, fix and test, splits from the client line and merges back at car ready. In the first, labeled come back Thursday, the client line is empty in between. In the second, labeled walk me through it, three green branches drop from the work into the client line: see the part, two options and your call.

Everyone has a client

By service I don't only mean selling. Anyone with a job has someone on the other side of it.

For a software engineer, that's the project manager, the product owner, the stakeholders and the sponsors paying for the work. They can't read your pull request, and they don't need to. They need to understand where things stand well enough to make their own decisions.

Picture two updates on the same problem. One says "the migration is blocked." The other says "we found that old orders have no customer attached, so moving them would break invoices. We can clean them first, which costs a week, or move only the last two years. I'd do the second." Both come from the same engineer with the same facts. Only the second lets the product owner ask a sensible question back. The first leaves them waiting, or worse, guessing.

A product engineer does this earlier in the process. Someone arrives with a confusing, half-formed problem, and the job is to make sense of it and hand back a story simple enough that everyone can see where it goes. The code comes after that, and it's better for it.

People pay to feel part of it

When someone hands you a problem, they're also handing you some anxiety. They're spending money, time or reputation on something they can't judge directly. What gives them confidence is feeling part of the process: knowing why things happen in the order they do, and seeing what they asked for turn into something with a purpose.

Technical skill is what makes the result good. The experience is how they know it's good. Most people on the other side can't tell a great solution from a decent one by looking at it, but they can always tell whether they were kept in the dark.

Polish can't cover a gap

Polish without substance is just a nicer way to disappoint someone. The vendors with the best story and the gaps underneath were exactly that. If the second mechanic charmed you and then the car broke down on the highway, the explanation wouldn't count for much. Skill comes first, and all of this sits on top of it.

It also costs time, and not everyone wants it. Some people really do just want the car fixed by Thursday. Explaining every detail to them isn't generosity, it's making them do your homework. The skill is reading how much the other person wants to be involved and giving them that much, instead of running the same speech for everyone.

Ask the other side

If you're good at what you do and don't feel seen for it, it might be worth asking the people on the other side of the table one thing: when they work with you, can they ask a question that makes sense?

References

Steve Jobs, WWDC closing chat, 13 May 1997. Video and full transcript at All About Steve Jobs.
John Gruber, "Working Backwards to the Technology", Daring Fireball, 2014.