Gatekeepers and pit traps in DevRel career paths

Joe: Today we are going to be talking about patterns in developer relations. First and foremost, we're going to be talking about patterns in developer relations that affect people seeking to start a career in develop relations or to get their first develop relations role. What we will then see is how that is part of a larger pattern that fundamentally shapes DevRel as an industry and holds it back as a profession and how that is an issue that affects all of us, not just beginners who rely on DevRel for work. By the end of this talk, hope to have moved us towards breaking these patterns through looking at comparable roles and how they face these issues and move past them. This talk isn't aimed solely at people seeking their first DevRel job, nor is it aimed solely at people hiring for their first time. Although I hope there's something to say to both of these groups. This talk is instead aimed at DevRel practitioners at large. That means you Dera Khan to offer a new framing on the persistent problems faced by folks in our jobs and how we might move past them.

This talk is called gatekeepers and pit traps.

Our adventure begins with an early in career developer. This developer has maybe graduated one or two years ago, maybe from a CS programme, maybe from a bootcamp. The specifics aren't important. What is important is that they have been trained to create software applications using the practical and popular tools of the day, and that they have occupied a job employing those skills every day for a length of time considered fairly normal in the industry, let's say 18 months. They are, as we would say, a developer today. They set out on a new adventure. They have attended a developer conference in the last year, and there they encountered someone whose title was developer advocate.

It was the first time they'd met one of these developer advocates and after chatting a while about what this person did day to day, they were intrigued and excited. The developer decided that that sounded like the job for them.

I loved software development and I love to help others do it. They've always been a people person anyway, and the travel sounds fun. They think they have always wanted to get better at writing. They'd written a couple of blog posts and they'd been well received. After some time of working themselves up to it and speaking to other developer advocates, they decided it was time to set out and find themselves a developed relations role. As they set out looking for work, they come to a fork in the road.

To the left is a well paved path leading to what looks to be a bustling settlement. The walls are high and well-maintained, and a constant stream of people comes to and fro through the gates. A sign at the head of the path proudly points towards the settlement. Reclaiming now hiring developer advocates to the right is a winding shady path through the woods.

The woodland is thick and it is unclear what lies at the end of the path. The path immediately after the fork is laid in the finest marble, but quickly turns into a plain dirt road, a short way beyond. Besides the path, a masterfully crafted billboard, the lettering in laden gold says Now hiring founding DevRel community experience accepted Keep doing the great work you are already doing. Given the size and seeming success of the settlement, the developer the size, the left-hand path offers the best chance of success in finding their new role.

They take the left path a swing in their step as they ascend the short work to the front of the settlement. The settlement is fronted by a large gate open as both residents and traders from far fun lands pass through in droves, not hesitating. The developer mixes with the crowd and begins to pass before they reach the arch of the gate.

Though a firm hand grips their shoulder and stops them dead in their tracks, it's the gatekeeper turning to face the hands. Owner, developer sees is the gatekeeper, and without pause, the gatekeeper asks the developer, you're new here. What brings you to the settlement? The developer replies, I saw your hiring developer advocates. I'm here to work.

The gatekeeper smiles and says, that's fantastic. Of course, if you are applying for develop relations role, you must be a developer yourself, right? Developer says, yes, I'm a react developer. For the last two years I've been responsible for the client of the small services company. The gatekeeper looks displeased just two years. Okay, well, not to worry, this isn't an engineering role after all. I suppose since you've been responsible for the client, you've got some experience in desktop applications as well. All kinds of developers use our products and we really need someone who can understand them All.

The developer beginning to wilt under the bombardment of questions begins to explain that they've tried electron before, but they're suddenly interrupted by the gatekeeper now in full steam. I suppose you've contributed to open source and any good open source project. Nowadays needs documentation in the community still be well versed in technical writing and community building. The developer catches their breath and looks around at the milling crowd who seem to be passing through the gate easily enough. Meanwhile, the gatekeeper has already moved on to the next question, and obviously you've organised a meetup or a conference for that community. These are the fundamentals. After all, the developer sensing a pause takes the opportunity and darts him. Sorry, what level is this role again?

The gatekeeper Sternly replies. Oh, entry level of course. Thanking the gatekeeper for the information. The developer backs away from the gate saying he will think about the role and be back.

