The state of Sales (Solutions) engineering in 2023

A lot has changed since I first started doing this 15 years ago.

I’ll save you the “back in the day” dreck, but suffice it to say what got us here will not take us there. Here’s a few observations I’ve noticed.

The first major change is the amount specialization and expertise required. When I started, it was enough to just be a smidge more technical than your salesperson, and the sales folks could get away with being the "dumb sales guy" and rely 100% on the SE s for anything technical. Seems farcical now, but at the time the amount of information that was available online was a fraction of what it is today, so customers were forced to take a call and see a demo to "learn more". Now, 80-90% of product research is done online prior to a company ever even contacting a vendor.

This is is generally good news. When customers get in contact, it's most likely because they've seen something on your company website that struck a chord with a use-case or some pain they're having, which in turn leads to less woody demos. This also means there just aren't that many places to hide for a mediocre SE anymore. The entire sales motion has been shifted in a technical direction, so the SE better have some proper in-depth content and detail to share because the salesperson is going to take care of all the generalist stuff. The prospect has likely seen a full demo on youtube already anyways. 

Following this same line the technical barrier for senior positions is much higher. You can still be a SE and do demos, but this is now a Sales Development position (SDE) and you’ll probably be on the marketing team and mostly work trade shows. Any sales rep who’s worth their salt can do a demo overview now and qualify 90% of the deals. SE’s time is now spent doing the tricker stuff like deep-dives with larger audiences, pilot planning, success-criteria definition, scoping, etc. Nothing that wasn’t already in a senior SE’s repertoire, but this is now the focus rather than the outlier.

With this comes a whole new set of skills that are moving from “nice to have” to “required” on a typical SE job rec. What got you hired as a senior SE 10 years ago would not get you hired for the same position now. In cybersecurity specifically, thinking that because you have a C|EH and a business degree will get you hired as a senior SE position right out of the gates is a recipe for disappointment. Unless you already have 5+ years experience I would probably pass on your resume for one of my open positions. I need folks who can write to an API, script in Python, know their way around network infrastructure properly and can rock a mic at a tech talk.

The third major change is the blur between pre and post sales. With technical know-how requirements continuing to increase, it’s only natural a bit is going to bleed over past the P.O. Nearly all software companies have pivoted to a subscription-model where the customer renews every year at 100%. When looked at objectively, it doesn’t take a genius to realize that throughout the lifetime of a customer, nearly ALL the revenue potential lies in post-sales. Once a deal is closed is when the real work starts.

For leaders, the breadth of understanding is more extensive than ever. With all these hyper-technical SEs on your teams, you need to understand what they know and constantly be shuffling folks around where they can make the most impact. I've always said that the best SE teams I've ever been a part of, either IC or coach, have been very diverse crowds. As a leader, you need to foster those skillsets and make sure that talent is being put to the best use. 

One of my tactics to help calm nervous testers is to let them know how many friends I have in the post-sales org and that I would never send them a customer where our software wasn’t a fit out of respect. Now however, I sure as hell wouldn’t do it because chances are I’m still going to have to support the roll-out long after the hammer drops. If you're working a territory like most sales teams, you're going to have to re-engage with the post sales folks if there's anything above and beyond a renewal that comes up the following year. If you threw something over the fence and post-sales managed to iron it out, is that customer really going to trust buying from you again? Doubtful...

TL;DR: Technical chops and specialization are the name of the game for SE IC folks, and broad understanding is key for leaders. The industry is getting more difficult, but that also means more job security and more money if you're working for the right org.

Why, in the Age of SaaS, Customer Satisfaction is Your Most Important Department

Woah, What the hell? 

Over the past year and a half, I have been running a post-sales team. This wasn't what I originally signed on as, but as with any startup you go where you are needed. The person we hired for the Director of Customer Satisfaction (CSAT) role ended up being deficient in a few key areas and I jumped in to help out and after a month or so that person was on my team 

Let me start by saying that I am not a good fit for this role in the traditional sense. I like things to have a beginning, a middle and an end, I do not like entitlement or taking orders of any kind, and I especially don't like listening to people complain. These 3 pillars were the world of CSAT as I knew it, and I was not thrilled about taking over this department. Despite this, over time I figured out a way to make it my own. 

