Ep. #26, Community Creation with Alex Miller

Grant Miller: All right, Alex. Thanks for joining us.

Alex Miller: Absolutely. Thanks for having me.

Grant: Cool. Just to get it kicked off, I think I'd love to have you just give a quick overview of your background and maybe a little bit about how you got into enterprise software.

Alex: Sure. My current role is the general manager of teams and enterprise at Stack Overflow, which is basically all of our Q&A that we help teams and enterprises do.

So, sharing knowledge privately. I've been at Stack for about seven and a half years now, and this is my third job there.

Originally I was hired as chief of staff to our CEO, which is one of the best jobs I can say you'll ever get.

Chief of staff is just random special projects and traveling around the world with someone, it's a really great role.

After that, what it turned out is I was doing all of these operational projects mainly as those special projects, so I took over as we were really scaling the company from 50 to 300 people, building out offices, putting legal stuff into place.

HR, IT, and I think most importantly company culture, as you're growing through something like that.

Getting your culture right from the beginning, or at least trying really hard and trying to do all those right things, you'll never get everything just right from day one.

It really pays dividends when you're trying to go through those hyper growth phases and double the number of people you have every year.

Before that I was in another startup here in New York, and before that I was an event producer in California producing things like TechCrunch 50, This Week In Startups, other podcasts that are very good.

Before that I was actually in PR and a concert and event producer. Everything from little string quartets to U2 at the Rose Bowl.

I've always had a very operational special project type background things, and that just over time and an interest in computers and technology just led me into the tech space and software.

Grant: Perfect. That's great. So I'm guessing that the evolution or introduction of Stack Overflow Enterprise is actually your entrance into the enterprise software ecosystem as well, is that right?

Alex: Yeah. That was really -- Especially if we're talking about enterprise, is thousands and thousands of people and huge deals.

Stack Overflow Enterprise was really the first time that I was hands on pushing into that space.

Grant: Great. So let's just give a quick overview what Stack Overflow Enterprise is, and then we'll dive into a little bit of how it came about.

Alex: As a lot of people know, Stack Overflow is the world's largest community of software developers.

We have more than 50 million people a month that are on StackOverflow.com, asking each other questions and getting answers.

Most importantly, as we like to say, they're learning and they're sharing their knowledge and they're building their careers.

One of the things we realized about three years ago when we were starting with this is that, "Our mission is to help software developers learn and share their knowledge, but we only have a way for them to do that with knowledge they can share publicly. Given how much of the information in this world is now embedded in software and how much software drives all our lives, that software is not built by one person sitting alone in their house."

Honestly that's never really been true, but I think as time has gone on and with the advent of more and more, APIs and SDKs and things, even if you think there's more you can do individually you're still fundamentally actually dependent on more people.

You need better tools for collaborating, so we've been the number one forum - type software and knowledge exchange for so many different types of technologies.

Whether that's Android and iOS or C Sharper, I kid you not, we still get dozens of Fortran questions a month because someone has to maintain those systems.

It was still always about information that could be public, and because so many of us work in teams there's so much that we can't do and be public with.

What do you do if you have a question about your build system? What do you do if you have a question about who to talk to inside your company, or what your policies are?

We just realized, "If we're going to help developers really be their best, we need to do something to fulfill our mission there."

So we decided, "Great. Let's go start with the enterprise, let's basically just go take a private version of the Stack Overflow software and spin it up inside some enterprises, and figure out how you actually really help these companies build a community."

Because fundamentally anyone can produce a piece of software. T here's a thousand open source clones of Stack Overflow out there. But what we learned really early on at Stack Overflow was that fundamentally we're not just a software company, we're a community company.

I think that's true for almost all software companies out there.

I think the ones that are especially really successful is that they understand software is only ever a means to an end.

It can create an amazing user experience, but without a viewpoint and an opinion behind it it's just going to flounder.

For us, that viewpoint and opinion is about how you build a community.

It's the reason that we actually have a whole support team and a whole service and deployment model that we work with people.

Half of the job is spinning up the software and writing a good piece of software.

The other half is really teaching people how to use it and how to build their community against it.

Grant: OK, cool. Stack Overflow Enterprise is, first of all, it's a private instance of Stack Overflow that you install into a data center or private VPC--

Alex: We can run it for you in our cloud, or you can install it on any infrastructure you run pretty much.

Grant: But fully private, not going to be something that you're worried about the data going out to--

Alex: Zero connections to the outside world.

Grant: Great. So, big companies are interested in this because they're concerned about the data and they want to make sure it's all private.

Makes total sense to me. How did you decide that was the right opportunity for Stack Overflow to pursue when it came to enterprise offerings?

Alex: People were knocking down our door for it.

Over the years, my favorite thing is I literally had two FBI agents show up in our lunch room one day trying to buy a copy of our software to use for knowledge sharing inside the FBI.

That is how badly people wanted this offering. For years, again, we didn't think it really fit in with what we were doing.

We didn't know how we'd build communities inside these companies and actually make the software work for them.

Really, that's what we realized, "OK. We need to find a way to make this work. "

So that's what my project was, to go out and figure out "How do you make this work ?"

Grant: Were you still serving as the chief of staff at this point?

Alex: No, I was VP of operations at that point.

There was a three or four month period where I overlapped doing both, but it was it was basically me and a product manager and two developers who went off.

The company was working on some big transformations to our talent product, which is a huge business for us still, and an amazing way to find a job on StackOverflow.com /jobs.

