Made by
Made by
Mano Marks
Mano Marks, director of developer relations at Docker, explores the tension between advocating for and advocating to developers. He takes a look at how different business models and company approaches can shape how you approach your work in this talk from DevXCon San Francisco 2018.
Thank you. I actually don’t get on stage as much as I used to because I have a team of people who do that for me. And this is… it’s nice to get out in front of a smaller group of people. And next week is DockerCon, which I hope some of you are going to. DockerCon. No? Yes? All right. There’ll be probably 5,000 people. It’s a little thing. So nice to be here.
Okay. So the topic is “Who do you work for?” And this is a question that comes up a lot in developer relations, for some reason. Reasons which I will start to go into but it is not this conversation. This is a frequent topic of conversation in developer relations, it is a very valid one, where do you sit? Who do you work for in a company, marketing, product, engineering? That’s a very common question.
But for me, I’m much more interested in this conversation. And I put in consciously the word practitioner instead of developers because I work for a company that works with both developers and IT system ops people who often there’s a huge gulf between. So practitioners, people who are technical practitioners who use the product.
So who do you work for? It’s a tricky question, but it involves us figuring out what each of these groups of people want, and then figuring out our strategies regarding, “How do we position that?” And I’m not going to give you a clear answer, right? A lot of you would get up on stage and say, “I work for the developer, I work for the IT ops pro,” but they don’t pay your bills.
How many of you are in it for the sweet, sweet Developer Relations money? No? No? Okay, yeah, me either. A lot of you do this for reasons which I’ll get into later with more about your own motivations and earning more money than in another kind of role is usually not that reason. So, but that is one of the primary motivations for your company.
So I spent a lot of time over the last few years thinking about why do companies do Developer Relations products? And I thought about this in part because I worked at a company that for a long time actually didn’t know. I’ll get a little bit more into that in a bit but the point was it didn’t have a clear vision until much later. And I’m seeing a couple of Googlers and ex-Googlers smiling up at me. They know what I’m talking about I think. But I’ve identified sort of three broad categories of why companies do developer products, do practitioner-oriented products. And the first one and the most obvious one is actually the reason that they all do it, which is money. But there are three different ways in which they make that money.
And the first one is somebody gives you money for your product. This is a classic Developer Relations strategy. This is Microsoft, they earn… Somebody buys their product, and then they develop on it and then it… or, you know, then they come back and spend more money. All the infrastructure, providers, a lot of consultants, a lot of different companies represented here today probably earn money in this way.
I work for Docker, we’re an enterprise software company. I think it’s a nice clean way because your customers come to you and they say, “Hi, I want this thing. I will pay money for it.” And you say, “Yes, I will try and do that for you. I think that makes sense.” Or no, it doesn’t make sense because, reasons. But whatever that’s becomes the fundamental, in some sense, a cleaner transaction than something like users.
So this is a strategy employed by companies. And this was one when I… we employed at Google. The idea is that you create users of some other product through a Developer Relations strategy. This is the older Google, like Google Maps API, but also Android. You get out there and you make it, you incentivize developers for a variety of reasons to use your cool stuff and then they deliver users to you. So the Google Maps API was one of the first APIs out there that was like monster on the web.
And it’s, last I looked, and this was literally five years ago, they were on over a million websites, you know, a billion people were seeing them every month. It was just like monster. But when it started, it’s hard to remember back in 2006, the web wasn’t settled. It wasn’t like this is the thing and everybody’s gonna go there. You still had a lot of people who were building apps completely offline, still do, but this is, you know, back when the web was still trying to get there.
Google was still trying to make it, they were they were getting a lot of money, but they wanted a lot more, they got it, and then they wanted to make sure that there was content for people to find. So they provided APIs that allowed you, as a developer, to go out there and add something to your site. And the more sites there were, the more people were searching for sites, the more people got money. And this similar kind of strategy with Android, you’re protecting the search product, you’re getting a lot of people to use mobile search through mobile apps. Okay, I spent a lot of time on that.
But the last one is data. This can be Cambridge Analytica data about you, but this could also be like data about how our open source project works, or data on Foursquare, Google Places API, data on where things are in the world. It’s a lot of… it’s, you know, different kinds of data. I often bring up one product that Google had, which is Google Reader, which wasn’t strictly speaking a developer product but it encouraged developers to use RSS feeds.
And Google then looked at that and went, “Oh, okay, all these people are giving us their RSS feed so we now know where a whole bunch of stuff is so we can index it.” That was the reason behind Google Reader. And that’s why when they didn’t need it anymore, they cancelled it even though, much to the horror of probably every engineer still at Google and millions of people around the world, it was their favourite product, and it’s gone. And the reason was, it no longer made them money, it no longer served a purpose that made them money.
Okay. So practitioners, on the other hand, have a lot of different reasons than companies. They want features. Certainly, everybody wants something that they don’t have to build themselves. They want something that’s cool, they want something that works and will just work and they can count on it working and they want something that will save them money or earn the money in some way. It’s particularly like enterprise software, you know, and again, just to pay the bills. That’s what Docker does. We create products that let you save money on… the end costs, make you much more agile, blah, blah blah. We give you a lot of features, we help save you a lot of money. Come to DockerCon. Okay, I’ve paid the bills.
So this is the most critical understanding. When you start a job, when you’re evaluating a job that you want to do and this talk is mostly…and it’s aimed at you. This is about your planning, your decisions around your career, but also your decisions around what you do in the projects that you’re working on. And that is understanding this dynamic where companies want something, they want a way to make money and practitioners want something else, they want maybe a way to make money but they have their particular needs. Understanding what those two things are is where we live and it is crucial to your understanding, otherwise, you’re going to end up on a cancelled product.
Okay. Now I hear you saying, “I just wanna build community. I just wanna lead people. I wanna promote women in tech. I want to give out T-shirts.” All these things are great. And I’m not mocking any of them. These are really important things. These are you thinking about what you want. But, fundamentally, if you’re not giving either practitioners or the company what they want, and we all know what they really want, which is stickers. Sorry, Jono. Sorry, Jono. You got to incentivize people with things. I know you just said not to do that but that’s what people want. They want the T-shirts, they want the sweet, sweet stickers. Okay, so. And thank you to Mary, I think, who puts together the DevRel weekly. This is how I’m getting my quotes.
So, fundamentally, who do you work for? Only in developer relations do we really ask this question. Do you work for the practitioner or do you work for your company? And the answer is, it depends. I know that’s a weekend answer, but there’s a lot of factors that go into what makes up what you need to think about where you’re at. If you’re at a young company just starting out, their focus may be on data and users. Data on how well our product does, what people want, open source contributors. You just want people to use the things so that you can show that it has value. If you work for a young team at a company, you still have that same… you often will have that same incentive but your turnaround times are going to be a lot slower before you move on to another stage.
So company maturity, product maturity, how much adoption you’re getting out in the community, these are gonna change your strategies and shape how you think about things. And this, for instance, is big company, big team, somebody from AWS, very rightfully saying, “I work for you, mates.” I think, yes, mates, “I work for you, mates.” Because that is really important. That’s the position that you can take; you can be that voice of the user solely. You can be out there in the community just being like, “I heard about this great open source project and that one and you should talk about this and this is really cool and here’s how you can do it.” And that’s super important, but it’s a luxury that is often provided by being at a very large team.
So these are just things you things you think about. So this brings us back to here and figuring out how to bring these things together, figuring out where you live within these things. So here’s some strategies to think about. One is and I have to remind myself the order I put these in. Help your company understand why it makes the product. A lot of companies in the old days, and they probably still do this, will say, “We’re just going to develop this thing and then see if people use it. If they use it we’ll figure out a way for us to charge for it.”
That’s great if you have that luxury. That’s going to be very rare that you’ll come across that and, you know, once in a lifetime, probably. Most of the time they will… they may not know and if they don’t know that thing is not going to be around for long. And I’m saying this in this like, you know, heavy tones because what I really mean is that means that your job on there is not gonna be around for very long unless you can make that successful and you can keep them doing the things that they do. And it’s only going to succeed like Google Reader does, as long as it keeps serving that function. As soon as that stops, it doesn’t.
All right. So another thing is, be honest with your users about why the product exists. Not in a negative way, “My company only does this for this reason,” but in a way that helps them understand how much they can invest in it. And the reason I say that is you don’t wanna trick people, right? You know, it’d be like, “This is the thing, this is the next great developer tool. You should always use my new widget because this will be the thing that earns you a lot of money and it will be the thing that does all the features that you need.”
If that thing can go away, if the if the reason that some… they’re putting that out there is to make users, they will invest in it only so long as it gets some users. It’s not a bad thing. I’m not dissing that approach. I’m just saying, you should be clear with developers why, so that you help the company maintain its reputation.
And then and this is not in a particular…this is not like a priority order. This is… these are just strategies that you can adopt. You need to find ways in which to convince them that your team that’s changing the product or meeting the users’ needs helps them earn money more, whatever way it is. Helps them get more users, helps them get more data, helps them literally spend more money. And, you know, I think back to opportunities that I missed doing this 10 years ago.
And I think things could have changed a lot. And that’s a really important lesson for yourself too. Think back on… Because many of you in this room have been doing this for a while. Think back on when you could have done this and when it might have made a difference.
And then, finally, keep your integrity because this is the other part that we don’t talk a lot about, at least in my experience in the developer relations community. This is tech. You’re probably going to be moving on in two to five years to another job. Your reputation in that community, not to mention to yourself, is really important. So just being honest with yourself, being honest with your users, and not in a mean way, not like, “All companies lie, and they’re trying to exploit you.” All companies are trying to make money. We live in a capitalist society.
If you don’t want that, try and make a different kind of society. That’s fine. That’s a different job. And I’m not like some right-wing Libertarian or something up here trying to convince you, that I’m just like, this is reality, what we live in. Keeping your own integrity also helps you land your next job, whether it’s in that company, whether it’s on a different developer product, whether it’s in, you know, a different role in that company, or it’s outside the company.
And finally, within all of this, what’s important to you? And I kind of mashed this up a little bit like, the other ones are, I think, a little bit more straightforward because I don’t know what’s important to you. Everybody here is an individual rather than a statistical block of people. Everybody has their own goals, their own desires and they’re mixed up in a way that’s not necessarily like… I can’t go, “You know, in my career, the most important thing to me is X.” I don’t have that. Like from moment to moment it changes but there are certain continuing things, but there are many things in there that are important. So you need to think about what is important to you and how you steer this. You try and steer your company and your developers, how you provide that leadership and how it gets you to the next thing that you want to be doing.
So, of course, the answer to the question, oh, I went faster than I thought, to, “Who do you work for?” is: “You work for you.” You work for yourself and creating your own career, creating your own opportunities and you work for the company because they pay you and you work for the developers. But fundamentally, the most important thing to you is, I’m gonna guess, you and your family and whatever your priorities are within that. Okay. I don’t know. Do I have time for questions? Yeah. Okay. Thank you.
Audience member 1: I would like to hear your thoughts on how we’re able to effectively maintain integrity on the job when management makes a decision we don’t agree with but we wanna be honest with our users without going negative? Like are there particular ways to massage that conversation?
Mano: Yeah, that’s a good question. I have done things like write and rewrite emails 10-20 times. I put off make doing it. These are good strategies. Write this down, write this down. Procrastinate, yes. You know, it’s a fine line and it requires diplomacy and, you know, in a lot of situations… in most situations you’re there representing the company and you want to… you know, you want to express what are the things that they will actually benefit from this.
The flip side of that is sometimes you can’t, sometimes there really isn’t a reason and the most important thing for you to do at that point is to say: “This is the decision. We made this decision for XYZ reasons. You know, we require a log on to the site because, you know, frankly people were Bitcoin mining on our site and…” you know, random, random made up example. But, you know, you come up with the… you know, something that they can understand that is concretely and honestly part of the decision. You can’t always be clear with people why decisions are made.
I worked on a product for a while, while I was at Google, I was out there promoting it for a year and then was told that, “No, we’re going to build another product. You need to stop talking about this other thing.” I was like, “But you’re you haven’t built that other thing yet. So I’m just going to stop, drop it completely?” And I didn’t have a choice on that matter. That’s one of the situations where I feel like I could have fought back internally, at least I could have pushed back internally.
So ultimately, you are constrained by company policies. What you do with that constraint, whether it’s like, you know, you argue about it internally, you pick your battles, you go on, is another… it’s a whole other thing.
Audience member 1: Thank you, Mano. Thank you very much.
Mano: Thank you.