Jeff Szczepanski – The Developer’s Guide To Running Sales Teams

Jeff ‘Tall Jeff’ Szczepanski from Stack Exchange delivers a talk on his experiences of what happens when you think about and manage sales like you would manage a great development team.

 

Learn how great SaaS & software companies are run

We produce exceptional conferences & content that will help you build better products & companies.

Join our friendly list for event updates, ideas & inspiration.

Unsubscribe any time. We will never sell your email address. It is yours.

Jeff: As Mark said, I’m Jeff Szczepanski, or tall Jeff. Certainly on Stack Overflow, and certainly within the company, a lot of my friends seem to call me tall Jeff as well. I’m actually, as I said a developer by training, an electrical engineer. I used to do a lot of embedded systems work, embedded C++ programming, embedded operating systems, stuff like that. I actually have a higher rep on Stack Overflow, I think, than almost all the employees in our company, except for just a few that were purposefully hired off of page one on Stack Overflow into the company.

For those of you that may not know a whole lot about us, Stack Exchange is the name of the company; Stack Overflow is our best, well-known community, a question and answer site for programmers. We have now over a hundred different sites that operate in all kinds of different topics, anything from the technical topics that are sort of more core to our audience to more things like English language usage, things that are programmer-related again, TeX, LaTeX, Android enthusiasts, stuff that gets a little bit more on the consumer side, and that, actually, the other parts of the network are now at this point growing much, much faster than Stack Overflow. Stack Overflow, at twenty-five million users or so on the site every month, is kind of running out of programmers on the planet, so we’re starting now to go into other languages and picking up these little niches. But in any case, the company itself really operates as two sort of different halves. There’s the half that’s responsible for the free product and services of the Q and A site, and that entire half of the company is focused on that and doing that in a very pure, community driven manner. And there’s the other half of the company, sometimes people try to think of it as the Dark Side of the company, which is what I’m responsible for, which is actually the monetization of the network and figuring out how to turn Stack Exchange as a question and answer site that’s a free service into an actual product business.

You know, I normally don’t do the speaking stuff that often, so in fact I’m kind of wondering how I got up here in the first place. I actually do have a good sort of theory. I did start a blog recently, but I think it has nothing to do with that, and it’s talking about some of these topics that I’m going to get into in the slides here. But the best theory that I’ve come up with so far is that Mark, in thinking about the inaugural event for Business Software UK here, said, “Oh yeah, I need to get JS over at Stack Exchange to do a talk here, to draw the crowds.” Wendy thought that meant Jeff Szczepanski at Stack Exchange, but he really meant Joel Spolsky. [laughter] So, sorry for the error. [clapping] I’m the other JS at Stack Exchange, and [audience: the real JS], the real JS, okay, that’s right. We can’t get Joel to talk here anymore, right?

In any case, with that introduction, I’ll just do a little bit more background on just one part of what we do. There are a couple different businesses that we operate within Stack Exchange. The company’s actually getting pretty large at this point. The background for the majority of this presentation is actually around the Careers 2.0 business, which is how we monetize Stack Overflow, which is really developer hiring. Any company that employs developers, if you’re looking to hire developers, basically, we’re trying to make this the de facto place that you come with twenty-five million people using the site every month. So the size of this team – and this is a lot of the work in this presentation is based off of stuff we’ve developed over the last several years – seventy sales reps across nine teams now worldwide, in these three different offices. We have six different sales managers, two sales executives, and I’m not including myself in that count, that are responsible for the team. One of them is here today, somewhere, [name inaudible]. And a marketing team that makes up another six people worldwide. And this is all just within the careers business. Stack Exchange now is about a hundred and fifty people, hundred and sixty, going on.

So, enough on the background. What is the presentation really about? What do we mean by the developer’s guide? So, I’ve actually done a few start-ups myself, or at least built a couple different companies. So I get involved at some entrepreneur’s early stage, some of the different investors in different companies in the portfolio bring me in, to talk to different people or give advice in different places. And I actually started over the last couple years to notice a very common theme of a lot of the way companies get started, and this is evolving a little bit with a lot of the good shared information that comes out of conferences like this. But basically, the common start up plan for a lot of different companies is, great idea, and really, great idea in many cases, you see a lot of really good stuff out there. The technical co-founders get together, and at some level, they can actually really sell, and sell effectively. They go out and they raise money, and they start building a great product. But this sales thing is always kind of a second level thinking, that at some point, even if there is a co-founder they bring in and say, hey, we need somebody to do sales, let’s compliment the team with somebody that specializes in sales, there’s still this distinction as Mark was alluding to before, between building a great product and scaling a great sales operations team. And so, it’s kind of this idea that, hey, we need sales at some point in the evolution of their product, and then profit will result and everybody’s happy. The problem is, this is what I actually usually see happens somewhere along the way, which is that they go through the steps that I alluded to, the cash is in the bank, and you start iterating, hire a VP of sales or have the one you got, struggle for twelve to eighteen months, fire that people, fire those people, this is not working, get a new VP of sales, and keep doing this until the cash runs out. I keep my fingers crossed, usually, that we’re kind of earlier up in the flowchart here, when I see these different companies, and obviously you want to try to avoid this in your own company. So really this whole presentation is about making sure this doesn’t happen.

Now, the one thing here to think about, and this is where the state of the art I think is moving forward nicely, is that when we talk about minimal viable product concepts and product market fit, there’s all this great stuff going on around connecting your customer, your potential customer base, to your product and your product evolution. The downside to all of this is that it’s essentially starting to advocate a thinking which is like, what’s the best way to increase sales? Add more features! And I’m going to actually argument, not against adding more features, because it’s obviously important, but I think you’ve got to think of this as a completely separable set of problems that are trying to be solved simultaneously. And actually from a scientific standpoint, as you’re building a business, you want to actually think about how you can run these as multiple operating petri dishes in different areas of your company, all at once. And so, the rest of the presentation now is going to talk about – in fact, Joel, I think, Joel Spolsky wrote a post, either a blog post, I can’t remember now, or maybe it was an Ink Magazine article, about the fact that at Fog Creek with their Fog Bugs product, that the single best way that they ever increased sales in their product was to add more features to it. And, I think it’s an important idea, it’s an important concept, it’s not wrong, it’s just that it also says a lot about their sales team, right, that somehow the sales team couldn’t go out and sell more than people putting features in the product. So again, what I’m really going to talk about here, is there’s sort of a fallacy there, I think, that adding features to your product is more about expanding the opportunity of who you’re selling to, than it is about increasing the rate of penetration into a specific target audience that you’re already addressing. And so, what we’re really going to be talking about here in this presentation then, is all the things that’s not about adding the features, or at least how it interacts with features adding and how to think about the problem as separable, scientific pieces, if you will leading to this conclusion, then, that if you think about the great companies out there, Microsoft is one of the ones with a sales force that comes up a lot, Oracle, all the eight hundred pound gorillas in all the industries… Does anybody really think – Apple might be the only sort of exception there, but even that’s going away – but does anybody really think that they actually build the greatest products, right? They don’t, but these are obviously the greatest businesses, and if you really break them down and look at them about what they’re doing, they get phenomenally good at all the elements of sales execution, is what they really are doing, and their product is sort of, so so. It’s good enough, or there’s a network effect, or there’s some kind of thing that gives them a vested interest. But it’s really the multiplier in this that is the way, the only way you can build the great businesses.