We couldn't be taking too much of the core focus out of the company, they needed to keep working on that transformation of the talent business that they were doing.

But we still wanted to pursue this, and so it's like "All right, great. Why don't the four of you go sit over here in your own little corner at Skunkworks."

Grant: You put together a tiger team.

Alex: "Tiger team?" I like Skunkworks.

Grant: OK, great. I think what's really interesting, is oftentimes I talk to folks that have a successful open source project or maybe it's a company that has a more consumer-leaning product and they want to go up-market.

It sounds like what you decided to do -- When you started this process to build Stack Overflow Enterprise, did you have a pretty clear picture of what you wanted it to look like?

Or was this like "Let's get this little team together, they'll go figure it out, and then they'll offer this to the market?"

Alex: We knew what we wanted the end state to look like.

The end state was we want every company obviously buying this thing, and having their own Stack Overflow community internally, just for all of that private knowledge that they can't put out on the public internet.

Sure, we add not a great idea of what that actually looked like in practice beyond using a copy of their software.

We didn't know, "What features do we need to add to the software? We know we definitely need to add single sign on so it can integrate into their environment. We've got to make sure it actually runs in their environment and we need to make sure that they can deploy it and run it and actually use it."

But the real details of what that looks like, we weren't sure about.

There were also a lot of questions down the line, "What does this look like? Do people want to run this themselves? Do they want us to run it? Do they want it on StackOverflow.com? Do they want it completely standalone?"

So really, there's only one way to answer those questions, which is going out and talking to customers.

Grant: Great. You led that project to go out and talk to customers. How do you find the right offering and bring it to market in that process?

And then even, you're at a company where focus is key. I think we were talking offline, that's a key part of this.

How do you keep that focus but still build in a new line of business at the same time? That's a complicated process.

How do you get the rest of the organization on board and leadership on board? Just talk about the general structure you guys use to do that.

Alex: I think the first thing to really remember about is when you're going into enterprise software, especially in-- Again, talking big company enterprise software is there is not a buyer.

Everyone talks about who their buyer inside the company is, and t here's four or five buyers.

Or the entity is this agglomeration of four key constituencies, as I like to think about it, which is "All right. Who's going to champion it? Who's going to use it? Who's going to approve it? And who's going to write the check for it? "

Depending on what you're doing, you might think more or less--

At the end of the day, if you don't have all four of those people on board you won't be successful. You might get the first year deal, but you're going to lose it after that.

You've got to do things to serve and support all four of those constituencies, so taking a look at it for us. Who's going to champion it, for us?

It's probably someone who runs an internal shared services team.

It's someone who is basically really frustrated that this massive dev team of 500 or 1,000 people or more is not sharing knowledge and building as fast as they could be.

Who's going to use it? Individual developers. That's for us, really, almost the easiest one.

Because they do know Stack Overflow, they're used to it and they'll give it a try at least, internally.

But ironically when it comes to getting the first year deal, they're not very important. I hate to say it, but the developers are more and more influential.

Where they really are a big deal though, is who's going to build it up and use it and get that second year renewal? Who's going to approve it? InfoSec, legal, finance.

You can have the best product in the world, but if you don't know how to work with those people, best case scenario your deal is going to take you twice as long as it should.

Worst case scenario, you're never going to get in the door. Especially if it's a regulated industry like finance.

Grant: Worst case scenario is you're going to spend three years and then never get the deal.

Alex: Absolutely.

Grant: And then you waste so much time in opportunity costs.

Alex: Absolutely. And then finally, who's going to write the check for it?

Again, you might have a champion who's amazing and loves your product and is wonderful and super influential.

But fundamentally, if they can not get someone to put down a 1/4 of a million dollars, or a million or two or three, whatever your product costs.

It doesn't really matter if you have the other things in place, but that check, that wallet person only comes if you've got a really good champion and a user base identified internally.

Grant: Cool. You went off to go figure this out, how did you look when you first started? You had probably some hints and ideas around what that might look like.

Alex: We had customers coming to us saying, "We're interested." Microsoft came to us very early.

Grant: Great.

Alex: And said, "We're interested in this thing."

They approached us before in the past and wanted it, so we just said "All right, great. Write us a check for this amount."

It's funny, we did a flat rate originally per instance, and we've since moved to per user pricing for everyone.

Grant: Sure.

Alex: But we just wanted to see, "Will people actually write a six figure check for this thing?"

And the answer is "Yes. People will write a six figure check for it."

Then from there it was like, "All right. Great. You're interested in buying it, what do you need it to do?"

I think one of our big goals was MVP. What's the absolute minimum you can do? Get it into the environment, and use it.

Because again, the customer-- I think there's a million fancy quotes from Ford and Jobs and everything on this where they don't actually know what they want.

They have an idea of what it is. They know what they want their end state to look like.

If they knew how to build it themselves to get there, they would have built it themselves to get there.

So actually getting it into the environment, because the other thing is that once you have something working in their hands, it's a lot easier to actually push back on feature requests.

When you're still building, if you're just off in this back corner building something they can constantly pepper you with "It needs to do this, it needs to do that, and it used to work like this."

If they actually have it in their hands, you can point out all the work-arounds and the ways that they can use it.

So a really good example of this is clients are constantly asking us for two big features when it comes to information sharing, one is "I want every search that I run on my internal instance to also return results from the external instance."

And the second is, "I want to import a bunch of old content from old systems."

In both cases, they don't actually want to do that one. There is huge info security concerns on the first one and on the second one, all that content stale and out of date.

