Nobody buys technical competence

The first time I tried to pitch a client project, I did what an engineer does. I put together a thorough explanation of the approach, the architecture, the tradeoffs I had considered and rejected.

It was good work. It went nowhere.

The thing I did not understand at the time is that competence was not what was in question. Nobody was sitting there wondering whether the thing could be built. They were wondering whether taking on the project was going to become their problem.

The actual question being asked

When someone is deciding whether to bring you in, the question in their head is rarely “is this person capable.” It is closer to: if this goes badly, how bad does it get, and does it land on me.

That reframes everything about how you should talk.

A detailed technical proposal answers a question nobody asked, and worse, it often increases perceived risk, because now the buyer is looking at a complicated thing they do not fully follow and wondering what happens when it breaks and you are unavailable.

What actually lands is smaller. Here is the specific problem you have. Here is what it costs you now. Here is the smallest possible first step that proves whether I can help, and here is what it costs you to find out.

You are not selling the solution. You are selling a cheap way to stop wondering.

Small first, always

The single most useful thing I changed was leading with something small enough that saying yes is not a real decision.

A short assessment. A working prototype of one narrow piece. Something bounded in time, bounded in cost, and structured so that if it goes badly, they have lost very little and learned something anyway.

Two things happen. The obvious one is that the barrier to starting collapses. The less obvious one is that you find out early whether you actually want the engagement, because a small piece of work surfaces how an organization really operates faster than any number of scoping calls.

I have walked away from things after a small first step. That is the system working, not failing.

Say the uncomfortable thing early

The instinct when you want work is to agree. Someone describes what they want, you nod, you find a way to make it fit.

I have come around to the opposite. If I think the thing they are asking for is the wrong thing, I say so in the first conversation, with a reason and an alternative.

Sometimes that ends it. More often it does the opposite, because most people have been told yes by vendors for years and can tell the difference immediately. Being the person who says “I do not think that is your actual problem” is a stronger position than being the person who says “sure, we can do that.”

It also saves you from the engagement where you build exactly what was specified and everyone is unhappy at the end.

The part I got wrong longest

I thought commercial skill was a separate discipline from engineering, and slightly beneath it. Something you tolerate so you can get back to the real work.

That was wrong, and it cost me time. Understanding what someone is actually worried about, and what constraints they cannot say out loud, and what a decision costs them politically, is the same class of skill as understanding a system. It is modeling something complicated well enough to predict how it behaves.

Engineers are usually good at that. Most of us just never point it at people.