I have a great personally story on this myself, actually, which is one of the companies, the company I was involved in, co-founder and CTO of before going to Stack Exchange, All Works, fantastic product. Everybody thinks their own product is great, right? My baby is always pretty, that kind of thing. No, but somebody else’s baby is always ugly. We built what I think was a great product in the industry, but it really comes down to me in the case of our exit, which was successful, but it was a twenty-five million dollar acquisition that was more of an acqui-hire and acquiring the technology of the business rather than actually operating, excuse me, acquiring the operating company itself, which we could have been a two hundred million dollar business or a billion dollar business when Google buys out at that stage rather than these earlier stage things. So again, this whole thing is just, I’m trying to really encourage you to kind of think about the business differently, and realize that even though we kind of think as developers and sales people in different things, the management team of the company has to think of this whole thing as one problem, that all of these things are equally important to each other. And I would kind of actually question the argument, speaking as a developer; the sales stuff is actually more important and actually more critical to your success. You can do a lot with selling the Cathy Sierra kind of stuff and getting users to make it more awesome, all really good stuff, but you will never be a five hundred million dollar company unless you figure out how to do what LinkedIn, Oracle, Microsoft, those kind of companies are all out there doing.

So, okay, so let’s start breaking this down into pieces and making what we’re doing here kind of a practical approach. I kind of like to think about businesses in three sort of stages of building out the sales organization. I’ll talk about these mostly as independent pieces, although I think they definitely overlap in time as I’m trying to show here in the diagram, but we’ll definitely treat it almost as like a phase gate kind of thinking of what you’re trying to accomplish from a [pause] a goals standpoint, and what’s the foundation you’re trying to build as you go through each one of these different phases.

[pause] So first, [pause] the essence of phase one. This is really what minimal value product stuff is basically about. But it’s really important from a sales perspective, because what you’re trying to do is proving that the market exists for your product and that people are actually going to pay money for it, with the goal then of having several paid customers who are getting value out of the product. Now this is again lifted directly from minimum viable product kind of stuff, but it has extremely important sales implications I think, if you really think about what’s actually going on here. And, where we’re going to kind of go with this, jumping ahead a little bit, is that this is not about professional sales tactics, in phase one yet. And it’s because of this. Your product actually really does suck at this level. Totally stinks. People don’t really want to buy it for its features, with maybe except one small nichey kind of thing around some kind of value that they get out of it. What it’s really about is that customers are buying into your vision more than they’re buying your product. And this is extremely important from a sales perspective, I think, because selling on features and benefits, and things that sales people are really good at, is not why people are actually buying your product. They’re trying to jump on the star of the same exact thing that the VCs heard when they think about this great market-shifting idea that’s out there. Again, it’s the essence of the early adopters and exactly the types of things that the founders are talking about. So what does that really mean? Have the founders selling. No sales people yet. You do not want professional sales people at this stage, you definitely don’t want professional sales management at this stage, I’ll argue. Doesn’t mean you shouldn’t be thinking about it, doesn’t mean you shouldn’t be learning about it, of course, but it’s just not what that type of people are actually good at. It’s all about the reproducible processes, and that’s what we’re going to get into at the later phases. But at this stage, basically, you want the founders out selling the visions of the company and in a sense, proving the whole market value fit to build this foundation that you then later can use for the professional sales people to start coming onto the scene. [pause]

So, what are the best practices here? We kind of mentioned these already. There’s the lean start up concepts. Getting the minimum viable product. The founder selling of the vision. This is really important. In a sense, what I think you want to think of this as doing, is having the founders going out and telling the stories around why the company was founded and why the product is going to be great, and then listening to what customers are saying back to them. And what you’re starting to do is create the foundations of the stories and the examples and scenarios that you’re going to start teaching to sales people once you start bringing them on-board. You’re essentially testing your price point, you’re testing the product market fit, and you’re trying to prove that there’s actually people willing to consume the product because from a scientific standpoint you want to know, when you start to bring sales people in, are the sales people not selling because they suck or are people not buying because your product sucks? And that’s the distinction you’re trying to create between these two different things, is that sort of petri dishes that are going along, that I’ll actually talk about in a few more minutes here.

[pause] So this kind of leads us into phase two, which I call understanding your pitch. I was starting to allude to this already, but as we look at thinking about starting understanding your pitch, this is before we’re going to do any scaling. Notice, I haven’t said anything about sales management or even sales people quite yet, until you have these sort of foundations in place, right? You want to see that you have a product that’s definitely proving useful in the marketplace. Some of the stickiness about it that we alluded to before is starting to go away, but the reality is that your product is still going to always suck and that’s an important element to think about even in phase two. I would think that the product development parallel to this is really kind of in the phase where you’re coming out of beta phases and you actually sort of have the 1.0 of the product. Certainly you have multiple paying customers that have paid real money for the product. Not giving away free things anymore certainly, if you did that even at the beginning, which I think you should avoid, and you also want to have this idea that you understand who your addressable market is based on who started consuming the product already, the list of your possible future customers. This is obviously going to be the prospecting list and techniques that you’re feeding to the sales people when you start to get them involved and on-board. And certainly it’s some sort of sense of your workable price point. The goal here, at the end of this phase two, is to have multiple sales reps selling your product successfully on their own. And I’m going to stress every element of those words in there, which is more than one of them, end to end on their own, in a sense without assistance. And this is the experiment built on the foundation of what we proved essentially in phase one, which is that we have something people want to buy and now we want to be able to figure out how to teach it to people that are not the founders, and are not pitching the vision, but they’re starting the transition from the phase of customers buying into the vision and customers actually starting to really buy the product or the solution that you’re selling.

