Modernizing Red Hat’s enterprise developer program

Joe: Thanks for joining me today. I want to talk about what's been a two-year journey working with Red Hat on their developer program. So I'm the product manager for developers.redhat.com, that's the primary artefact of Red Hat's developer program. So they do events, and they do a lot of other things online, but that site is kind of the keystone that holds everything together.

Red Hat's had a site for developers for the last 11 years. This is what that primary artefact looked like in 2008, shortly after Red Hat purchased another company called JBoss, you may have heard of, who makes a lot of middleware applications, big on Java. And on the site, we went from informing people that Red Hat thinks about developers and that a program exists, to a few years later, telling a product story. By this time, Red Hat had gotten the OpenShift platform as a service, and then started a blog for the program in 2013. Then by 2016, there's still these four major areas of the company, big product silos, and each one had their own motion for talking to enterprise developers that use their work. The idea in 2016 was let's pull this together under one roof, and talk to enterprise developers with one voice across all these different products. And that's the Red Hat developer program. This was the brand that we used at the time to communicate with that audience of about 400,000 members. This is what I saw on the web property the day I started at Red Hat, December 18th, 2017, which is not too many days from today, being two years ago.

The program was historically for SIS admins, DevOps focus, there was a lot of activity there, developer adjacent, but serving up a lot of things for no cost evaluation for development purposes, things like that. On top of that, there was a deep developer affinity for the JBoss family of products, but not so much an affinity for Red Hat proper. At this time, the main work of the site being done here was access to bits. Let's get that trial, let's get that download. There were some links out to valuable documentation. But job number one was that delivery of bits. Then there was some community blogging added, some gated books and a dash of product marketing.

Let's fast forward to now, two years later, and let's talk about the results of what's been done in the last two years. Here's a page from the site today offering Getting Started materials for Red Hat's productized version of Apache Camel. This page combines content types, features multiple CTAs, has a developer specific value proposition, offers a discreet hand raise to sales, is mobile responsive, highlights all the upstream projects that make up the productized product, and has a context around of information architecture that does not rely on prior product knowledge. All of these things I just described are completely new to the property in the last two years.

Some high level numbers. For MAU (monthly active users) that means a registered program member who performed an action like logging in, or downloading a book, cheat sheet, product, this growth has been extremely strong. November of this year was the best month in the program's three year history. With regard to signups, we've done in three quarters of this year, what took us four quarters to do last year. So, that's working well. And time to publish, this is like not a thing in the startup world, but in the enterprise world, it's actually really hard to put stuff on the internet sometimes. That 83% is kind of a joke, because the way it used to work is we would hit the publish button, and then an hour later, depending on caching, things would hit the live internet. So When we took that down to less than five minutes, we could say, "Oh, 83% improvement on time to publish". But what that means is just what everybody else expects when you hit the publish button, which is that it goes on the internet.

So those are some results up front. I could stop right here. But actually, the question is, how did we do that? And it's a really long story. I want to skip around a little bit, I can't quite tell it in chronological order with the time that's available. And I think this way of presenting it also makes it look a lot smarter and more intentional than it maybe was at the beginning. But what I've brought for you today is some insights about looking back over that two year period. What I think were the factors and how we did what we did and how you might be able to take some of those ideas into small, medium or large organizations. So, just being apropos with where we are, we can be a little timey wimey here, and mess up the timeline and how all this stuff worked out. I'm going to take you through these six ways that we did this modernization. Six things to remember when evaluating your existing program. I think symbols and images are easier to remember than just endless slides of bullets. These six pictures mean nothing now, but they'll make some sense in just a minute.

The first thing to know is to know who you're actually serving. When we kind of started out, we had this broad, almost sort of generalized idea of the maker. And I think the maker is an interesting concept to discuss. It includes all these different groups. But a maker is someone who puts their hands on the products to solve their personal and professional challenges. Now again, in startup world, where you're doing B2C directly to the developer, this is not a shocker. In enterprise, though, that's not the person who's buying most of this stuff. An emphasis is required to keep telling the story of who the maker is. What we're doing, why we're doing it, is for the people who actually put their hands on the product. And I say personal and professional, because personal, these folks want to advance their own skills and abilities. And then professional, they have goals that they want to meet in their own career. I don't like the word user. I think user is an extractive storyline about who these folks are, and indicates that they're taking something from us, but a maker is someone who builds. And the goal of doing DevRel is to try to join them on that building journey. Because they're going to build with lots of different tools and technologies. Your hope, your aspiration is to be able to join them in that building process. If we're lucky, we get to do that.