So we actually did a couple of those imports, and one of the things we found out from the clients almost immediately "There's actually no value to this old content we imported. It's stale. It's out of date. People didn't mind recreating it."

The only way we were going to find that out was by doing it a couple times, a nd since then we get the question all the time and we push back on it all the time.

Grant: It's interesting too, I think one of the non-obvious challenges you mentioned to me offline was the idea that because you had this strong bottom up pool, and people were familiar with Stack Overflow, they came in with some preconceived notions.

Alex: Yeah. They especially thought, "What they're trying to buy a lot of the time is this experience they have where they run a Google search, the first result is Stack Overflow every time, and it has the result they want every time."

And they're like, "Great. I just want that internally." This is also probably just an individual software developer there, and building a community internally requires you being able to influence everyone else to use it.

As I say, communities don't happen organically. Communities exist because someone wanted them to exist.

So, one person just sending it up without a really strong champion there, nothing is really going to happen.

We really do have to educate them on, "OK. Here's what you actually can buy from us."

" You can buy the software and you can buy us helping you do it, but you're going to have to commit some resources to actually getting it in there and being successful, and you're going to have to address it out to a large enough group to do it. You have to have an organization that wants to do this."

There are companies that come to us not irregularly who are like, "I want to buy your software because I want to tear down these silos."

We're like, "Do you actually? I get that you do, but let's say you've got this structure where you've got VPs who run these siloed organizations that, let's say, consult for other companies and things.

They view the software that their teams build as intellectual property that they can sell to other parts of their business.

Are those people actually going to encourage or even allow their teams to collaborate with teams on other parts of the company?

Grant: There's so many interesting political and structural challenges around these really big companies.

Oftentimes they are their own ecosystems unto themselves.

Alex: Absolutely.

Grant: So acknowledging that and building software that sees that, I think it's a great point.

The one thing that I love that you're talking about that I think is really interesting is this obsession with what you talk about as community creation.

Because you know that the core thing that's going to make an organization successful is to have 500 engineers who are using Stack Overflow Enterprise daily or often.

That's the minimum threshold for the network effect and for the knowledge to all be shared there.

So the thing that really is important to highlight with that, for most companies that might not be community, but it's some threshold of knowledge and engagement pain.

Alex: It's a threshold of pain, too.

Grant: What do you mean?

Alex: When you've got that many developers, you have a massive pain around knowledge sharing and just the communication overhead.

You are willing to pay a lot of money to solve that pain, because not only is it expensive and time delays and stuff, but you're shipping products slower because of it.

We have data that shows companies that have deployed our product to ship things faster, because their teams don't spend as much time stuck on problems, and they find other teams that have started things that are partially solved the problems for them.

You see this, and I'm not going to claim to be the only company in the world that can do this.

You see this when people deploy GitHub internally, maybe they get better code reuse.

We get better code use and better knowledge reuse, too. So that problem's scales exponentially with the number of people .

I think what any company pursuing going down this line has to have is, "What's the real pain that we're solving here and how are we going to solve it ten times better than anybody else?"

Grant: Yeah. I think the interesting thing here is you focus so much on that, and you measure it, and you make it an important part of how your customers adopt your software.

You just said you don't even think about it, you just sell software. You sell--

Alex: Community.

Grant: Community and software, but the important takeaway that I see here is I'm guessing that you've built a lot of tooling to help make sure that these communities are built internally.

That type of training feels like, if you go into an enterprise sale and you just give them the software and you don't give them any of the prospective community training, whatever you want to call it, they might not adopt it.

Alex: Absolutely. I'm a huge fan of service organizations.

Grant: So, yes. Talk about how do you organize? How do you go about that? What do you produce?

Alex: Yes. I think this actually goes back to the idea of focus, too, because again you have to know what you're doing.

There's so few products out there in the world that actually adopt themselves, and Grant can see me doing air quotes right now.

Even the ones that you think of that adopt themselves don't usually right, but that's usually a story that's been crafted to help sell it better internally.

I went back to that. Communities and things exist because someone wanted them to and has done the work to do that.

So, we've built an entire service and support organization around making sure that people adopt our software the right way and build their community the right way.

We're focused on that because it's a long term ROI for the companies.

They're really going to see-- They'll start seeing some immediate benefits within a couple weeks of deploying enterprise, but where they really get it is a year or two down the line.

But we can't wait for that, right? We can't wait a year to see how they're doing and then adjust.

We've figured out, "What are those metrics and things that we have to be adjusting and tweaking, not even from day one, but before we go in that are going to really make the difference for it?"

I think that also, I just said before they even go in, goes to qualification of your customers.

Especially in the early days, qualifying your customers well and picking people who are going to be good partners to you is probably the most important thing you can do when it comes to the customer side of your business.

Because if they're not going to talk to you and give you feedback on what they're doing, how they're doing it, show you the technical tweaks maybe they've implemented--

Our current deployment model, the evolution we made is based on work that one of our own clients did to deploy it more easily inside their environment.

So, getting that sense of which deployments worked, which ones didn't work, and then constantly moving that up the funnel so you can spend less and less time on people who aren't going to convert or who aren't going to be good clients, will pay massive dividends in the end for you.

Grant: Taking what you learn as you go out and try this out, and being like "OK, That didn't work. Let me now adjust how I qualify potential customers so that I don't get in this situation later on."

Alex: It's constant iteration, just like you do with actual software that you're writing.

You constantly tweak your code to try and get it a little bit better, to optimize it, to figure out what works.

You have to do the same thing in every part of your business.

