This is how I work, in two parts. The first is about selling technical expertise, which is most of my job. The second is what I believe about building a team and doing good work.
Selling technical expertise
Technical companies rarely lose a deal because of the product. They lose it because the buyer can’t explain the decision to the people who approve it. These five principles are how I work on that problem. They come from solution selling, adapted for technical sales.
1. Start with their problem, not your product
The first conversation is about the buyer’s operation: how it runs today, where it breaks, and who deals with the fallout. Hold the product back until you understand that. Show it too early and the meeting turns into a demo.
2. Make the cost of doing nothing visible
A good product isn’t a reason to change. People change when the current way costs too much. Put a number on it: downtime, rework, hours of manual reporting, a quote that takes two weeks. Without a cost, there’s no reason to act now.
3. Map who decides and what each of them needs
A plant manager, an IT lead, and a CFO look at the same system and care about different things. Tell the same story in a way each of them understands. Find out who signs, who can block it, and who has to use it every day.
4. Translate features into daily work
A feature list says what the product can do. The buyer wants to know what’s different in their day once it’s running. End every technical point with what it means for the operator, the manager, and whoever owns the budget.
5. Give your champion a story they can retell
Most of the decision happens in meetings you’re not in. Your contact has to explain it to people who never saw your demo. If they can’t do that in a couple of minutes, the job isn’t done.
What this isn’t
It isn’t a pitch deck, a script, or more product training. Your technical people already know enough. The work is helping them turn what they know into a story the buyer can pass on and defend.
What I believe
Outside the sales conversation, these are the beliefs I lean on when working with a team. Some I learned the hard way. Some I picked up from people and books I trust. They’re not rules, but when I’m stuck, they’re usually where I start.
Standards are set by what you let slide
A team’s real standard isn’t what’s written down. It’s what we accept from each other without saying anything. So I try to be clear about what I expect, from myself and from the people I work with, and to say it early and often. I’d rather over-explain than leave someone guessing. I put a lot of energy into people who want to push further, and into helping others get there, because that’s how the whole team moves forward. When we hire, a real doubt usually means the answer is no. And being better than most at something is less rare than it sounds. Most people never practise on purpose, so steady, deliberate effort gets you further than talent.
Move fast by moving calmly
Speed matters. A good answer next week often beats a perfect one next quarter, and most limits on how fast something can go are assumptions nobody checked. But rushing isn’t the same as speed. Calm, well-practised work ends up faster than frantic work. So we cut the scope until something can ship, get it in front of real people, and spend the polish only where people will notice it. Pressure comes with the job, and I try to read it as a sign that the work matters. Small teams make all of this easier: fewer handoffs, faster decisions, and everyone sees what their work changes.
Clear thinking beats clever solutions
I start with why: why this, why now, and why it matters to the customer. A good question does half the work, so I’d rather spend time on the question than rush to an answer. I push back hard on vague thinking, including my own. “Improve efficiency” isn’t a goal until someone can say whose efficiency, measured how, and by when. And I try to stay attached to the problem, not to the first solution I liked. It’s rarely the best one.
People make sense from where they stand
When someone does something that looks wrong, they usually have a reason that makes sense from their position. Finding that reason is more useful than judging it, and the way I judge others often says more about me than about them. Feelings are information too. Frustration usually means an expectation wasn’t met, so the fix is often to talk about the expectation, not the feeling. And nerves before a big meeting are mostly energy. Take a breath and use it.
Open by default, and fun on purpose
Share work early, keep information visible, and make closed the exception. When everyone sees the same thing, arguments get shorter. Freedom in a team means the freedom to take ownership, not freedom from responsibility. And the work should be fun. Teams that enjoy what they do stay longer, learn faster, and push harder when it counts. It’s one of the few advantages that’s hard to copy.