This quote from Andy Jassy is a big one from us, for us, we keep it in the forefront of our minds, and you know this story. It's the story that, it's a B2C world for developers now, not a B2B world. We think about that a lot. And when we talk about who we're serving, I don't know if you know who this is, but this is Ginger Rogers. She was one of Fred Astaire's dancing partners, perhaps the most famous of all his dancing partners. A colleague of mine described enterprise developers as being like Ginger Rogers, which is, compared to their startup peers, they dance backwards and in high heels. She had the tougher job than Fred Astaire, because she had to do it all in reverse. The heels, for the enterprise developer, are security, scalability, and legacy. Those are not things that a startup developer, or necessarily an open source developer, has to worry about. But in the enterprise, these are very tough jobs that the enterprise developer has to think about.

If we start honing in a little bit, what you might know about Red Hat is that we facilitate this marketplace. There's people in the upstream, in the open source communities, building a lot of these technologies, and then it's Red Hat's job to take that technology down into the enterprise and help that enterprise developers be successful. It's the difference between the people who build the technology and the people who build on the technology. So we're starting to hone in, not just the word developer, which can mean a million things to a million people, enterprise developer and the enterprise developer that builds on top of open source technologies.

To get even more specific, in the Red Hat world, we know that this person is more than likely an enterprise mid-career Java developer. Java is not a new thing for them, they've been doing Java for a long time. When you're in the big banks and you're in the Telcos, Java is what they're using. Marty Cagan of Mind the Product fame says that the way to make a great product is to fall in love with your customer's problem, not with your product solution. That's how you make something that's a product that people want, not something that people don't want. And the problem for this enterprise Java developer is that coding on Kubernetes is actually extremely difficult. It's a big change, a lot of platform change, and a lot of new things to learn. Meaning there's some anxiety and there's some concern there for that mid-career enterprise developer of "Jeez, all this stuff is changing, and how am I going to adapt and stay relevant in that world". So honing in even further, Java on Kubernetes is kind of the sweet spot that we've decided to focus on. Enterprise Kubernetes developers, enterprise Java developers - it's the person who's considering the jump that our program has tuned into to try to serve. So, first thing to remember, fall in love with the problems of your audience. I like to say member because I feel like if you're running a developer program and you're inviting people into the program, there is a promise, a compact there, between you and the developer that you've invited into that program. It is a membership, you are providing something to them. They're not a user, they're not a taker. Audience is a little more passive, members on the other side of the line where someone is actively engaging with you. That's your first takeaway.

The second one, I believe, is to know what you stand for, what your core principles are. Why does your program exist? Why does it really exist? Not just to drive sales, you have to go deeper than that. This is an example of an exercise we did to start thinking through on what are our core values, what do we care about, and what's the purpose of the program being here? It can't just be a picture of a dollar sign, it's got to be something more than that. What we came to, is that for organizations big and small, it can't just be about what the org needs, it's got to be about what the people in the program need. Now, most things are typically weighted towards the business, towards sales, I get that. But if you're in DevRel, and if you're on the team that's advocating for developers, you've got to provide a counterbalance to that. It's not to say that that's not what pays us all, got to pay us, got to close the deals and stuff, but who is the voice for that developer in them getting what they need to move forward in their career, it has to be you.

What we came to is that our program exists to empower that developer along their journey. When you're doing a purpose, you want something really clean and clear. You saw version a minute ago, that was like a big paragraph, lot's of aspirational words, that's all good and well. But this line right here is crisp and clear, it's in simple language, it's big and bold, it has an 'aha' effect, it comes from the heart and it's not about money. You want to think about what that purpose might be because this is the thing you're going to align everything else to.

We learned this model from an excellent agency called New Kind that we worked with. We realized that if we start with developer empowerment as the base, and then we start thinking about our personality of how we look, how we act, how we sound when we communicate to our audience, that gives us the foundation for a brand story at the top of that. This is the story that we use, this as the tagline that we use now, 'Build here, go anywhere, with Red Hat developer', and that's kind of how we have this stuff oriented. But this has been incredibly useful for us to remind ourselves. At one point, I had this printed out and taped on my monitor near my workspace. Every time I was writing a piece of copy, every time I was deciding what should go on a page, I was looking at this to remind me why are we doing what we're doing. Think about the personality you want to deliver with that purpose, and then that builds your reputation. Reputation and brand mean the same thing.