Grant: That's a great point.

I think early on, and this is true for --Obviously this wasn't a new company that you were starting, this is a new product line and it's a new offering. But you're basically, it's the same.

Alex: In a lot of ways it was a new company.

Because selling enterprise software was not something Stack Overflow had ever done before, and it's a very different business than the existing engagement and talent businesses that we've had in the past.

We absolutely had to figure out a lot and then actually go back and retrain a lot of parts of the organization on how you have to do something.

Grant: What was the dynamic between, as enterprise started to really come together, what was the dynamic between what you were building and now because you have enterprise and teams?

Which is the hosted version of this, the difference between that and the rest of the Stack overflow?

Alex: The first year was really fun and easy, because the first year was just us again sitting over on the side thinking, "All right. We're messing around with stuff we're doing."

Every win that we got was a huge win, and there was no such thing as a loss because expectations were all zero.

Then you get-- That's the hacking in your garage side, a phase of messing around with robots.

Grant: Sure.

Alex: Then we actually started having that initial success, and we were like "OK, we're going to commit to this. We're going to hire a couple salespeople, we're going to hire customer support--"

I'd been doing all the sales initially and I'd been doing all the support initially, again it was four of us.

OK, so now we've got 10 people and now the company is actually-- We basically raised money from the rest of the company to do this.

OK, now we actually have metrics we have to perform against. That meant two things.

One, we had to perform a lot better, but it also meant we were reliant on the rest of the company things like HR, Legal and Finance.

All these groups for things, and we had to then train them how this industry in this area expects to do business with you, because it's not the same.

We can't execute our job and do our job if we don't have that appropriate support. But we obviously also had to recognize they still, too, had their own requirements.

We had to adapt certain things that-- I can't tell you how many hours I've spent talking about billing models and invoicing and legal documents.

It's a huge amount of time, but again, it's just like anything else.

Just like tech debt, if you don't get it right upfront, if you're not at least flexible enough to iterate on it and try and evolve it, it will sap you just like tech does on the performance side.

Grant: If you're willing to put up a little bit at the beginning, but acknowledge that you've adopted it.

Alex: Yeah, and I really like the flexibility example. Just figure out the minimum you need to do upfront because it's going to change over time, and you don't want to over-optimize too early.

Grant: I want t o lean back into this, what does your training materials or org, what does that look like structurally?

How many people are in it? What are they doing? What's day one?

Alex: For the customer-facing one, or internally facing?

Grant: For your customer-facing. I think this is probably an often missed thing in enterprise software.

I feel like people write some docs and they're like, "OK, go get started."

But you are really engaging with your customers, and I just think it's a really interesting model.

Alex: T he first thing is we've got our sales teams trained on this pretty heavily.

They know the vision that they're selling, they know the end state that they're selling, and they can definitely talk about it, as I to say.

My view is that sales should be able to talk about the basics at least, what the framework is.

Where you have engineering or specialists coming is when you're talking about the customization to the client end state.

To use a technical example, your salespeople should be able to talk about how we support SAML and what flavors of it.

If they get a question about, "OK. Here's how our SAML setup is."

At that point you bring in sales engineering, and it's actually no different for us on the community development side.

Sales can absolutely talk about, "OK. What's the benefit of a community? How do we generally do it?"

As soon as someone says, "OK. Here's t he nature of our Orgs," the teams were like, "All right. Let's bring in our community development team and have them talk to you."

So the key parties we have involved is we've got a salesperson on every deal , we've got a customer engineer on every deal, which is basically the technical deployment side of things who helps you get it up and running, and we've got a community development manager.

Those are really our secret sauce people who have really all been at the company for at least two or three years at this point and just know how they've taken all this lessons.

They have this playbook. They know how to customize these things and work with our customers and actually help them get it up and running, how to train it, who we need to work with internally.

The way I like to phrase it is, "They've got a playbook. There is no one size fits all plan here because it really does depend on what their internal culture is like, what teams are involved, how big the deployment is, what they want to achieve."

So they'll talk both presale, we'll have a couple calls and we'll try and understand it.

Then once the contract is signed they will really dig into it, and there's probably a two to four week period where the technical guys are getting everything spun up and starting to get things connected to SAML, install the software, and all that jazz.

The community team, really, during that time is--

Grant: The interesting thins is that's where most people stop.

Most people stop at, "They've implemented." They're ready, and then they're like "Go. You've got the software."

So this is where I think it's really interesting, and it is a unique way to go to market, is you're saying that's great --?

Alex: That's 10% of the deployment process. That's important, and actually a lot of the times that's not even the core people that we're dealing with doing that.

They have a technical team doing it.

Grant: Sure.

Alex: What's really important is during that initial process, the real leaders, the people who are going to run this ongoing are sitting down with our community team and saying, "OK."

Grant: But they've already bought the software?

Alex: They've already bought it.

Grant: So it's like, there's no community building or exploration going on, or a pre-POC community stuff happening?

Alex: There's a little bit of pre-sales that does.

Again, insofar as we want to qualify, we don't want to go into a client who we don't think is in the place, for lack of a better term, emotionally to actually buy the software and be successful.

Grant: You have a survey or something that you send out, just to understand if it's like, "Do they have enough engagement where people are really going to be--?"

Just discovery, basically.

Alex: We absolutely do that. Right, "Do they have a big enough problem or pain point? "

There is that discovering qualification process that our community development team works on.

Grant: And then they sign a contract and get them implemented, and now it's like you've got a playbook and it has different timelines, and estimates for how long--

