How to make sure the CEO funds your crazy ideas

Adam Fitzgerald: One:

Speaker 2: store for today. And this is where finish our section on on kind of where we are as as a as a craft, as a profession. So I'd like to introduce Adam Fitzgerald from Amazon Web Services who is gonna talk about something that we've probably all come across at some point, which is how do you actually convince people within your organization that what you're doing is worthwhile. And so you know the drill. Come on, let's get on your feet and say welcome to Adam.

So thanks very much.

Adam Fitzgerald: Hopefully you guys can hear me. Thank you for coming and spending a Saturday, and thanks for listening to me. First of all, I want to pause for some introspection and consider my place in the existential universe, and wonder who I am. Thank you to Tim for all the help. But more importantly, why would anybody in this room bother listening to me?

I've done developer relations at a handful of companies over the past twelve years, starting at BEA Systems, then working at Spring Source, VMware, Pivotal, and then most recently at a little company called Amazon Web Services. We've got a couple of computers. You might have heard of us. And in that time I spent a lot of energy trying to convince people in various different levels of the organization why they should be doing Developer Relations. In some situations I was very fortunate to have a great founder that was very passionate about developers.

In other situations it was a little bit more hard work. And there's a couple of things I've learned along the way that I thought maybe I'd share with you guys. And so I thought I was going be talking about ancient history when I talked about my history, but apparently I got beaten to it by Josh and Tim too. So we're not going to go anywhere near that far back in my talk. We already asked a couple of questions about who you guys are.

So we've got some geographic information, we've got some title information, but what I want to understand a little bit better is what type of business are you in? Because the business you're in is the thing that makes a difference to how you communicate and convince people to back your strategies, your tactics and things you want to do. So what do you make? What do you sell? What is your employer doing that pays for your salary?

So are you selling packaged software? So who's selling packaged software? Who's got a licensed piece of software? Wow, that's a small number of people. Who is screw those capitalist pigs, we're in open source, it's all about the freedom of ideas.

Yeah man, rock on. So we've got some open source people. And who is in the consumption based model, the pay as you go subscription service. If you have as a service anywhere in your company description, you're in this category. You put your hand up.

Are the three sorts of different models of software delivery that I'm going to talk about. And I'm going to talk about them in very specific characteristics of experiences that I've had or that have been related to me by other people. This is by far no means an exhaustive list of the different ways that you can build business models for selling software or selling technology. So this is just a small caption of those different pieces. The rude awakening in every single one of those situations is that you are a cost center for your business.

You cost your company money. Everything you do in terms of engaging with developers costs your company money. If you want to have a conversation with a CEO or a CFO or somebody that is asking you to do something, you have to understand what your business model is in order for you to make the convincing argument that they should give you more money to do the things that you want to do. It's really important. It's hard to remember sometimes when we're all wrapped up in making sure we get community participation, we've got the right voice, we're putting the content out there, we're making developers feel good, we're finding great community members.

It's hard to remember there's a business behind all of this and there's a rationale behind it. But that's the critical thing when you want to convince a founder, or somebody with the dollars in your company, or somebody that is going to be funding your programs. That's the thing you need to remember. What are the things I'm going to do are going to contribute to the value for my company? So remember you're a cost center, and that will help you understand how to have those conversations with the CEO.

The question you should always be asking yourself is what does one developer mean to my company's business? Now you might be in my company might be in the business of actually selling software. And so a developer is actually a user or consumer of that software, and therefore that is one unit that you've sold by engaging a developer. Your company might be in the business of selling services or software to a general consumer population. In which case one developer is not the endpoint but should be an enabler for helping more consumers to use your product.

So you've got to understand what a developer means inside your business model. Let's go back and talk about package license software. I'm going to use an example which I thought was ancient history. The Windows operating system. There's plenty of Microsoft people here, so they can feel free to correct me on some of these things.

I didn't work at Microsoft at any time, but I had the good fortune to work with a couple of people that did. And in the late ninety's the job for Microsoft was to sell as many licensed copies of Windows as possible, get it in many different desktops as possible. If you haven't seen the developers, developers, developers, developers video, I strongly encourage you googling it right now. See a sweaty Steve Ballmer getting really, really excited. This was a critical strategy for Microsoft.