Next up, signal change. You have to give outwards signals, especially when you're in a turnaround or a reboot, that something has changed. A friend told me this story once about a small town where a new mayor was elected. The first thing he asked the city manager to do was to go out to the maintenance group and make sure all the city trucks get a fresh coat of paint, clean decals and repairs as many dents as you can. The city manager's thinking what a waste of time and effort this is. But what he doesn't realize is that, as these trucks roll around the city, citizens are seeing them and saying to one another, "Wow, this new mayor's really cleaning up the town". So this buys the mayor a solid 90 to 100 days to focus on the real work to be done, and it tells the town that something new is happening.

The mark we had in 2017 was a bit symbolic of an earlier, say closed perspective in the company, an inside out view about what we needed, and not what the audience needed. We wanted to move forward with something more developer centric, something that reflected the reality of that membership. We went back and reminded ourselves who we were speaking to, that every developer's familiar with layers and lines of code, the blocking, the stacking, the indentation, the alignment, and there is a shape, a universal code block, that all developers recognize, it doesn't matter what language they're in, you can see that abstracted in the IDE at the right. Everyday's work is a portion of that endless river. Our program is a part of the story inside that river of code. We came up with these personality aspects for why we were going to do what we were going to do, what the brand stands for, and what the reputation is. This is the mark that we went out to market with.

We also wanted to start tackling our first round of swag with this mark. We did this deep cut and started thinking about like the history of computing, thinking about how our audience really loves a good puzzle. We started making these symbols that went on all our merchandise with no key or language to decode them. It was this test inside the group that if we put this out, how long will it take for someone to come up to us be like, "I know what that means"? It's about reorienting things and putting that fresh coat of paint on everything. We actually went to our first big show with these, and they were a big hit. So, paint the trucks.

That said, you can't just do that. You have to back that up with visible outward signs. The visible outward signs had to be backed up with real behind the scenes change. That brings us to this fourth thing, which is you have to make a place. You can't just clean up the town, you can also make a new one. This is a map drafted by Walt Disney when he articulated his vision for the first Disneyland in California. And if you don't know the story, Disney laid out the park in order to create maximum discovery for attendees. That radial design in the center was to prompt exploration. No area of the park was to be inaccessible from any other area. This was experience design. Creating a place for people is no different when we're in the digital sense.

This is a quote from Christopher Alexander. He's a famous architect and writer. It was a turning point for one of my colleagues, David, who began to lay out the vision of our placemaking on the site, our information architecture. "We wanted to create a place for learning, not a place for teaching". We decided that our IA was going to be placemaking as much as any other thing. We changed our story from products to technologies. You don't need to know our product names to go on the site to be successful in finding what you need. Because of where we were positioned with the developer audience, it was a mistake to assume that they understood Red Hat's huge product portfolio. Instead, orient around the technologies and the upstream projects these folks already know, and they would find their way to the products. Show, don't tell. The navigation is the brand. That's a thing that not everybody really thinks about. And we decided to just kind of look at the best content we had and figure out the best way to present it.

This is what we actually went out with in spring of 2018. And this may not look like much, but when we launched this strategy, it was a huge gamble, internally and externally. There was a palpable unease from the product teams about where is the product story on the front page of this thing to developers. We didn't know if it was going to work. I already spoiled the ending at the beginning and showed you that it is working. Every time I get someone coming to me going, like, "What I really want is product X, right here up on the top". I go, "Let me show you these stats of how it's been going for the last couple of years. This strategy is actually working" and "They're like, hmm. So then you say, well, what's the thing you're really trying to talk to this audience about? Oh, what I want them to learn is this." And I go, "Okay, now we're in business. Let's take that idea and bring that idea forward. And we will get them to your product eventually when the time is right".

We knew that developers think a lot about problems. That's why we did this, we started fronting different kinds of content. And again, this is timey wimey, so I'm doing it all out of order. This did not happen initially. But we started doing some placemaking on a pilot series of content bundles that were wrapped with some storytelling about a developer working inside a fictional theme park. We would give them these complex tutorials and assignments with a lot of materials, and start stacking these tutorials together inside this storytelling framework. We did this place making online and in person. Coderland got a portion of our booth at Red Hat Summit last year. It was the first content campaign we'd ever done that had crossed the physical and the virtual together.

For other events, we make the Red Hat developer booth a place for our audience is in the spotlight as, again, those heroic makers. In these booths, attendees get different mythological creature T-shirts from each of our four demo stations. And the tagline is Create Legendary Code. And we'll talk about why that matters in a minute. But we wanted to make a place where these folks are heroes, not us, it's not about us, it's about them and what they do and what they create. Think about the places that you're making, and how to craft them by choice, both online and offline.

