GitLab’s DevRel career ladder

John Coghlan: So 2021 has been a pretty interesting year. In some ways it feels like we're still living in 2020, but in some ways things are obviously a lot better. We had the vaccines bringing us hope at the beginning of the year, and then a slow kind of rollout in the Delta variant felt like a big setback and kind of delayed us getting into the new normal. Now, the past few months have been dominated by these discussions around inflation, supply chain bottlenecks and labour shortages, and it's becoming clear that mass and virtual events aren't the only things that have kind of changed in the post covid world on labour shortages in particular, much of the conversation has been focused on the impacts on the retail and hospitality sectors, but the impacts of the tight labour market have extended into every industry, including tech. I'm sure many of you who are probably like me, extremely online types, have been seeing a lot more of those, some personal news tweets as people announced their goings and new beginnings in this kind of crazy job market that we're in.

And it's just another example of how the challenge of recruiting and retaining talent in tech has never been harder. And just listening to the discussion that was happening right before the Orbit video, people are talking about how expensive things are and the difficulty in finding senior level developer relations folks, and I think that applies across many different job types. Technology companies have been super resilient during the pandemic driven, both by their ability to kind of adjust to the changes in the world like working from home, but also the growing importance of technology and everyday life as more of our lives moved online.

I mean, we've all been attending virtual conferences for a few years now. Millions of kids did online school for an extended period of time. Lots of us were ordering groceries on different delivery services. So I think technology has really become even more prevalent in people's lives as a result of all of this change that's been happening.

And the kind of success of technology companies coupled with this need for every company to become a software company has created more demand than ever for this limited pool of people with these similar technical skillsets. And so there's literally more opportunities than ever before for technical people to go out and find work. And if you couple that with inflation driving wages higher, the end result is that more people are changing jobs, the shift is so prevalent that it's even got a name. The Great resignation, I'm not sure if anyone else is a fan of the news like I am, but you'll find countless articles online about this phenomenon that's happening across every industry, including tech.

And so I'll start by kind of talking about what managers, leaders, and organisations can do, but there's going to be lots of lessons for individuals in here as well.

Before I go on, I want to introduce myself. I'm John Coghlan. I've been involved in developer evangelism for more than five years. I've been in a leadership role at GitLab for just over a year, and I managed our developer evangelism team. The team consists of developer evangelists and programme managers, and collectively we engage with the GitLab community through content creation, community engagement, and community programmes like our GitLab Heroes programme, which recognises our most active community members. As we go through the Talk GitLab, our mission is that everyone can contribute. And so I'd love for people to give feedback, ask questions.

You can Google some of the stuff that I'm talking about it. It's all publicly available in the GitLab handbook. And if you find any typos or things that you want to change in the handbook, you can even open up a merge request and submit your changes.

And just tag me at John Coghlan one word in a comment on the merge request, and I'll be happy to check it out. And you can start contributing to the GitLab job families that we'll be talking about today and some of the process around building those. So to get started, I'm going to just kind of rely on a sports analogy, and I apologise, but I'm a big college sports fan, and in recent years, there's been changes in the collegiate rule book that have really empowered players. And here's a picture of my alma mater, Penn State. So one of the big changes for players is the creation of this thing called a transfer portal.

And student athletes can enter this portal, and they're allowed to talk to coaches from other schools and learn about the opportunities that exist outside their own campus. Another big change for student athletes has been the creation of a one-time transfer exception.

So previously students when they switched schools would have to sit out a full year of their playing eligibility before they could play their sport. Again, with this exception, student athletes who switch schools can take the field or court for their new teams once they're enrolled. And these changes have created more transparency, flexibility, and choice than ever before For players. The result is that coaches now need to worry not just about recruiting new players for their teams, but they also need to focus on recruiting their own players. So in the past, coaches would've been primarily focused on star players and bringing in new recruits, but now they need to make sure that everyone on the team is getting attention and happy in order to continue to build their programmes and their culture. And this means more work for those coaches, but it's clearly a net positive for the players.

And all of this is very reminiscent about what we're seeing play out in tech. There's more flexibility, more transparency, and more opportunity, and people or team members are finding that they can go out and really explore this job market and find great new opportunities elsewhere. And it's really shifting where the leverage is. And so this brings us back to that question I was asking earlier. What can managers, leaders, and organisations do right now? So we need to be recruiting our own players in addition to building up our teams and pipelines. So recruiting is more competitive than ever. Our team members have all of this opportunity in front of 'em and the importance of both recruiting but also retaining our teams has never been higher.

So we can ensure that we have happy high performing teams if we constantly have churn and people coming and going, we're never going to reach that kind of high performing level that you need to get to after you go through your kind of norming, storming levels.

