Traditionally1, when we think of DevEx in any of its shapes, we think of product companies. Alternatively, large enterprise settings with different tech products aimed at developers - think AWS, GCP, etc.
As I often find myself working with agencies and agency-like settings, it got me thinking. Does having a DevEx department/people make sense for these environments? I suspect the question arose from my active interest in DevRel and looking to switch careers to it. Still, it is an interesting problem - what’s the value proposition of DevEx for a commercial entity whose main export is talent? Put another way, if your main “product” are developers2, what use do you have for DevEx?
In my quest to answer that question, I read plenty of DevRel and DevEx material, talked to people that do DevRel in agencies (yes, they do exist), and spoke to people that run agencies and have no idea what DevRel even is. The summary? It makes sense. I’d like to make a compelling case for it.
DevEx? DevRel?
DevEx = Developer Experience. DevRel = Developer Relations.
Let’s start with a few quotes and prior art.
The first one is from Daniel Bryant, who is a DevRel for ambassadorlabs:
For me, devrel is about two fundamental concepts: communication 🎙️ and feedback 👂
In addition to being an experienced engineer, a DevRel person needs to be a good communicator and listener.
On to some more definitions - to quote getclockwise:
As a software company, developer experience encompasses the experiences of your internal software developers as they carry out their work. That involves making sure their tools, processes, and working environment are all conducive to their best work. But that’s not the only way of looking at DX.
And to quote whatisdevrel:
DevRel, also known as Developer Relations or Developer Advocacy, is a role that exists at developer tool companies (companies whose target market is developers). Developer Advocates help educate developers on a specific product or technology through building community, creating content, and improving the developer experience of a product.
According to the last quote, we can call it a day. There’s no point in doing anything DevRel in agencies, as they don’t deal with developer tooling externally, for the most part. The thing is, I’m afraid I have to disagree with that view. Still, whatisdevrel is a good read. I’d recommend going through it to understand what DevRel people do, especially if you are new to the idea.
Back to my disagreement - let’s go through each aspect of DevRel and DevEx engineering, as described by whatisdevrel.
Community
Most dev agencies, especially the big ones, have a percentually significant pool of developers as employees. They may work on different projects, but more often than not, they have at least some overlap in the tech they use. They share a space (virtual or physical), and they go to the same company events. In a nutshell, they are a community.
Communities need nurturing. HR departments do that to an extent, but only partially. And to no fault of their own - HR people usually aren’t techies or developers. While they often do an excellent job of understanding us as people and professionals, there is a special “je ne sais quoi” that only a developer can fully grasp. From the perspective of a theoretical agency DevRel - the reasoning is simple. You, as a developer, have already been in the boots of the person you’re nurturing the community for. The way you empathize with developers will always, by definition, be different than how HR empathizes with developers.
In contrast to external community building, you’re not nurturing your community primarily to have external developer mindshare. Instead, you’re doing it for the benefit of your developer colleagues.
I’ll get into every aspect of “community” as described in whatisdevrel and discuss its value for agency-like settings.
Organizing events
This one is the most obvious. Agencies organize events for developers, too - meetups and conferences are common to product companies.
The goals and value of these will vary from event to event, but we can classify them in two piles, depending on the type of event - internal and external.
Internal events
We can define internal events as primarily aimed at the company’s employees. Whether these are knowledge-sharing sessions, mentorships, or workshops, the value is always twofold - raise the sense of community within the company and allow your employees to speak, teach or learn. These can also take the form of training and mentorships from industry experts that the company hires to run workshops for the employees.
As an agency DevRel, your responsibilities for this type of event would be:
- Understanding your colleagues’ needs for education and mentorship. One of the primary functions of a DevRel person is communication. Therefore, it is paramount to understand the people that you advocate for. Listen to the feedback from their projects and find commonalities in their needs for mentorship/education.
- Mentor colleagues for the skills within your expertise. Since you’re an experienced engineer, you probably have a specialty (or specialties) in which you can mentor your colleagues. Additionally, you must remain “sharp” in at least a few areas ideally related to the agency’s expertise.
- Invite industry experts to run workshops. As a DevRel, reaching out and maintaining relations with industry experts is essential. One practical benefit is knowing who to invite to mentor your colleagues (and yourself) for skills you identify as necessary to the agency’s projects and mission.
- Encourage your colleagues to mentor others. It is also essential to know your colleagues’ specialties. The reason is simple - those who are good at something can often teach others how to improve. It falls on you to facilitate this, regardless of shape.
- Run the event. It falls on you as a DevRel to run the technical aspect of these events. Whether that’s moderating, timing, questions, etc., it’s your responsibility.
- Measure results from these events. To understand whether the effort put into these events resulted in the improvements we’re after, we have to set a metric. These efforts are a case-by-case measurement, depending on the type of event and skill taught.
- Post event feedback. As part of your understanding of your community, gathering feedback from your colleagues about whether the event was valuable, made sense, helped them in their day-to-day duties, and so on is essential. Feedback from your colleagues, plus the success metrics you set in place, will give you the complete picture of how good and valuable an event was.
We can easily group these in a chart:
If some of these sounds like something HR usually does - congratulations on the keen observation! That doesn’t mean the agency DevRel is here to replace HR in any sense. Quite the opposite - HR’s efforts for these events are synergistic and parallel to what the agency DevRel would do. Having well-synchronized DevRel and HR teams for such an effort would quickly yield the best logistics and event quality results.
These are fundamentally different than your usual team-building fare. The critical distinction is the knowledge-sharing aspect, which classic team building often doesn’t do.
External events
This type of event is public-facing. Whether meetups or conferences, these goals are to make the outer developer community aware of the agency and establish the agency as an authority in some industry segment. The value proposition here vaguely aligns with marketing, PR, and hiring efforts. I want to emphasize vaguely here because if we were to classify these in classical marketing terms, this would easily translate to indirect marketing. However, that’s not the point. To quote Christian Heilmann here:
One crucial part to becoming a successful developer advocate is to remove the brand from your thinking.
The same goes for public events - your company logo is there as the event organizer, and that should be the extent of it. Speaking from personal experience, public community events should be about community first and indirect marketing second. It’s more of an effort to build presence and get mindshare, but it’s long-lasting. Long-term efforts with these events come off as more genuine and signal specific values that, based on my experience, attract good talent.
To expand on the “your company logo” part above:
- It’s okay to give out company swag to whoever wants. However, please don’t force it on people (I’ve seen it happen. It’s ugly.)
- We’re running the event to learn and teach something. Everything else comes second. Here are a few practical examples of what not to do, and I’ve witnessed these happen:
- Don’t bore attendees with how great your company is. Let them come to you if they want.
- Don’t push hiring agendas on the event. I’ve seen good meetups die because attendees were pestered about getting hired by the agency that organizes the event.
- Don’t put flyers and marketing material masked as a “swag bag” in their hands at the entrance. You get the point.
- Invite the public community to participate. It’s good to provide speaking opportunities to your employees, but this should also be community inclusive. A meetup is okay to have a speaker from somewhere other than your own company. It builds trust with the public developer community, precisely where you hire your talent. Leaving a good impression can go a long way.
To summarize, avoid being tone-deaf towards the community. Do what developers like.
On the flip side, be active in and encourage your colleagues to participate in community events that have nothing to do with the agency itself. Indirectly, this also affects how your company’s talent and culture are perceived. It can go a long way in attracting like-minded individuals as potential collaborators. Additionally, sharing your knowledge and findings helps establish the agency as an authority on the topics presented.
Doing live streams
This piece of the whole DevRel puzzle is the hardest to find value in on the surface. The value of these is similar to that of events. Where events aim to engage the community real-world, streams and online events aim to do the same on the internet. Besides establishing authority and attracting talent (which we’ve discussed at length above), this is also a way of giving the stage to colleagues (and yourself, as a DevRel). For many, online events and streams are a significantly less stressful way to get started with working and learning in public.
A note on open source: Streaming and contributing back to FOSS projects is another venue that should be considered valuable and interesting. A large part of our work as developers is grounded in FOSS projects - think frameworks, libraries, and package managers. Contributing back to these has a two-fold effect:
- It signals deep expertise in the technology
- It can attract the kind of talent that has deep expertise in these technologies
Discord / slack community
All tech companies have some online communication channels. For many, this is Slack; for others, Discord, and so on. Regardless of platform, the responsibility of a DevRel in these would be mainly identical to outward-facing DevRel engineers (as in product companies).
You’re still working with a community but an internal one. Communication platforms are your hub and a central spot from which you can reach out and engage your community. As an agency DevRel, large parts of what we’d be responsible for is teaching and education. For the most part, we’re most up-to-date with the latest in our tech stack and expertise, and communication platforms are the perfect venue to share this news and spark discussion. These discussions, as a result, can easily influence tech decisions and direction. That can significantly affect productivity and simplify the decision-making process for tech/library choices.
Talking to users for feedback
In addition to communicating with your developer colleagues, which we’ve discussed above, we could also help with client communication. Going with clumsy comparisons again, if your developer colleagues are the “product,” your clients are the “users .”As a communicator and listener, the agency DevRel would be perfect for feedback collection and turning that into something actionable. Not all of us are good at everything, and it’s often hard to discuss these directly. Having a DevRel makes these things more manageable. Similar to internal events, we can use client feedback to identify situations where we can offer mentorship, direct help, or workshops on a personal level. Sometimes, a colleague may need to perform better. Other times, they may need to work on their communication skills. As a teacher and mentor, the agency DevRel can help and improve the situation.
A DevRel here would also wear the hat of a “matchmaker .”Occasionally, a developer isn’t a good fit for a project. Or a client isn’t a good fit for the agency’s expertise. An agency, DevRel, would be uniquely positioned to identify these situations and help devise a solution.
One unique aspect of agency DevRel here is understanding what a client needs before a project starts. While generally applicable, it is more often the case for greenfield projects that tech stack decisions are driven by hype. Particularly with clients that don’t come from tech backgrounds or don’t have an internal dev team. While one could easily make a case for “their project - their problem,” it can also heavily reflect your team’s productivity and quality of work. As a communicator and listener, it’s the agency DevRel’s responsibility to understand these and apply their experience and expertise to agree with the tech direction. Alternatively, to offer a better solution devised collaboratively with the team working on the project and make a case for it to the client.
Summary and a CTA
Before I continue, I’d like to quote a tweet from Daniel Bryant again:
A few of you may be thinking “but this looks like several roles across marketing, engineering, product ownership, and program management”
To which I reply: “yes” 😁
DevRel is a challenging role, and you’ll wear many 🎩 s. It’s also an extremely rewarding role
If you could write any of these off as the responsibility of a different career path, I congratulate you on the keen observation. DevRel tends to live on the tangents of these. But, what DevRel primarily is about is relations. It’s in the name. But we don’t aim to replace these or step on their toes. Instead, the aim is to fill some apparent voids and enhance what these careers already do. This is a team sport, and we aim to succeed as a team.
Join me in part 2, where we’ll discuss the second aspect of DevRel, as described by whatisdevrel - content.
The call to action
Did you find this read exciting but still need convincing? Feel free to ping me, and we’ll talk. I’ll get on a call with you (free of charge), and I’d be happy to make a case for your unique situation. I’m not out to sell anything - my sole motivation is that we, as an industry, can benefit significantly from DevRel engineers in agencies.
1 As “traditional” as it can be, with about 15ish years of DevRel being an established job description.
2 Talent as the product isn’t meant to offend here at all, and I sincerely apologize if it does - it’s just an attempt to draw a parallel.