The developer returns to the fork in the road. The experience though discouraging has not defeated them entirely. There's still that other path that, and this one seems quite the deal. They set off down the path and quickly across the well-maintained marble stretch and into the darker dirt paved road of the forest.

They walk and follow the path for what feels like ages and still it seems as if the path just ahead of them is always obscured by the undergrowth with no end or goal in sight. Suddenly though new light appears to be breaking through the undergrowth and the end of the path feels near. Just as that light reaches its peak. The developer's foot lands on the path of a dull fud and the ground shifts beneath their feet. A pit opens beneath the developer, plummeting them into the darkness, regaining their senses. The developer inspects the pit.

The walls are steep with no visible handholds, a way of climbing up and out of the trap. The floor of the pit is bare with no resources offered to help the developer scale to the top, the developer sumps to the ground resigned to waiting for help.

In retrospect, the path was of course too good to be true. It offered so much, but with no clear goal in sight, it was dangerous to venture down it alone. This is often the reality of the DevRel job pump. This is a consistent pattern that new starters to our industry are faced with. Job roles fall into two camps, either that of the gatekeeper with requirements describing an impossible person, someone who has led a full and illustrious engineering career where they have mastered many disciplines related specifically to the company's products, while simultaneously also having experience doing the work of developer advocate or the role promises the world, the opportunity to build a derail function.

Being on the ground floor, you can bring your existing experience, no derail background required as long as you've done a lot of unpaid labour in open source or for your community or have a big audience. The only trade off is that you're expected to do basically everything at the company that isn't engineering, including docs, SDKs, community support, sales, engineering, training with no resources or even a clear answer as to why these two extremes. Share some qualities this breakdown those problematic qualities seen in these two camps.

First is the skills emphasis. Almost universally, both of these camps will place emphasis on some kind of skill that isn't core to devros success. In the example we heard from the gatekeeper, placing undue emphasis on very specific engineering skills and not necessarily on the fundamentals of how we communicate with developers. Next is tactics over outcomes. A universal quality of these roles is a long laundry list of things that you'll do, but not the ends that those things achieve.

Tactics are a way to achieve an end. They're not the end in itself. As an example, we go to meetups to achieve something.

Meetups themselves are not the end goal, and then finally, the levelling is all over the place. They either demand too much or not enough. They expect to get impossible skills for very little, or they place people without the experience needed to make a DevRel function of success in an impossible situation. Having to strategize at a level we normally expect from executives, these qualities are all symptoms of something. Do you see it that something is a lack of understanding of developer relations? Don't worry. Please do not go anywhere. I'm not about to turn this into a what is dev?

I'll talk, but I do want to talk about a pattern here, something that I find myself asking, what of these things are related?

What is the fact that DevRel is fundamentally misunderstood more than 40 years after its inception is linked to the way that we hire and welcome new people to the role? What if there is a relationship between those two things? So let's talk about metrics. A constant topic of conversation in developer relations is metrics. What to measure, how to measure when to measure. The derail community talks about it constantly. I know I'm not alone in feeling a certain sense of deja vu about it.

Anyone who knows me will know. I'm very frustrated by this. It's a hard problem for sure, but derail is not the only business function that has to measure its work. Surely some somewhere has cracked this. I had a quick look around at what res had to say about it, and there is in my quick Google, at least 36 DevRel talks before this year's, DevRel com, at least one book focused on it.

Other books mention it, at least five podcast episodes. God knows how many blog posts there is more. I gave up counting and now there are startups, sponsors of this conference, orbit and comso as well as other companies like Savannah.

There is an endless amount of resources about derail metrics, and surely we have reached peak metrics. Is there not enough metrics content? How is this not being solved with all this fantastic knowledge out there? Some of it must be useful. So what is going on? Here's my theory. It's all about knowledge transfer. Knowledge transfer is how knowledge built up within a group is passed on.

Something is fundamentally wrong with knowledge transfer in developer relations. The knowledge about metrics exists. Experienced people who have been in this industry for a long time and led big teams to success exist and they have shared their insights at this very conference, but when it's shared, it is forgotten.

It fades into obscurity before it can be used. How and why does that happen? We all know intuitively that is not enough for knowledge just to exist. Anyone in this audience who has created documentation or built the tutorial knows this. Anyone who has tried to teach themselves something knows this.

