Jono Bacon

Introducing Jono Bacon

Jono Bacon is a community and collaboration strategy consultant, author of People Powered: How Communities Can Supercharge Your Business, Brand, and Teams and The Art of Community, a columnist for Forbes, and the founder of the Community Leadership Summit. His clients include Deutsche Bank, The Linux Foundation, HackerOne, The Executive Centre, and many others, and he is a regular keynote speaker about community strategy, collaboration, and organizational leadership. Find Jono on Twitter: @jonobacon.

Geertjan Wielenga: It seems to me that this whole profession has exploded over the last three or four years; would you agree with that?

The history of developer communities

Jono Bacon: I would. A lot of the work has actually been happening for a long time, but we now have a clearer understanding of it and the branding of it has changed. People have been building developer communities for as long as computers have been around. These communities were forged at universities and in local groups before the internet was around, but the internet has provided the ability for this to happen on a much broader scale.

Especially in the earlier days of open source, we saw developer communities forming.

I think what's happened, especially in the last couple of years, is that the value of a developer as a pivotal decision-maker in a company has become better known. Developers have gone from being seen as people with thick-rimmed glasses who build software and sit behind a bunch of managers to being a primary audience that companies want to target. Targeting developers through developer relations has become a thing. I don't think that the patterns have changed massively; it's just that developer relations has now got the attention of more senior decision-makers.

How developer relations is implemented differs very widely. In some companies, you've got developer relations people who are really senior members of staff, while in other companies, they are fairly junior and work in marketing or as individual contributors. We've got a pretty broad scope, but it's still early days.

Geertjan Wielenga: In what sense is it still early days?

Jono Bacon: When new professions form, in the beginning, companies don't know what to do with them. There isn't a lot of structure and predictability about them.

I'll give an example. Back when I started my career, in the late '90s, I always knew that I wanted to work in communities, but the idea of a community manager wasn't a thing back then in tech. It was around here and there, and there'll always be someone who says they were doing it before anyone else, but as a general role, it wasn't really a thing. I'd never heard of the term "community manager" when I applied for the Ubuntu community manager job at Canonical, for example.

Over the years, community management has become a profession, but at first, nobody knew where it should fit into an organization, where it should report in to, what the value was that you should see from it, what support you needed to give to that person, and so on. Since then, the idea of how a community manager in open source works has become much better understood.

I think we're seeing a similar situation now with developer relations. Developer relations, I would argue, in its current form in most companies, tends to be a bit more of a tech evangelism job. It varies; some people do more in-depth versions of developer relations, such as managing infrastructure and products, but, as a general rule, I think we're still in the early stages for this particular type of job. In the next five years, I predict how the job is managed, who it reports into, what kind of value you expect to see, and so on, will become more solidified.

Geertjan Wielenga: In my case, I came from a law background and ended up working as a technical writer. That's the kind of function you had in the late '90s that translates to developer relations today. In fact, on LinkedIn, I changed all of my job roles to "tech evangelist" or "developer advocate." That's what I was really doing; it just wasn't called that back then. Do you agree?

Jono Bacon: Yes. We see these patterns forming. As the branding and the market understanding of that role adjusts, you can then look back and say, "Okay, that's what I was doing."

"As humans, we need to be able to put things into logical boxes; that's what we're seeing, to a reasonable degree, with developer relations."

—Jono Bacon

I find developer relations interesting because I see it as a subset of community management. It's always difficult because every company is different, but we're all building engagement with people. Developer relations is about building engagement with a subset of people: developers. As humans, we need to be able to put things into logical boxes; that's what we're seeing, to a reasonable degree, with developer relations.

Geertjan Wielenga: If there's one characteristic that is common to all the developer advocates or tech evangelists that I've ever known, it's extreme flexibility. On the one hand, you're coding and on the other hand, you're explaining things. You're actually meeting customers alongside sales and pre-sales people and coming in from a technical angle. You're also engaging with high-level people in your organization to explain what's going on. Would you agree that if you don't enjoy this variety, this may not be a good role for you?

Jono Bacon: I would mostly agree with that, except that one of the problems that I see with my clients as a consultant is a lack of consistency in terms of what developer relations people, community managers, and directors of community specifically do.

I think it depends on the company. For example, a developer relations person or community manager joins a company and they start doing the things that they're familiar with, which they believe add value. They start blogging, doing social media, going to meetups, designing swag, and incentivizing and awarding their community members. Executives in the company look at the work that they're doing and say, "That's great, but what this isn't doing is moving the needle that we want to see being moved." This needle may have some relevance to revenue, growth, or market adoption.

What happens is you end up with a really awkward situation where the executives have got a point, because they hired this person with a certain set of expectations, but also, the individual has got a point, because they're doing what they feel that they were hired for. There's a disconnect. Clarity about these roles is important to reduce that disconnect, because, to make a sweeping statement, most people aren't particularly great at setting expectations. This lack of clarity can sometimes generate a bit of angst.

Geertjan Wielenga: Mary Thengvall's book, The Business Value of Developer Advocacy, is the crux of all these discussions about what the real value-add is and not moving the needle in terms of revenue. Do you think that's valid?

Making a connection with revenue

Jono Bacon: I think it depends. There are some companies that I've worked with, and currently work with, that see community management or developer relations as having a direct connection to revenue. That's a red flag for me.

