Bruno Borges

Introducing Bruno Borges

A Brazilian and proud immigrant living abroad, Bruno Borges has been a software developer, Java community member, and tech influencer since 2000. He previously built end-to-end business applications as an engineer and team leader. In recent years, he has worked with, or continues to work at, vendors like Oracle and Microsoft in roles related to product management and developer relations strategy. Constantly present at conferences around the world and a contributor to open-source projects, Bruno believes developers are the best source of new business ideas in a digital world, and empowering them with great tech is one of the major goals in his professional life. Find Bruno on Twitter: @brunoborges.

Geertjan Wielenga: I want to start right in the middle of a topical discussion: on Twitter, you said, "Developer relations isn't simply about traveling around and going to conferences and parties; it's actually part of a strategy of a company." Can you explain more about that?

Developer relations as a strategy

Bruno Borges: When companies decide to build a developer relations team, that becomes a strategy. Developer relations can be something that an individual ends up doing naturally. For example, someone working with open-source foundations in their free time could be described as some sort of developer advocate, but that's more just community engagement.

The formal structure of developer relations within any company is about engaging with the users of a product, service, platform, or API.

For that reason, the company needs to see the discipline of developer relations as having a strategical structure. That structure could be inside the product management team, the engineering team, the marketing team, or even the sales team. Depending on where developer relations is situated, the company's strategy, purpose, goals, and metrics will be influenced.

Not every company can simply go and start up a developer relations team. Sometimes it comes about naturally when different employees sit together and start discussing developer relations as a business strategy.

Generally, companies have the need to position their tech within a developer community, whether that community is an open-source community, a partner community, or a customer developer community. Companies need to start communicating with developers. That is, I think, the ignition for having a developer relations strategy. More and more companies are becoming software companies, so we're seeing developer relations becoming a strategical part of the way companies do business.

Geertjan Wielenga: I'm sure for many people who have been involved in this field since the '90s, they accidentally ended up in developer advocacy by being enthusiastic. If you were technical on the one hand but people-oriented on the other hand, you could end up being a developer advocate. It seems like developer relations has a much more formalized structure now. Would you say that being a developer advocate is a far more officially recognized role today?

Bruno Borges: Yes, by 2009/2010, we started seeing more formal structures in developer relations.

That's about the time that Google started its developer relations team and IBM started investing in its developerWorks platform, with several engineers creating content specifically for developers. In the last 10 years, we've seen developer relations becoming part of software companies and also non-software companies that rely completely on software, such as banks and retailers.

Geertjan Wielenga: Does every company need a developer relations strategy of some kind, then?

Bruno Borges: I would say that any company that exposes its software, platform, or services to others, in order for them to build new custom stuff on top of that, does need a developer relations team within the company somewhere. This depends on how the company benefits from software built on top of its own structure externally, of course.

One example is Ford. Ford has a developer relations team that is focused on its partners. Developers work at partner companies to integrate tech with Ford cars. So, a car manufacturer has its own developer relations team, which is interesting.

If a company is a software company, but it only produces software for itself, then that's an example of not needing a developer relations team. But the moment that the company has external developers that need to work directly with its software, whether it's community users, external individuals, partners, independent software vendors (ISVs), or customers themselves, the company would benefit from a developer relations team.

This can help with all the questions, feedback, engagement, and growth that comes from the adoption of software by external developers. That, in essence, is what developer relations can do.

Geertjan Wielenga: Apparently, there is so much business now that there are companies out there offering developer relations as a service. Representatives will come in, analyze the situation, and recommend people from their own organization or outside their organization to fulfill developer relations roles. Have you heard about this?

Bruno Borges: No, that's amazing to hear and only proves the point that developer advocates are becoming needed by software or software-related companies. Sometimes, the company might not be ready to implement a developer relations strategy right away. It might not have the skills, resources, or people. Having a company that is able to help with navigating through this period is a big signal to the market that this is an important area.