That brings us to journeys. Speaking of heroes, our fifth way here is to think about taking that hero, or that developer, on a journey. Now, all people want to be on their own journey. Enterprise developers, just as much as anybody else. If you know Joseph Campbell, and the hero with 1,000 faces, this is the plot of every film that makes a ton of money at the movie theater. Star Wars, Marvel, DC, all of it, even indie films, where someone's not sure what they're doing with their life and where it's going to go, that is the story that they are on over and over again. The wizard shows up, they get the supernatural aid, they have the trials, they go away from home, they come back home. It's really good stuff. If you're in any kind of a storytelling role, or you're thinking about how to lay out your content along a story, I highly recommend taking a look at that. You can see that that quickly starts to line up with the things that we have to do in the developer program.

We had great success in starting to map out the journey for that mid-career Java developer who's learning serverless. What are their way points along their journey to understand DevOps? What are the offerings that we have in Red that map to those different stages of their understanding? And what stories across the top do they tell themselves about themselves, about their work, about their world? Then across the bottom there, what content are we going to create? And we may know all the steps in that journey now. But then there's going to be future steps that we don't know yet as the industry emerges.

When you dig in on that, another tool we had was this content matrix. The prompts on the left are a way to stir your thinking and content you might want to create for that developer as they're going on the journey. Then across the top, you've got content types. You might be thinking what does someone need early in the journey? They're just trying to understand what it is, right? So we're going to do 'What is X?' And we're going to think about that as an article, as a video. What are we going to do on social to teach people about what X is? And then what do we do on other community locations? The green one is bolded, because if you're starting from scratch and you have nothing, that's the first one to make. How to do this on this. That's the first one. Another thing to use is the awareness journey. If you've never seen this before, there are moments of truth along this journey, where someone is moving from left to right, and they have a moment of proof that tells them, holy cow, I think I'm on the right track. Google it.

There are many doors into these complex topics. What we're trying to explain to developers in a lot of cases are abstractions, right, lots of abstractions. It's really difficult to just force feed people documentation on these abstractions. You need to put some storytelling around it, and you need to recognize there are many doorways into these concepts. Just because you built one, doesn't mean, just because we're humans and we think of everything linear, that there are not multiple ways through that bundle of content.

That brings us to our last one, which is to optimize your publishing motion. This is a compound mill engine here in London Science Museum. The serrated ring around the wheel provides grip to rotate the main engine. The engine is a flywheel. It's a device specifically designed to efficiently store rotational energy. Each tooth provides a gripping opportunity. When you're running a DevRel program at scale across many locations, digital, online, grip is everything. Your job is to fix the broken gears and teeth, even if you can't see the immediate result. For us, we've had a very complicated process to make that big red wheel turn. On this project, we had a lot of challenges. We had two CMSs when we first started out, Now we've kind of combined those into one thing. This is a two, maybe three year process to get this all completely done. That's enterprise for you. But what we're there is trying to optimize the motion of that flywheel.

Another thing that we did, was we started thinking about our site in terms of spoke and hub. We actually went out and optimized content on other Red Hat websites, other author personal sites, and across all of our social. One interesting idea we realized is that each of those social locations is an alternate browsing method for all of your content. If someone never even makes it back to you, think what would I tell someone who's on that journey, just on YouTube, and just curate everything there in that same way, as if they never found their way back to you. Now you put links, you hope for it, but maybe you're not going to get it. These are all small compounding changes. When you're up at like 11 o'clock at night, and your spouse is watching TV and asking you why you're not in bed yet, and you're optimizing SEO titles, it can feel like this is not going to go anywhere. But it's compounding interest as you make these small changes.

Mobile layouts. Google is prioritizing layout of sites with excellent mobile optimization. As you do all these different things, these changes compound on top of each other, and it builds a virtuous cycle in your publishing. Now, you may not have a lot of volume, but if you can get your ops right to do that stuff as you're going out initially, it pays huge dividends. Nobody really talks about that optimization of the publishing motion, but I think it's pretty important.

Doing all this, if you know Charlie Chaplin's Modern Times has a famous scene that feels very apropos to this work. It has been quite a ride to tune this thing, and sometimes you feel like you're inside the wheels of the machine more than anything else. Our six objects, they look like objects, are in fact these concepts. And there is no correct order, you can't do it all at once. It is not easy. Stay true, have heart, you can make it through.

Finally, big thank you to the designers and developers on our digital experience team. This is the result of a lot of hard work from a lot of people. Peers, mentors, colleagues, advisors, the folks in blue worked directly on the program full or part time. And that's it, thank you.