And so when I think about building high performing teams, I always go back to a lesson I learned when I was reading Daniel Pink's book Drive. I don't know why, I can't remember why I read this book because it's really a book about management, and I probably read it like five or six years ago, way before I became a manager. But regardless, the lessons from that book have really stuck with me. I probably read it. I didn't like my mantra at the time. I was like, maybe I can give this person some pointers from the book.

But yeah, in that book, the author outlines three aspects of work that drive high performance and there are autonomy, mastery, and purpose.

And so based on some research that the author did, there's evidence that by providing each of these kind of motivators to your teams, you can drive higher performance than any extrinsic motivators, like higher pay or bigger titles, or kind of more responsibility. And so I often think about how can I provide this for my team? How can I give them these elements of autonomy, mastery, and purpose? And there are a lot of different kind of ways to approach that. But clearly this talk is about the DevRel career ladder. So we're going to focus on that because I think there's a lot in having a clear career ladder for your team that you can unlock to kind of drive each of these different elements.

So for people that haven't been listening to the other talks today, I know there's been a lot of great talks on this topic. A career letter shows the progression for a specific role through a number of different levels and provides a map for people to follow to achieve higher levels of responsibility and mastery in their chosen career path.

And it does this by providing clarity around each role and each level within that role. And so a well-defined career ladder will include an overview, detailed responsibilities and requirements for each level, performance indicators or expected results for each level. And it will show you how to progress out of bigger kind of job, family or the career path that you're on into higher level roles or even horizontal moves as well. So the best career paths take all these elements and provide options for people looking at both people management and individual contributor paths.

And so you need to be able to have those dual paths for people who have different kind of passions and different personalities, and you also show these lateral moves that you can make for people who are maybe interested in exploring different career paths. And I know some of the talks that I've seen throughout the day, a lot of people talk about movement from DevRel into product management or product technical roles into DevRel. And so having those explicitly written out in your career ladder gives people a clear sense of where they can logically move in your organisation, and it gives people giving That kind of clear definition then allows people to have more autonomy over the decisions that they make around the work that they're doing and who they're spending time with and can help them have more success in achieving those goals. There's a number of other reasons that career ladder are so important that transparency shows people what's required to grow in an organisation.

And so for people who are motivated, high performers and who want to advance in their career, it's essential that you give them this roadmap for success by providing clarity of these requirements and responsibilities at each level. People know what they can aspire to, they know what type of work they need to focus on. The performance indicators really allow people to have a metric that they can measure their success by. And so for people who are data-driven results-oriented people, they want to know, okay, am I doing a good job or not? And if you don't have performance indicators, it can be really difficult. And I know a lot of talks also touched on this topic of burnout, and without having a clear sense of these are the deliverables for my role, these are the results that I'm supposed to deliver, it can be hard to say no to things.

And that's one of the reasons people often wind up feeling really burnt out. And this last piece is the key, right?

Which is it gives people ownership of their careers so they can clearly understand their requirements, they know the expectations and what they need to achieve to progress, and this empowers them. They can align their development with their career goals, and it also allows 'em to advocate for themselves when they feel like they're ready to take the next step in their career. And I think some of the best career development conversations I've had with my team, or when people bring the results that they're delivering, the wins that they've had, and say, look, I want you to see all this great stuff that I've done, and this is why I think I'm ready for the next level. And oftentimes, those conversations lead to people getting the results that they want, which is promotion and more opportunity.

So now we understand this fundamentals of what makes a career ladder, what makes a good career ladder. Let's dive into the elements, the kind of details. So every good career ladder is going to start with an overview of the role. And so I often joke that if you put a bunch of dev people in a room, the conversation inevitably lands on one of three topics.

Hey, John, I don't think your slide advanced. The slides are kind of loosely associated with the talk. Okay, but you have a cityscape. That's the slide you want. Yeah. Okay. Yeah, that's fine. Yeah.

So I open joke that if you put a bunch of DevRel people in a room, that the conversation is going to land on one of three topics. What metrics should we measure? Which org are we supposed to report into? And what should our job title be?

And so for the last one, at GitLab, we used developer evangelist, but that was just through process of elimination because we already had advocates and people with relations in their titles. But everything that we're going to talk about today applies to these roles broadly. And every good career ladder is going to start with an overview of this developer advocate or developer evangelist role. The overview sets the stage and it can add a lot of nuance and be a place to give some flavour, some context, maybe a little bit of story storytelling about the role, the team's mission and those types of things.

So make sure you take that opportunity to speak about your organization's mission, how your team fits in, maybe if your team has a specific mission, mention it there, talk about the structure of the team where they report into. And I think all of this touches on that purpose element.