The established sales methodology that has been in use since my career began shows the difference between pre and post sales can be measured in miles, not inches. Sales folks closing the big deals get all the glory and serve as a shining example of what grit and perseverance can achieve. Once a new customer is acquired, the customer satisfaction (CSAT) team just needed to listen to customer complaints, answer tickets, and make sure a few new features are released every quarter. Software sales and delivery has evolved dramatically in the past 20 years. When I was first learning the ropes, the typical sales motion was based on a heavy front-end sale and a small renewal. In a large part this was due to the style of delivery for software at the time; fat clients and appliances. Software as a Service (SaaS) offerings were a small, emerging part of the market and largely not yet trusted. Over time, SaaS offerings became the norm and permanently shifted the way we buy and sell software... and because of this traditional methods of selling to and retaining customers must be updated. 

So what does SaaS delivery do? In short, software just isn't as "sticky" as it used to be.  

When you buy a house, you own every aspect of that house. You own the structure, the foundation, the land, and all the bits that make up the house itself. As a homeowner, if you see a new house come on the market that's in better shape, or has some of the upgrades you want, chances are you're not just going to stop paying the mortgage on your existing house and buy the new one. No... you've invested serious time, energy, and money into the house you have now and moving is a huge pain. No... you'll probably just stick with the home you have. 

What if you RENT a house that is fully furnished? If you're living in a rented house full of rented furniture and we take the above scenario... would you move? I would... why not? I have no money and very little time or energy invested so why not make the switch? 

This is the fundamental difference between traditional and SaaS offerings. Because SaaS offerings are in the cloud, they typically require much less effort with installation, configuration and upkeep. As a result, it's much easier to switch should the right opportunity present itself.

Software just doesn't harbor the same loyalty as it once did. So how do we keep our customers? 

 First, let's think about the acquisition process... what does that look like? In enterprise sales, typically we have a sales team that primarily includes one sales manager and one sales engineer. Their sole purpose is to introduce the software, match a customer need, prove the value and close the deal. In my experience this process can be accomplished in 14 to 30 days, and at the end we've obtained a purchase order and we have a new customer. Bully for us. 

20 years ago, we would have been set at this point. The customer gets passed to the support team and we now have a new brand to put on our website and a slew of newly purchased hardware and software to deploy. With SaaS however, the relative ease of switching vendors is always looming. The software company can no longer just throw their new customer over the fence... what if the sales team from a competitor is already talking to them? I have learned this lesson firsthand. 

Up until this point my career has focused primarily on presales work... designing pilot deployments, proof-of-concept's (POC's), and building business cases. When you have a beginning, middle, and end to the engagement it's relatively easy to design a set of criteria and milestones to push to a positive completion. Contrast this with CSAT... once a customer has been acquired, the timeline to prove value stretches on infinitely. The success criteria defined in the pilot have (most likely) been proven out... and everything is SaaS so there is the possibility of losing the account at every turn... so what do you do?

The solution is the CSAT team needs to act more like sales. This doesn't mean they act like they're out to get something from their customers, but rather they are constantly showing, explaining, and "selling" the value of their software to their customers. CSAT can no longer just be "order takers" or "stewards". If all a CSAT engineer is doing is listening to complaints, answering tickets and drafting up feature requests on behalf of the customer, they WILL eventually lose that customer. It's not because that CSAT eng is doing anything wrong... the paradox is the customer could love their CSAT engineer and sing their praises constantly about how well they listen and take direction... but that doesn't mean they'll renew. 

So what... you lose a customer. The amount of revenue brought in year after year from an existing customer is a fraction of the initial purchase price, right? 

No. With a SaaS model, customers will buy a subscription to the service. These subscriptions typically renew annually... but not a fraction of the purchase price... for the ENTIRE purchase price. Yep, for SaaS delivered solutions, renewals are 100% year in year out... which makes the loss of a customer much more damaging to the vendor beyond just losing a logo. 

Couple that pressure with the difficulty of implementing a new, disruptive solution from a startup. This is the scenario that a typical startup CSAT eng faces with each new customer: 

• One or two proponents of your solution in a team of 20+ who have never seen it and don't like change
• Existing processes in place that have been built over years of research and tuning that will need to be re-tooled 
• Issues, delays & bugs that need to be explained to a team who are largely looking for any reason to shelve your solution 
• Other vendors that are looking for any chink in the armor to harp on and replace you come renewal time 

