First On: Technical Sales with Fred Pullin

If sales is an art, technical sales is alchemy. Technical buyers don’t buy software, they adopt first and then convert to a customer. Executing this conversion is an incredibly difficult task but assembling a team to do it reliably can seem impossible. But Fred Pullin, Director of Sales for Garden (a Fly portfolio company) has done just that. Fred has built a sales motion that identifies and empowers developers with equal parts process, tactics and a little magic. I first met Fred to get his thoughts on an investment I was looking at but I immediately realized that his mastery and ability to explain technical sales would make for a fantastic interview. I was not wrong.

To start out with just you telling us a bit about yourself and the career journey you've taken.

In university I studied psychology and political science and wanted to work for the Canadian Foreign Affairs Department or maybe in an NGO. When the recession happened in 2009, there were literally no jobs that I could take within foreign affairs so I ended up in a Boiler Room job in 2009. Everyone had to wear a suit and tie at the office despite not meeting a single human. It was just, “Here's a piece of paper. Here's a phone. Start dialing!”  It was brutal and it taught me exactly what not to do, both in terms of sales and customer management.

I started meeting up with a lot of tech founders in Montreal and realized there's an alternative world where people are actually building cool businesses. I never was interested in business before, but I started realizing that I could build something from scratch and there's a method to it. The process of it all inspired me.

I worked at a few startups in sales roles within Montreal and eventually moved to Berlin. The city gave me the same feeling as the first time I went to New York City. It was all very loose and experimental with individual founders trying things out. I saw much less of an institutionalized method of company building so there was an opportunity for me to come in and apply actual sales skills.

I then joined Contentful when it was only 20 or so people. We ended up growing quite a lot and now it's a big unicorn and a serious business. From there Garden seemed like a very natural progression. Both had very technical founders working on an open source product, which is sold to engineers and DevOps. It was almost the most natural progression I could have thought of after Contentful.

For those that are unfamiliar, could you provide a quick summary of what Garden is and your role within it.

I’m the Director of Sales, which just means I'm responsible for new recurring revenue and building a team that grows recurring revenue.

Garden is essentially a developer experience tool. We provide a layer of abstraction on top of Kubernetes so that developers can start developing quickly. There's a tremendous amount of time that is being wasted when setting up tooling for developers. In the old world, people had servers in their own office and if they needed a bigger server it would cost you a lot. Then you had cloud providers that sold cloud computing or really virtual machines. As the world moved to containers on the cloud it became much more convenient to run applications but setting up your own containers is a huge time drain. You don't want your application developers to become YAML jockeys. You want them to just do their work.

Our CEO, Jon, realized that if you could map out the different requirements between services, then you can start doing your tests much quicker and the odds of it passing through CI are much, much higher. It would allow founders to empower their teams to immediately test code and onboard new employees much faster. Garden takes away the whole set up of infrastructure so that people can start working right away. In essence, Garden is focused on developer productivity through a better developer experience.

How would you describe the go-to-market strategy at Garden that you’ve built within your team?

We’ve always had a strong online community. Early on we noticed a lot of traffic from people with the problem that we're trying to resolve. Maybe a month before I joined, the team released a set of features which is what you might expect in enterprise software - SSO, admin rights, etc. In the enterprise world people pay for governance. They pay to make sure that only the right people have access to the right thing. 

Then comes pricing that makes sense for people. This can get really complicated with a lot of questions. Are you paying for just a user? Are you paying for an application? Are you paying for an enterprise license? Are you paying for SLAs? You want to make sure that you can provide a lot of value for your customers as well as capture some of that value for yourself. If a customer only has 10 users using your product but they keep applying it in different applications they're probably getting tremendous value.

The second step is building a sales motion. Ours is very discovery heavy. We jump on brainstorming sessions together with our prospects and ask a lot of questions. “How are you currently doing your onboarding today? How are you doing your builds in your tests today? How are you currently deploying to production?”

Modern sales isn't just, “Here's the demo. Do you see value? Give me money!” It's much more about understanding a prospect’s actual challenge. It really strikes a chord with people when they realize that their vendors understand them. For us we like to deeply understand how they make their own software.

You're describing a very consultative approach, which seems very human oriented. How have you built your team in terms of structure, role, metrics, etc.?