The reason it was a critical strategy, not because if I sold Windows to a developer, he would be using Windows. The critical reason was because if I sold Windows to a developer, they estimated that more people would use Windows. The more products, the more software, the more games, business applications, tools and things that were built on top of Windows, the more likely people were to be buying Windows to run their operating system. There's a couple of chaps here that told me the story about all of this. The guy on the right is Todd Nielsen.

He's now the head of Roku and platform at Salesforce. And on the left is Charles Fitzgerald, who's now a consultant. I had the pleasure to work with both of these guys. In the late 90s Charles was the head of platform strategy at Microsoft, and Todd was the head of Visual Studio at Microsoft. Basically in order to justify to the executives at Microsoft why they should build a developer engagement program for Windows, they did an economic calculation that showed that every developer seat that used and built applications for Windows resulted in seven additional sales of Microsoft licensed Windows operating systems.

Windows was $69.75 dollars per install at the time. So you've got seven times $65 That's the total revenue that every individual developer is. That's what funded that was the model they used to convince people at Microsoft to fund the developer engagement they needed. That's what funded their conferences. It's what funded their headcount.

It's what funded their Channel nine. It's what funded the Microsoft development network. All the things they built were built upon this basic economic model of one developer is worth this much money. Now, it's not really you can't do it just based upon the retail price of Windows. You've got to understand what the individual cost is for producing those Windows.

Well the marginal cost is very small for producing software, but you've got a bunch of sunk costs you have to aggregate for. So you have to understand what the marginal value is for each one of those licensed package software and it gives you a simple calculation. As long as your developer acquisition cost is less than some multiplier by the number of units sold by the marginal value of the packaged software that you're selling, then it makes sense to go ahead and spend that money to acquire a developer. This is a simple formula in this environment. And this is an idea that I'm going to try to come back to in the following slides.

The X is a tolerance factor, and it depends very much on the organisation you're in and the people you're trying to convince, whether they're willing to spend between 0100% of their energy or their revenue on acquiring more people. So it's a business factor. But the total cost factor is really straightforward, very easy to understand. So if I'm selling packaged software, what's the marginal value of that packaged software? So what's my revenue minus my cost to give me my marginal value of producing an additional unit?

Multiply by the number of units sold that's associated with acquiring a developer, multiplied by some factor, and as long as my cost of running a developer marketing tactic is less than that total cost, then go ahead and spend money all you want, because I'm going to ultimately be making more money for the business. So that was the story for package license software. So let's talk about open source. Now there's lots and lots of different open source business models. I'm going to talk to you about just one of them and this is my experience working on the Spring framework.

Anybody here heard of the Spring framework? A couple of you guys know about it. It's a very popular dependency injection framework. Still going strong. Lots of people using it.

Very popular in the Java community. Actually Arun I'm sure is a big fan of Spring. He and I go back a long way. The company behind the Spring Frame was created by Rod Johnson, the founder of the Spring Framework. And in 2010, when Spring Source was acquired by VMware, this was the state of the universe for the Spring developers.

I went back in my archive, lifted this straight out of an old deck. So we had a global population of 2,500,000 Java developers using Spring. We had really good metrics to assess that based upon download numbers and Maven packages and all kinds of other things. We had 125,000 people subscribing to email communications. Those people were really interested in us.

We had 12,000 people that registered and active on their forums and logged in in the last twelve months. We had 400 people that actually answered questions on the forum that weren't even employed by Spring Source. And the whole open source project was controlled by a small group of engineers largely employed by Spring Source and that was just 20 people. And this stack ranking ratio of the total population was like, this is amazing. How many of all these people we have here?

How are we going to make money out of this incredible trend in open source software? Well we were a start up. We tried lots of things. We tried selling an IDE. That didn't work.

We tried selling production support for Spring on whatever app server. We tried plug ins for advanced capabilities for Oracle. We tried all sorts of different things. We tried creating an OSGI based application server. It didn't go so well.

We did lots of different things. Started up, we pivoted lots of times. And so eventually we hit on this model. And that was give all the tools away to the developers for free and monetise on the run time. Monetise on the production systems.

And so because Spring meant you didn't have to use a full blown Java EE application server, you could just run Tomcat, what we did is we built a production level version of Tomcat called TC Server and acquired a management system and monitoring system called Hyperic, glued those together and started selling those to enterprises that were paying large license fees to IBM and Oracle for application servers, WebLogic and WebSphere. This was an incredibly successful business for us because we were selling at a fraction of the cost. People were using it. We had this Who's base. But we had to ask ourselves the one question, what does a developer mean in this business model?