Who are these people? This is kind of important and this will start alluding to some of the things that I think are a little bit different about how I’m sort of advocating to think about the process going forward, but I don’t want to jump ahead too far yet. But in these early phases, again we’re not talking about sales management here yet; this is just the first people after you have the sort of basic minimum viable product element in place for shipping beta and version 1.0 of the product. You’re looking for sales people out there who this is not their first sales job before. And the parallel to draw here from a software development perspective is the early developers that you’re hiring on your team, right? So if you want to kind of back up a little bit, and think about how you think about your technical team, when you start doing the foundation stuff, right, you don’t get a couple technical founders together and say, “Hey, let’s go out and hire a CTO and a VP of engineering to help us out with this, and start having them build the product for us.” Those are the companies that don’t get invested in, by the way. It’s usually the business, MBA type people who say they want to go do exactly that. Because there’s something very unique in that founding team, the vision, the insight, and the actually ability to go out and execute and build. And so you don’t start hiring really junior developers really for the most part at the beginning either. You might go and find a couple critical dev hires of some really experienced but open-minded people, and I think you guys will know from software development that actually too much experience in certain things, especially if they’re from the industry, actually kind of counts against them. And I’ll make the same exact argument for the sales people, right. So you want these kind of earlier in their career sales people who are smart and aggressive and they want to go make good money, they believe in your vision to some level, and they’re consciously competent about the process that they’re executing. So again, it’s not their first sales job. You don’t want to have the risk of them, like, never having coded before, and again I keep drawing the parallels there. If you think about the ideal role model of these early hires you want to do for your software developers, this is exactly who you want to hire for your early sales developers, if you will. And the reasons here, I got it on the slide already, but avoiding the experienced reps comes into these preconceived notions and sort of the prima donna effects. Again, we know these in the developer sense of those types of developers that are just extremely caustic to teams, and the sales parallels are directly there as well. And it was really quite a eureka moment for me, somewhere probably in the first six to eight months of the job at Stack Exchange, after starting to think about this in a more structured sense, the light bulb really went on as you start realizing people are people in a sense, the management techniques are very similar. And not only that, I’m going to make this argument a little bit more further into the presentation, is that I think sales is actually evolving in a way that’s converging towards the software development thinking, which is actually even more interesting. And in fact, some of the things that are being done in sales, or innovations in sales and companies recently, I think are broken actually in similar ways to how software development used to be broken and we’re starting to learn how to fix, which is exciting, at least to me, anyway.

So those are the sales reps. what goes wrong in phase two? This is the most classic one right here. “I can close customers myself without any problem, but the reps I’ve hired can’t close the deals on their own.” This repeats itself an amazing amount, to me. And, the founder inclination, much like the baby analogy, I think, that my baby is never ugly, my product is never ugly – my sales people suck, when they see this. What am I doing wrong? How am I hiring these people wrong? And the answer almost always is, the founders are doing something wrong when this is happening. What it’s essentially telling you, based on the way that we’ve built this theory so far, is that the founders are not figuring out how to convert what they know to be the vision and communicating to sales people in a way that can actually be articulated. In other words, by sales people who are not believing in the vision necessarily right from the very get-go. There’s actually a kind of a funny story that comes to mind around this, or at least it comes close to home. When we think about expanding the careers business, building out into some major customers, to get some major brands, I won’t mention names but any Fortune 500 type companies, but we’re having trouble getting them to adopt the Stack Overflow career service for whatever reason. And we’ve got some really good sales people cracking along, and I can’t figure it out. Sort of the last string we pull is to say, okay, it’s time to send in Spolsky, go do a talk to the developers out there and find out how to get a meeting with the HR people. And Joel goes off to these companies and does a visit and does a great talk and meets with the HR people, and he comes back time after time again, times that he’s done this, and he’s like, “I don’t understand why this account was hard to break into [laughter], I got in there, they wouldn’t let me leave the room without giving us money.” And the reason is, is like “Okay, Joel, wait a minute here, first of all we only send you in on the really hard ones, you’ve got to appreciate that first of all. In other words, there’s something interesting going on here that’s not so obvious. And then the next part of it is that, you have like 165 IQ, that’s a different part of it.” And even though he claims not to be a great sales person, he really is. But obviously what Joel’s going in and doing is he’s selling the vision of the company. He’s a walking personification of everything we sleep, eat, and breathe about every day, and so there’s just no better person to go out and pitch that vision in front of some board room or senior people in the company. The trick is figuring out how to get that from his mind and our minds that talk about it as the management team or the founders level, and the VP of engineering and CTO, and all these people that really know and understand the vision, is translating that and communicating it in a way that the customers at that scale understand, and also even more importantly initially, that the sales people that you’re hiring understand and can communicate it effectively.

Okay, so another common problem to run into in phase two, sort of a pop quiz kind of thing. And I maybe hinted at this a little earlier in the presentation, so I’ll give you that. But the pop quiz essentially is, when you want to try and understand how, if you’re in that loop that I talked about before and struggling to get sales traction of the company, do you go out and survey your customers that bought the product and understand what they want to like about it better, or do you go and talk to people who haven’t bought your product and figure out what you need to do to get them to buy more? Anybody want to take a guess at that? No? Okay, so, the answer is always, in my opinion, you need to talk to the people that are buying your product. It is absolutely wrong to talk to the people that are not buying your product. And the reason is, it gets back to this fallacy about product expansion. You’re expanding the market of who you’re attacking by talking to people that aren’t buying. In other words, the people that bought, there’s a self-selecting thing going on that’s actually extremely important which means they either bought into the vision or they bought into some features of the product that you already have. You don’t want to go wide, or at least, you can’t singularly go wide with your product before going deep into a particular segment. Nobody wants to get, you know it’s the fallacy of, “Hey, if we get one percent of the hundred billion dollar market, we’ll have a huge company.” No, nobody wants one percent of a hundred billion dollar market or a hundred million dollar market. You want ninety-eight percent of the million dollar market, and then you want to start adding more of those on. And so, when you’re building your sales teams out, when you think about your sales rep coming to you and saying this, “I can’t close it without features,” you’re sort of like, messing with the petri dishes, right? You’re putting stuff in there that’s messing with the stew of it, to keep going with the metaphors. And, you’re not really solving for what you want to solve for, which is getting them to be able to communicate more effectively to the target market. And so you just need to break that loop and think about the different best practices here with phase two, is what you’re trying to do. And that leads right into; your product will always suck. You can never use as an excuse, “I can’t sell this because of whatever.” It might be a hint that you hired some of the wrong sales people, if they’re really sort of giving up and saying no one’s buying it because it doesn’t have x, y, z that I heard on the phone yesterday. But really, I think for the most part, it just gets into this idea that you’re not keeping the two different independent arms separated in these experiments, and you need to keep focusing on those as separable problems in a unified, concerted manner. Helping with the petri dishes analogy, is the three sales reps as fast as possible, I think is extremely important in phase two, because you do want to know, for sure, that if two people are selling and one is not, or one person is selling and two not, getting those guys, people, on the team working together, talking with each other, sharing best practices, and potentially understanding if it was bad hiring decisions made in there. If you only have one data point, obviously, it’s hard to know what it means, and you really want to maintain that independence there. The reason that sales managers are not needed or important here is that you want a really tight feedback loop here in phase two, because you’re doing these experiments and you’ve got to be figuring out how to communicate the founding team’s thinking and the early vision kind of stuff into languages that customers and the sales reps understand. And the faster, the tighter those loops can be, the better. And this all applies directly to the sales development, lean startup and minimal viable product development kinds of things, and any of the agile processes. That’s what you’re really doing here, is trying to maintain that scientific integrity, if you will, of the whole process. Aggressive compensation plan, too, I think it’s really important not to skip over that one. There’s no reason not to be paying them as much as you can possibly afford in the early days. You want everyone to be making money, in a sense, and making sure that people are well-aligned and driving towards the same thing.