The good news is, there's a way to combat this litany of shit. CSAT engineers need to start thinking of themselves as guides rather than waiters. Coaches rather than waterboys. SHERPAS rather than assistants. This represents a paradigm shift in our idea of customer "care".. but I would argue it's actually far more caring than the previous methods. 

What happens if you are a sherpa taking a group of people up mount Everest and one of the folks in your group says "I want to go this way!" Will you listen to that person and take the group in that direction? Absolutely not. As a Sherpa, YOU are the expert and you know the best way to go. You would politely explain that if we follow the instructions of the person making noise we will all get lost and freeze to death or fall off a cliff. Based on your knowledge and experience, you would resolutely point the group in the right direction and press on. 

This is how CSAT needs to operate in the age of SaaS... letting the customer direct is no longer an option. If the value of your software isn't realized, it WILL be replaced. The only way for any customer to realize the true value of your software is for an experienced CSAT sherpa to show them the way. This is "value" selling, and though it's typically thought of as a sales motion, it is 1--% necessary to maximize customer retention. Remember, the SaaS model is subscription-based, so the value of the renewal is 100% or more of the original purchase price in perpetuity. Meaning the more customers you keep, the more your revenue compounds year over year, and this is by far the quickest way to show exponential growth.

Operator vs. Builder in an increasingly code-ish world

It's been a long time since I've written anything, and a lot has changed in a year. For those of you who don't know, I've moved on from the microservices world. I enjoyed it, but it tested me to my very limits. As with any challenge, I learned ALOT about the field, the tech, and also what I'm good at and what I'm not.

I consider myself fairly technical, but I am not an engineer/developer by any stretch, nor do I attempt to play one on TV. The world of microservices stretched my abilities in awesome new ways, including skills FAR beyond my previous capabilities. I spent more time in a Terminal window (usually multiple) in my 2 years in microservices than I have in the entire rest of my life combined. And no bones about it, 90% of the time I was completely lost (and I'm told that's considered normal)?

Prior to this gig, I was able to get along with bash fairly well, I knew my way around Linux and Mac via command line and I could do some light scripting... but mainly I was just running scripts other people wrote for me and modifying them when I needed to. I never needed to know how to build anything, especially from scratch. I didn't go to school for computer science, I've never taken a coding class, and I never had any real world application prior to force myself to learn. 

I was an operator, not a builder. 

In the world of containers and microservices, even being an operator is difficult. Anybody who has worked with Kubernetes or OpenShift will tell you:

  - Keyboard fatigue is palpable
  - Instructions are confusing (or unavailable)
  - There are a million commands to learn, each with their own function based on context
  - Error reporting is cryptic at best

 Ever tried to set up an OpenShift cluster from scratch? It's like trying to chop down a tree with a pocketknife. I've never operated in a space where the customer EXPECTS things to fail the first 10 attempts. 

That being said, there is a TON of money in this stuff. OpenShift typically costs around $10k per node...per NODE! A cluster for a microservices deployment has at least 10 nodes, but usually more like 200-500... that's a big chunk of change. 

This is because the microservices space is fundamentally different than traditional infrastructure. Once you get things deployed, everything operates with an extreme level of efficiency. Even at the basic level the amount of automation and resiliency far exceeds even the best of the best virtualization. That said, the space is still very much in it's infancy. Bugs abound (as they do with any software), support is minimal for non-RedHat orchestration, and there's just not that much generally available for it. This means lots of trailblazing. 

I define trailblazing in the engineering world as creating something that doesn't already have 10-20
stack overflow articles explaining the proper way to do it. For someone like me, this poses a huge challenge... especially in a startup with limited documentation and resources.

The people who sat in that office with me are some of the smartest, most talented engineers I've ever met. There were more folks with Ivy-league PhD's in my engineering team than folks who didn't have them... and those that didn't were definitely there for a reason. Trailblazing is a way of life for these brilliant minds. Fact is though, even engineers of this caliber struggle in this space... ask anyone I worked with, and that's saying a lot. In a startup that exists in an industry where EVERYBODY is still trailblazing EVERY day... things don't bode too well for the SE who's more of a "people person," do they?

