Chapter 1

His badge was turned around, so I couldn't tell where he was from.

It was mid-afternoon at the Amazon Web Services trade show — that particular hour when the hall starts to thin and the delegates who remain are the serious ones, the ones who came to find something specific. My colleagues and I were on our company's stand, doing what you do at these events: scanning faces, reading body language, trying to work out who was browsing and who was buying.

This guy wasn't browsing. He walked up to the stand with the kind of purposeful energy that said he'd already decided we were worth his time. He looked at our signage, looked at me, and asked the question every person at every trade show stand has heard a thousand times:

"So, what do you do?"

I could have jumped straight into the script. Every pre-sales person has one. The company overview. The market positioning. The product features. The customer logos. The deep technical architecture that most technologists, including me, find comfortable — that safe ground where we can demonstrate how much we know and hope it's enough to impress.

But I didn't.

I asked him a question instead.

"Before I get to that — what do you do?"

He paused, just for a second. It was a small thing, but I noticed it. He wasn't used to being asked. Most vendors at trade shows launch into their pitch the moment someone makes eye contact. They're broadcasting. They're not listening.

It turned out he was the head of architecture at one of Australia's largest banks. His team was wrestling with a legacy authentication platform that couldn't keep pace with the bank's digital ambitions. He needed something modern, something that could scale, and he was running out of patience with vendors who wanted to talk about features instead of problems.

We spoke for nearly twenty minutes. Not a pitch — a conversation. We moved from his team's programme of work to the broader architectural challenges, then into a detailed discussion about the protocols underpinning our solution's capabilities. He knew his stuff. I knew mine. And because I'd started by asking about his world instead of describing my own, we'd built a bridge between the two.

The following week, I was in front of him and his team in their office, facilitating a three-hour workshop. They were well-versed in their requirements and deeply technical. After my introductory slides — which I kept short — they peppered me with questions. How could our solution integrate with their existing environment? How would they manage the deployment? How would it scale as a consumer banking service? How could we meet their security requirements, which were, to put it mildly, exacting?

I moved to the whiteboard in the corner of the room. By the time our session ended, every inch of that board was covered — diagrams, protocol flows, integration points, deployment models — like something out of a film where a maths professor has been lost in thought for an hour.

I was a wreck by the end. I felt as if I'd gone fifteen rounds, each member of the team taking turns to work me over.

But something remarkable happened afterwards. Our account executive started discussions with their procurement team. A couple of weeks became a couple of months, and we signed the contract — without a product demonstration, without a proof of concept, without any further involvement from me or the pre-sales team.

We had won their trust. In one meeting.

That bank went on to become one of our most significant customers. They expanded their footprint with us, took reference calls for other prospects, and spoke at our events in front of their industry peers.

And it all started because I asked one question instead of delivering a pitch.

I didn't always know how to do that.

Let me take you back to the beginning.

February 1990. My first week at IBM. My head was a blur of acronyms, job titles, and colleagues' names, each day bringing a flood of new information that left me drained by five o'clock.

I was a fresh-faced graduate, straight out of university, brimming with that special brand of naïve enthusiasm reserved for people who have never had a real job. IBM had chosen that very week to announce the release of their new mid-range computer, the RISC/System 6000, running a new version of their Unix operating system, AIX v3.

I was skilled in Unix. I'd learnt the vagaries of the OS at university, on Silicon Graphics workstations. And I made sure everyone at IBM knew it. I told every person I met, with the brash confidence that would make Messrs Dunning and Kruger blush, that I was a Unix expert and would love the opportunity to work with AIX.

Most people smiled and nodded at my youthful energy.

Except for a sales rep in his early fifties who had worked at IBM his entire career. He listened to my spiel. Then he looked at me the way a doctor looks at a patient who's just diagnosed themselves via Google.

"Look… no."

His blunt reaction stopped me cold.

"Don't tie yourself to a technology," he said. "IBM still has people on staff who are experts in the time clocks we sold in the 1960s. We no longer sell time clocks, but those people are still here. Work on your customer skills and go with the flow on the technology."

I stood there, deflated, my carefully rehearsed pitch about Unix expertise suddenly feeling very small.

That conversation lasted less than two minutes. But it has echoed through every year of my career since. In hindsight, that sales rep gave me the single most valuable piece of professional advice I've ever received. He was telling me something that took me years to fully understand:

Your technical knowledge is the price of admission. It gets you in the room. But it's not what keeps you there.

What keeps you there — what makes you indispensable to your customers, your sales team, and your company — is your ability to connect with people. To understand what they need before you tell them what you know. To earn their trust, and then to keep it.

That's the job. Not the technology. The people.

This book is about how to do that.

If you're a technical person considering a move into pre-sales — or if you've recently made that transition and you're wondering what you've got yourself into — this book is for you. Maybe you're a developer, a support engineer, a consultant, or a systems architect. You're good at what you do. You know your technology inside and out. But you've started to notice that the people in your company who seem to have the most influence, the most interesting work, and the most varied careers are the ones who sit between the technology and the customer.

The pre-sales engineers. The solutions architects. The technical evangelists. The people who walk into a room full of strangers and, within an hour, have those strangers leaning forward in their chairs, asking questions, imagining how this technology could transform their business.

It looks like a gift. Like something you're either born with or you're not.

It's not.

It's a skill. A set of skills, in fact, that can be learned, practised, and mastered — just like any programming language or deployment methodology you've picked up in your career. And over thirty years working in pre-sales at companies like IBM, Netscape, Sun Microsystems, Oracle, and Ping Identity, I've learned those skills through a combination of mentorship, observation, practice, spectacular failure, and the occasional success that made all the failures worthwhile.