And so when you have in your overview like, this is the organization's or company's mission, and this is how we contribute to that, people can see, does this align with the sense of purpose that I have for my career? And then they'll also be able to make that decision around where they fit on the team. And so the overview, it seems kind of simplistic, but I think it's really an important element and sets a tone for the rest of this career ladder. And the rest can be somewhat more or somewhat less creative and more detailed and specific. And so I think take advantage of the overview to give yourself to provide that colour about your team and where they fit into the broader organisation.

The next step is to kind of have your levels and any specialties that you may want to include.

So for GitLab, our developer, evangelist, job, family, we have multiple levels. So it starts with your developer evangelist, then senior, then staff, then manager, and then we also have a programme manager role in doing some research for this. There's definitely organisations out there that have principal DevRel roles. I didn't find any organisations that have higher level like DevRel fellows or something to that effect, but would love to hear about it if anybody is aware is one of those kind of levels themselves. But yeah, the teams that tend to have that principal level role seem to be parts of really big organisations. And so depending on your team's maturity, that's probably something if you're a very mature large organisation, that's probably something to consider. You may also want to have junior or associate developer relations roles.

So you need to think about what the needs are for your organisation and who you're looking to bring in, and then you can assign those levels accordingly.

And then once you have the levels laid out, you also need to think about what type of specialties that you need. So at GitLab, we're hiring for a community engagement specialty. And this is because we're a super community focused company, a tonne of our announcements and communications, our team is being asked to give input on all of our kind of announcements, communications, blog posts. And so just given the volume of things that we're being pulled into, because we have such a good understanding and empathy for our community members, we needed to bring someone in to really focus on that stuff. And that way the other developer evangelists on our team can focus on more of the traditional de activities like conference talks and blog posts and workshops and those types of things.

But yeah, the specialties for your organisation should align with the work that you or team will be doing. So maybe that's aligning with specific products that your organisation offers. I've seen a lot of companies do stuff around integrations.

There could be specific audiences that you want to target. And then there's also companies that segment their Devra functions by region, which is another really cool option to consider. It's not something that we've done at GitLab yet, but I could see that being something that we explore in the future. And yeah, I think the kind of general rule of thumb is that the larger your organisation and the broader your product surface area, the more specialisation that your team will have. So if you're a smaller org or a startup, you probably won't need to worry about that. But if your organization's growing, that may be something that you need to look at.

So yeah. Now, once you've laid out these levels and specialties, the next step is to create a set of responsibilities for each.

So the responsibilities clearly define the expectations for the role. And so in DevRel, this could arguably be more important than any other job in tech. And as I touched on earlier, the reason is that the breadth of things that people are asking DevRel teams to do, and the unique kind of skillset that DevRel people have means that we can do a lot of things, but that can often be really overwhelming. So just imagine your, you're Monday, you're writing a blog, working on a tech talk, communicating with your Meetup community about an upcoming event, and maybe answering some questions on Stack Overflow, and that's just Monday.

But that can get super overwhelming when you think about that over a five day week and then over a month and over a year. And that's why I think burnout becomes such a popular topic in this industry. But if you have this clearly defined set of responsibilities, then that makes it much easier for people to say no. And so there was a talk in 2018 that James governor did at this event, and it was entitled, sympathy for the Dev.

It's one of the best talk titles I've heard. And all the slides were like Rolling Stone song, such a great talk.

But in that talk, there was a slide highlighting the importance of people in DevRel to say no, which is so real and so important. But without that framework where you can go back to your responsibilities and say, actually, this is not my job. It can be really hard to say no. And especially people in de tend to be these outgoing kind of people, pleaser type of people that love to help others. And when you combine that with an unclear set of responsibilities, you can wind up in a really weird place. And so making sure that you have that clarity about your role is so important and gives you that kind of confidence that you need to say no and not feel like not be losing sleep over it.

So to kind of wrap that up, and that's the autonomy element that I mentioned earlier. When people know what the expectations are, they can take control of their backlog, their calendar, and their career, and it makes them feel a lot more empowered and gives them a lot more flexibility to kind of decide what the right things to be working on are. So requirements are the next piece in the career ladder puzzle. You can think of responsibilities as the stuff that team members will own, but the requirements are the skills that you need to achieve those things. And so depending on the responsibilities that you outline for your team, requirements could be things like technical proficiency, communication skills, values alignment, experience levels. Maybe you need people with a certain kind of reach or following online or experiencing community leadership roles.

