Creating meaningful and sustainable relationships with developers

My name is Jayson DeLancey, and I lead the developer relations program for Dolby.io. Dolby works with a lot of great partners who embed Dolby technology into devices. We also work with a lot of creators who make the video games, movies, TV shows, and music that we all love and enjoy.

Dolby is a technology company, and in order for people to use the technology, we need a software developer to put it all together and make the magic happen.

Here’s an overview of what I'm going to be talking about:

Who are developers?

Is an animator or a production engineer a developer?

Well, I used to be a Production Engineer at DreamWorks Animation. My job was to write code. I worked with a lot of animators who had computer science degrees because it was a very technical endeavor, but these aren’t necessarily the roles that might show up in marketing analytics around the role of a developer.

What about an aviation ops specialist? Is that a developer?

While I was at General Electric, I worked with a lot of people who had very specialized engineering roles but needed to find ways of automating things. So, suddenly they became developers and acted in that role.

What about an audio/video/embedded engineer? These are the sorts of folks that typically work with Dolby. Are they automating workflows?

Absolutely. And sometimes that involves understanding, manipulating, and working with code.

What a developer does can range from a website to sophisticated database development, and there’s a large range of projects. But automation and the adoption of technology are fundamental components of that.

What is the persona of a developer?

What’s the persona of a developer typically?

There are a lot of stereotypical types of answers related to this, and you can't just view source on a developer to understand.

Developers are unique. Just like any segment of the population, no two developers necessarily think the same way. There are some trends, but it's not as easy as saying, “Hey, you're wearing a hoodie, you must be a developer.”

There are some really great resources out there if you're new to the developer marketing space and you're trying to understand who developers are.

I recommend a couple of books: Ask Your Developer, by Jeff Lawson, and Developer Relations, by Caroline Lewko and James Parton.

They'll cover some of the generalizations. There are trends for a reason. For example, someone who’s technical typically approaches things in a very detail-oriented way or approaches things with skepticism.

There’s also processes around creating personas. There are personas around user experience design or buyer personas. So, whether you're leaning more on the marketing side or a little bit more on the product or engineering side, that may influence how you think about personas specifically.

There are techniques for doing data-driven segmentation. If you're looking at the market as a whole, looking at different reports and things like that, those are all really great, but if you’re taking on this type of initiative, remember that it’s a group project.

You need multiple departments agreeing on personas because that's the only way you can communicate cross-functionally in an effective way.

There's a quote that a persona is like using a toothbrush. It's a good idea but nobody wants to use somebody else's. So, if people are invested in the personas, understand what they are, and are reminded of them cross-functionally, then it becomes a resource you can share.

Some problems with personas

By definition, a persona is a semi-fictitious person, and that sometimes leads people down the path of creative fiction. I don't think that’s as valuable.

If you were putting on your thinking cap and brainstorming what a persona is for your target audience, if it's completely based on creativity or data overview, that may not be as effective.

There are also a lot of details in personas that I've seen that don't really help make certain decisions. If one day you're defining a product or how to message, does it have the details you need for that?

If you don't have the right information there, or you have too much of the wrong information, you're not getting the value from it, and that leads to a lack of applicability, how you take that persona and use it on a day-to-day basis.

Having a narrative profile around a typical person and some clever name like Donald Director or Sally Sys Admin doesn't necessarily drive your decisions forward.

A/B testing your personas

It’s really important to take a moment and go back and look at your personas and test them. If you have a job description of a CTO of a twenty-person startup and a staff engineer of a two thousand-person corporation, are their jobs different? Are they both making technical decisions? Are they both evaluating technology?

If you're looking for a business opportunity, you may care about that. But if you're talking about messaging, they're making decisions around similar characteristics.

Take a front-end engineer adding video conferencing to a healthcare app and a front-end engineer adding video conferencing to a finance app. Does it matter if it's healthcare or finance? Those are very different industries with different requirements, but if the front-end engineer is adding something very common in both scenarios, maybe that industry doesn't make a difference.

Is a college graduate different from a boot camp career changer? Is it a hobbyist versus a professional? Sometimes we have some meaning behind that designation within a persona. But if everyone's not in agreement on what that means, that becomes very problematic.