Learning is easier when assisted by peers or by a teacher. It's also easier when set in context, which is again something that we know it is not enough mely to describe how an API works. It's better if developers can get hands-on with it in an example application in organisations and professions with rigorous practise around knowledge transfer. A common theme and a common element of the job is some on the job training look at medicine with the idea of the residency or trades with apprenticeships. This brings me right back to the past that we lay for new people trying to get their first developer relations job.

How many of you in the audience would say that you received any intentional training around the practise of developer relations from an employer, from those of you who say that you have received that training? My bet is that it's likely been a very specific set of training on tactics only. For example, you may have had a public speaking class or a bootcamp on a technology fundamental tool, employers product.

By my observation, the most common experience for most IL people when it comes to working out the very fundamental knowledge that equips us to do our jobs is that we have to invent it from first principles, and this is why the memes endure. This is why we can't stop talking about metrics. This is why the old adage developers don't like marketing persists. No one likes marketing. There is not a single consumer in the world who would not prefer to hear from a like-minded person or an existing user of a product before they buy that product.

There's not a consumer in the world who would not appreciate having their feedback about the product addressed by the creators. The reality is that developers, any customer of any product, have a unique set of needs that companies looking to sell and market to them need to meet. The phrase developers don't like marketing is a gross oversimplification, hiding whole swats of professional skills that exist and are used by our peers in other roles, those skills such as requirements analysis, user research, and even persona identification, but without an infrastructure around knowledge transfer, the only thing that can survive is the PE lines to be recalled again and again and to haunt and mislead new entrants to the profession.

And that is the cycle. We fail to train and we fail to create an institution of knowledge transfer within DevRel, which prevents the advancement of the field and in turn leads to conditions that just reinforce the cycle.

We fear metrics, and so we try to hire unicorns who will succeed and meet those metrics becoming gatekeepers ourselves. Leaders draw the business value of developer relations only from the persisting memes, and so they dig the pit traps. And this is where the issue becomes one, not just for new starters, but for all of us. Many of us have felt burnout. Many of us have thought about the short career path that DevRel offers. DevRel is a transitory profession for a lot of people.

It's something they do for a few years before going back to engineering or product or marketing, something with more sustainable practise and more potential for growth. This reinforces the cycle. We force people to reinvent the wheel on first principles, burning them out in the process, and then they leave with their knowledge. We fail to support new starters, leaving experienced people, few and far in between leading to the conditions that create the burnout in the first place.

We need to break this cycle, and I wish I had an easy answer on how to do it. It's very easy for me to sit here and say, Hey, hire more juniors, make more entry level roles. Add a training programme to your Devra programme. But then we're in the cycle.

We need to hit those metrics. We're trying to convince leaders to give us the headcount to do that in the first place. I would be lying if I sat here and said, Hey, just do this thing. It doesn't work like that. All I can say is that there is hope. There is other roles of a similar story that have succeeded here, and for that, I want to draw your attention to one in particular, that being product management. Product management and developer relations both started around the same time in the early eighties. They even have a similar origin story.

Let's take a look at a description of early product management from Martin Erickson at Mind, the product in his article, history of Product Management. This is part of that description, which is that putting decision making as close as possible to the customer and making the product manager the voice of the customer internally. Now, I dunno about you, but that sounds very familiar, right? That sounds like one of the things we say quite a lot about the role of developer relations, and yet product management has achieved a lot more of the hallmarks of a sustainable profession than developer relations has. You might argue it's because product management is more applicable to more types of businesses than developer relations, and that is certainly true, but I would say the success of product management in tech is largely in part to how new product managers are created, mostly due to things like associate product manager programmes.

Associate product manager programmes will start by Google in 2002, and the A PM scheme offers a fulltime role with full-time pay, where applicants learn how to be a product manager from scratch on the job. They often include product management bootcamps, teaching all of the fundamental skills by experienced product managers and a rotation through different product teams so that product managers get to experience the whole breadth of the profession and all the different ways it manifests. They also provide defacto professional bodies.

The alumni network of the Google programme, for example, that programme, that alumni network is now 20 years old. It's influential on the future careers of those members, and they hire everyone from new grads to career changes, providing an entry path to all kinds of people from all kinds of backgrounds. Most tech companies now have, most large tech companies, sorry, now have a large A PM scheme or some AP M scheme, at least in short, these AP M schemes provide a path for people to move into product management with clear expectations and support.