Okay, we ran through that pretty quick, actually. Phase three. This is where it gets really interesting [pause] and a lot harder, I think, in a lot of ways. And this is where, I think, some of the evolution of the way sales is evolving and what I alluded to earlier about the parallels to software development become really important.

Okay, so, the entry foundations here, for phase three. What does it really mean to start graduating into phase three? Well, obviously the goal from phase two was one of them. Multiple self-sufficient reps closing deals. Happy reps, basically, on the team, making good money. You don’t want to start hiring more people if they’re cranky, or not selling well, or can’t make a lot of money. These things that Tim talked about earlier in his conversation, people talking about your product. Things like these. These are all things that it’s not about you going out and saying we’re awesome or our product is awesome. Getting other people to say that you’re awesome is obviously a part of it. As a foundation, you’re starting to build essentially the marketing tools, if you will, into the sales process and the things are starting to become the more reproducible things here that you’re going to start leveraging into phase three here. Lots of paying customers, definitely repeat business. This can’t be just the betas and the alphas and things like that. You need to have whatever’s big in your market or measurable in your market. Is it tens of units or hundreds of units, that’s going to vary, or maybe even thousands of customers, depending on the scale of the business? The parallel here in software development, I think, is when you’re actually in a mode where you’re starting to have certainly multiple developers in a team, probably some sort of sub-teams and sub-systems, scaling it out, half-a-dozen, a dozen people. From a sales perspective side of things, you’re getting beyond the three to five. You’re basically starting to get overloaded, keeping up with this effective, budding sales team that you have. That’s really what you’re looking for there, from that perspective.

The phase three goal is jetting to your vacation home in Aspen, Colorado. It really is. I mean, this is getting back to the five hundred million dollar company, the billion dollar company, the really successful businesses. This is where you want phase three to end. So in a sense, it never ends, or at least you’re continually trying to grow the business further. The problem with this goal is that it’s not super actionable, right, so what are we really trying to do? What we’re trying to do at phase three is have predictable revenue that is scaling. And again, I want to stress every word in there, which is about this idea that you’re trying to build a reproducible process in a predictable manner. The parallel to software development here is good process stability relative to scheduling, right? So if you have a certain amount of features you want to do, you need to start coordinating this with marketing, have product launch windows, trade shows, things like that. Company’s not going to be super successful unless you get, in most cases, some level of predictability and robustness in the product relative to your software development practices, and that if you say you’re going to ship it in three months, it doesn’t take twelve, although that’s not uncommon for that to happen beyond people’s control. But it’s something I spent a huge percentage of my career figuring out how to avoid and always this sort of frustration that when you put people in charge of things and they can’t say you can give predictable outcomes, I don’t quite know what I’m actually paying you to do or what I’m getting paid to do if we’re not trying to stabilize things and make it into a predictable thing. In other words, the essence of engineering and innovation is actually moving those things forward and having understandable processes that are predictable. So clearly, for the sales side of things here, this is your core goal that you’re driving to. This is all about the precision and how you operate and things like that.