I remember at Contentful one of our security guys asked me, “why do we even need salespeople? What's the point?” Actually, why aren’t all products just a credit card swipe? I think that's good up until maybe $500 to $2,000 a month. Then maybe you don’t need Sales. Up to $4,000 you need a couple of Zoom calls. Anything over $10,000 requires consultative sales. And anything over $50,000 a month you're going to need a handshake and the customer to look you in in the eye.

I wanted to do everything myself first to really understand a sales motion before I filled it with people. The first role that to me seemed pretty clear was an SDR (Sales Development Representative) position. That person is mostly doing cold outreach. I used a bunch of hacky tools on LinkedIn to see if our message was resonating. Surprisingly a lot of people had heard about us and were thinking about the problem. They actually did want to speak to us but at the time we only gave them a bunch of auto-generated messages.

I needed someone who had done outreach at scale before. I really wanted to find a person at that SDR stage but about to become an AE (Account Executive). Once you promore that person you immediately need to find another SDR to fill the gap. You can't hire an AE if you don't have a proportional amount of qualified opportunities. I don't think that an AE should ever have more than 15 to 20 qualified opportunities at any given point. More than that is too many to manage but you do want to make sure that you have roughly that amount to start with. So I always hire an SDR first, then an AE. This SDR / AE rinse and repeat can work for a while.

Actually there are a couple other aspects that are really important. A Sales leader really needs to make sure their people get the right education on the tooling used. I've heard so many VPs of Sales say that their first batch of hires work out great but their second batch bombs. Why is that? Because the first batch is always in direct contact with the CEO or founders. It's really hard to replicate that at scale so you need to have an initial education system right from the beginning.

You also need to have a proven framework from the first to the final steps. Your stages need to have clear rules for what is allowed you to enter and exit a stage. You need to know the questions that must be asked and when. It was important for me to really create a process that avoids the entire company relying on two or three to hit quota. You really want a process where most of your AEs are hitting their target 80% of the time.

Have you found any hacks to make sure that you’re actually the right person for that SDR role? How do you find that candidate and what makes a great fit? 

One thing I really like is ensuring you have a scoring sheet when you're interviewing people. You're going to write that you like a person or why you didn’t, but you also need to actually score them. There are lots of things you can quantify, such as how did the person break the ice? Is this someone that you'd spend four hours sitting next to in an airport? Is this someone that is very coachable? Is this someone that researched what you do? Can this person write well?

Your initial hires are so make or break that if you make the wrong move initially, it can really have an impact on your company for months or even years. I make sure that a candidate meets the founders and that everyone on the team gets to score them as well too. Everyone should have a really good feel about that person. Cultural fit is maybe the most important aspect because culture eats strategy for breakfast any day of the week.

For Garden specifically I think that because we're selling to engineers and because we have a very technical product, an SDR has to be super eager to want to learn something that they don't understand and they have to be very comfortable with ambiguity. They’ll need to build their own processes and you need to give them a lot of trust early on. Then as you grow and bring on new people you want to get more experienced people generally. Every person that you add to your team needs to make a significant improvement and level up of your team. Every next person has to be almost better than the last person that came in.

Developer tools as a category has really exploded in Europe over the past few years and there are more options than ever. I have to imagine that that creates a lot of pressure on buyers as they now have to evaluate so much. How do you break through the noise and overcome buyer fatigue?

I think technical buyers don't necessarily buy software. They adopt software first and then they convert into a paying customer. If they come our way and they're already using our open source software it's going to be quite easy for them to be able to turn into customers.

The only reason people pay for anything today is because of speed and convenience and that's the only reason we exist. I think that the interaction a buyer has with salespeople should also be speedy. If someone's trying to haggle you or they're stalling a deal or they're slowing you down, people are gonna sense it and they're not going to like it. Also an experienced buyer just won’t put up with shit any more. I view sales as much more of a project management job - sit down and figure out what the actual challenges are.

One thing that we do, which is unusual but quite effective, on each discovery call we say why we appreciate our own colleagues. This is something Dmytri from Delivery put in place, we do a round of introductions and we say why we appreciate our colleague. “Hey, I like Dmytri because he's clever and he's set up great processes.” Then he might say, “I like our Customer Success Manager, Charlie, because he's always on top of it.” And then Charlie's gonna say something nice about me. Then we ask the prospect we're working with to do the same. This puts us all at the same level and it shows us who we are. Once we do that we can ask them about their stack and they feel completely comfortable opening up to us. I know it's not a conventional way of approaching sales, but it really allows us to be totally open and transparent. People can look us in the eye and know what we're about. 