I've won eight-figure deals and lost to competition I thought was inferior. I've delivered presentations that had rooms buzzing for hours afterwards, and presentations that died a slow, painful death in front of everyone. I've built demos that blew customers away and demos that blew up in my face. I've worked with brilliant salespeople who made me better, and salespeople whose methods made me question whether I was in the right profession.

Through all of it, I've found that the same principles keep surfacing. The same skills keep making the difference. And they have very little to do with how much you know about your product's technical architecture.

Let me be honest about what this book is not.

It's not a sales methodology. There are plenty of those — MEDDIC, Challenger, SPIN, Sandler — and some of them are excellent. But they're written for salespeople. This book is written for technologists who find themselves on a sales team and need to figure out how to thrive there without losing their identity or their integrity.

It's not a presentation skills handbook, although you'll learn a great deal about presenting. It's not a guide to running demos, although there's a detailed chapter on that too. And it's not a motivational pep talk full of platitudes about being your best self.

It's a practical guide to becoming a trusted advisor — the kind of person that customers call before they've even defined their requirements. The kind of person salespeople fight to have on their team. The kind of person whose reputation follows them from company to company, opening doors that would otherwise stay firmly shut.

And at the heart of this book is a framework I've developed over those thirty years. I call it the Influence Architecture.

The Influence Architecture is a four-stage developmental model — a way of thinking about the skills you need to build, the order in which to build them, and how to apply them in every customer interaction, from a chance meeting at a trade show to a year-long enterprise sales campaign.

The four stages are:

Ground — the foundation. Your product knowledge, your industry awareness, your business fluency, and, most importantly, your self-knowledge. What you bring to the room before you open your mouth.

Orient — the pivot. The moment you stop thinking about what you know and start thinking about what the customer needs. Listening, discovery, empathy as a practice rather than a platitude. This is where most technically trained people struggle, and where the real transformation begins.

Elevate — the craft. Translating your knowledge and your understanding of the customer into communication that creates influence. Storytelling, simplification, presentation, demonstration — the visible skills that make the difference in the room.

Anchor — the trust. Delivering on your promises. Admitting what you don't know. Building relationships that compound over years and follow you across your career. The stage where connection becomes trust, and trust becomes your most valuable professional asset.

These stages build on each other, like the floors of a building. You can't Elevate without having first Oriented to the customer's needs. You can't Orient effectively without solid Ground. And you can't Anchor trust without consistent delivery across all three stages below.

The bank deal I described at the start of this chapter? It moved through all four stages in a matter of weeks. I had done my Ground work — I knew my product deeply and understood the banking industry's challenges. At the trade show, I Oriented — I asked about his world before describing mine. In the workshop, I Elevated — I adapted my communication to his team's level and moved to the whiteboard when the slides weren't enough. And the trust we Anchored in that single session was strong enough to close the deal without a proof of concept.

That sequence — Ground, Orient, Elevate, Anchor — is what this book will teach you to do, consistently, in every customer interaction.

I should also be honest about what this career demands.

Pre-sales is not a desk job. It involves travel — sometimes relentless travel. Time zones, hotel rooms, airport lounges, and the particular loneliness of eating dinner by yourself in a city where you don't know anyone. It involves being "on" in front of customers when you're exhausted, jetlagged, or dealing with personal problems that have nothing to do with work. It involves the highs of winning a deal you've poured months of effort into, and the lows of losing one you thought was yours.

I've seen the toll this takes. Colleagues who put on weight from years of client dinners and hotel breakfasts. Relationships that buckled under the strain of constant absence. People whose confidence was shattered by a run of bad presentations or a particularly brutal loss.

And I've felt it myself. There were times, even deep into my career, when self-doubt crept in after a bad day. When I questioned whether I was good enough. Whether I belonged in the room.

In those moments, I'd repeat a simple mantra to myself:

I am enough.

It's a powerful statement. It doesn't mean you can't improve — of course you can, and this book will show you how. It means that you are where you are for a reason. You've earned your place. Your knowledge, your experience, your perspective — they have value, even on the days when it doesn't feel that way.

Pre-sales is demanding. But it's also one of the most rewarding careers in technology. You get to learn constantly. You meet fascinating people. You solve problems that matter to real businesses. You see the direct impact of your work in signed contracts and successful implementations. And if you do it well — if you build the skills this book describes — you become someone that people trust. Not just with their technology decisions, but with their professional reputations.

There is no higher compliment in business than being told: "I trust your advice."

That's what this book will help you earn.

The structure of this book follows the Influence Architecture. After the next chapter, which presents the framework in full, we move through each stage in sequence.

Part II covers Ground — knowing your product, your industry, and yourself. Part III covers Orient — listening, discovery, and reading the room. Part IV covers Elevate — storytelling, presentations, demonstrations, and written communication. Part V covers Anchor — delivering on promises, working with your team, managing long-term relationships, and building your public profile. And Part VI — The Long Game — brings it all together with a guide to building your career over the arc of a working life.

Each chapter opens with a story from my career — sometimes a success, sometimes a failure. Each chapter gives you both the principles and the practical techniques to develop the skills it describes. And each chapter connects back to the Influence Architecture, so you always know where you are in the journey and what to work on next.

I wrote this book because I wish someone had given it to me in February 1990, when I was standing in that IBM office being told to stop talking about Unix. It would have saved me years of learning the hard way — through embarrassment, miscalculation, and the slow accumulation of scar tissue that eventually became wisdom.

You don't have to learn it the hard way.

Let's begin.