Concepts here. Here’s a really interesting book. I have nothing to do with the book, other than I’ve read it, a few times, actually. This is definitely a must-read book, when you think about the business and actually at any stage. There’s actually a funny parallel in the picture relative to the three phases I outlined, not exactly the same, although there might be a little bit of similarity, certainly in the C phase here where you’re starting to scale the organization. They talk about a really interesting thing here. Aaron Ross – just for a little bit more background, you may or may not be familiar with the book, Aaron Ross is the guy at Sales Force who basically was on their lead team doing email stuff. I forget the exact background of the whole story, but he could be credited with certainly the earlier if not later successes of SalesForce.com becoming a multi-billion dollar company. And this book is all about how to think about essentially building a sales machine. I think it’s a great book. I am strongly recommending reading it. I think there’s a lot of really interesting things in it. But it actually kind of takes things too far, or maybe not too far enough. I don’t know how to think about this part of it. I’m jumping ahead a little bit. I think there’s a lot broken in this book, and maybe I’ll just start off by teasing the idea of SalesForce.com. You know, they built a great business. How many people here are actually familiar with using or have in-house Sales Force for their CRMs? Right, most people? Everybody uses them? How many people in this room actually like doing business with this company? Exactly. Exactly Not a single hand. I love this. So, one of my future missions in life is to go destroy that company and build a much better product and solution. In other words, yeah. So anyway, predictable revenue. I’m jumping ahead by getting into it, but what’s really important is this whole idea, they talk about the scalability and how to think about it, and I really can’t do it justice quite here, it’s really kind of a different thing, but they’re talking about a really important element of the message which I’m kind of ignoring in my presentation here, just mostly in the interests of time, which is the whole lead gen marketing, what are you doing to supply your sales team with things that are going to keep them productive essentially going forward. Where the book goes too far, and again I’m jumping ahead a little bit, but they somehow think of this as a specialization and they have this pipeline that they’re putting everything through like a nice little manufacturing line, and it’s good in scientific and it feels great from an engineering perspective and you’re reading it and you’re like, oh wow, and then when you actually do business with Sales Force, you’re like, oh, this really sucks. Right? And it has to do with this idea that they’re actually putting you down a pipeline as a customer. And they’ve got people that are great at prospecting, and they’ve got people that are great at objection handling. And then insult to injury is once you build a relationship with somebody that actually helps you figure out how to solve your problem, they say, let me introduce you to Charlie, that you’ve never talked to before, and now that you’re actually a customer and spent money, and it gets into all the Cathy stuff about the context and the expectations being set, it just all goes out the window. It’s even worse, that salesperson, and I’m sorry for picking on them, especially if anyone here is from Sales Force. I would fire you guys tomorrow if I had a better solution. So, maybe that’ll inspire somebody. The thing with them is, yeah, they hand it off and then even once you’re a customer, they have people that are like renewal specialists separated from people that are actually the account rep that you’re talking to. And I have no idea even why they do that. Other than this whole idea about they’re trying to optimize something behind the scenes. And this is just where I think they go too far, or not far enough, in terms of their thinking around this. And actually what the rest of the presentation now is going to kind of do is to start focusing in on how you actually solve this problem, in a better way, I think. But again, I do not want to discredit this book to any significant extent, because I think it’s really important thinking. Maybe I’ll team up with Aaron or something and figure out a better way to put this together. Anyway, and this kind of leads into some more of the bad news around sales, and I think maybe this is part of the reason – maybe the book’s just dated, is another way of thinking about it, it was a good way of doing it but the state of the art in sales is just moving forward, or the nature of it is changing, and this has to do with the massive penetration of the internet into everything that we’re doing in life, and sales is no different. Sales is evolving from this thing, I think, which is sort of controlled dissemination of information to the way the company decides to do it and will let you become a customer, by letting you or manipulating you into becoming a customer into more like a sales process where you want people jumping in the boat and moving down the stream with your customers, educating them about solutions, being an expert or a conduit to adopting the products, not so much about manipulation. So the skill sets and the idea that sales people should be reading from scripts or going through process pipelines is wrong. And this is wrong in the exact same way that software development started, I think, which is, you had architects and you had coders, and there was the marketing people and the requirement analysis people, and it was all broken into these separate subdivisions. But what it turned into is the products started getting more complicated and nobody could manage any of it. The standard management techniques didn’t apply in this process. And so it really started forcing us as software developers, as that evolving complexity was going up, information was becoming freer and more readily available, it all just started to break down, and we started, over the last twenty years or so in software development, we kind of came up with some ways to think about this differently and solve the problems differently. And I actually credit Joel quite a bit in writing a lot about how Microsoft and different companies at that stage in software development started refining these ideas, moving forward, and turning it into other types of more end-to-end processes solved by the autonomous leaf-nodes, if you will. And it’s really alluding to where this presentation is kind of going, so if you look at this bad news stuff here, classic management methods are failing in sales, expertise doesn’t equal experience anymore. You can go hire a VP of sales that’s very experienced from Oracle, he’s not going to help my business at all. Or Career Builder, or Monster.com. We don’t hire anybody from Monster.com or Career Builder or any of these places, none of our sales people, I don’t think, maybe one or two, have even ever come out of the industry. And there are actually really specific reasons for that. Maybe it’s a self-selecting thing at some level. But the problem we’re trying to solve – if you’re innovating with your product, you don’t want to sell it the same as everybody else is selling it, right? And actually, I think Tim was alluding to that and some of the other presentations even talked about. Once it becomes everybody doing it, it’s no longer a productive thing. And that’s what I think is going to get Sales Force in the end, is that people are going to really start coming up with a better solution that is also being sold better and they’re going to lose rapidly once that actually happens. But the bad news is not necessarily bad news, as I’ve already sort of jumped ahead here, if you think of this as exactly the evolution that software development went through.

So what could this actually mean? And this is sort of a thought-provoking process I had several years ago, and then not so impractical. Instead of looking for VP of sales and specialists in sales in our company, what if we just hired another VP of engineering and had him attack the sales problem? Kind of a crazy idea at some level. But, as you probably already guessed, Joel Spolsky did this. This is how I got here, or at least, at Stack Exchange. And it does lead to some interesting things. The problem is, maybe you’ll be wondering, how does that really help? In other words, hiring a VP of engineering or CTO, as co-founders or people starting companies or businesses understand, not easy to find either, right, it’s just a rare bird. So maybe the first level that it helps at is that you can kind of double the talent pool, so there’s the prospective VP of sales that will kind of do this and think about it in the right kinds of ways or your sales manager. I think there’s the other pool out there of people that can say, hey, maybe we can go find a VP of engineering that’s just going to look at this as another data driven problem like any other software project he would have built. He’s going to go out and build a sales team, read Aaron’s book, and maybe read me and Dimitar’s blog, or something like that, that talks about some of these ideas and how you can draw parallels here. And those are definitely some of the reasons, but I think the more important reason that it actually really does help is that, I’m making a very strong argument here that everything you know about software development and sales management run in direct parallels and that the two things are actually converging together over time, because of the way sales is changing, because of what we already know about software development, different agile process, agile thinking.

Which means then, now if we think about this, instead of our presentation being called The Developer’s Guide to Sales Teams, I think we can kind of flip it around and say, how would a developer run a sales team, and that’s exactly what we’ve been essentially attempting to do at Careers in Stack Overflow now, for the last four years. Of course, to actually do this, we do need to talk about, and I alluded to this, the software development track record is not the greatest thing in the world, even today as things are evolving. But it is again really interesting to start drawing the parallels to what you may already know or have learned from hard knocks and, what was the presentation earlier about being rubbish continually? I would spend a lot of years as a rubbish CTO and VP of engineering before becoming not-so-rubbish. Same thing on the sales side and trying to re-apply some of these things in the thinking. So let’s just kind of break it down. What do we think about in terms of successful software development strategies?

The first one, smart and gets things done. This is actually a picture of Joel’s book. I don’t make money off of this either. But it is a really great book; it’s really fun to read. I’m guessing a lot of people are probably familiar with it. It’s adapted from Joel’s blog. But really the point of what’s getting here, is that when you think about good software developers, what makes a really good software developer is somebody that’s empowered and autonomous to do the task at hand. You’re not asking them to write certain lines of code in some one page of V-I to go do this, you’re looking for somebody that says hey, here’s sort of a business problem or at least some sort of subsystem that’s been defined and go off and do that. I’m going to argue the same thing for sales people, basically. There’s another key element in software development. If you really want to stabilize software development, you have to recognize that you can’t just look at the output. Oh, is the schedule ahead or behind? Did we make it? Did we not make it? Right? As engineering managers, as engineering team leads, CTOs, you’ve got to look at the entire problem. There’s not only the addressable market that you’re looking at, but there’s all these different sort of skills that each one of the developers or the team as a whole must be pretty sophisticated at to actually pull off a predictable software development schedule. There’s the requirements analysis, and requirements development, task estimation, project management, all the ongoing maintenance and deployment things, obviously the code construction itself and understanding the language, and all these things. And it’s kind of funny, when you usually stop as a developer, we kind of internalize all this stuff and we don’t really think about it broken down like this, but even a relatively junior developer already knows a whole bunch of things that are a bunch of different separable skills that are actually really important for them to be productive software developers. It’s kind of why they’re hard to find.