At last, I arrive at my point. I am a firm believer that no one should ever stop learning. Acquiring new skills are how we can all continue to grow as people and increase our value in our careers. I also believe that any experienced professional knows where they excel, and where their weak points are.

There will never be any one person who is good at everything, so eventually no matter how eager you are to take something on, sometimes it's best left to the professional who made a career out of it. I will always try my damndest to figure something out before I ask for help... but eventually I have to take a step back and ask myself: "Is this the best use of my time?" More often than not, something that takes me half a day to choke through can be done in 5 minutes by one of the engineers I have the pleasure of working with.

The key is to maximize the value of their time as well as your. Any time an engineer is helping me figure something out is time taken from whatever engineering-centric task they're focused on. Because of this, I make it a point to document what I learn as much as possible every time, so they don't have to repeat the effort they've already put into my problem. I also put whatever I documented in a place available to everyone in the company, so the other folks on my team can reference our documentation before needing to go back to our engineering team. 

So previously, I was solely an operator... do I consider myself a builder now? Maybe a builder of how-to guides...

I Listen to ALOT of House Music, Here's Why

Anybody who knows me knows that I'm really passionate about music. I listen to everything... literally everything. From classical to metal, dubstep, hard dance, dark techno, trap, bluegrass, folk rock, classic rock, big band... whatever. The only place I don't really listen to music oddly enough, is in the car. For whatever reason I always end up listening to talk radio or podcasts. Regardless, music is a huge part of my life, and that includes during work.

For me, work hours are restricted to house music in various forms. When I'm not on the phone or in a meeting, I've got techno in my headphones. No particular sub-genre, but it needs to have a 4-on-the-floor beat with lots of energy and the longer the track, the better (live/recorded DJ sets are good). The most important attribute however, is little to no lyrics.

I always find it fascinating when people listen to rock or hiphop when they're trying to get shit done. For me at least, if someone is talking to me while I'm typing, I will inadvertently end up typing what they're saying. Same goes for any music with words, I'll end up with a bunch of song lyrics in the email I'm writing. I've tried classical, ambient, jazz, and various world music as well, those genre's just don't have enough energy to keep me productive. This is also not to say I absolutely can't work with wordy music in the background, but if I have it on in my headphones I find that the quality of my work dips and it takes me longer to complete if it's not a banging house set.

Would love to hear some thoughts on this... what do you listen to at work, if anything?

Also, here is my personal repository of work tunes for your enjoyment/productivity:

Matt's "Get Shit Done" playlist of sets

I also have a set of turntables and record my own sets sometimes, those are here:

Matt's Techno sets

RSA Security Conference 2018, the beginning of the end

RSA Security Conference is a circus.

Everyone I spoke with that went this year noticed a difference. All the companies are still swinging for the fences with extravagant booth designs, gimmicks and giveaways, but the attendees seemed more disillusioned this year than in previous years.

Security conferences are a funny thing... almost fickle really. Also a complete catch 22: they're good, until they become big.

This is sad to me. The whole goal of security conferences are to bring people together to learn and share ideas on security. The more people who get to share, the better right? Unfortunately this is not the case.

I have been going to RSA since 2007, so I've seen alot. I've seen the birth of the 2 floor booth, the rise and fall of the "booth babe", and the giveaways go from remote control cars to real cars. As things started to go to pot, the constant refrain was "yea, RSA is more of a marketing event, the real show you want to attend is BlackHat." Anyone who's been to BlackHat in the past few years knows that this is no longer the case either. I read that in 2001 (before my time) RSA boasted 250 vendors and 10,000 attendees, this year there were over 600 vendors and close to 42,000 attendees registered. What's interesting is the number of attendees was actually down from around 43,000 registered attendees in 2017...which I found interesting. These numbers are difficult to gauge regardless because of what a sprawl the show has become (is this people who actually walked the floor or just registered for the conference?) Half of the hotels in the city are rented out for customer meetings, venues in surrounding buildings are used, etc.


Contrary to popular belief, there is still solid content at both of these shows. I have friends who have presented at both RSA and BlackHat with relevant and innovative research with great reception. There are also still ways that both RSA and BlackHat recognize trail-blazing new vendors to help them get noticed. For example, my company was part of the "RSA Innovation Sandbox" and it drove all kinds of attention to our little booth, and I know BlackHat has similar methods of recognition.