Alex: Different timelines, estimates, tactics, strategies.

Grant: Do you deliver this playbook to the--?

Alex: No, the playbook never goes to a client because we don't expect the client to know how to do it.

That's the whole point, is that the client's got to do a lot of the work themselves but we're their guide on that journey.

Grant: Are you collaborating in any tool together, do you use a shared Google doc, or is it--? What do you do?

Alex: It depends on the client's infrastructure.

A lot of time, again, we're dealing with these 10-20-30-50-100,000 person organizations, and we've got to adapt.

Part of what they're paying us for is to adapt to their work style, so it's a lot of video conferencing too.

We're really big fans of video conferences and actually getting to look at someone.

Grant: So they're not going on site, they're not going to you?

Alex: Sometimes. That was the next thing I was going to say, is going on site is inconvenient for a lot of daily meeting type stuff, regular meeting type stuff.

But I'm a huge believer in it for the first meeting, or at least one of the early ones, I think you form relationships by looking another person in the eye and shaking their hand.

Grant: Build a little trust and have that human element.

Alex: Exactly. Once you've done that, even just one meeting for half an hour, you can do everything else over the phone. And again, there's a big difference between looking at someone on a Zoom or a Google Hangout where they're right in front of a computer screen staring at you, than a conference call with eight people. So we do a lot of Zoom and Google Hangouts as well, again it depends on--.

Grant: WebX. You probably have a subscription to every possible video conferencing.

Alex: We just have Zoom and Hangouts, but we use the client stuff for everything else.

Grant: OK, cool. Got it.

Alex: From there, it's "OK. Tell us about your thing. Tell us what you're facing, what you're doing, what you want to get out of this. OK, here's the playbook that you need to run."

We'll do everything from the strategic level down to tactics and specific things to be doing, down to we have pre-written emails that we will customize for them and send to them and be like, Send this out."

Now again, they have to do all this work themselves. We're not going to go around their organization for them because we're not credible to do that. That won't be successful.

But we'll be there like, it's like any good sitcom where the person doesn't want to go on a date so their friends send them on a date with an earpiece in their ear and tell them what to say on the date.

It's like that, we will help them to that extent. That is the level we will go to with our clients.

Grant: OK, s o you have pre-built generic collateral that you'll customize, like "Here's some templates that you can use to send out and get people involved. We found that this is a subject line."

It's really like that playbook has everything in it, that step by step, you can customize it as you're going along but you're not just handing off the playbook.

You're actually creating this project plan together, and bringing them along the whole way.

Alex: Absolutely.

Grant: Is it like, during that implementation phase is your community manager--? Is that what you call it?

Alex: It was community development.

Grant: Is that person, do they have one customer at a time? Do they have 5-10 customers?

Alex: We think that right now they can run about 2-3 active deployments per person.

Grant: Got it.

Alex: And still maintain that focus , and then manage an existing book of probably 20-30-40 clients, depending on what stage they're at.

Grant: Because the kickoff is by far the most--

Alex: Absolutely. We do monthly check ins. During the kickoff, we're talking to them 1-2 times a week probably.

But even on an ongoing basis after that, we're talking to our clients once a month.

Grant: Sure.

Alex: That does two really big things. One, we want to keep that partnership up. We want to know how they're doing. It's really valuable for us.

We get feedback on what's going on, we help them solve any tricky issues that have come up.

The other thing that's great about that is, you never want the first time that you talk to a client after they buy to be when you're calling them to ask them for a renewal.

Grant: Absolutely.

Alex: You want to have a relationship with them all the way through.

Grant: What's interesting here too, is that you don't actually even--

You don't structure this as "You have a license fee, plus you're going to get this whole implementation thing and that's 100 hours at this price."

You bake it all into the license fee.

Alex: Right. You pay a per user licensing fee and that includes everything. The thing I want to caveat with that though, is that was the right decision for us.

Grant: Sure.

Alex: We made that decision because we understood there is no separating the community development from the actual software itself.

We're like, "We've got to roll this all into one."

We then also decided to roll in the technical support because it's such a small amount of the overall time and expense we have that it felt weird to split that.

You don't want to charge someone $200 a user or something for this, plus an extra $1 for technical support. It's weird.

We decided to roll it all in together, and for most people I would say that's actually the wrong call because most organizations do have vastly different requirements when it comes to the service and support.

You should absolutely think about, for your particular product, how required it is.

What can we include that's the required amount that we know everyone should be doing to be successful?

In which case, "Great. We're going to build that in." Versus "What's more customizable and flexible and things, and can get extra money for?"

Grant: I think it also probably feeds back into the way that you went to market with Stack Overflow Enterprise, was you had this huge site that everybody loved and you had a ton of inbound interest for a business edition.

Instead of saying, "OK. Let's start to step into the hipster enterprises first , those companies with 1,000 employees that know how to do things in a modern way.

You went straight to the top, you went to the biggest organizations in the world and you said "Let's get these deals first."

It's a different approach than I think a lot of other people will take. Generally--

Alex: It was driven by necessity.

Grant: Sure.

Alex: You used the term "Hipster enterprise," I to call it "SMB plus single sign on," it's kind of what those middle-ground ones are.

Grant: Sure.

Alex: The reason we did it that way is, as I mentioned, we needed to go off and not disturb the rest of the company as we were doing this.

We needed to let people maintain the focus because you can only focus on so many things at one time, and the easiest thing for us to do was say "OK. Let's just take an entire copy of the current software, add single sign on, make it run in someone else's environment and drop it there."