Geertjan Wielenga: Developer advocates have had to fight for a place at the table in organizations because there isn't always a direct connection between our work and revenue. Nowadays, there are developer advocacy job positions. You can go to LinkedIn and there are recognized functions within organizations. Would you say that the fight has been won as a result of times changing?

Winning the fight in companies

Bruno Borges: The fight happened in the first place because executive teams were not aware or not educated enough about the benefits of having a developer relations team.

Without that knowledge, they couldn't make a decision about whether it was important to fund developer advocacy within companies.

Now, as we see, developer relations is everywhere. I think it's just a matter of time before executives who previously had doubts catch up with the market. We're going to see developer relations being covered as a formalized extra structure within companies, just like engineering, product management, business operations, and so on.

We're at the bottom of a big hill of adoption of the developer relations discipline within companies. I think this area will explode in the next few years, simply because the major companies are connecting with developers. As I mentioned earlier, even companies that are not traditionally from the IT industry are adopting these strategies. This is a great moment to be involved in this field and for any engineer who would like to do this kind of work, there are fantastic opportunities.

Geertjan Wielenga: Has the only change been that many organizations are now doing this and therefore developer relations has become more attractive? Do companies now see value that isn't expressed directly as money?

Bruno Borges: It really depends on the company and how the company makes money. It depends also on how a particular product, service, platform, or API generates money. One thing that we can say is that the better the relationship between a company and its customers, the better the customer retention, customer satisfaction, and adoption of growth. I'm not even talking about developers as customers here, just the importance of building customer relationships.

When we consider developers as customers, and we start focusing on that particular set of customers with their specific needs, we can improve that relationship. Soon, it will just be natural to want to better the relationship with developers. This will lead to more satisfaction with products and more adoption of them. New developers will also come to that platform, product, or service.

Customer relationships don't just happen. When we look at account managers, those sales employees work within their accounts and they have one-to-one relationships. Anything that they do keeps those relationships strong and they can easily track that. Account managers are responsible for taking all the actions needed to support a particular customer.

"In developer relations, it's hard to track the actions needed to engage with a particular customer."

—Bruno Borges

When we look at the developer relationship, that's often a one-to-many relationship format. You have one developer advocate or you have one program manager in developer relations. You also have one event, one article, or one documentation piece. All of those things are one-to-many relationships and because of that nature, it's difficult to track a direct impact on revenue. In developer relations, it's hard to track the actions needed to engage with a particular customer because you don't have a track ID per customer when it comes to someone coming in to see you, watching a video, reading an article, attending a presentation or workshop, or anything like that.

That said, revenue becomes an indirect metric. Depending on how a developer relations team is structured, it can be possible to track direct revenue. One example is developer relations teams that are focused on the existing customer base of a company and their objective is to help the customers to take advantage of new products and services that the company has recently released. It might be possible to track that because that is a one-to-one engagement. It really depends on how the team is structured, its goals, and how it engages with the developers.

However, the general rule is that developer relations has indirect impact and executives need to understand that. They have to see that there are benefits, but most of that will be indirect, in the same way as brand awareness and customer satisfaction. Those things are measured by analysis on the marketing side. If marketing takes a look at what customers are thinking about the company, that will show the growth opportunity that the company has just based on brand satisfaction. Developer relations is similar to that. It is possible to track developer satisfaction, which might or might not have a direct link to revenue. Tracking will definitely show that there are opportunities for growth.

Geertjan Wielenga: What is your own story? How did you end up in this domain?

Bruno Borges: Like most developer advocates or developer relations personnel, it was something that just happened. Developer advocacy is not a discipline that is taught at universities; there's no training specifically for this. Most often, somebody will come to realize that what they already do is actually developer relations.

This is a discipline that is a conjunction of several other roles: software engineering, product management, and marketing.

"In my view, everyone is always selling something."

—Bruno Borges