So why is everybody so jaded?

These conferences are "pay to play" to the extreme. EVERYTHING costs money. Do you want a 10x10 or a 10x20? That costs money. Do you want internet? That costs money. Do you want CARPET at your booth or do you want your customers to walk on hard concrete? THAT costs money!

When all is said and done, to have even a SMALL presence at RSA you need to shell out at least $50k. That is ABSURD. If a company makes a $5k investment in a conference, folks are comfortable having casual conversations with potential clients and discussing their needs before mutually deciding it makes sense for another conversation. When it costs $50k you are scanning anything that moves and hoarding leads like a chipmunk getting ready for winter.

It's a shame really... because nobody wants that. Because of how ridiculously expensive it is to even be at the show,  companies need to do everything they possibly can to show a return on their investment, inadvertently turning these big shows into marketing conferences rather than security meetups.

The one saving grace (to RSA and BlackHat at least) is that all the vendors still go, which gives a great opportunity to reconnect with old friends, customers and colleagues. One such colleague, asked me why I don't blog anymore and hence... my first article in almost a year. So it's still good for that at least =]

Big Company vs. Startup

As many of you may know, I made the jump from Cisco to run Sales Engineering for a small startup in the valley. Even though my gig at Cisco was awesome, I am confident this was the right move for me. I know there are a lot of folks out there wondering whether or not they should take the plunge (because it is a huge risk), so I thought I would talk a little bit about my thought process in making this move. 

I have always been a risk-taker. I love fast cars, snowboarding, skating, cliff diving… you name it. My wife always tells me I’m missing that little voice in the back of my head that says ‘are you sure you can do this?” So I guess you could say my personality is slightly unhinged to being with… but that’s only part of the reason why I love startup life.

 I began my career as a sales engineer at a startup in 2007. I was employee number 25 in a company based in Boston with a satellite office in LA (I was in LA at the time). I was the 4th SE hire, which was impressive for a company of that size, but the way the model was built we had two SEs in Boston and two SEs in LA. 

I had no idea what I was doing, but I loved it. 

I was getting in early to prep and spending time with the engineers to learn the technology and the industry late night. The days were long, the office was a dump, my sales team was a shit-show, and my commute was horrific… but I didn’t care. I was learning new things at lightning speed, living in the awkward every day, learning the iron-clad fundamentals of what it takes to be successful, and attempting (and succeeding) at doing things I had no business doing. It was fun. 

I have often reflected on what I thought made this absurd lifestyle enjoyable for me. Why on earth would someone do that for a few days and then not run for the hills? For me, the reason is the challenge, the opportunity for rapid career growth, and the love of the unknown. My then CEO had this great saying that we were all just “bozos on a bus”, and I like that. 

I can actually sum up why I love startups in one quick back-and-forth in 2008 with one of my early mentors. We were out for a “career lunch” which you need in your 20s at a startup because you’ve been working insane hours and there’s no money yet for a raise and your manager needs to give you a pep talk and discuss the “long run”. Anyways, I was baffled about how she knew so much and always seemed to have a plan. So after a few beers I asked her, “You seem to know exactly what you’re doing… how do you know it’s the right decision? Have you done this before? When do you know what the next move is going to be?” 

Her answer would forever change my outlook on business and life. 

“Matt”, she said. “I just make it up as I go along. I never know what the next move is going to be, I make the most educated decision I can and if that doesn’t work, we say fuck it and try something else”. 

That’s why I love startups. Big companies can take chances as well, but if a decision is made to change something there are many layers of bureaucracy that your idea has to pass through before it can be implemented. What I love about startups is, if your idea is better than the idea currently in place, your idea becomes the company idea. The opportunity is always there to swing for the fences and make a huge impact in a very short amount of time (not to mention the upside potential, but more on later). 

That said, startups are not for everybody… and even with the ability of extreme influence and upside, not all startups are something you actually want to do. My first gig was pure luck. I interviewed on a whim, got the job, and it turned out to be one of the most rewarding decisions I’ve ever made. It started me on the path to where I am today. The thing is, if I hadn’t been willing to put in 12 hours a day for 3 or so years non-stop, it would have been a blown opportunity. 

