That’s the question I posed on Twitter recently, and it’s a question I ask myself now and then when I consider my own career trajectory. Pre-sales engineering is the sales part of engineering in which a technology professional works with customers, account managers, and project managers to discover customers’ needs, design solutions, build quotes, determine scopes of work, and create bills of materials. Sometimes these folks are called Sales Engineers, sometimes Solutions Architects.

Every company I’ve interacted with uses these titles somewhat differently, and I don’t think there’s a true consensus on  the nature of the role. Sure, you can look up the actual definition if you like, but survey a bunch of companies and individual engineers and you’ll get a variety of responses.

In my estimation, someone meeting with a customer to learn their business needs and how they relate to technology doesn’t necessarily have to have a deep knowledge of every routing protocol and every piece of hardware out there let alone how to implement them. Discovering an organization’s business needs is a skill in and of itself, and in that sense doesn’t need someone to be able to configure a router or firewall.

But those business requirements eventually translate into technology requirements. When a pre-sales engineer determines that a particular technology will fulfill that requirement, I have to assume they know something about it.

Account Managers spearhead the initiative to discover the customer’s needs and begin the process of building trust. But the real trust is built on the [successful] delivery of the solution. The pre-sales folks start this process by instilling some semblance of confidence by explaining and recommending some technology, but it’s the actual delivery activities that make that real.

If the design doesn’t reflect an intimate knowledge of how this stuff works in real life, the project is set up for failure. The trust which was just starting to develop will be lost, the relationship strained, the business opportunity squandered.

Deep familiarity with the technology, including the gotchas, caveats, and intricacies deployment engineers live and breath, is what really produces a solid design and implementation plan. What sets good pre-sales engineers apart isn’t their charming smiles and ability to squeeze just a little more margin on every deal, but the ability to meet the customer’s business need with technology in the context of how it works in real life.

A pre-sales engineer with little to no deployment experience is lacking in their ability to deliver a top quality design. I don’t mean that a pre-sales person with a few certifications and no delivery experience can’t churn out Visio diagrams based on the last 154 projects the company did. In fact, that may work out just fine in certain market segments. But that’s not solutions architecture, and it’s a disservice to most customers.

I know a lot of deployment engineers who see pre-sales as the next step in their careers after tiring of 2am cutovers and what seems like an eternity of windshield time. I don’t disagree with this, because the experienced deployment engineer who also has the ability to see the big picture and interact effectively with customers is the linchpin in a successful project.

This doesn’t mean that a solid pre-sales person needs to be straddling the fence between pre and post sales. The really good pre-sales folks I interact with are frequently in the lab experimenting with a design or keeping up with the latest technology. Even if they’re unable to actually implement the solution, they’re staying close to how the technology works in the real world, and that gives them the edge to go from Senior Visio Maker to Senior Solutions Architect, in the truest sense of the title.

Does a pre-sales engineer need to have strong implementation experience to be good at their job? I think so. Even if it’s from labbing potential designs, the best pre-sales engineers I know actually know how this stuff works in the real world.