And so, sales, same exact thing. Paul Kenney – something he taught me actually here really well is that, when you think about sales, you just can’t look at obviously your sales team’s sales results and start saying, in a sense, everything is a closing problem, right? If you’re not generating enough revenue, in the end it all comes down to, we’re not selling enough. So what does that really mean in a useful kind of way? Well, in sales development, there’s exactly the same thing going on as you do in software development, which is there’s a whole bunch of different separable skills. And this is where the predictable revenue book goes too far. They’re going to argue that you need people to specialize in each one of these things and you’re basically going to build a pipeline that chains them all together and you’re going to expose your customer to that pipeline and that’s essentially what the book’s all about. I think it does a great job in the first step or two of this, and that’s the part of the book that’s really useful. Where it goes too far is to actually assume that that’s a business process. And what I actually think of it is it’s just a set of skills that you’re trying to instil in a team of people. And in the same way, you would not take your people that know how to debug, and people that know how to write code, and people that know how to run a compiler or make script, you’re not going to separate those into separate skills, certainly not to that degree. That’s essentially what a lot of companies are doing today with their sales teams, and I think it used to work, because if you thought of, read this script, do this thing, smart marketing and sales people at headquarters handing off canned demos and scripts and presentations, and people just went around and talked all of it off the script, it actually kind of worked, in the same way that it kind of worked in software development in the early days when you had relatively unsophisticated systems by today’s standards and you just said, this is what we needed to do, here’s the five different steps and break it down in sort of a waterfall kind of way. Those things collapse when it gets more of a dynamic problem. And this is where Agile and the more modern processes come into play, and this is the reason that I’m arguing that this is exactly what you want to be doing with your sales teams.

Another really important in here in terms of stabilizing the team – team morale and the cadence aspect. This is one of the things maybe about five or seven years ago, as I started getting more advanced in my years and career relative to running larger development teams, is really actually understanding that, in addition to all the skills pieces, that the morale aspect, which maybe is somewhat intuitive, but the cadence aspect and separating this out is actually the most important thing you can do to stabilize your software team. And this has a direct parallel in sales, which is your revenue forecasting ability in a sense, and driving to forecasts, and creating predictability on your sales teams through this notion that there’s this underlying thing always going on completely that’s separable from everything else. That’s what’s the pace that people are going and doing things at? How do you keep that consistent and smooth? And so if you start thinking about that as a separable steady output continuous process, you start getting insights into how that’s separating out from the rest of the skills, and then even the moral aspects that obviously contribute to that. So in this slide, I kind of lump them together into one thing. I think they’re two different things. On the moral side, this is where you can actually learn a lot from the sales teams and the motivations, and I think the techniques here are evolving a little bit, but if you’re going to read sales books or get experienced sales people on your team, understanding the psychology and the dynamics behind morale and, to some extent, cadence is actually the most valuable thing you can bring in. And in fact, on the software development side, I feel like I’ve learned a lot about even more insights into the software development side of things, just understanding exactly how the sales teams do exactly the same things.

Okay, Cadence. Basically the rate or the clip that the team is moving, right. So, what is it that, in the software developer sense, at what rate are your features coming out, right. It’s really bad, and you kind of get a sense why from a business perspective, if there are fits and starts, you predict when things are going to come out, right. You want the features across some sort of a road map, essentially coming out in a pretty consistent, timely manner going forward. On the sales team, the revenue is the obvious output, right; you want continuous acquisition of customers, and smooth growth relative to on-boarding people and keeping the thing going. And it’s the death marches things, too. I think that’s on the slide here, right. The death march kind of thing in software. You don’t want this huge push, because everybody has some massive trade show release, and then everybody stops for three months, right. It’s just really bad. It’s not efficient, in any way in there. And maybe in the end, now that you kind of think about it differently, because efficiency is ultimately what you’re looking for, isn’t that right. A continuous, steady process is way more efficient than one that moves in fits and starts. And so this idea of separating out cadence here is actually really important, I think.

So. Translating this all into sales, the sales rep role in phase three. The good news is this is exactly like the phase two rep, I think. You’re hiring for the same smart and gets things done mentality, but you can start to loosen up the constraints up a little bit. And this is again just like your dev teams, the experience and latitude that you have in your hiring as your team grows can expand because you have more infrastructure to support the more dynamic things. And so you can start to, I’m not saying hire some people that are not as smart later on in the cycle, but I think experience level is probably the biggest thing. Your ability to train them and take them from knowing less to knowing more, either about sales itself or certainly your product and the sophistication of selling, you can definitely move things forward in their career. This is also really good for the advancement side of things, make sure there’s career paths for these people, too, within the organization.

In the elements here, translating everything I was talking about in the software over to the sales rep side. It’s this idea that each one of our reps has end-to-end ownership of the business. They own the entire life cycle, from figuring out which accounts they want to call on, putting together their forecast. We have no scripts, no quotas. It’s all about shared best practices and the support of an infrastructure system that lets them each run their own essentially independent businesses. And I think there’s a direct parallel again to the coding side of things, which is that you want your coders enabled with the best tools. It’s all of the stuff that Joel’s written about in Smart and Gets Things Done, talks about in the book, which is, we don’t ever think twice about getting the right tools in front of these people on the development side. You’ve got to do the exact same thing on the sales side. There’s no second-class people here, there’s no difference in thinking, it’s all exactly the same mentality about enabling the leaf-nodes to be really productive and all the things, again, that Cathy was starting to talk about. You get these intrinsic motivations start coming out when you start taking the shackles off of people and letting them do great things. And in fact most of the stuff that we do in our business, that I think are some of the best ideas we’ve come up with, it wasn’t me or Joel or anybody else in the company coming up with these ideas, it’s some sales rep we hired that’s like two years out of school that’s been selling for a year. They have some really great insights and you’ve got to figure out how to funnel that stuff out, no different than some of the best coding ideas and new algorithms and stuff come from all the young whipper-snappers you’re hiring into the organization. And it’s this really bottom-up, organic way of thinking about it, that for some reason people haven’t really fully applied to sales yet, and I don’t quite understand why. And that’s really the argument that I’m making here.