And so whatever those requirements are, just keep in mind that while I think requirements can sometimes exclude good people from good positions, but it's also important for people to be set up for success. And so you want to make sure that you're clear about these requirements, and that way a person who's taking on the work at a certain level has the skill sets and the experience that they need to be successful.

So yeah, when you're defining these requirements, just keep in mind what's necessary for a person to succeed at each level and then align those requirements accordingly. And a lot of orgs, more senior team members are going to be expected to help support the junior team members. So mentorship and leadership skills might become important as a person kind of climbs up their ladder. The ability to connect either with a broader audience or higher level, more technical audiences, or both may also be required as people advance in their careers.

More senior people may also need greater domain knowledge or really specific languages that they're familiar with, or content creation skills that maybe a more junior person doesn't possess. So once you have those responsibilities and requirements tied up, you can understand it and make sure that they're both aligned. And I think the requirements fits with this mastery element. And so when you provide people with this clear set of requirements that they need to advance, they're empowered to align their professional development with their career goals to reach that next level.

And so you'll find that people who are ambitious and driven, they'll see what they need to do to get to that next level, and they'll work to develop those skills accordingly.

And so yeah, the next thing for your career that our jobs family and potentially for even each level and specialty, depending on how you structure your team, is the performance indicators or expect results. And when you think about how this is different from responsibilities, think of your responsibilities as what you will do, and your performance indicators are how you measure what you will do. So I made that joke earlier about the three topics you'll inevitably hear if you put a bunch of Deral folks together. Of course, now I'm bringing up metrics, but I'm actually not going to get too far down into it. There's so many great resources out there to touch on metrics for DevRel. I have a blog post on it on my personal blog, but there's also going to be a tonne of great talks throughout the rest of the event that cover metrics.

And so if you're looking to evaluate what type of metrics to add to your career ladder, I would encourage you to consume some of that content, join the talks, listen, ask questions, engage in the discord, and use what you learn to inform and improve the performance indicators that you're using for your team.

And then you document those in your career ladder and you're all set. So we've discussed these critical elements of the career ladder and overview levels, specialties, responsibilities, requirements, and performance indicators. The next step is to put them into a cohesive and comprehensive order. And this is the latter part. So finally, the slides are starting to make sense, but yeah, when you start at the lowest level, each rung on the ladder should have another rung above it. And it may also make sense for there to be a rung to the side when horizontal moves are rail and attractive options for a person.

So some natural moves might be into product marketing or product management, and this grid should be publicly available to everyone in the organisation so that folks in product marketing and product management who want to move into DevRel also know that there's opportunities there for 'em. And that's something that we do really well at GitLab.

If you look for our marketing career ladder, you can Google GitLab Marketing Career Ladder and go take a look and see what all the different kind of movements and potential opportunities exist for our team. So yeah, just a couple other things to highlight before we move on. When you're crafting your career ladders, make sure you use inclusive language that's so important to make sure that everyone, like they can see themselves in all these different roles and levels. And for junior levels, I think we talked about experiences or potential requirement. I would discourage strict experience requirements for junior levels because I think you'll open up more opportunity for people from diverse and unique backgrounds to apply.

And particularly for DevRel roles. I'm from a non-traditional background. I know PJ from our team who presented earlier also comes from a non-traditional background.

I think there's a lot of great people in DevRel who if you look at their cvs, you'd be surprised about where they started and how they got here. And so I definitely want to make sure that we keep that kind of uniqueness and interesting kind of community that's building here by not having too much strict experience requirements and allowing people to get a start. And this can help you attract a broader pool of candidates, but it's also just I think, the right thing to do. So big plus one to that for me. So we have the different levels, the different elements to consider for each level. The levels are structured into an organised progression with lateral moves, and now what do we do with this?

So I think this is the important part, and this is the call to action for all of you. So it's time to get to work.

And so whether you have a career ladder in place or you're looking to start something new, the next best step is go talk about this with your team. Start a dialogue, get everyone contributing. And this shouldn't be something that falls strictly on the team leadership or the manager of a team. Everyone on the team should be able to contribute to this and have their input and goals and aspirations and vision for the team accounted for in the career ladder. Just like the team's results have shared ownership and career development is something that's shared between managers and the people that report to them. The career ladder, I think is just the same exact thing. It's something that the team and the leadership need to collaborate on, and that makes sure that the ladders are aligned with day-to-day realities of the role, the future needs of the organisation and the team members, and sets everyone up for success. And so these documents go out, get started, collaborate with your team on 'em, and then be empowered to use these in your discussions around career development that you're having with your manager or with the people on your team and discuss them, make changes, make them dynamic documents, update them as the company changes and the roles grow, and make sure that they're viable and valuable to the team and the business.