Another aspect is sales. Most developers don't like the word "sales," but in my view, everyone is always selling something. Engineers are selling something; they're building software that will be sold somehow, somewhere, to someone. Product managers are helping to manage the development of that product. Marketing is communicating with people about that product. Sales is actually helping people to start using that product by ensuring that they understand the benefits in more detail.

This mix of roles means it's hard for someone to decide to do developer relations just from day one. Coming out of college as a computer scientist and deciding to do this job will not happen anytime soon because, for someone to be able to do developer relations properly, there are so many disciplines that come before that.

In my case, it happened that way. I started as a software engineer and then I became a product manager. As a product manager, I was engaged with marketing divisions and sales divisions directly on a weekly basis. Maybe in some companies, sales, marketing, and product management are pillars that are not needed. I think it might vary. But, in my opinion, those pillars are essential for doing a proper developer relations job. Trying to aim for those pillars is a great foundation.

Just as in computer science, when we go to college for four years, sometimes we don't use some of that background, but it gives us a good foundation.

From outsourcing companies that just build business software for companies, I then went to vendor companies. That's where I landed as a person helping users to take full advantage of the software that they needed to build their own solutions. That process is, ideally, what I see happening to others.

Geertjan Wielenga: What kind of personality fits this role best?

Bruno Borges: I think any personality fits this role, but I would classify the ideal person as someone who is able to create things without anybody telling them what to do. I think that is crucial.

It's clear that developer relations is a mix of multiple disciplines. Because of that, the kind of person who will be able to do the job is someone who is very proactive in learning and experimenting with things. I know engineers who are great at building things, but only once they are told what to build. That's why we have product managers in most software companies: they are the ones who are able to identify what needs to be built.

It's very important for a developer advocate to know what to build and what the best delivery mechanism for such a creation is. Is it an article? Is it documentation? Is it a video? Is it a presentation? Is it a demonstration? Is it a library? Is it community engagement? That's why you need to be self-sufficient. It's not a requirement to be self-managing, but it's a good idea.

You need to be creative and being able to listen is important too, along with understanding what others are saying but not being biased by a small set of opinions. You need to understand that the world of developers is quite big. We have millions of developers in the world and most of them are not even on Twitter. Most of them are not publicly exposing their opinions about software.

I think the cognitive requirements of a developer advocate are quite demanding: being able to analyze and process all that information to be able to make a decision on what actions to take next. While those qualities are not hard requirements, they will definitely show the potential of an employee to become a developer advocate.

Just as in software engineering, where we have software engineers, architects, and product managers, in the future we might have more content producers, developer relations engineers, product managers, program managers, and so on. That's where you start to see the developer relations team being formed with specific hats or roles. While I was outlining just now the ideal person, that doesn't mean that a team can't be formed by putting together people who have some but not all of those qualities as individuals. You can create value as a team.

Geertjan Wielenga: If you see an opportunity for developer relations as an employee, what can you do to make that happen in your company?

Starting your advocacy work

Bruno Borges: Getting started is tough. As you mentioned earlier, sometimes there is an eternal fight to justify that role. That's actually a good way to start, but it's a painful way to start, just because you not only have to do the job, but you have to justify it. I think a good way to begin is simply by performing the expected tasks that a developer relations team would perform without being asked to do that. That would be a side job for sure.

Once you realize that you can actually do this role, that is the moment that you go with a business plan to your company outlining what you have done over a period of time and what the outcome of that was. Maybe the outcome was content, product feedback, customer support, community engagement, or all of that. Most importantly, you need to show what the value was. If you aren't able to convince the company that this work is important, then you should get a full-time job elsewhere.

"You have to do developer relations to understand what it's about."

—Bruno Borges

It's also a possibility that you will realize that developer relations is very hard and you don't want to do it again. You may stick to product marketing, product management, or software engineering, and that's okay.

But it's important to go through the exercise of trying to do developer relations in all its forms. Once you do that, you will learn a lot. You have to do developer relations to understand what it's about, and then you can decide whether it's something for you or not. That, in my view, is how you can get started.

Geertjan Wielenga: Thank you, Bruno Borges.