Well, it turns out that developer, those 2,500,000 developers, one of those developers means almost nothing. Because they weren't the ones that were buying the production systems. They were the ones that were just building the software that ran on the application servers. So they became the top of the funnel for our regular sales process. They became the raw leads.

Not the raw leads. They became the addressable audience for the raw leads that the sales team then went after. And then the raw leads, they had to change from community to raw leads, had a conversion ratio. Raw leads turned into open leads. Open leads turned into working leads.

Working leads turned into opportunities. Opportunities then turned into closed sales. And the conversion rates for every single one of those is actually much lower than the numbers here you see on the left hand side. So to ask yourself, how much money should I spend trying to convince one more person to use Spring? Well, the cost of developer acquisition, in this case, was some multiplying factor x, multiplied by the cost of conversion from community to raw lead, cost of conversion multiplied by the conversion rate from raw lead to open lead, open lead to working lead, working lead to opportunity, opportunity to close sell, multiplied by the average deal size for the production systems that we were selling.

Now, that's a lot of multipliers. One, two, three, four, five multipliers of conversion rates. You've got sub 10% conversion rates in every single one of those. Multiply them all together, you're going to get what? You're going get a really small number.

I used to be a mathematician, so believe me. It's a small number. That means you either need to have an enormous deal size in order to make that number worthwhile, or you're going to have an incredibly small developer acquisition cost. And that's exactly what happened. Our deal size was actually pretty big in enterprise license sales for Spring Source and we did really well, but it still meant that the cost per developer acquisition was just pennies.

You could only spend pennies trying to convince a developer to use Spring. So that meant having that realization, having that understanding, meant that's how we funded our developer engagement models at Spring Source. We did two events a year, our own conference and Java one. We didn't do other stuff. We didn't go to lots of things.

We got many of our engineers to go speak in public because we didn't have enough money to justify having lots and lots of evangelists. We had one evangelist, Josh Long. So there's these situations where the business informs you how you should be engaging in your developer capture strategy. How you should be talking and engaging with your developers. So that's my Spring Source war story.

Let's turn to the one where the majority of the people here in this room said this is the model, this is the business model you're in now. So this is pay as you go, or consumption based pricing, or some kind of subscription service, or as a service based situations. So there's a big distinction here between two types of things. First of all, some of you will have the developer is your customer. The developer, say you're Twilio, you're PubNub, or you're someone else.

The developer is your customer. They are using your service to do something and you charge them money for it. Same as AWS, platform as a service companies, other infrastructure provider companies, the developer is the customer. Some of you may have subscription services where the developer isn't the customer and you've still got to engage. I can't talk knowledgeably about those situations.

Had a chat with you during a break about it. But in situations where the developer is the customer, then the critical thing to compute and to understand is what is my customer lifetime value for using my product? This is actually surprisingly easy to work out if you've been in business for more than six months. What happens is when people, when you bill your customers for things they do, whether it's a fixed rate or whether it's a consumption based rate, you produce what's called a time series of data. These are distinct.

You bill them every month or every week. You tell them how much they owe and they pay it. That's a set interval, discrete set of numbers that are aggregated across all of your customers. That becomes something that's called a time series. And amazingly, there's a fantastic rich area of mathematics and statistics dedicated to analysing time series data.

There's lots of reasons for that. Financial markets produce time series data. Weather observations produce time series data. Lots of scientific endeavours produce time series data. But you can bring those same techniques to bear on your revenue data for your business.

So This is actually a chart of a random stochastic process. You don't have to worry about it actually displaying any real information. I'm going bore you for just a second. Bear with me. So there's this great technique called an autoregressive integrated moving average that you can use on time series data to get great insights and do customer lifetime value computations.

It looks like a complicated formula, but you can see it. It's on Wikipedia. Just go get it. I didn't have time to LaTeX it up and put it in the slide myself. I just copied and pasted the image.

But it's pretty straightforward. You need to understand what your revenue from your customer is, and you need to understand what your costs are. So that's great. Understand what those things are. You're billing on a regular cadence.

So you need to understand what the profit for the usage you have is and that gives you your actual value. That gives you the value per data point. Then you want to get rid of all your high flyers, your top billers, that one company that's keeping you all afloat. And then you want to get rid of all your bottom liars as well. So the people that are costing you money.