They recognise the skills important to product management and train for those skills rather than seeking them in related fields, they provide an infrastructure for knowledge transfer that has allowed the profession to grow and advance. They have broken the cycle. I hope DevRel can break the cycle if nothing else. I hope that this talk will help you in your journey. If you're new to DevRel, I hope it'll help you spot the gatekeepers and the pit traps and avoid them and make your path a little bit easier.

If you're an experienced DevRel practitioner, I hope it helps you think about your role in the future of the profession through the maintenance of the knowledge that you possess and that you are adding to here today. And if you are hiring for DevRel roles, I hope you think about how you could contribute to breaking the cycle and making DevRel a lasting and sustainable profession. Thank you very much. That is the end. Hi, been Joe Nash.

Matthew: Thank you. Joe Nash, two of me. Nash, that was wonderful.

Thank you.

Carmen: Thank you. That was amazing. My

Matthew: Pleasure. Thank you. I think that's the first time we've had a dungeon master

Joe: Talk, so thank you for that. Honestly, I just need an excuse to make a d and d key note template.

Matthew: Cool.

Well, so let's turn to Discord for some questions, Ramon. So we've got, Hugh says you have to give another talk about how to have big dungeon mass energy.

Joe: Yes.

Matthew: That was

Carmen: Amazing. Folks were quite intrigued by not so much the art as well, but also the layered template on top.

Joe: I'm happy to talk about this. Some people asked, I'm going to add my screen share back to the screen. I'm very sorry.

Matthew: Oh, we lost your audio.

Joe: Oh yeah, of course. That will happen. Some people asked about streaming techniques for Devra people. This is keynote in, but what you're seeing is a screen share through my OBS, so that's how I'm able to do these transitions. So I've set this up to give me the space I need, but then the slides are driven by Keynote One day. I'll give a talk on this as well because I've had a lot of fun during covid with just really getting into OBS and using it for things I really shouldn't use OBS for.

Carmen: Yeah, plus one for OBS.

I'm a big fan as well.

Joe: Yeah,

Matthew: So just taking a step back from before your talk Tamao is asking, well, she wants to hear the resources that you shared with Ramon that you mentioned.

Joe: I wish I could say what those were, but honestly I have a five minute memory and that was a while ago. Does Carmen know

Carmen: I have 'em here. You did them to me, Joe, so I'm happy to share them briefly if I may, and then I'll put links up.

Joe: The irony of me talking about there being no knowledge transfer and not being able to remember which resources I sent Ramon,

Carmen: I didn't mean to put you on the spot, Joe. That's okay. No, you recommended the hardware education framework called Teaching for Understanding.

Cool. Oh,

Joe: Nope, keep going. I thought you were going to say, I thought you were going to say a different book, but yeah.

Carmen: Oh yes. Stephanie URIs, resources on content production.

Joe: Yes.

Carmen: Platform Revolution Made to Stick and Traction. Three books recommended for new donors to the GitHub team.

And there's a book on DE Communities, no on Communities

Joe: Practise. That's one I thought going to say

Carmen: Yes. And that is,

Joe: Sorry.

No, go ahead. No, sorry, I'm just now very excited. Yeah, those are all. So to run through those and why I recommend them. So the first one, the Designing for Understanding is a lot of those resources come from my time at GitHub and from the leaders there, mainly Ella, Vanessa, and John.

So the Designing for Understanding is like an educational framework that was created by Harvard and that Vanessa taught the campus experts, actually GitHub campus experts once. And I really appreciate it and use it a lot. The free books you mentioned, traction Platform, revolution and Made To Stick are just all really fantastic books on platform marketing and marketing in general. And these are recommended by John Briton to new Join us to develop marketing team. And when you hear about the marketing aspects of DevRel, those are really great books to start and understanding it.

Particularly Platform Revolution, which talks a lot about the existence of platforms in two-sided marketplaces, which are pretty core to a lot of the API industry basically. And then the other ones, there's two community books I recommend. One is building Successful Online Communities by MIT press, which anyone who has spoken to me for more than five minutes would've had this recommendation because I'm obsessed with this book.

It is in my mind the only community, the only community development book that isn't based on EC data. It is basically like a bunch of MIT, well, I dunno if they're from mt. A bunch of researchers stake out all these design claims about communities. So they'll say actively calling on community members increases participation. They just make these claims. And then the book then dives into it and assesses whether those claims are true or not and gives you the evidence and gives you how it works.