So, if I'm a professional with a lot of industry experience, you may treat me in a certain way, but maybe I don't have a project but I'm looking to advance myself in some way by learning a new technology.

What about a React developer versus a Vue developer? If they're looking for content, yes, there's going to be a decision there. But if your content is Vanilla JavaScript or isn't even a front-end technology, maybe that distinction doesn't matter as much.

So I think there's value in testing if the characteristics that you're using to define your personas make a difference.

Ways to build relationships and trust with developers

So, how do you get to a point of having better personas? It's really important that you take some time to get to know developers.

There are over twenty million developers in the world. The question is, how many do you know?

If the answer is, “not many,” that's maybe a good place to start.

There are a few things you can do:

Leverage developers who work at your company

I've been asked this several times in a developer relations type of role: “Hey, I need some developers to ask a question. Do you know anyone?”

They think that I might pull some people in from the community, and they really just want someone technical to sanity-check something. I have to remind them that we have dozens of engineers who are working in the same industry as us, who may or may not know much about all of our products.

So, there's an opportunity there to leverage people in your group about how they think about technology adoption and get them involved. That also allows engineers to see the other parts of the business.

Find technical coworkers

Find people who may work for your company and ask for introductions. Maybe they know too much about your product so they can't give you that unbiased opinion, but maybe they know people as well.

Use social/community tools and goodwill

Developer relations can help in using social or community tools to bring people in based on goodwill. But make sure that you have some people who are part of your network as well that you can reach out to when necessary.

Hackathons

Another great way to develop relationships is hackathons. Sometimes it's approached as a tactic for growth, but it can also be a secret weapon for getting marketing feedback, as opposed to running a survey because you have a captive audience.

Depending on your role, maybe you're not as technical and you think you don't have anything to contribute at a hackathon. But that's not necessarily the truth. Part of a hackathon is pitching. So suddenly, someone with a marketing and storytelling voice becomes super valuable to all these teams.

Go talk to the teams, see if you can help, give them your perspective, give them feedback, and help them iron out their pitch. As a result, you build a little bit of goodwill so that you can have them as part of your network, and people you might have a long-going rapport with.

Help a developer promote themselves and their experience after the event. Ask them questions about what it was like for them and get to know them a little bit more.

Even at the beginning of a project when people are brainstorming, it's really helpful to have people with very diverse experiences. Someone with a marketing background might understand the business problem a lot better in terms of the use case. Or if it's a user experience problem they're trying to solve. Having any user who might be understanding of the demographic becomes a very valuable resource.

So, if you have the opportunity, go to a hackathon, walk around, and talk to the team. Don't just sit at a booth. You have to go out and engage with the audience and get to know what they're working on. Even when they're busy, grab them when they have an opportunity to take a break.

Another great way to get involved is by sponsoring events. Most teams send cross-functional groups to events, so make sure to rotate that opportunity around different people so that everyone has an opportunity to go and experience an event.

Also, attend with goals. Prepare questions. When someone comes up to you, don't just say, “Have you signed up for an account? Here, have a t-shirt.” Actually have questions. Use it as an opportunity to do field research while you're there.

Test your ideas. Take two pieces of collateral, put them out on a desk, and see which ones go faster. That might tell you something about the information that you're presenting and what messages are resonating or are of interest to a particular community or crowd.

If someone comes in and says they’re not interested in your product, if they're still interested in the industry or have some connection, maybe there's still an opportunity for you to learn something from them related to how you target people who are interested in your product.

Mystery customer theater

Another tool that I've used quite often is something I refer to as ‘mystery customer theater.’ This is inspired by the idea that teens used to get together and watch TED talks every Friday.

If you have a customer and you want to learn from them about how to develop marketing messages or what programs speak best to them, it’d be really awkward to have thirty people in a room with the customer. It’d be a little overwhelming.

But with tools that record customer calls (abiding by any legal rules of course), it's an opportunity for people to review and then coach. “What are the questions that come up? That was an interesting way to pitch. Did it seem to resonate with the customer or not?”

And because this is such a useful end perspective, especially if it's a technical call with a technical team, you might start seeing what their concerns are, how they think about the problem, and what types of questions they ask, to lead to better outcomes.

Have a developer co-pilot