But that version, that style, only works when you have at least 500 people who can join that community.

If you've got at least 500 developers, that means you're probably about at least a 5,000 person organization total. You might be a super tech-driven startup, you'd only be 1,000 people, but generally speaking you're probably at least 5,000 people. So everything we did around that enterprise, the reason we went to that enterprise is because it was in a way more easily abstractable away from everything else.

Since then, we've come back and we've created Stack Overflow for Teams. The whole idea behind that is you don't need 500 people there.

How do we go below 500 people? We used the fact that your team's already on StackOverflow.com today. Enterprise is a new place, completely standalone.

Teams is on StackOverflow.com, so you can make it work easily with a five or ten person team which just won't work if it's a standalone.

Grant: Just servicing the content that's internal.

Alex: Exactly. It's still completely private and totally isolated. That was a huge project.

That alone, making Stack Overflow for Teams was a year long project, I would say was one of most complex things you can do, which is changing a fundamental assumption about software.

When we launched Stack Overflow, all content was always going to be public.

When you change that assumption, how do you do that? How do you do that right?

That was a much bigger project that required most of our engineering team for months on end in order to get done.

Now we have it, it's great, it's an amazing product.

We just launched it in May of 2018, so it's not been out there that long but we've already got thousands of companies who are using it and really like it.

We've already seen them moving up that towards the enterprise when we actually had people who started with only a few people on it, but have now grown and are actually big enough to go to the enterprise product if they want to.

Grant: Interesting. This is, we talked a little bit offline too, about this idea of the continuum.

When you started, you went to the most extreme enterprise-y end of the continuum, and then you launched teams --

Alex: All the way at the exact opposite end of that continuum, and now we're building towards the middle.

We're actually working on another version that I can announce on this podcast here.

We are working on a version to cover exactly what we just called "The hipster enterprise" ones.

Where they want that completely web-based version, they don't want to have to run any of their own infrastructure, but they do need some extra features like single sign on and certain SLAs.

Grant: Sure.

Alex: Things like that. That's going to actually be coming soon, because we know that there's a big demand in there too. But again, that's actually the hardest possible version to build.

Because it required both building the small team version first to enable it on the site, while then also building all of the enterprise features that they care about.

Grant: Sure. But then it sounds like you'll have a pretty wide spectrum of possible--

Alex: Once we're there we will be able to cover any company from 2-200,000 people , or 2 million people.

Grant: Instead of either open to the public, or the biggest companies in the world--

Alex: We were at a point where it was just open to the public, then it was open to the public or if you have 1,000 or more developers then we got to "OK. 2-200 people or 500+ people, but not a great option for people in the 200-500 person range, a nd now we're going to have that total continuum all the way across.

Grant: Throughout that whole process was there ever second guessing, like "Maybe we should have built teams first." Was that a thing you did?

Alex: Yeah. I think there was more of the wish or the fantasy that we could have done it, then the thinking that we did it wrong.

Again, we understood the constraints that we had at the time and so I don't think anyone's ever said, "Man. We did this wrong."

I think if anything it's, "God, why didn't we start doing this five years ago?"

Grant: Interesting.

Alex: That's the biggest thing, is that we'd written off actually back in 2010- 2011, written off the idea of doing this private Q&A software business. We wish we hadn't.

Grant: All along though, you just built up more and more demand, likely, for the product.

Alex: Absolutely. The number of unique users every month on Stack Overflow has tripled since then, so it's only become more and more of a part of developers daily workflows.

But I think one thing is, in business you always wish you'd started everything that's working earlier.

Grant: Yeah, I have this thing I always say.

Whenever I became an entrepreneur I'd always had a problem with procrastination in my prior life, and then when I became a founder with my first company I realized that every idea that I had was like "We should do this now."

But then the next realization would be "Oh my gosh, I should've thought of that six months ago."

Alex: Yes.

Grant: So instantly, by having a new thought, I would have thought--I would have been like, "I've already procrastinated on it by six months."

So it created this insane sense of urgency for every new idea.

Alex: The other thing you then realize is, "Because I'm already working on that other idea I had six months ago now, I've got to wait another six months to start pursuing this idea."

Grant: Or just try to do it all and don't sleep.

Alex: Yeah, that doesn't work. That really doesn't work.

Grant: Right, or hire people. That's why one can work.

Alex: There's still a limit to how much you can do though, with focus.

Grant: True. It's so interesting, that approach.

I think one thing that's probably important is instead of second guessing and then halfway through trying to build teams, you just stayed the course.

You stayed the course and said "We're going to keep going enterprise. This is the right path for us. We'll get there eventually."

Because I think oftentimes you get into a project and you realize how hard it is and then you're like, "Maybe we should have done the other thing first."

You never see it all the way through. This is a is a challenge that you see oftentimes when people start doing new stuff.

I love that you just saw it through, you continue to see it through and then you're like "We'll backfill it later."

You probably have a long enough time horizon at Stack Overflow where you're able to say, "In three years, we know we can set these goals."

Alex: Absolutely. I can tell you where we want to be with the product in a year, in three years, in five years.

It's not just about that individual product, it's how it ties into the overall ecosystem both for Stack Overflow itself and the industry as a whole.

Grant: That's cool. You can tell us now, or not?

Alex: No, I can tell myself where it is.

Grant: Yeah, I get it.

Alex: We've got to keep some secrets.

Grant: Yeah, no problem. That sounds really interesting.