The surrounding enablers for this, so what does that infrastructure mean for the team leads and the sales managers? First we’ll do the sales manager one. These are the people in the organization that are the line managers of the sales reps. they are the ones they essentially report to. The refinement here of what I think you would think of as the traditional sales manager in our process is that we’re separating that cadence piece out that we talked about and separating it out as a separable thing from the skills development. So the primary focus of the sales manager in our organizations is really the skills development piece of it, getting them to be good at every one of the stages in the pipeline and thinking about a longer, lower-pass filter on performance than “let’s get through this month,” or this week, or however you break it down, quarter maybe, depending on the business, with this longer-term horizon. And this role will specialize as you grow. There’s sort of operationally focused sales management, and the deal flow, and contracts, and the legal kind of stuff that you need to support the sales team. And then there’s the skills development. Sometimes people call these trainers. We’ve defined very specifically the sales management role. And again, the direct parallel to this is the engineering manager, at least what I think of as the engineering manager. The person that, they’re not in the day-to-day, they’re not the team dev lead that’s putting the subsystem out the door and making sure that that gets shipped and done right. It’s the person that’s looking at the longer-term resourcing issues, hiring people onto the team, expanding the team, more to the longer-term requirement definitions in the engineering sense, that kind of carries over to sales, into the sales manager role.

Team lead, which I already kind of alluded to here; again, this is all about the cadence and the morale of the team. They are the ones that are actually in charge of the Agile processes that I’ll talk about in a minute here. They’re kind of – just like your dev leads are, they’re the walking personification of every other person you want to hire after them. They’re the great anchors of your teams, the dev leads. They’re the ones going around teaching other people good coding practices, making sure there’s compliance to coding standards, things like that. Whatever they are these different social pressures and dynamics that are on the team, the people that are already doing that the day that you hired them keep your eye on them, those are the ones, and those are the reps that are going to become your team leads. This is a difficult role to hire from the outside. I think you kind of have to grow them internally, not unlike dev leads in most cases, in most companies, if you want to do it successfully. So all the parallels are there. And it’s really this idea that they’re both the player and the coach to the team, but they have no management responsibility for any of the logistical stuff. They’re still mostly about closing their accounts and being that ideal rep, but they have the important role of running a few of the key processes sort of in the background, day-to-day and week-to-week.

Just to expound on the separation here, to kind of drive in this, and maybe it goes back to the question before, what I meant about cadence, the team leads, in charge of cadence and morale, are the track racing pit crew, making sure the cars are going around the tracks at a consistent speed, as fast as possible on a consistent basis, and that’s both the reward, the motivation, and sort of the spot-treatments, like hey, we need to change the tires, but we’re going to keep the car moving, kind of thing, where the sales management is the garage mechanics, engine tune-ups, suspension overhauls, really the longer-term effects of maintaining it on a month-to-month or beyond an individual race, where the race being, in the case of sales, basically whatever your forecasting cycle is and how that’s broken down. The laps are your sprints, and the race as a whole is sort of your forecasting cycle.

Tools and process. How do we pull all of this together? I’ve already touched on a lot of this in really quick ways. This is really about running your sales team in a very Agile-driven kind of way, and this actually becomes very literally. We actually use a SCRUM sprint based process for driving the sales team. Each one of these teams, the nine teams that we have now worldwide, each one of them has a team lead. They run a joint retrospective and standup meeting every week for us. We have a monthly forecasting cycle, and we run one-week sprints, so any monthly forecast is broken down into a weekly cycle that people are pacing off of. And one of the key elements of the team – and we talk about this on the blog actually quite a bit, we could do a whole other presentation on how we’re applying SCRUM, the blog talks about it, we’ve got a couple different posts that break all this down, on the DevelopingSales.com blog – but, one of the key elements you’re really looking for is the same thing you’re really looking for in your software development teams, which is, what keeps the sales side of things from being dog-eat-dog and competition between the sales people competing and fighting over accounts and things like that? On the software teams, you don’t quite run into that – “hey, that’s the feature I really wanted.” The natural competition isn’t quite there, maybe because of the compensation systems and the motivations there, which is a whole other thing to talk about, but the bottom line is that the SCRUM setup and the week-to-week retrospective and standups is where all the best practices get shared, helping people diagnose each other’s accounts or what things they’re stuck on, and really the team collaboration aspect to drive you to a common, rolled-up forecast amongst everybody on the team, is really where all the collaboration and teamwork element comes in, and it’s really how you combat the sort of dog-eat-dog nature that tends to creep into sales a little bit. And it’s obviously also a lot about the people that you hire, again, no different than dev teams.

Here’s just a picture of, that’s New York office. We actually have all the deals on little Post It note cards still, in a very manual, SCRUM-based way, SCRUM board. Let’s see what else we’ve got here. [Audience member speaks, laughter] That’s a good question, actually. Let me see there. That’s actually the shower in the New York office right there, so somebody must have been running and they’re in the shower right now. In any case, that’s the SCRUM board right there. All these different deals, if you look just at the rows really quick, might be better to see on this one, oh yeah I’ve got it labelled, each one of the different rows in a colour is actually individual reps in their pipeline, and the SCRUM stages hopefully you’ll be familiar with to some extent, the backlog, to do, in progress, and completed, are the different areas for the deals. The backlog is like wish list customers that you want to have, the to do’s are stuff that’s actually being worked on and sold right now in terms of being pitched in its various phases. And we don’t put every deal on this; these are typically the larger, more noteworthy deals that we’re kind of talking about on an ongoing basis. There’s the in progress stuff, which basically means we think it’s going to close or there’s some sort of verbal commit. And there’s the completed deals that we want to do the retrospective on and talk about something good or bad that happened in a particular thing. And so this whole thing is being driven by the team leads, all the sales reps participate in there. There’s a lot of nuance and detail that goes into this. I’m not actually the expert. Dimitar, who is here – maybe you want to flag him down if you can find him – can really talk to this a lot, about exactly how we do all this here.

And again, it’s on the blog. We actually use a burn-down. This is one of those things that actually quite literally works out better [pause] and it’s sort of easier to do in revenue development or sales development than it is in software development, just because it’s inherently a more measurable thing. It has its downsides, getting back to results versus performance, but if you keep the performance stuff separable, and think about results at least in terms of these burn-downs here, we have a real-time, live information system that tracks every single rep, team, office worldwide, whatever you want to do, in any given month right up to the moment of any deal that’s closed, so people can see how they’re burning down on their revenue. This obviously drives one hundred percent towards cadence. This is the team leads’ primary tool for maintaining cadence. Again, it would be similar to the way you’re doing burn-downs for software development. I think it’s just actually easy. We talk about even where they’re pacing, where they’re going to be predicted at the end. This is the 2D view that really gives you a sense of obviously if these aren’t running parallel to each other in some way, shape, or nature, or at least converging at some level, or correcting in-bound, the team lead’s going to be all over it. Hopefully the sales rep or reps that are responsible for that deviating are going to be all over it. And this is really the thing in terms of real-time information that’s the primary driver of day-to-day activity from a cadence perspective.