DevRel can help find who these surrogate personas are. In other words, it's not just a persona. Have a person behind it that you can go to and ask and test ideas and say, “Hey, I have this thing I want to do but I don't know if it resonates. I’ve got a couple of different options, can you tell me which one you think works best?”

You can always resort to paying for services, and there are a lot of really great firms that can do market testing for you as well. But that firsthand account gives you a lot of value as well.

Sustainable personas - how to build upon your relationships

As you start developing this and you're trying to get to something sustainable, focus on the actionable attributes.

Can your persona help you determine what message to deliver? Determine where - which events, which channels?

Identify which vendors or tools to integrate with. Prioritize code samples or features. Which way should you message something or focus on it? How do you order content and navigation items?

If you're building a proof of concept of some sort and you're trying to evaluate it, having a real person behind your questions can help to start informing how you think about personas and how you think about how that persona thinks, and focusing on trying to make an action. These are the attributes that really matter in making this categorical type of decision.

Minimum viable persona

That can lead more to a minimum viable persona. It's not this creative fiction of all kinds of things. If you use real relationships, not just your imagination, you actually have a very colorful picture of, for example, what Steve does when faced with this type of problem. If you know Steve the developer and you keep working with him, you start getting a little bit more empathy for what matters.

Look for branches in the developer buyer journey. Those are the attributes that really matter so that you can prioritize whatever actions or behaviors you need to take based on the actions or behaviors of a person who's in that persona you care about.

Make personas a reality

What I'm really advocating for here is to try to take those personas and make them a reality.

First, diversify your portfolio of real-life developer contacts. First, you have to know one developer, but you need more. If you ask five different developers, you're going to get different perspectives. But if you can get four out of five to agree, that's a pretty good indication of a path to take.

You have to be respectful of their time and the effort that goes into it. But have a few trusted people that you build a relationship with. That's why I often say, start with someone in your own company, ask them, and partner up with them for a while.

Eventually, you get to a point where you no longer need to ask that developer because you get a sense of how they’d think about the types of problems that matter to the projects that you're working on.

Behavioral factors

If someone has an existing solution, are they happy with it? Are they aware of the problem or not? If they're aware of the problem, is it a nice one to have? Are they aware of alternatives?

These things can help guide sales enablement, messaging, and ads you're running because you're targeting with a knowledge of your product, how people think, and what behaviors they may take in the face of that information by categorizing people along that journey.

Decision matrix

It might not necessarily be an attribute, but more about what their project status is.

What’s the range of options? Well, it might be a greenfield project. Maybe it's a legacy, or maybe they’re not working on a project.

Instead of talking about if someone is a hobbyist or professional, now you're saying, “Is someone starting a new project entirely? Or is someone trying to fix a tool that's already out there or add a new feature to it?”

Maybe they already have that feature and are trying to switch from a competitor, or maybe they're just looking at something to do in the future.

The reason this matrix becomes valuable is because then you know that they have technology constraints, and suddenly you might target a segment as a result of that.

Or, if you know that typically nobody has this type of feature, now you have to teach some of those fundamental concepts more, as opposed to someone who's coming in from a competitor who already understands those concepts and is ready to roll.

In terms of learning style, if someone's a little bit more visual, they want to see source code or tutorials. If someone's a little bit more auditory, they probably want to watch videos.

This helps inform how we allocate resources to which projects based on this matrix, not just some truisms about developer personas in general, to make sure that you cover them all.

Decision matrix for developer learning style

Likewise, what's motivating a developer? Is it revenue, learning, or recognition? Maybe those are the only range of options we need to consider in making a decision, and that can help us focus our attention on what matters. It’s not about trying to tell a story or the life history of a person, but focusing on the things that matter in terms of decision-making.

Decision matrix for developer motivations

Persona advisory group

If you've started building these relationships, you should start having this little persona advisory group where you can evaluate messaging and product fit with your surrogates. You can A/B test ideas to come to important decisions, and then observe usage with live testing and data.

So, now that you're starting to make changes, you can go out and ask your five folks and see whether there’s a trend or if they're just completely split. And then maybe it doesn't matter as much to focus on. That helps you to determine how much time you spend on it.

Explore our in-depth guide about developer personas to learn more about this audience and what you need to do to engage it.