That’s the other thing, in big companies everything is already established… tried and true. You can just leverage what others have done before you to make yourself successful. I think of it as hiking in the jungle. Big companies have already cut a trail for you that you can get to the top of the mountain. The path is well-formed with benches and supply stops, but it’s a roundabout way that’s going to take you a while to traverse. A startup has a general direction to the top of the mountain… maybe a few people have cut back some branches here and there… but it’s essentially bushwhacking. You have a map and a compass so you know where you need to go, and the way is potentially much shorter, but you have to figure it out (and you could be heading in the complete wrong direction). No supply stops, no rest areas, just a general idea and a goal. 

So why did I drop one of the cushiest jobs I’ve ever had to go bushwhacking again? Because I love the hunt. I love just "figuring it out." I love working with a bunch of intrepid explorers in uncharted territory, blazing a trail where there’s never been one. New technology, new market, new challenges... I love trying something new and failing because failure helps you grow. I love trying something and succeeding, I love helping other people succeed where they thought they couldn’t. I love the camaraderie, the “everybody does everything” mentality. I love the possibility of a MASSIVE payout if we pull it off. I love accountability and transparency. I love the trust that everyone in it is working just as hard as the next guy. 

So should you drop everything you’re doing and go join a startup? I don’t know… like I said earlier it’s not for everybody. There is also the very real possibility that the startup you join will crash and burn… most do. I must have turned away at least 60 or so companies before I finally made my choice… Cisco is a great company and I wasn’t going to leave for just any ol’ group of kids with a good idea. Going with a startup is losing your safety net… but with great risk comes great reward. At this point in my life my wife and I are in build mode so we’re swinging for the fences. It takes hard work, sacrifice, and “balls like church bells”. I’ve only been in it two weeks and I'm working as hard as I’ve ever worked my life… and I love it. So I guess you have to ask yourself “am I willing to work my ass off and take that risk?” For me, that wasn't even a question because that's what I do. 

The Case For Recycling Content

As we're rapidly approaching year-end, I thought it would be a good idea to broadcast a friendly reminder to back up your content... but not just your personal media, your professional content you've created.

Over the years I have generated tons of content in my professional life. Meeting outlines, hundreds of powerpoint presentations, notes, whitepapers, training guides... the list goes on. To be honest, a lot of the stuff is crap, but there are still a decent amount of gems in there. Gems that if I apply a few tweaks, could probably be used later on in different applications.

Recently,  I did a sales engineering training for a client who had just hired two badass SEs that came from the support and engineering world. These guys were sharp and hungry, but without a SE background. To me, this is the best situation I could ask for. Smart, driven students; no bad habits to break.

The obvious next question is, what stuff have I created that can be used? The actual SE profession applies across all lines of business, so IMO it doesn't really matter if you're selling software or snowblowers, the method is going to be similar. That being said, nothing I've created is an exact fit to any new application, so everything requires at least a bit of customization.

People have told me "you reuse your content? Isn't that short-changing your clients?" I believe the opposite is true, if I don't leverage at least the basics of the content I've created that has made my other clients successful, I would be shortchanging my new clients. The concept is called "reinventing the wheel."

You may think you've created something amazing, but you never really know until you can apply it somewhere else.

 One of the things I struggle with is: "Is this a one-off?" After much useless agonizing, the answer is almost always no. The first step is to break down your creation, what do you have? Even something as specific as a pitch has a cadence you created. Is there something effective about this particular cadence? What worked (or bombed) about this method? Even a good call can be repurposed. Break it down, what are the pieces of the call? Every conversation has a beginning, a middle, and an end... what was effective about that approach? Are there any elements in there that can be applied elsewhere? How can you create a template for that call?

More often I find that good training meetings can be reused elsewhere if I keep the topics more or less universally applicable. What are some of the overarching topics that exist across all lines of business or products? There are several that come to mind; competitive analysis, intro/intent, ecosystem/integration, presentation skills, overcoming objections... let's take "finding need" as an example. I wrote a piece about need and the importance of it a few months ago here. There isn't a product out there that people will buy if they don't have a need (or want) for it, so I figure it's pretty universal... all we have to do is template-ize the content.

After you've been doing this for awhile, you'll start to realize you've created a process, and then that process becomes part of your brand. My approach is as much a part of my professional identity as my skill set, and my approach is supported by content I've created. Seems worth it to me...