With this highly collaborative, highly conversational style do you get a sense for when you have a good client vs. a bad client? At the early stages founders and early sales teams are just trying to get as much engagement as possible. They're not asking themselves if a given account is going to actually build them to that next stage or is it going to be a drag and splinter priorities. I’d love your perspective on this.

You have to be totally open with your customers and really give your time to them. If you do spend a lot of time with people and you realize, say, their cloud adoption strategy is very outdated, they're not going to be a good customer to work with. Someone might come in asking, “can you just help us adopt Kubernetes? We don't want to have to think about it.” Those are accounts that don’t realize what’s required to build out their infrastructure. Also, if you can tell that a team is going to be very difficult and create a disproportionate strain on your support then you can't accept them.

You can't have more than a certain amount of actual enterprise accounts very early on. It's much more sustainable to build for SMBs and early enterprises than for strategic accounts right from the beginning because they can end up overtaking your roadmap. We like working with like minded startups that are, maybe 300 or less engineering teams [headcount]. Of course, we do have some strategic accounts that we work with. We're lucky to have some Fortune 500 and customers, but the thing is we're actually working with just a team within a much larger company. We're not fooling ourselves and thinking that we're going to force a Fortune 500 to adopt Garden across every single team. 

We do need to pick our customers as much as they get to pick us and that's why this process of doing a discovery process is so important. It’s hard to turn down a quarter million dollars but if you fall for that too early, you might be be stuck slowing down your product delivery. 

A lot of companies experiment with lead gen and may find themselves with lots of different prospects from lots of different sources. This can have a really big impact on both the sales process and how you build a team to support that demand. What have you learned about how you treat the different types of accounts in your funnel depending on their source?

To expect that every single customer of yours will go through the same steps is shooting yourself in the foot. Especially if you provide tooling. Larger companies typically have more money than time. They can spend but they very much care about understanding how you solve their problem. In the old world of sales, it was always about, you know, creating fear, uncertainty and doubt and they're gonna buy eventually. That's complete madness. It totally doesn't work in the 2020s. So I think that people just care about making sure that you understand what their challenges are. We always start with a discovery process first for large accounts.

Startups have to be lean and mean and move fast so they don't have time to spend an hour and a half on a discovery call. They want to get to product right away and see a demo first. Obviously no one wants to take a step in the wrong direction so we make sure to do a discovery process after the demo. You always want to show different bits of value depending on where the companies are coming from.

One thing you need to know is who you don't want to speak to from the beginning. Someone who's not a good customer is someone who has not even adopted Kubernetes or serverless. Or, you know, a kind of containerization technology from the beginning of our relationship. If you're really, really small and not there yet, we're not going to work out. If you're a big company and thinking about moving to Kubernetes we probably can help you.

My last question comes up all the time. When is the right time to hire us like a proper sales leader and what should a founder look for? 

This of course depends on the level of complexity of the challenge that’s being solved. But as a rule of thumb, I would say anywhere between three quarters of a million [in annual revenue] is a good time. In Europe we're always looking three months ahead to hire people so you should already have someone in the pipeline to hire as soon as you hit one million or so. 

If you get someone that comes in as a Head of Sales you want to make sure that person is able to sell end-to-end by themselves right from the beginning. If it's more of a dashboard-based and accustomed sales leader then perhaps wait until you have at least three three people in sales. 

The initial person that comes in has to just really focus on culture because that's your foundation. If people don't like showing up to work in the beginning you're never going to hit your targets and your team will never grow to something more. And you want them to create a very clear path of growth for those early people on your team as well. I would say avoid if you want to get someone into real leadership avoid the “Head of” title as much as possible. That's sort of ambiguous and that Head of person can feel like they have a target on their back and they're just going to get replaced.

I would say the more important thing there is if that person has sold deal sizes close to what you're selling or what you want to sell. Has that person worked with similar technology is what you're working with? I've never sold to DevOps but I certainly sold to CTOs, VPs of Engineering, people that are responsible for the entire technology stack. That was an easy transition for me. If you're used to selling automobile parts and you're suddenly selling to a very technical audience, I don't care how many years of experience you have in sales, it's just not going to going to be a match.