Made by
Made by
VP, Developer Relations
Hashicorp
DevRelCon 2021
To build a DevRel organization within your company, it is essential to give your team clear guidance on how they can grow, develop and get promoted.
A career matrix is a useful tool that explains core DevRel responsibilities and performance expectations for each level. This talk from DevRelCon 20201 describes a process for creating a career matrix that matches with your company’s culture and walks through a concrete example.
I’m Adam. I’ve been doing developer relations for most of the last, I think it’s 17 years now, something like that, at various different companies, most recently at HashiCorp. You can find me on Twitter.
All right. So, let’s talk definitionally, what is a career matrix? So, dictionary definition, it’s a document that describes functional responsibilities for a job or role that outlines expected impact on performance by job level. Practically, it’s a tool that’s used by managers to communicate expectations for career advancements within an organization.
Or cynically, it’s a weapon used by idiot managers to thwart my career ambitions and hide behind when they don’t understand my genius. It’s one of those three things, or possibly all of them anyway. We’ll try to avoid that last one anyway. But in a general sense, I’d kind of say a career matrix looks roughly like this, right?
You got a collection of columns that correspond to individual job levels. So, here, we’re listing them as associate manager, senior manager, principal. Maybe you’ve got them as junior, regular, senior staff, or some other set of titles, whatever your titles are, maybe there’s more than four.
Maybe there’s 6, maybe there’s 8, maybe there’s 27, maybe a lot of them. And then you’ve got rows that are the job functions, and then the common job functions for this particular job family. Now, that gets a little complicated, but you got to do one thing or two things or three things. And then each cell in the matrix is filled out with a description of the job responsibilities that call to that function by level.
And this allows you to have a conversation about what happens. This is all random text in this slide, but we’ll actually look at a career matrix in a second. You know, in a matrix, a matrix has got basically two dimensions, like the number of columns, number of rows. So, you’ve got to ask yourself how many columns should I have in my career matrix? And in my experience, I’ve been making career matrices for the better part of the last seven or eight years for various different functions.
The number of columns kind of depends upon a collection of things. How big is your existing org? How mature is your company? How often should you be promoting people? That’s usually a philosophical statement or HR organizational statement from the company perspective. And on a practical level, quite often, the levels inside your organizations may be actually limited by your ability to discern the difference between those levels.
And that may actually be related to the amount of salary and compensation information you have about those job roles. We don’t have very good salary banding for developer relations, generally. If you go look at Radford or any of these other services that provide salary bands, there’s no information about DevRel.
There’s a little bit about advocacy and evangelism, but they’re not very useful. So, most of the time in the DevRel space, you’re making most of this up. There’s still a huge amount of variation, as the size of your company and the maturity of your company, and your promo philosophy. So, you know, I’ve got some recommendations later on. But you could start out with three, maybe have four. At Amazon, I had six.
I’ve got six levels in the career matrix for the DevRel team at HashiCorp. And you can actually see here, the column themes. The ones at the bottom here, learn, coordinate, execute, own, evolve, lead, those are actually the themes from HashiCorp. That means that at the most junior level, you’re learning the role, learning the responsibility.
At the next level, your responsibility is to coordinate the execution of the things that are going on. The next level, you’re actually on the hook to deliver and execute things. And the next level, you’re owning the direction and responsibility of the program function on the output you’re engaging with. The next level, you’re responsible for setting the next stage of evolution for that function capability category.
And then the last, the senior level is leading that overall function, being responsible for setting its direction. So, you can see those main sorts of ideas. If we get asked about the columns, let’s ask about the rows. So, here in the sample diagrams, “Do thing 1, thing 2, thing 3, thing 4.” Well, how many rows should there be in your career matrix?
Well, again, it depends on a bunch of other things. Possibly, the biggest one it depends upon is what your definition of DevRel is. And I don’t know. I’ve got an idea about what DevRel is after I’ve been doing it this long, but it’s certainly not unique. It’s not universal, and there are plenty of different unique takes on it. And in lots of different companies, DevRel means different things.
Do you have an open-source component or you’re a closed-source company or you’re a SaaS only? Or do you DevRel function operate in the partner ecosystem? Or is it only responsible for direct user engagement? There’s a whole bunch of questions there you got to answer to work out what it is you’re expecting people to do in this job function. And to a certain extent, some of those things are dependent upon your company maturity as well.
Early-stage, you probably got a couple of people doing everything that’s DevRel-related. But once you get a little bit bigger, you might be able to specialize in the individual job families. So, you might be able to separate your content creators from your engagement specialists from your program managers, for example. But, you know, it’s all about where you sit inside the growth of your company, and to a certain extent, what your company’s principles or philosophy is about these sorts of things.
Column themes…sorry, the row… sorry, the column themes, [inaudible]. The row themes for HashiCorp are technical expertise, storytelling, ambassadorship, effective communication, growth mindset, customer focus, driving outcomes, and setting direction. And the first three of those: technical expertise, storytelling, and ambassadorship, adjust for the DAs.
The other five down there are the row themes, specifically for the general marketing organization, which the DevRel team lives in. So, these are common traits we expect across marketing. And then there’s a layered set of job functions that’s specific to the DAs. All right.
So, that’s the columns and the rows. So, what goes in each cell? Well, on each cell, you should provide a description of what the performance at that level for that job function is. And the best advice possible for this is to do it with very, as little flowery language as possible, do it with absolute clarity, try to be as objective as possible.
It’s not necessarily you have to make it numeric, although I’ve got other points of conversation about impact hours that relate to numeracy here. But also, try to make it as clear as possible because this isn’t just a document for a manager, it’s a document for everybody in the organization to understand what performance expectations look like.
Again, if you have company principles you want to echo, you might want to feature those inside the document itself. And hence more specifically, when you think about it, when you read these documents, you should expect that mastery at one level is implied by reading at the next level. So, he can actually see that this cell right here is presuming that you’ve actually mastered things in the cell.
Anything that you do in the senior manager level, you’re expected to have the skills to do that at the manager level before it. Is there a reasonable expectation ? Maybe not in every situation, but it’s the way to think about how these documents build on one another as you go across reading them. All right, so, let me just go ahead and show you a sample one.
So, I’ve created a career matrix to use at HashiCorp, at Amazon, and prototypical ones, back at other companies as well. But I thought I’d create sort of a fictional one to kinda serve as possibly a template for a generic organization that has a small DevRel team, so a DevRel team of five or less people, early-stage or small org.
And so, I kept trying to keep it as simple as possible, and it’s small. So, there’s going to be three columns. One is the baseline column for a developer advocate, the deliver column. The thing this is responsible for is actually doing the work, the advocacy. As a senior developer, I’ve got responsibility, which is much more like, okay, I’m not just delivering but I actually have some sort of input on strategy about what’s going to happen, and I’m responsible for making sure things operate well.
And then there’s a sort of leadership responsibility, director-level responsibility in this in here, could be another title relevant for your role. And that’s where we’re saying, “okay, I want to develop this org in a way that’s appropriate.” I’ve sort of broken-down DevRel into a five simple functions, technical expertise, outbound interaction, inbound interaction, customer focus, and execution.
So, why don’t we actually flip over to this spreadsheet? I’ll share this with everybody who wants to take a look at it. And I kind of broke it down into these individual pieces. So, let’s pick out, say, one of these rows. If I take a look at technical expertise, there’s two sub-functions in technical expertise for general and specific.
If you think about…specific here, we’re talking about, all right, what level of technical expertise should a developer advocate have for this particular function? Well, here I’m saying, “Maintains comprehensive knowledge of complete product portfolio and how they apply to key use cases.” The next more advanced level, you would be saying, “Able to articulate long-term product and company technical vision in a way that is consistent with the value users will understand.
That’s on top of understanding product portfolio. And then at the director level, it’d be providing expert guidance to the executive team about how to plan product development to maximally capture the attention of technical audiences. So, you can see there’s different levels of expectations across the row by the level of the job level at the top.
You can go down each of these individual rows. Hopefully, the language is clear enough that people can understand it, and then differentiate between one level and the next. So, for example, if we do outbound communications via talks, your standard developer advocate needs to be able to own the end-to-end process for delivering a talk at a digital or in-person event, conceive the topic, submit to this CFP, develop the content and deliver the presentation.
That’s great. But I assume the developer advocate is going to be able to do all of that and be considered an excellent presenter and valued expert in this particular community or technology space. And the biggest indication that that’s true is also that they’re going to be invited to speak at third party events or industry events.
And then at the director level, you know, should be really an exemplary technical presenter who’s able to create original presentations for audiences. And you’re invited to keynote, not just to deliver content. So, you can see the progression from one column to the next. Some of these might look like really big jumps here in this particular template. But if you’re going to have more columns, or if you’ve got more different levels, you’re in a larger organization, you need more differentiation between these job functions, then you can actually pass those out a little differently, and then be more fine-grained about it.
You know, there’s a whole list here. This is a publicly-readable document. I’ll share both the presentation and this document in the Discord channel, after the talk and maybe we can go poke holes in it and argue about whether I’ve said the right thing about what thing and then tell me that my definition of the developer advocate is inappropriate and possibly have sort of fine arguments, that’d be great to have.
Intentionally, I’ve been very, very broad here. So, there’s a whole list of things here. So, for example, let’s just think about, you know, inbound catalyst functions. Here, this just talks about defining broad-scale programs and fostering community engagement contribution, then maintaining feedback loops with leaders in the external community.
And then building programs that allow these external champions to be used in high-profile customer communications. Like that, quite often, that function in itself winds up becoming an individual program inside of a large organization. And it will probably be run by a program manager instead of being run by your DAs.
But when there’s only like a handful of people in the DevRel org, everyone’s kind of all hands on deck, and you don’t have the headcount to spare to go get a program manager in order to do that. So, this is very, very broad in terms of job functions in the columns, and very, very narrow in terms of the levels across. So, if we go back through our presentation, you know, the next thing to think about is what happens if I’m not at a small company?
Maybe I’m in a mid-sized company and my DevRel’s org size is less than 20 people, but bigger than 5 people. Then you might actually wind up splitting things out into multiple job families. You’ll probably keep something similar to the developer advocate job matrix, career matrix. Here, you might have now added a principal developer advocate level. You’ve separated out the IC responsibility from the director level management responsibility.
And maybe you’ll no longer have your director as a player-coach, maybe they’re much more of a people manager, as Jeff talked about in the last talk. So, there could be a little bit of sort of that you need to tease apart, or there could be more divisions in this. Or if you work at Microsoft, you could already have 27 of these different columns if you wanted. And then I’ve kept the same broad job functions here in the rows.
But, you know, you could actually see a way to extract or narrow some of those things based upon the conversation we just had about the short doc. This would be what I would recommend. Once you get to this sort of size, you start doing some specialization. You start recognizing there’s job families that aren’t just developer advocates.
You’re not going to have an army of 50 developer advocates and still be a mid-size org. You’ve probably got some kind of specialization. So, if you’re looking at one of the first places I expect specialization to come in is when you look at your documentation or technical content creation. And this could be as simple as writing the docs or moving the docs work out of product and into a DevRel org, or actually having a separate responsibility for creating content that engages with technical audiences, largely on the written side.
And so, this is actually not that different from the map we have for the technical content creation team at HashiCorp. But the idea is you have, you know, sort of base-level expectation for people to be able to deliver content, a technical creator, and then somebody who’s able to do more than just sort of read through the technical docs and turn it into readable material, but turn it into something that actually translates more directly to customer use cases.
That’s a synthesized approach. So your senior technical creator should have a high index for customer or the developer pain points and be able to take the baseline information and turn it into really valuable information. You might have somebody that’s on the IC path that is very close to being sort of a PAM product expert that can actually tie things more directly into universal themes that are happening across the industry or across your technical domain, and you’re looking for somebody that is going to be able to say, “Let’s look at the library of existing technical content, and how can I improve that overall structure of that library and produce new, innovative ways through interaction?”
It could be sandboxes or playgrounds or demo environments or video instructions, or whatever it is as a way to sort of push the envelope of the technical content that’s being created there. And then again, we’ve got somebody on the right here that’s responsible for org structure-wise management of the team. And this is much more of a manager function.
Although I’m a strong believer on the technical content side, you want your, you know, you want this…your people manager to actually be somebody that comes from this content creation background and has a real understanding of how to be productive there. Job function-wise, we look across the rows, we’ve got several are the same, technical expertise, customer focus, execution.
But the two pieces that are really important here, the flip for content creation is very much about content creation and process of content creation. There’s a collection of different levels here we talked about a little bit when we talked about these roles for content creation that sort of expand across this. And then the role I have here is this notion of conceptualization, the idea that there’s a certain level of abstract thinking you have to have in order to operate at more senior levels here.
And so we have different expectations for what your level of conceptualization is for each of the job levels in this role. You can sort of like divide up different pieces for those bits. Similarly, for the technical content creator, the other thing that you frequently split out once you go into a midsize DevRel org, is somebody that has responsibility for either community management or more likely program management within that family of community.
This is usually a little bit more of a straightforward program management execution-style responsibility. And it has great similarities with certain programs that you might see in things like, you know, field marketing, for example, or customer success. And so, I don’t think there’s quite as much a necessity to have as many level differentiations here, and you can actually get very effective junior staff to go operate in these areas.
So, we’ve got three columns here, associate community manager, community manager, and senior community manager. And then you would sort of like expect anybody that’s operating at a high level, the senior community manager, to also have a responsibility that spans into either content creation or into advocacy as well. We’ve got a few differences here in terms of the job functions that I see when I look at program management.
Effective communication is the top-level responsibility because very seldom are program managers able to do anything individually by themselves. They often have to interface with other teams. So, that clarity of communication there is incredibly important. They’ve got to be able to execute because it’s only successful as a program itself. Efficiency is the key measure of what your program management does. If you’re going to run twice as many programs and you need twice as many people, then you’re doing program management wrong.
The goal of program management is to automate things, get the people out of the system so that things can improve. And your job as a program manager is to drive everything to be more efficient outcomes. The responsibility for being efficient increases in job level responsibility, which is why that you seldom see a program manager at the very, very senior levels. Again, customer focus is super important.
And impact is the other critical part here. It’s very easy to be caught up in program management work in busy work. I did lots of things. I took lots of tickets, or I checked off lots of things on the to-do list. And that quickly disconnects you from all the things you’re doing actually making a difference for the technical audience that you’re targeting.
So, impact is the critical part there. I’ll add sample career matrices for each of these additional job functions in this mid-level size stuff to the spreadsheet of the next week. I’ve got some nice outlines. I think I’ll do that. If you’re in a large org, you’re more than 20 DevRel people, don’t listen to me. You shouldn’t even be talking to me.
You’re going to be talking to your HR business partner. If you don’t know how to write the career matrix for that size org, they certainly do. And they should be able to help you. If you want to talk about it with me, I’ve written career matrices for orgs as large of 120 people. And so, you know, we can have those conversations, I’m happy to help you out. But literally, your HRBP knows your company philosophy, knows the levels inside your business, knows the salary patterns inside the business.
It’s probably got baseline career matrices for the other job functions inside your company that are worth using. So, go talk to them, it’s worth doing. I’ve got a collection of other small thoughts before we get to the end. All right, so, there’s always a question about individual contributor versus people manager. It’s generally true that the career matrices for these two things are not the same.
I’m a big fan of player-coach sort of behaviors at small and medium-sized responsibilities, particularly in the advocacy responsibility. But that said, generally, you should think about general people manager career matrices. And that should be universal stuff across your entire company. Some part of it may be unique to your organization.
But generally, those things are common to the entire company. Another thing you should think about is minimal promotion requirements. So, there’s a lot of rows there in that career matrix. How many of them should you be successful at before you’re eligible for a promotion? Well, it’ll better be at least half of them, right? And that’s like some judgment value for this.
Depending on your organization, you may have different criteria. The general rule of thumb that I’ve seen work pretty well at Amazon and HashiCorp is you expect the preponderance of those job functions to be successfully executed by the candidate, and them to have demonstrated success of operating at the next level for a sustained period of at least six months before they are promo-eligible.
It may be longer than that before their promo, likely. But that should be sort of like the minimum requirements. There’s a bunch of things that could inform that, including personal philosophy, organizational philosophy of your company, and a bunch of other things. So, you know, you’ve got to think about it and know that’s a part of it. The key tip here is the third one here.
The career matrix is just the start of the things you’re going to create in order to help you as managing your organization. The most important thing to create after the career matrix is to create delta documents by level. This is what is the difference between level five and level six, or level six and level seven? What is the difference between, developer advocate and senior developer advocate?
It’s laid out there in the career matrix because if you can write a difference doc that actually tells you what the difference is, that winds up becoming the outline for the promo justification doc. It also winds up becoming the outline for the personal and professional development plan for the individual in your organization you’re helping to try to advocate for their promotion. So, the diffs wind up becoming super important in having the conversations about helping people manage their careers, okay?
So, that’s kind of, like, the career matrix is your starting point. The diff documents is the next things that come up next. The last part here is don’t reinvent the wheel here. You will think you’ve got a lot of unique requirements, but you’re probably going to find out, like, surprisingly, a substantial amount of the things you think are specific to your job responsibility actually have intersections with other job functions inside your company.
Here I said DevRel versus SysArchitect. Maybe it’s another job function, but an intersection of those two sets is non-empty. I encourage you to engage with the other leaders in your organization as they work out how to interpret what they’ve written in creating those career matrices. I certainly created all my career matrices by copying other people’s and then changing them to fit my organization and my company’s philosophy.
So, that’s something I strongly recommend. Certainly, I didn’t just make this up, there are actually two good DevRel career matrices out there. Bear and Mary both published ones last year for Slack and Camunda. They transposed their career matrix in the way I’ve been writing my career matrices for the most of the last decade.
But I wrote in my way. There’s no difference. It’s a transposed matrix. You can work it out anyway you want. But it’s definitely worth taking a look at and worth reading, and a good starting point, as well as using the template I sort of outlined. But you should pay attention to how thing are written because they really are an expression of the philosophy of that individual company when you go take a look at them. So, definitely use all the resources.
And these are great people to use the information from. And lastly, just remember, the career matrix exists in order to help you have conversations to improve people’s trajectory inside your organization, their development, their growth, their learning, their understanding. If you are the recipient of the career matrix, don’t be afraid.
It’s there to go help you become the person that you want to be. And that really is your choice, your thing to do. It’s not your manager’s job to do. It’s your job to work out the person you decide to be. It’s the only thing you really are in charge of. And hopefully, the career matrices and a good manager can help you in those situations.
All right. That’s it. I talked a lot. I don’t know how long I talked for. But I’m happy to answer questions. What do we have here? Hashi is 1500 people?
Yeah, we’re a little bigger than that now. Yeah. DevRel at Hashi is about 50-ish. We just crossed over 50 this year. When I was at Amazon, evangelism was 75 when I left, Dev marketing was 15, something like that.
That was a couple of years ago when I left. I don’t know where they’re at right now.
That’s one of the important parts about these documents is they’re living documents, right? They shouldn’t be static. They should reflect where you are in the organization, where the growth of your company is, and what needs to happen. So, it’s not unreasonable to say, “Hey look, just looking at the way the organization is stacking up and well, where are we going to be bringing people in?”
We need another vertical slice here. We need another subdivision of this responsibility. “We need another management layer,” for example, is a common thing for people to add instead of having everybody just report to a director or something like that. And these can go up as high as you want. The one I wrote at Amazon went all the way up to VP. So, Jeff Barr’s promo was against the yardstick I wrote in the career matrix.
I’m not sure he thanked me for that. But I’m pretty sure it was not something he must be happy about.
Yeah, so that’s a great question. So, like I say it’s a living document, but you hope you’ve got it right, mostly right the first time. If you’re going through and making a bunch of really major edits, that’s a little bit of a concern. Your first write of this is probably the thing you want to spend the most time on and the most that you’re going to go do most iterations on.
And then the next should be sort of, like, incremental changes. There’s very little point updating these on any cycle less more frequently than annual. If your org is moving so quickly that you need to update your career matrix more frequently than that, then you might be better off just saying, “Here’s the general template we’re going to use, and we’ll revisit this in a year’s time and just use this as guidance.”
Because if you’re rewriting it all the time, you’re not getting the value out of it. The value you have out of it is you’re setting a collection of goalposts that you’re helping your team shoot for so that they can understand what the next set of expectations are for them. And so, that’s the thing that I would sort of, like, you know, push on.
You can make tweaks and tunes to it, but if you’re going to go make a major revision, you know, don’t do that with any more frequency than annually. And, like, realize that every time you do do it, everybody that was judging their career progress by your doc is now going to think you moved the goalposts on them, right? And so, that’s why getting as much of it right the first time as possible is super important.
[Tamao] Go ahead, yeah.
So, it seemed that you’re in there answering some questions, asking some. So let me scroll up to the top just to make sure…
I think that one was the top one, or you had one as well, right?
I did. I think this is a quick one. Did the functions come from the company or are they specific to DevRel?
Well, I mean, I tried to be… So, in the doc, in the sample one that I created, those come from my conception of what a general DevRel responsibility list is in a small org, right? So, I think back to my times in small companies. And it’s like these are the things I was asked to do.
Well, I mean, I didn’t include sales training and running the website and, you know, managing the licenses of all the web software and all the other kinds of stuff you wind up doing because you’re the only technical person that exists in marketing, right? That’s a different thing. This is just, like, if you were just doing developer advocacy, this is what I expect the laundry list of things you’d be asked to do is.
But there might be some things in there that are very much sort of, like, related to the company principle or culture. So, in the template I have, under External Execution, I’ve got, “Engages all users across all channels in a way that exemplifies the company’s principles for integrity and humility.”
Those are actually very…integrity and humility are two of HashiCorp’s leadership principles, along with a collection of others like pragmatism and execution, and beauty works better, and all these other things. So, that’s very much HashiCorp language. I would hope everybody in DevRel has integrity and operates with humility, but that may not be a principle for your organization.
You may have sort of an organization that values, so like different things, and those would be expressed as some of those, sort of, like, responsibilities. So, it’s entirely possible that, you know, one of those job function pieces is an expression of the company principal. Customer focus, for example, is a job function thing that I include there that’s kind of a hangover from Amazon’s customer obsession.
HashiCorp has a very similar sort of, like, sense of paying attention to the end-user with a high degree of integrity and thought. And so, like, it makes sense for me to include it like that. But that may not be the language other people use there. Or you may be in an organization where your developer relations responsibility is actually about not customers, but a partner ecosystem development, for example.
And so, that might be a job function that is culturally more responsible for that type of job. So, this is my best approximation. You know, adapt for your own circumstances, so to speak.
Yes, I would love to read a paragraph. There’s an overlay to the career matrix, which is compensation and retention. I noticed that the last gig there was a big desire on the part of a lot of employees to see a promotion about once a year, which seems brisk to me.
How do you balance the career matrix and the needs of the business versus expectations around compensation and retention?
There’s a lot there.
Yeah, there’s a lot. Thank you for that. There’s a lot in that one. So, let’s talk promotion first, and we’ll talk retention and then we’ll talk compensation, okay? All right.
So, I would hope your company has a philosophy about what appropriate rates of promotion are. Right? That’s an expectation you should have from your people lead, okay? There are companies, and Microsoft is a phenomenal example this, where they’ve got very, very large levels with sub levels.
And there is an expectation that you’re promoted every year or every other year. Like, you have these little micro promotions all the time. There are other places where promotions are actually bucketed in very, very large tranches, and you have a log scale of promotion. So, you might get promoted at the junior levels every two years.
Then you wind up again taking 4 years to get promoted to the next one, 8 years to get promoted to the next one, and then, like, 20 years to get promoted to the next one. Amazon is not too dissimilar from that sort of, like, level. There are people that are set at a career level for, like, multiple large year tranches at Amazon. So, you’ve got to have an understanding what your philosophy is in an organization about what promotion means.
It’s not unreasonable for you to express that in a career matrix, like a requirement to get from one level to the next level as an expectation of this much amount of, sort of, experience in this role. I kind of hate the experience sort of, like, thing because if you want…people come into DevRel from all sorts of different places.
And so, like, if I’ve been doing DevRel for 10 years, it doesn’t necessarily mean that I’m any better at it than somebody that has that super relevant experience in that particular product, and comes in and happens to be naturally very good at engaging with the community. They shouldn’t get to say, “Oh, you’ve got to wait 10 years to be as good as me,” if they’re already demonstrating impact as high or better than me, right? And so, there’s an element there that you don’t want to guard off on the promotion banding with timelines, which is why you want to make the language in each of these columns as clear as possible and try to make it as objective.
The one thing I’ll sort of, like, pimp here is the thing I did successfully at Amazon and the thing we’ve been copying at HashiCorp that we talked about last year is measuring impact hours for DAs as a mechanism for measuring overall performance.
And it turns out, in my experience in both of those places, those impact hour measures kind of bucket everybody very organically into these levels. They just fall into those levels based upon their output. And then all of a sudden, you’ve seen somebody that’s gotten impact that is higher than their current level.
This is a fantastic signal you should be considering for a promotion, right? So, like, promoteability, you know, you don’t want to make it hard and and fast based upon time-based windows. But you do want to think about it from a perspective of, you know, there is a philosophy we better work out in our mind as an organization before we get to that point. The second one was retention.
So, let’s get back to the reason… So, for the most part, the reason that I’ve been pushed to create career matrices in most of the places I’ve been is because there’s been an exodus of talent or a concern that people aren’t going to be retained, or they don’t know what their career path looks like. Well, this is the explanation of what your career path looks like.
Or if you’ve come from SDE land where there’s an SDE matrix that everybody understood and it’s been around for 10 years, and now you’re in the wild and woolly west of DevRel, like, you know, it can be disconcerting for those people to make that transition. So this enables you to have some sort of, like, concreteness. But retention comes down to a lot more than just are you being promoted?
Quite often, that’s sort of the excuse or the dissatisfaction people express. But retention really comes down to do people feel like they’re in charge or autonomous, in charge of their career, being able to drive to the next level? Do they have clear expectations about what they’re trying to do?
And are they given trust and space in order to execute on the things they’re trying to do? And so, if you can cover off those three things as a manager, you can get better retention, career matrices to…two of those things where they set clear expectations for you. And they allow you to give people the freedom to flex inside that set of responsibilities and know where they stand.
But you still got to trust those people to go do the right work and give them the opportunities to go do it. So, it’s still up to you as a manager to make sure you’re giving people the right sort of projects and work that will keep them retained. So that’s one of those things that’s just sort of, like, career matrices are not a panacea, they’re not a solution.
They’re just an aid to help you as a manager. Compensation is also a retention problem. And like I said, a lot of these levels some of that comes down to what is your compensation philosophy or what is your compensation information? Like, compensation bands for DevRel in particular for DAs are kind of crappy. They don’t really exist in most commercial tools.
Even the, sort of, the groundswell sort of engagement for trying to build compensation bands with DevRel, the couple of people in the community have done are like, they’re okay, but they don’t necessarily comport with the bands I’ve seen inside organizations. And then there’s a lot of argument about is a developer advocate equivalent to a technical position plus an extra capability so they should be compensated more highly, or are they not somebody that’s carrying a pager and don’t have the SRE on core responsibilities that somebody else’s mission-critical might have, and so they get less compensation?
Like, there’s a bunch of sort of, like, different points of view in arguing for those things. You’re going to see compensation be a really strangely discussed topic in DevRel for a long time. And until there’s a big enough population that survey programs like Radford and others will be able to pull them and get that information in the hands of your HR department, it’s going to be kind of a little crazy there.
And it will always be blown up by large organizations that are going to be willing to pay top dollar for some of these things. So, you know, I’m so excited, but Google kind of blows the curve on all these computations. So you wind up with… And Microsoft does it too, unfortunately. But you wind up with you know, recruiters coming up and picking at your DevRel team with really, really attractive salary pieces.
And that’s just really hard to compete in that kind of environment. So, I wouldn’t put the salary stuff in the career matrix, but I would use the career matrix and your salary band information to inform your decisions about how many columns you have across the matrix. All right, that was a lot of talking for one question.
And Craig, I’ll talk to you on Friday about it if you want.
Yes.
Stilly typing, so maybe we should wrap up before he fires off another question.
Absolutely. And I’ve got a couple more queued in there. So, we’ll take it to Discord. Sorry, Adam, thank you so much for wrapping up our fantastic Day 2. Of course, always great. And I saw, this time we kind of inserted equation-like things.
I tried. I tried. I got the empty set in there. I was just very happy. I was very happy. I mean, it’s just the most trivial mathematics I could put in a slide, but I wanted something in there just to make me happy and keep my streak alive.
Exactly.