OK, so then what are some of the other lessons that you feel like you've learned along the way while building Stack Overflow Enterprise?

Alex: Your first couple deals will always deceive you.

You're going to go around and read a bunch of blog posts about how long this stuff takes, and how it gets dragged out, and where all your chokepoints are.

Then your first couple deals you're not going to run into those, and you're going to be like "Those are ridiculous and they're wrong"They're not.

It's unbelievable, and you really do run into everything. There's a number of people who've done great writing on this.

In particular, I really Mark Schuster's blogs and posts about this.

In particular, I think the most important post anyone can read is his posts on NINAs, which is "No Influence, No Authority" people, because they really will suck up just so much of your time.

I think one of the best things that I did is knowing that going in and knowing how important the sales qualification process was, it's huge.

The other thing, and this goes back to that idea I said of having to retrain the organization on how to work in this specific business, it's learning how to understand when you want to hire for specialty vs. eagerness, basically.

Because you really do need both.

Obviously, having someone who's a complete expert in their field and really excited about taking on something new and will do anything that's required as part of a startup is great. But when it comes to, I think, especially internal promotion, when do you make an outside specialized hire who has done it before vs. an outside hire who hasn't done it before but with potential, versus an internal promotion? You can't do all of one, or all of the other. You've got to figure out that balance.

The way that I've started to approach it now really comes down to, "What does the level of competency and support system inside the organization for that role already look like?"

A good example of that is, "Is this the first product marketer you've ever hired?"

Or "Is this the first financial analyst or first CFO you've ever hired?"

You better hire someone who's done it before, because they're going to have no support structure inside the organization, especially if they have to train the organization in how to work with this function.

Let's say you're a salesperson, if you've been a head of sales actually, let's say, and you need to hire a head of sales.

Then it's a lot easier to promote someone who you think has the right skills, not just your best salesperson, but who you think has the skills because you can coach and develop them.

Now you make sure you have enough time to do that, but at least fundamentally you have the skills, you have the experience to do that.

Just building that balance between "OK, here's we're going to promote someone up. Here's where we're going to go out and seek that outside expert and advice."

It's really important to figure out, because otherwise you just keep running into the same problems of everyone's upset because they don't feel like there's any promotion ability.

But then on the flip side, no one knows how to actually do anything because they're having to spend a lot of time re-learning these lessons that someone who'd done it before would have done, or would have known.

Grant: Yeah, OK. I like that a lot. That framework seems to be super valuable for--

Do you apply this every time you're thinking about a new role? Or is this mainly for leadership roles? What is your--?

Alex: I think about this for almost any role we do, especially when it's the first role.

Similar thing, we recently hired a role where we're hiring a product marketing manager focused on the growth of our team's business.

One of the things we identified is "What's really important here is we're running a B2B self-serve SaaS funnel."

No one inside the organization really has a lot of experience doing that.

We've always done sales-driven funnels, whether it's on our ads or talent business or the enterprise business.

This is somewhere we should really be going out of house and getting that particular experience, because we really needed it.

The flip side is when most of our development roles and our engineering manager roles now, we actually look to hire from within on those because we've got a structure that we can promote people with and actually develop and train them on.

Grant: This is something that I always think a lot about, because I have a bias towards people beyond move up through the organization.

Because I trust them when we hired them, we love them and they're amazing.

As founders, we've had to level ourselves up constantly. So that's my inherent bias.

Alex: This is perfect, because I can point out now that's a false dichotomy in my mind.

You're actually, if you just promote people without a support structure and someone they can learn and develop from, you're actually doing them a disservice at the end of the day.

Because A, how are they supposed to figure out what to do?

And B, you're going to just end up annoyed with them and annoyed with the fact that you're not moving fast enough.

Especially when you're talking about, "Do we promote someone up into a management role, do we bring in or layer them with a new manager?"

I think the thing you really look for is "All right. We probably need a new manager, but one of the key criteria needs to be how are they going to do with supporting that existing team and leveling those people up, so they can become our next manager as we continue to expand?"

Grant: I think that because I have an inherent bias, I have to acknowledge that inherent bias and then try to make sure that I'm being thoughtful about "OK. Does our team have the skillset that we need, or should we be trying to bring people in from the outside that can really help out and scale that role?"

It turns out when you're a pretty small company, we're like 20 people, you have to hire a lot of people from outside because you just don't have that many people in the organization.

You have people of all different skill levels, but my goal is always over time I want to continue to develop people so that they can grow when they feel like there's opportunity.

But it's a challenge on both sides.

We were talking earlier about the amount of time that you spend interviewing and recruiting folks can just be, as the leader of your organization, can be so time consuming.

Is there anything you do in order to --? Do you guys have an internal recruiter that's helping to screen folks for you?

Alex: Yeah, we have a whole probably 10 person HR team.

Because Stack Overflow as a whole is 300 people, so this is one of the little upsides of building a startup inside a startup, is there is a lot of existing infrastructure we can rely on there.

Grant: But then this is your point around some of the training that you have to do internally--

Alex: There you go, that's the flip side.

There's a lot of existing process and things that we have to comply with, or existing systems that we have to use and rely on that we don't actually get to pick.

I think anyone who's ever worked inside a big company in a single team inside a big company is really used to that inherent tradeoff there.

Grant: But even so, the team that you have that is doing recruiting has probably never hired a product marketing manager before, right?

Alex: At least not this specific type. They've hired product marketers before, and they, of course, may have done it in a previous role.

Grant: Sure.

Alex: So it's then just about, I think, a really strong collaboration and partnership between them.