And this is a great example of why it's usually a really bad idea to offer unlimited free services for a period of time for customers. They wind up becoming a negative value computation for your customer lifetime value. It's a judgement call as to whether it makes sense for your business, but in the pure math of it they're a drag on computing of this value. So you could have negative values in here. So you eliminate the top band, eliminate the bottom band, look at the middle two quartiles of data, and then you run the first of all you've got to run what's called a difference mechanism to work out if there's any seasonality in your spend.

Because if you're on an annual spending cycle, maybe you're in a retail business and there's this big peak every year, if you don't do the difference, take the difference out of it, then you might be making a prediction about your customer lifetime value over a window that doesn't cover your business cycle. So you've to be a little bit careful about that. So if you do that, if you do those things and you take the difference and then you just run the order regress integrated moving average. Moving averages means you take the average over the collection of months before and after the month you're currently interested in. And autoregressive means you actually make a comparison between it and the other billing cycles and people in your customer base.

That gives you this, and I'll say this, you can use an R package that does all this for you in two lines of code. You just need the data. And you can actually do it in Excel if you're really hurting yourself. Just use the R package. This gives you a customer lifetime value and you have to pick the window in order to do it.

So you say okay, I want to know what the next four years of spend for this customer are going to be. And that gives you some understanding about what is the value of that customer. And it's going to be much smaller than you ever thought possible. So the customer lifetime value is now the key definition to your business about what is the value of one of your individual customers. And if your customer is a developer, then that tells you what your developer is worth.

So your developer acquisition cost should be some fractional component of your customer lifetime value that's defined over some time frame that matches the business cycle that you're interested in. Maybe you want to do it quarterly. It's usually better to do it yearly if you're trying to avoid seasonality concerns. Usually what you do is you extend the time frame out for a long period and you have to make sure you're not baking in if you're a new company, you've only got data for like twelve months, you've to factor into a churn mechanism into this. You don't know how many people are going to turn over and leave yet.

When you've got years and years of data it's much easier to work out what your churn rate is and that's actually built into the model. As long as your Developer Acquisition Cost is less than some factor times your customer lifetime value, then it's really reasonable for you to spend on tactics and programmes that will go and acquire those customers. This is a model I recommend people using when they're in an as a service type environment. Compute your CLV and then work out what portion of that spend your CEO is willing to let you use. If that X is 100%, you've got a really generous CEO.

Traditional numbers are much more in the 20% to 30% range of the CLV will be able to be spent on marketing, developer marketing. So let's recap. How do I make sure the CEO funds my crazy ideas to make developers happy? Well we saw that you need to know first what the developer acquisition cost is for the tactic that I'm going to pursue. So the thing that was on the left hand side of all the equations I showed you was this is the money I'm going to spend getting this guy.

What is that money you're to spend? Are you going to spend it on throwing a party, giving away free sodas, making t shirts, having a conference? You've got to know for each tactic you pursue which one of those costs are for getting another developer. Secondly, you've got to know for the right hand side of the equation, or right hand side of the inequality, if I'm being specific, you've to know your company's business model. You've got to understand what are the things they need to multiply together and compute in order to get that thing on the right hand side.

Whether it's the CLV, or whether it's the conversion ratio for my sales funnel, or whether it's the marginal value of my package license software. Those are the things I need to understand in order to compute the right hand side. And the last thing you need to know is there's that fudge factor in the middle there. We've got developer acquisition cost is less than x times business object. That x is, as a service model, could be as low as 20%.

In package license software, I've seen it as high as 100%. So you've got to understand what your company or your decision maker's tolerance is for that factor of X. You need to be able to say, okay, I know that they're going to be on board with this, so I can spend up to the net new value for that product. So we're going go to a break next. So that means you guys have lots of opportunities to ask me questions, you have any.

So I'll leave then. That I put this unicorn farting rainbows in the slides because I worked with Tamaho for a long time and I promised her I would do it. If you're in the Bay Area, this is a fantastic facility here at Microsoft. I'm really impressed. If you're in the Bay Area, AWS also has a community facility.

It's called the AWS Loft. It's at 925 Market Street. It's just over there. And we're open weekdays from ten till six. You can walk in, talk to an AWS expert, an architect.

We have boot camps and training sessions and sometimes we drink beer and listen to music. And I encourage you guys to all come. So that's it from me. Thank you guys so much for listening. I hope the math wasn't too scary.

Happy to answer questions during the break. Thank you very much.