However, I don't subscribe to the viewpoint that this work shouldn't have any connection to revenue, because I think everything in a business should have a connection to revenue in some form. However, the questions are how direct that connection is, what the expectations that relate to it are, and how it is measured and quantified.

One company that I worked with didn't explicitly say this, but it clearly wanted to see the revenue connection between downloads of its product and customer sales. I said, "You really don't want to connect those two pieces of data; you're going to be ultimately dissatisfied."

Where the company needed to get to was an understanding that if you're focused on building a community, which is about creating awareness and helping people to engage with your product and team, you need to know the value of this work within the context of revenue (such as customer success, enhanced support, and so on).

There needs to be a clear path to overall value for a company or it will struggle to understand why it should fund this work. I don't think it's as simple as saying, "Community managers shouldn't have anything to do with revenue," because other people in the company are going to start questioning why that area is being invested in at all.

The key thing is that value can be either indirect or associative. Sales, for example, has a direct connection to revenue. Marketing people design the funnel that ultimately will have a direct connection to revenue. Community managers and developer relations people, meanwhile, invest in relationships and customer success.

If you build long-lasting, sustainable relationships, what you get is more revenue because people want to refer your product to other people, and that brings more customers in.

"Some people have a holier-than-thou attitude that their work should have nothing to do with revenue."

—Jono Bacon

The problem I have is that some people have a holier-than-thou attitude that their work should have nothing to do with revenue. I find that to be a rather unrealistic perspective to take. You need to set the expectations very clearly.

Geertjan Wielenga: Could developer relations be seen as an extension of customer support, then?

Jono Bacon: Yes. That goes back to my point earlier about the roles and responsibilities, and how most people aren't very good at setting expectations. I think, frankly, we all suck at it. We need to go in and tell people the value that we'll be creating.

Geertjan Wielenga: Would you say that burnout can happen if the developer relations person is trying to chase things that they can't possibly achieve?

Jono Bacon: Yes, I agree with that. I mentioned earlier that relatively new professions don't come with much security, workflow, method, and so on. We've seen this, for example, with the software development life cycle.

Back in the late '90s, there wasn't really a consistent software development life cycle.

There was a lot of variance in how people built software. Now we have code that lives in repositories, people submit contributions via pull requests, and we've got continuous integration and deployment, rapid release cycles, automated testing, and so on. All of these things are the staples of how good software is made and made consistently. It's taken us years to figure that out with software engineering.

Developer relations and community management don't have that structure: there's no single way of doing it. When I wrote People Powered and The Art of Community, I wasn't saying that there is only one way of doing it; I was saying, "This is my approach."

Right now, because the profession's relatively young, people who come into it can experience burnout. They try their best to figure out how to offer the most value, but because there isn't a model, sometimes those expectations are not aligned. That can freak people out and create a stressful environment for them. I am confident that this will get better with time.

Geertjan Wielenga: One of the key attributes for someone who wants to be involved in this domain is passion. Some people care so much about the specific community that they've been building, or specific tech, that they care more about it than the company for which they're actually doing that work. Have you seen problems occur when the company then pivots in its direction?

Jono Bacon: Yes, I have. Where it gets tricky is when you're an ambassador in some ways. You're there to represent the interests of your company and your community.

That can sometimes result in some pretty difficult discussions. Most people in a company, frankly, are not going to understand how communities are built and operate, but many people in the community aren't going to understand the dynamics of how that company operates.

The company always has more information. Even if you are the most developer-friendly community in the world, the company will know its customers better and will also know about certain constraints that it can't talk about publicly. Therefore, to me, the very best people that do this kind of work always look at how they can keep both sides honest and how they can consistently add value to both sides.

Some people will always say, almost as an ethical priority, that the community is their number one focus and the company has to fall in line. If you take that approach, you're going to potentially limit your employment options. I don't think it makes you unethical to say that you need to consistently look at how to build a healthy relationship with both sides of the fence, and frankly, to break the fence down and create an environment where the divisions between company and community are not so strict. At the end of the day, you're getting a paycheck from the company, so you have to provide value to it. But you also need to be in a position where you can go to the company and say that a given decision is a poor one and the team needs to look at it from the perspective of the community that is impacted. This all requires careful balance.

When I meet clients, I often say, "Part of the reason that I'm here is to deliver information that may be uncomfortable to hear, but it will better the relationship between your company and your community."

It has to go both ways. There were times at Canonical when members of the community were just being ridiculous. I'd get on the phone with them and say, "Look, I'm talking to you as a friend and not an employee of Canonical; you're being unnecessarily aggressive right now and not accomplishing what you want to accomplish with this approach."

You've got to put yourself in the position where you can do that and you need trust for that. If the company doesn't believe that you're acting in the interests of both parties, it's very difficult to have those conversations. If your number one priority is always the community, it's very difficult to build that kind of trust with the company, and vice versa.

Geertjan Wielenga: Especially if you're working within a large vendor's community, it's very easy to get completely dislocated from that company and be too focused on your community. Would you agree?

Jono Bacon: I think it's really hard, particularly in the early stages of your career. You probably have a lot more imposter syndrome and you're nervous about what you're doing. It takes time to have the confidence to go up to your company and say, "We're not doing the right thing." If anyone reading this doesn't feel ready, that's normal. You'll get there.

Geertjan Wielenga: Thank you, Jono Bacon.