Grant: It's actually really interesting to think about the duality for the supporting roles, the back office roles.

They have to be able to be both consumer and enterprise, they need to really understand both worlds. Those supporting roles, that's probably hard to find.

It's a great experience, but that's not super common skillset.

Alex: No, and I think it goes back to why you have to have a strong partnership between them and the folks who are doing a lot of the work, because a lot of that context can be explained easily if you take the time to sit down and talk through them and be able to.

But a lot of times, I think in a lot of companies, there's a tension between those groups and you need to just figure out ways to humanize them to each other.

Make sure everyone understands why people are doing, and I think context, explaining why you're doing the things you're doing or why things are the way they are as opposed to making it feel like it's an arbitrary or capricious thing.

The flip side is one side can't make the other side feel like they constantly have to justify themselves and justify their existence.

I think it's a careful balance, and this goes back to why company culture is so important.

Grant: It probably helped a lot for the enterprise business that you had such a fundamental and important role as the person leading operations and culture inside of the company before you took on the enterprise side, right?

Alex: I hope so. I think certainly the fact that I think it's important has had an effect, and I've tried to spend a lot of time on that.

Grant: I guess my point there being that someone maybe with less agency inside of your organization who tried to spin up the enterprise portion of business, maybe they'd just hire it in.

Maybe your CEO hires in someone to run the enterprise business.

Alex: Absolutely.

Grant: They don't have the working knowledge of the organization, and they don't have the seven years, or at that point four years of back history, that you had with everyone.

That trust, that's a hard--

Alex: Yes, absolutely. I think that's a reason a lot of the time you'll see any internal Skunkworks project internally, I think is almost always initially kicked off by an internal person by exactly that reason.

Once it gets established, they may bring in an outside head and maybe they're planning to replace me right now, but I think absolutely you'll see that.

Grant: Just check StackOverflow.com/Jobs.

Alex: Yeah, exactly. There we go.

I think absolutely you'll see that be the case inside a lot of companies, because you save so much time knowing just how to use the organization and the tools and the assets that already exist in it.

Grant: That's a really interesting perspective there . I'm sure that there's a lot of folks out there, where this idea of taking a existing company and finding how to add new lines of business into it.

What do they call that, "Intrapreneurship," or something.

But it's a really important part of how companies grow, because your options are that you either acquire or you do this, and you figure out how to do this.

Is this something that Stack Overflow has done with other lines of business? I guess you have a family of businesses.

Alex: We have two other lines of business, which is our engagement business.

Which helps companies run very targeted and very calm ads, as we say, on our site.

The things that developers might be interested in, and that was the first and oldest business.

Soon after that we spun up the talent business, Stack Overflow Jobs. I t's called "Talent" for employers, "Jobs" for developers.

We definitely have some of those businesses which have grown and evolved over time, and gotten new products and offerings that have been part of them.

This is really, I think, the first time we're building out a new-- Especially something that is just so drastically different than the other two.

Those aren't really enterprise SaaS businesses.

Grant: But do you think that this is a skill set that you'll continue to use, and find new--?

Alex: Absolutely. I could see myself going to companies big and small after this and taking this role.

For me, I really enjoy it because I'm a big fan of the rapid iteration thing and building startups. I love that.

I don't care if it's its own independent thing, stand alone, or inside a big company.

It's all just-- for me, the challenge and the fun is in the actual act of the building.

Grant: Do you also think that Stack will need to be able to add on these new product lines over time as well, and find those new opportunities and some of the lessons you learned around that Skunkworks and creating that organization?

That those apply to the next, whatever next Skunkworks project is?

Alex: Absolutely. Because I can already see, too, what some of those projects might be.

Grant: Cool. So you laid the foundations, the pattern, and other people got to follow that to create the next--?

Alex: Yeah and I just think the organization, by all of us working together, has figured out how you do this better. I'm not going to take credit for that, it's just been the exercise that you go through by doing something the first time.

Grant: It's the hardest time to go from one product, multi-products, to go from one line of business to another totally separate private business.

There's a lot of-- It seems like you've made a pretty -- Like, you found the path.

Alex: Yeah, we actually even saw this in spinning up Stack Overflow for Teams.

While it was a lot of technical work to do, there was a lot of work that was easier in a lot of ways to do some of that stuff because we'd gone through it once before.

Now we see it working on this middle version of it that'll bridge the gap between the two.

So much of that work I can already see is being eased by the work we did on Stack Overflow for Teams.

Grant: Yeah. One of the big challenges that personally I've been facing, and I'm guessing based on your recent hire it's something that you've also been toiling with.

How do you communicate all of these things and how they're different, and how they work to the market?

Like the first version of Stack Overflow Enterprise. You're like, "It's Stack Overflow in your environment."

Alex: How do you balance the difference between Stack Overflow for Teams, versus--?

The thing you don't appreciate is that you live in this all day, every day. You understand every minute difference.

You're literally incapable of understanding how the market is going to perceive it, just because you you're not your own customer once you start doing this, I think.

Grant: Yeah.

Alex: So this is one of the reasons we're looking for people who specialize in it, and really know how to do this and understand even with building this function internally.

We continue to work with outside people who do this on a daily basis.

But not for us, because it's that outside perspective and experience that is really important.

Grant: All right, this has been great. Alex, any other parting thoughts before we head out?

Alex: No, I'd just reinforce the key thing I was talking about earlier, which is get to know your customers really well and focus relentlessly on what they're doing. Don't forget about your internal culture.