June 20, 2019
Ep. #41, Simplifying Developer Workflow with Paul Biggar of Dark
In episode 41 of JAMstack Radio, Brian is joined by Paul Biggar, CTO of Dark. They discuss improving developer workflow in the JAMstack, as ...
Hopefully this is going to be interesting to most, if not all, of you. I think I'm pretty opinionated when it comes to content. I often am a black sheep on a lot of things like content panels and event panels and whatnot.
Just to give you a little background of who I am, right now I work at GitHub. I focus pretty much exclusively on our events program right now. I've run our entire outreach program in the past. That includes our outreach to government, open source, education, just our general developer marketing.
I've been an open source advocate. I've spoken at a lot of conferences for GitHub. I did the same thing at New Relic. You might have heard of New Relic. It's an applications performance monitoring company. I started there as a developer evangelist after taking a break from being the engineering manager and CTO for a long time, at an ecommerce company you've never heard of.
I built out a great program around events and content and developer advocacy at New Relic. As the person that runs events right now, what that means is I don't do the logistics. I don't plan where the bathrooms are and things like that. I really work on a lot of our content.
I work with the developers, our future speakers. I write a lot of the keynote speeches for our CEO, and things like that. So I'm pretty familiar with thecontent space. I do a lot of writing. I'm one of the keepers of the GitHub voice, at this point in time. I get too many pings to edit at this blog, or edit this thing, I don't have enough time to do all of it.
I've also been very fortunate. I've been part of a great set of people. We have copywriters, and we have customer advocates and whatnot. This isn't just me that does all of this stuff. There is a whole suite of people.
I think a lot of you come from very small companies, so hopefully at some point in time, you will have a whole suite of people helping you. But hopefully stuff we can talk about today will eventually get you to that point, where you've grown those things.
Why does good content matter? Why do we even care about good content? It's a huge, huge time sink. How many people have spent 30 hours writing a blog? It takes me 40 to 60 hours to write a good conference talk. That's from once I've done the research and want to put the slides together and write it all. That's probably a week and a half's worth of real work. It's a huge time sink.
But it matters more because of what it provides. Content provides a lot to the company. A lot of you are probably using it for lead generation. How many people use it for lead generation? Half, I'd say. Is that the primary reason you do it? You can speak up, it's cool. No. Good. So we're on the same page already. That's great.
One of the great things that we do, one of the great reasons we create content, is to create super fans. That's what we call our most championed advocates that we empower at our company, at GitHub. What they do is create more customers and those customers create more visitors to the site, and those visitors tell their friends to come see the site.
It's this network effect of bringing more and more people to GitHub to learn about it, to learn about the community, to learn about what the platform does, what our tool does. But we want to start with super fans.
What's really important that you have to understand is your customers are going to go through a whole series of experiences. You start with somebody who has never heard of you before, the stranger. And you want to work them all the way to become a super fan. You need to do that in various different ways.
Strangers, you just need to get the word out. You just need to get in front of them in some way. You might be using social campaigns for that thing. You might be doing a billboard on a street for that thing. It doesn't matter. That moves them into someone that comes to your website and understands who you are. Eventually they sign up. Hopefully they sign up and become a long-term customer for you.
Once they become a customer, how do you delight them and turn them into a super fan? This is important, because you need to understand what your content is doing. Is your content for a stranger and you're trying to reach people? Is your content for a visitor, and you're trying to turn them into a user? What are you doing and why are you doing it?
If you're just writing a blog to write a blog, because you want to put it on social media, then it's going to be voiceless.
It's not going to know who it's talking to. It's not going to know what it's for. That means it's probably going to meander. You're probably going to fight through it. You're probably going to fight with whoever else is on your team. Like, "This isn't good enough," or "This should say this instead."
One of the most important things you need to understand is who are you writing it for, and why are you writing it? Why is good content so hard? What makes good content? It's easy for me to stand up here and say "Write good content. See you later." That's not a very interesting talk.
What if you don't have a good writer on your team? What if you don't have a good conference speaker on your team? Where does content come from?
One of the big problems I've seen in content programs is that you're trying to create a false narrative. You're just trying to create content to create content. That's why it's so hard. Because you're not doing it for the people that you're supposed to be doing it for.
You need your content to be authentic, helpful, and human. What does authenticity mean? Authenticity means it comes from a place for the community. It means that you have their interest in mind.
It doesn't mean that "I'm writing this content, I'm writing this blog, I'm giving this talk so that I can get more users on my platform." You're doing it because it benefits them. You're doing it for their help. You're doing it so they get something out of what they're reading.
You think the writers at Bon Appetite Magazine don't love food? You don't think the producers at ESPN don't love sports? You have to come from a place of community. That's where authenticity comes from. You can't just fake it.
We hire content writers, we hire external collaborators, all kinds of things. But if they're not part of the community, if they're not a member of your community, then it's going to be a struggle. I get to say that because I was a 15-year software developer and now I write content for software developers.
It's easy for me to say that. I'm writing stuff for myself. If my friends don't want to read it, why would anyone else want to read it? But that's what's really important. So don't just write content to write content.Write content that's authentic and valuable.
What does it mean to be helpful? Helpful means that it actually moves your customer, your reader, your audience, to somewhere new. You give them something. You're doing it so that they are in a better place than they were before they started.
That's what helpful is. It's not a sales pitch. It's not a veiled sales pitch, even worse. It's literally, "I want you to improve the way you work." I want you to learn about a community. I want you to get connected with other people like you.
You want them to benefit from reading this content. And if you can't identify the benefit of your content, it's probably going to be a struggle.
Human. This is probably the hardest one to understand. When I joined GitHub a couple years ago, we have a phrase internally that's called "talk like a human." That's like the GitHub voice. I'm like, "What the hell does that even mean?" It's literally the least normative statement you can say about writing. But being human is important.
It goes back to being authentic, as well. Talk like you're talking to a friend. Read your content out loud. If it sounds mechanical, it's mechanical. If it sounds like you're talking to somebody that you're reading it to, it's probably fluid. If it doesn't make sense to them, it's not going to make sense to somebody reading it. So be human.
Remember that you are writing things for humans, that you are a human. These are really important. My handle is amateurhuman, so I care about this. Right? Be human about this. Don't think about your audiences, as some secondary purpose. Treat them as people, and they will reward you for it.
Good content is about being a great curator, more than it is about being a creator. It's really important that if you're authentic and helpful and human, you're actually gathering up content more often than you're not.
You're not trying to create artificial views. You're not creating artificial likes on Facebook or whatever platforms you want to use. What you are doing is you really want to be a curator of content.
When you publish things, you're reflecting your values. What does that article, that was a list of the ten best practices of x, y or z, say about you? Are those things important to you? Are those things important to your customers? Or did you publish it because listicles get lots of clicks? They're the best performing thing on your blog.
What are the values you have with your content? Whatever you publish tells the world what is important to you. For GitHub, and for my team, we have a list of values. We think about audience over self. Why are we doing this, and who is it for?
We don't want to do it for ourselves. We're not here to get something out of you. We want to highlight an amazing open source project. Because it's amazing, and we think it's going to improve the way you work. We want to show you how to use our product, because we think it makes your work better.
It doesn't have to be community-only. It can be about your product. But remember, it has to be why it's good for them, and not for you. People over technology: Underneath every technical problem is a people problem. If you've been an engineer at any current point in time, you know no technology problem can never be overcome if you can solve the people problem underneath it.
Behind every open source project is a team of hackers trying to add value to the world. Those are the stories to tell. Tell the people stories, about the struggles and humanity that exists there.
We don't empathize with code. We empathize with people. And you're trying to write a story for people. So tell that story. Don't tell about your product. Tell about how your product solves a human problem, because that's what we're doing, solving people problems.
Educate over selling. You don't want a sales pitch. No one loves a sales pitch.
I spent a lot of time on stage for New Relic. I never talked about New Relic, their product. You might have seen a dozen screenshots, in the couple years that I worked there, of New Relic's product. I talked about the things that the people that were buying New Relic cared about: application performance, browser performance, caches, CDNs, database tuning. Those were the things I talked about.
That's educating the industry on what matters and what matters to companies like New Relic. I was trying to express what we wanted to say to the world, not "Here's our thing. Buy our thing." Even in the times when I got the unfortunate curse of having to do a sponsored session, we never talked about that. We talked about DevOps. We talked about modern collaboration.
Don't sell. Educate. Teach people about your product. Teach people about their industry, that's why they're there. They either want to hear you talk about it in-person or they want to read your blog post about it. They're not there to be sold. I think everyone in this room probably knows that. But don't forget it. Don't let it slip out of your mind.
This one's really important to me. Amplify over boosting. Don't tell the world you're the greatest X. There's no better Y in the world. Let other people do that for you. Amplify their work. If someone writes a great blog post about you, do something with that. Don't stand on your stage and say, "New Relic and GitHub are the best code collaboration tools in the world." No one wants to hear me talk about myself for a really long time. At least I don't think. You want to really amplify your community.
People are probably doing great things, your customers are, your open source communities are, in the case of GitHub. All you have to do is take that and then do something with it. Blog about it. Interview the person that gave that talk. What else could you do? How could you amplify the work that is being done by other people?
That ties very closely to something I'm just really passionate about, diversity over consensus. Lend your voice to people that are usually unheard. GitHub is very fortunate that we have a very large voice. We say something, and a lot of the industry listens. So why can't we lend our voice to people that are traditionally unheard?
That's really important. We want to hear what other people are using, what other people are doing. And from what they're doing, why they're doing it. We want to elevate them and amplify their voices, versus just talking about ourselves the whole time.
One of my favorite things that we did at a GitHub conference is Michael B. Johnson, who's the head of R&D at Pixar. He's a filmmaker. He builds tools for filmmakers. I pitched the CEO, "This is going to be a great talk. It's going to be the best one at the conference, I guarantee it." Lots and lots of naysayers who are like, "He's a filmmaker. What is he going to tell us about writing tools and writing software?" I'm like, "Just give it a second."
He spent 30 minutes talking about how Pixar isn't the best at making movies. They're the best at finding problems. Pixar doesn't have the best filmmakers in the world. They just know how to identify a problem in their story so early on, that they can stop, fix it, and keep going.
There are so many parallels to the way that Pixar makes a movie with how we make software that it blew the minds of the audience. But we wouldn't hear about that if we didn't think, "Well, let's look somewhere else."
Where are other people solving the same problems that we are, in other industries?
Filmmaking. If you think anything that's been done in Agile is new, you haven't seen what the Japanese did with the automotive industry 45 years ago with William Deming. Agile is not new. It's just repackaged. Get ideas from elsewhere, and share those. We're telling human stories, and so how can we do that?
How many people have built good content and then tweeted about it and then just waited for the cash to roll in? There's that blog, there's that tweet, kickback. It doesn't happen, right?
Some marketing books will tell you these things, seven different times for an audience to respond to your message. So you have to tweet at them seven times, or you have to give a conference talk seven times, or you have to give some combination of a video clip and a trade show and a meet-up, and having them come to your office, and then receiving a newsletter from one of you.
The blog post, tweet combination is not going to deliver anything. It's going to get you some things, but it's a flash in the pan. Hundreds of tweets go by every single day that I never read. I haven't even looked at Twitter all day today. There are a thousand of your different tweets that have gone by that I'm not responding to.
You have to start thinking about how you can take your content and repurpose it in multiple different ways.
This is a slide I talked to my team about a lot, how do you take a single blog post and turn it into 20 different opportunities? How do you take a blog post that we wrote, open source licenses on GitHub, and the current state of those things. Turn them into videos, conference talks, a content portal, a blog with those videos and conference talks.
I think what happens is we get distracted. We run away with, "Oh, cool, I gave that talk, did the blog, did the tweet. I'm done. I'm on to the next thing." But how can we keep re-purposing them?
Here's an example. Ben Balter, who's on my team. He's the government evangelist, so he talks a lot about government using open source. He also cares a lot about licensing. We wanted to care about licensing. We'd gotten a bad reputation in 2012, 2013. There is no code that is licensed on GitHub, and it was just the wild west of code and unlicensed software, and all of the traditional open source advocates of the world are angry at us.
We're like, "Cool. We need to figure out how to fix that. So how do we start to tell stories that remind people that we're starting to fix that?" We wrote a blog about it, did some research. We tweeted about it, nothing too special. It got, what is that, 194 retweets? That seems good, pretty average for a GitHub tweet.
He gave the talk at OSCON about it. He put those slides on Speaker Deck about it. We created an entire portal around how to choose a license and what the different licenses mean.
We were lucky. We have a really great PR team. They got us into some articles, so ITworld covered it, Opensource.com did an interview with Ben. Sometimes they don't get it right, no matter how many times, they missed the point. No matter how many times they saw it, they still missed the point.
But content is adaptable to the media. You can say that the medium is important, and a blog post should not be the same as a tweet. Your blog post title shouldn't be your tweet, for example.
We used to do that, very lazy content marketing. But every piece of content can be adapted into one of these 20 spaces, right? You can have a blog post, and it can turn into a video. And why not take that video and take clips out of it? Send that as a newsletter for some of your customers that have signed up, to hear interesting things from you.
Good content is adaptable. Bad content is not.
Bad content's like, "Cool, I made a tweet. Why can't I repurpose this?" Well, because it's probably not very good content. You're not thinking about who is the audience, and what are they trying to get out of it? What are you trying to do with it? How are you trying to move them along?
A couple things I want to leave you with as we walk through this. There's a bunch of things you need to remember. One is, a blog and a tweet aren't going to get you anywhere, because it is a flash in the pan. Your message needs to be seen seven times, and that can be multiple tweets. I don't have any problems with that.
If I've written a blog, I've already done all the research, and now I just need to produce some slides. Even if I never give that as a conference talk, I can still make the slides. It's still consumable in another way. If I make a talk, why can't I just write down exactly what I've just said? If you look on the Heavybit website, you see all of the content from the talks are transcribed. That's great additional content.
How can you take any piece of content and turn it into seven different things? If you don't start out with that in mind, you're probably not going to get there.
You're probably going to forget to do it. Sit down. If this blog is going to be these seven things in the future, you need to be authentic, helpful, and human.
I think this is probably the most important one on here. If you are not authentic, if you don't come from a community, don't just try to create false content. It's doesn't help anybody. It doesn't help you. It's going to burn 15 hours of your life. Its not going to be useful for your customers. They're going to stop listening to you when you say, "Here's this 10-piece article," or whatever. Be really authentic. That's hard to say.
I'm lucky. I come from a developer background, so I can sit and write content that is applicable to the developer. But if it takes training, if it takes education for the people writing your content, then give it to them. Get them partnered off with someone in your organization that does know how to talk and think through what it means to be authentic.
You need to be a part of your community. The way you sit and figure out what is interesting what is not interesting. What the industry is talking about, is just being there. There is no magic formula. There's no algorithm I can run to say, "Well, here's what's trending." We have a trending page, but that's not actually what people are talking about. That's just what people are starring on GitHub that week. And that's okay.
I can highlight some of that. But what are people really talking about? What are people talking about on Twitter, or what are they talking about on Hacker News? What are they talking about at conferences? You have to be a member of the community if we're going to do this right.
You can't sit back and say, "Cool, we're going to write these scripts, and they're going to sort out all these problems. They're going to create our great content plan, and then, cool, we're going to sit back, and we're done." You have to be there.
Amplify the work of others. If you're not a good writer, if you're not a good public speaker, amplify the work of people that are.
I guarantee you there are people talking about interesting stuff in your community. If you're a CDN, there's somebody talking about CDNs in the world. If you write developer tools, like GitHub, if you write a collaboration tool, then write about what collaboration means. Talk about Conway, talk about Code Review .
Even if it doesn't mention your product, let the world know that this is an important thing that they should be thinking about. And get some free press that way. You don't have to do all the work. I think we try to do all the work ourselves, and that's probably the biggest mistake. Amplify the work of others.
I guarantee that there are smarter people in the room than me, so I should amplify their work. And I guarantee there are smarter people in the room than you. And so amplify other people's work. A lot of that has to do with being humble. Don't talk about yourself. Don't boast. Don't celebrate your successes. Let other people do that. Give them a platform in which they can.
Write a case study, do an interview with your customer that just absolutely adores you. Invite a customer to speak with you on a stage. If you have a tradeshow presence ever, have a moment where people can meet other customers in your booth. Have a meetup with customers. Let other people do the work for you, and don't talk about yourself.
If you're trying to write for multiple audiences, then you're confused why you're writing it, because you're not going to be able to get out your message clearly to any of them. If you have to dumb it down, then it's not valuable. Just assume that developers are the smarter ones in the audience. If you have to dumb it down so that it's less technical, so that an investor can understand it, that means the developer is not going to care enough about it.
If it's too technical, then the investor is not going to do it. I don't like multiple-purposed content. We just did a major pricing change. You might have seen that a few weeks ago. We spent months talking about what emails do we write, what blog posts to write. Who are we writing it for?
It became very, very clear that we needed to write for our user. We're not trying to get a press article out of it. I would write a blog differently about a pricing change if I was trying to get a press pickup for it. We needed to talk to our users and tell them why this is amazing for them and why we did it.
We needed to focus that down, even though we had so many people we could have written a pricing change for. You can write multiple things. There's nothing wrong with that. It doesn't hurt anybody. People aren't going to unsubscribe from your blog. That's like, "Wow, there's too much traffic on this thing."
It's highly unlikely you're publishing enough to freak people out in their RSS readers.
I think you stay focused on a single audience, and you stay focused on a single purpose, whatever that is. If you're informing them, educating them, celebrating them, delighting them, pick one thing, and pick one audience.
"How do you measure success?" We actually had that conversation over dinner. Success is hard. There are things that are measurable, and then there are things that aren't. You have to recognize that, the things that are measurable, measure them. Blog traffic: measurable. Tweets, re-tweets, things like that: measurable.
But that isn't the whole story. If you're touching somebody seven times, and the thing that they clicked through and signed up for your product on was a tweet, was it because they saw that tweet for the first time? Or that they saw you give a conference talk a month and a half earlier, then they read a blog about it three weeks after that, and then they eventually read the tweet that mattered and clicked it.
You're going to give credit to that tweet, but that's probably not fair. That's probably a half answer, I understand that. But it's important to recognize the things you can measure and know that they're not the entire story.
Know that you have a gut. I say this a lot to my team. In very large organizations, let's say the Oracles of the world, maybe data is the only thing that matters to them. But in small organizations where we're trying to move so fast, I can't even get metrics put into place half the time by the time I need to do the thing. So we have to use guts, and we hire people for their gut.
We're experts at the things that we're doing. Trust those, and allow them to succeed at that. If you have a content writer on your team, is their content succeeding? And are you going to measure them on that? I don't know, that's a tough one, to say that "Your content just doesn't produce as much as Billy's," you know? And so, sorry, you're out. Is it because the content wasn't focused? Was it not the right content? Who's deciding all those things?
There's so many factors that go into what makes a good topic. Did you publish it at the right hour of day? All of this stuff is so theoretical, and so much talked about. Make sure you publish & send those emails before 8am Pacific, because they have to get into inboxes before people get busy, before lunch on the East Coast.
It's just not possible to track all of that stuff. So measure the things that you can, and just be respectful that that's not the whole story. Especially when it comes to building a brand and a large messaging platform. You can't measure brand. If you're the experts in application performance, then how do you measure that? Sorry for the half answer, but it is what it is.
The different programming communities somewhat function differently. I'm a Rubyist by trade. I've been programming Ruby since 2009. When it really boils down to it, I'm not meaningfully different than a Python developer. I'm not meaningfully different than a Java developer.
It's hard, when you're not a developer, to know the nuances, and I'm not even an expert as, say, the Java community or the Go community. How do I know how to talk to the Go community and what they care about, versus what the Java community is caring about?
In the end, if you're telling people stories. I think that's what matters. Most developers don't care if their problem is being solved in Java or if their problem is being solved in Python. Great computer science books are written in multiple, different languages. Algorithm books are written in all kinds of languages. You don't have to know those languages.
What you're trying to do is solve that problem. You want to learn how algorithms are done and the theoretics behind them. That's why various computer books have succeeded over time. Think about talking to them as humans. What are their human problems that they are trying to solve?
We did a Python conference, an open source conference for the Python community. That one was not remotely successful. This was before my time. It was not remotely successful because the Python community just didn't communicate, say, the way the Ruby did at the first conference, which was wildly successful. You have to get in there and know some people.
Go to some conferences like OSCON, for example, and talk to some people that are Python developers, Java developers and Windows developers. And get in there and understand what they are talking about. It just takes time. You just have to put in the effort to learn about what the communities are caring about.
When I write just open source talks, open source is open source to Python developers, open source to Java developers. That's a human thing more than anything else. I don't have a great set of advice, sorry, to your specific question, but they're not as different as you think they are. Technically, they will scream and shout that they are wildly different, but in the end we're all humans.
I see some smirking, so clearly everyone has encountered this experience. In the end, we're all human, so talk about being human.
Most of the time, it moves from founders and early employers to engineers. Technical content is really popular. A lot of people like to see how the sausage is made. I think some of the most popular talks that GitHub gives are how GitHub scales. We'll pack a room no problem with that stuff.
We have a dedicated engineering blog, so start going into your technical expertise. That has two real benefits. One, technical expertise testifies to your product. Great engineers and great people, at any company, don't work for crappy products. It's just not the case.
Two, great people that work at companies want to work with other great people. So if you're trying to recruit, that's a way to do it. I would say get your technical content out. And then after that you're starting to look into community managers, once you actually have a community that's fostered around whatever product you have.
Community managers, product marketers are great as long as they keep in mind that a great product marketer understands that they're looking for an audience, and they want to talk to that audience. I would look to your product marketing team. I would probably not advise you to bring on a copywriter within the first 10 employees. You probably have a lot of other needs before you get into copywriting. A lot of that burden can be spread around.
But also remember, you can make content and use it 10 times. If you have a founder that has a great narrative, grab that and retell it over and over. Tell that story for six months. There's no reason not to. People aren't going to get bored. You're not going to be like, "Well, we already gave that talk, and it was on YouTube. So everyone's seen it." That's just not true.
I've given the same conference talk at five different conferences, and everyone in the room is new. So reuse your content. It's okay. I get bored after about four or five times, so I switch out my talks after that. But I guarantee your audience probably hasn't seen it, so go ahead and reuse it. Even if they had, it's not going to offend them. Start with that direction.
Don't dive into a content team too early. You have to be pretty big by that point in time, when you're wrangling editorial calendars and so forth. I think there's real value in those people, but you have great writers on staff just because your day job isn't writing. My day job wasn't writing. I still don't think it is.
I get this question a lot when I would talk to companies about building evangelism programs. You have to treat an evangelist like you would an engineer. Ben Balter, who wrote the open source licenses, he's an engineer. John Britton, who runs our education program, is an engineer.
They took some time to do something different. I did the same thing. I was a CTO that got burned out after 90-hour weeks for two and a half years, and I'm like, "I just need a break." And so then it became about how to convince, say, engineers or anyone that's a technical expert, to want to do these other things.
You have to treat them like that. You have to provide the career path for them. It's important that they get paid the same as an engineer would. They're just doing something different for a while. That means you value the content that they're producing. You really do. The same way that you value the code that they would be writing. And if you don't, you're mistaken.
The code that's underneath, it's just as valuable as the content and the marketing on top. Without either of them, you've got nothing. You have to treat them in the same way.
When it comes to finding contractors, that was really hard. The easiest way to find a contractor? Most evangelists that I know hate writing. They like talking. I don't know a ton of engineers that love writing as a format.
So what you can do is get your engineering team, for example, to find, "Here are the people in the community that you can interview about the product, or about what your ecosystem is." Do an interview system, instead of trying to do, "All right, give me a blog. I don't care what it is, just give me a blog." That just doesn't work.
I've stared at any number of blank pages in my life, just frozen. Something I like to do is do the interview with a technical expert. It releases their burden. They don't have to do the writing, because that freaks people out. But also it allows you to take someone who doesn't have the technical expertise in that area, to then translate those words.
Again, it's a human story. Tell a profile of somebody. Where did you come from? How did you get to be this person? Why do you care about this thing? What's important to you, and what's next? Five simple questions, an hour, hour and a half of an interview over some lunch, and you've got yourself a great blog, for example.
You can use contractors that way to do interviews with your community, with your own engineers and stuff like that. I found that interviewing people on the team is easier for people that are uncomfortable with writing.
I'm of the opinion that every technical problem is a human problem. There's a reason someone's writing that code. There's a reason why you're building that feature. Talk about those things.
I don't think you should ever write a technical post without writing about why it's being written. The "why" has everything to do with people. You don't just write code to write code, generally. You shouldn't. Probably a wasted feature.
Figure out who the customer is that you're writing that feature for. What is the team actually, if you are doing an internal technical post about, "We did database optimizations." Whose lives sucked before you did that work, and whose lives are better after you did that work? Include them in the story.
Don't just say, "Here are the 17 SQL tuning things we did." You know? "Oh, we doubled our RAM on these boxes, and it just improves our performance." Or, "We doubled our cache hit rate on our mem cache cluster." That's great. But I can probably find that on Stack Overflow, most likely.
If you want it to be valuable, tell the team the story on both sides of that. Who was it before it happened? Who was it after it happened? I don't think you should ever separate the two.
Participate. You have to go, the same way an engineer would have to go to a meetup and learn something about their craft. You have to do the same thing. You have to. You have to get out there and meet the people. Don't be afraid that the people that are there are way smarter or know something that you don't know. It doesn't matter.
I've never met somebody that's like, "Oh, you're not an X. Don't talk to me. I don't have time for you." I've never met somebody like that. I send my team to conferences. The production team that does a lot of the actual logistics work that I don't do. I send them to conferences so that they can help me understand what the content is that we should be building, as I'm trying to help them grow in their careers.
They go and meet, I help them pick out conference talks to go watch. And then sometimes I'll go with them, and we'll sit and talk about it after the fact so they can understand why this is important, why this is important.
You just have to be a participant in the same way that anyone else would that wants to be part of a community. You just have to go. It's a hurdle. It's hard if you don't have a language, but I think it's hard for someone that's learning how to code to do the same exact thing.
If you've never coded in your life and you want to get started, you've got to dive in. Just be a participant and get encouragement to go to conferences and meetups. I don't expect anyone that doesn't understand a technical space to sit and read a bunch of blogs. It's probably not that useful, because you can't ask questions. Go in a way that you can ask questions and have people walk you through it.
As a content creator, that also gets you tons of context. It's really important that you have a network of people to call on when you need an interesting idea, or you want do this one thing, or you want to invite them to speak at your event, or whatever. You need to have that network. So you do that by being out there.
I guess it all depends on the medium. We don't do a lot of emailing. I don't think we, almost ever, email you as a customer, unless you're one of our enterprise customers. But as a dot com user, we never email you, so we don't have that as an avenue.
So, how do we get in front of you? We used to think our blog is the end-all, be-all of that, but I think we finally got it into our heads that not everyone reads our blog. Tweeting is pretty popular with GitHub; it's the right community for that. But your community could be very different. The Microsoft community is not a very Twitter-centric industry or group. If you're in that space, you're going to have to find something else.
Videos: Right now we're producing a lot of custom content and videos. I can't ask you to do that, it's really expensive and really long. But those videos are probably one of our best formats right now. Our YouTube channel is pretty popular. We put all our conference videos on there when they get published.
Video's pretty easy. You can give a talk in front of a camera, and luckily the camera can't see all of you. But you could just fake it if you needed to at that point in time. But video works really well for us. It's an easy format to deliver in, as well. At least I think it is.