And it's so well researched. Every single thing is so well cited, it's so actionable.

That way of design claims is like you can have a problem in your community, pick up the book, find a design claim that addresses it, and you've got the blueprint. It's just the best book ever. I love it so much. And then the Communities of Practise one is from Per Hammer, JP Morgan, very relevant to the knowledge transfer. The way developer communities work is very similar to this existing thing called Communities of Practise, which is, as it says, communities around practitioners of a certain field. And it's a very well studied industry or very well studied thing I guess, that I hadn't really heard anyone talk about before per introduced me to it. And the book, which might be one over there, the book is really good. I'd highly recommend it.

Oh, thank you everyone.

Carmen: Oh, thank you for recommending those.

Matthew: Okay, well we have a question from Tron who says, ironically, I've been trying to convince our product manager about the similarities of the job, however, doesn't this require people to subscribe to the idea of products led growth?

Joe: And then he says, I asked because I'm still sceptical of the product led growth. Product sells stuff, the product sells itself if it's really good. Oh, that's a really great question.

Matthew: From open source projects and developer led projects over the years

Joe: Of, well, it's good

Matthew: If the code's good enough, it'll sell itself,

Joe: Build this, and they will come. So I agree.

I would say Neva approach stands alone. And I've had several experiences in the last couple of years that have really actually convinced me that although product led growth is not sufficient on its own, if there is not some element of truth to it for your product, you are doomed. And what I mean by that is I've done DevRel work in a freelance capacity luckily. So it wasn't too effective, it wasn't too detrimental to me for a couple of products that if we're honest, we're not yet ready for prime time. And I've been in the position of trying to build community, trying to do, develop advocacy around those products when they didn't yet have product market fit when they didn't yet really serve a need. And the thing I would come back to time and time again is like, what's the point of me doing this? I bring people in and they bounce off. So I agree with the scepticism about product-led growth.

It goes hand in hand with outreach. And I don't think, if anything, that's more of an argument to the similarities between the two roles in that they are two different lenses on the same thing, which is meeting the needs of the customers is how I would answer that.

Matthew: And one p Flores is in the Discord now sharing links to the various, of course, Juan

Joe: Pablo is amazing. Thank you for that.

Matthew: Okay. Yeah, thank you. Alright, so Joe, one last question from me then.

Carmen: Yeah.

Matthew: I think a lot of what you presented was an honest reflection of where we're at, but if you were to have a hopeful and optimistic view of two years from now, because I think one year is not enough to make much change, but what would you like to have seen changed at that point? We're talking again in DevRel Con 2023.

Joe: I would like to never hear people say DevRel is new. Developers don't like marketing. You can't measure the value of relationships. Basically, I want us to develop a culture of knowledge transfer. That means that more than the piffy lines survive, I want us to get beyond these little truisms and to the skills that properly uncover the truths behind what truths there are behind those things. And I want this to be the last ever com where anyone submits a or talk about metrics.

Because it's solved. It's solved, it's solved. We've done it, it's done. No one will submit one ever again. There we go. That is my answer. So

Matthew: We're allowed to have metrics next year because it's not solved at that point. But in two years time, in

Joe: Two years time in, honestly, I, I've been quoted as saying no one at DevRel has ever read anything ever.

And that's a bit harsh and a bit untrue. But we need to do something about the fact that we don't retain knowledge. And I think there's lots of things that contribute to the fact we as a profession don't retain knowledge. And I think some of it is the motivations for creating content about DevRel as well. It's very fairly creating DevRel content is also about personal brand. And so there are certain topics that are going to be trot as part of that just as there are in any blogging sphere, but it does have a real effect on people. And the anecdote I told Matthew when I was pitching this talk was I heard not too long ago from someone applying for their first DevRel job, and they told me how they got in an argument with the first they approached about the department that DevRel reported into because they had heard from us from this community that it matters. And they didn't know why and they didn't know what they were arguing for.

They report, the department reported into marketing and they knew that was intrinsically wrong because we said it was. And that's what I want to stop.

We need to train people. I want to see a training programme. If you have the capability to hire DevRel people in 2021, I want to see those people be juniors and I want to see them trained in fundamental skills. And that is my spiciness for the conference.