Here’s sort of the two-dimensional view, so any one of these burn-downs – this being one, we’ll call it the team one for now – shows up here in a two-dimensional form. Each one of these can be clicked on to get the actual 2D burn-down. But in the 1D form, each one of the bars here shows essentially progress to goal, so we can very easily see. These are on wall boards all over the world, plastered in each one of the offices, everybody has it on their browser available, I have one live outside my office which has two effects, one is that I see it, the other, people see that I see it, which is good. It can have its downsides. You don’t want it to be too dog-eat-dog, but this is where the cadence in the performance and the role of what the sales manager is doing on a longer-term basis complements what the team leads are doing on a day-to-day basis to really drive more consistent results. So just to decode this a little bit for you, just to kind of get an idea what’s going on, the red is, when this was taken as a snapshot, in this picture I guess June 15 – could it be that new? Yeah I guess it is, two minutes ago on June 15. These are live updated. The red bar basically is where they were during the month, so about halfway through the month against a hundred percent goal. The solid bars indicate that this particular team is at sixty-nine percent of goal, even though they only needed to be a forty-eight or fifty percent of goal, so they’re pacing ahead. The shadow line shows actually the revenue pipeline forecast for where they’re going to be at the end of the month, irrespective of where they currently are. So the blues are good, that means they’re essentially ahead. The reds mean they’re tracking behind. The shadow colours will tell you where we really think you’re going to end up based on what we know about it now.  It is only ever as good as the information that goes into it, and this gets into a whole other thing about psychology of CRMs and bad stuff that happens there, but it is a really effective tool that we use to manage the team, again on a day-to-day basis, at the sales management, team lead level, and an individual rep level, even. You know, reps don’t want to, teams don’t want to be in red, and offices don’t want to be in red. It all plays together nicely. There’s a whole bunch of other stuff we built on top of Sales Force basically as a real-time system. But we’ll be writing posts about more of this and probably open-source the whole thing at some point maybe, just to, “f— you, Sales Force” [laughter] and so, this is what you should be doing if you’re out innovating. In any case, this is the system we have for that. [Laughter] Back just before, because we’re running out of time here, the whole goal here is the idea of predictable revenue that’s scaling. All of these systems coming together, in the same way that you think about software development and how you’re stabilizing that process, using that as a system to converge your sales teams on a predictable goal with a fixed set of trainable skills that are well-understood relative to your market, relative to your products, relative to sales processes, all converging together to a very predictable outcome.

Just a little bit of family pictures kind of things. I needed to obfuscate this for a couple different reasons, but we actually do a forecasting cycle that looks out at least a quarter in advance. We’re more actually planning the six- to twelve-month horizons on revenue prediction and forecasting based on our hiring plan, and so we have this model of activities that people are putting into the pipeline, what a reproducible rep looks like at a steady state in their ramp-up history. This goes into a big Python script, most of which I’ve written, to model what we’re doing as we hire people onto the team. What this graph is showing here is, looking – it’s not always consistent, we run it at different times, a little bit batchy, just based on when I have time or travel schedule or whatever – but typically, it’s looking, these are predicted numbers that are between three to six months in advance of when the revenue is actually going to occur. This shows the accuracy of the prediction of the revenue in that three- to six-month window relative to the actual numbers. So what you see on the graph here is that we’re predicting revenue typically within five percent, three to six months in advance, usually guessing revenue in the simulations better than the sales teams’ forecasts on any given month. In other words, if you took the team’s actual forecast for one month, the simulation from a month, two, three, four months ago is actually better than that roll-up number, and we tend not to share that for a lot of good reasons. [Laughter] You don’t want these self-fulfilling prophecy kind of things going on. But in any case, within five, ten percent would be kind of a bad guess in any given month, six months ago, so very happy with that line and how that continues to progress. This is going all the way back to the beginning of last year, and just to show we’re not really sandbagging or anything, this is not like a stable revenue base in the sense of flat, steady revenue, this is built on a picture that looks like this. I actually cut this off at the beginning of this year, just to further obfuscate data, I guess. But in any case, very happy with the growth. If you can just imagine predicting this line, I guess I should have plotted it, within five percent, typically three to six months in advance, that’s what we’ve been able to do so far over the last four years of refining this on Stack Overflow Careers team.

So, best practices. First phase with professional sales managers is in this phase three. This is really, again, the first time where you’re converting from the beginning stage where it’s all about the vision and the vision-selling into, these are actually reproducible sales skills and you want people with sales skills coming onto your team and who can teach sales skills coming onto the team. This idea that you’re separating performance from results, and that each one of the reps is this autonomous, independent business that’s running that you’re developing these reproducible skills in or hiring it onto the team. The real-time information is super critical, this idea of separating out the cadence of the team from the skills development and the results from the performance. And then, in the end, it’s autonomy and empowerment is the name of the game. Two other quick things I threw in there, I guess I already alluded to this, CRM systems suck. You’ve heard that from me three times. I really do think there’s a lot of innovation that can happen investigating the psychology or maybe the anthropology behind how sales people actually work. None of these tools are really doing that, in my opinion. They’re basically just glorified contact managers and calendaring applications. They really know nothing about what sales people really do or how they should be thinking about their problem. Maybe there’s a good overlap in the software development tools, now that I think about it. I think I’ll go look at that a little bit. The other thing is, and this is one that I learned relatively quickly from some really good advice from some other very experienced people, which is the way to think about your compensation systems. This is one of the other pitfalls, I guess. Running out of time here. I would love to cover more in the phase three, but it’s using the compensation system to try to manage people’s behavior. That’s an absolute mistake. It’s no different than trying to “incent” your software developers with bonuses and things like that – hopefully you’re not doing that – in terms of how you get the consistency and cadence out of the team. And I’m really intrigued by the sort of flat compensation or no commission based things in sales. We haven’t gone so far as to do that. We do have a traditional commission-based system of some sense, but it’s extremely simple and it’s never being used as a management tool. It just needs to get out of the way, so that when people are doing the right things, they’re not paid unfairly, essentially.

Okay. Thank you! [applause]

Mark: I hope you enjoyed that. We certainly did. For more talks from Business Software Conference and other BLN events, visit TheBLN.com or come to our next event. You’ll love it as much as we do.