Forging your career in DevRel: Advocate to Exec

Kim: So I am going to talk to you about forging your career in developer relations from advocate to executive. Now, this is a really exciting talk for me to have the opportunity to give, and I really couldn't have given this talk earlier in my developer relations career because there's something that's changed in just the last few years. And really it's that the tech industry as a larger entity has recognised the importance of developer relations. Company leaders and stakeholders have recognised that developer relations is a key growth lever for developer products and a company's developer relations resources either right now or in the past might have been at one time a single developer evangelist. And then over time developer relations teams have grown quite substantially. And as these teams grew and the roles began to specialise and also to diversify management and leadership positions in developer relations have evolved, the teams and roles have continued to grow. And we started seeing more and more need for strategic manager of managers in developer relations roles. And this started to be things like directors and senior directors.

And now it's really exciting because we're finally at a point where developer relations has vital business leadership roles like vice president of developer relations. And this really kind of brings DevRel to the executive table alongside VPs of other departments that many companies are very familiar with, like sales, product, marketing, engineering, and more.

So like I said, I'm very excited to be talking to you today about the developer relations career path and about what has become possible even in just the last few years or even in the last year. Because I remember having conversations with my bosses pretty early in my days in developer relations, and I couldn't help notice, there were very clearly defined career ladders for departments like engineering or product or customer success, basically departments that have components in them that developer relations is involved in or does. But then the developer relations career ladder was just like this big question mark. We couldn't just assume or co-opt another department's career ladder because developer relations is so cross-disciplinary in and of itself. And at the time, developer relations at the company that I worked for, it reported to another department and didn't have any strategic leadership in place in order to be able to create and then implement a developer relations career ladder and then push it up through the bureaucracy to get it to become the established norm.

So I started wondering how the heck I could advance my career that way.

And I seriously considered switching back to engineering because I could clearly see the career path. It wasn't that I didn't want to do DevRel anymore, it's that I couldn't see where the path would lead me and where I could go with my career. Not only was there a lack of clarity in the individual contributor path, which could potentially be co-opted more easily from other disciplines, but there was also no upward mobility in the developer relations leadership because at that time there was no such thing as a director of DevRel at the company. There was no VP of Deral. There was nothing to really move to. So if I wanted to seek a leadership career, then I would have to essentially change my role to VP of marketing or something like that.

But this has changed now. So this is why I'm so excited to tell you about this.

Let me introduce myself. My name is Kim Mida. I belong to a handful of experts and ambassador programmes, and I'm also the vice president of developer relations at Ionic. Now, normally I'd stop here and I'd begin my talk. I'd start talking about a different subject, but this talk is about the developer relations career path. So I'm going to share, albeit in reverse, the path that I've navigated in my career so far. So prior to my position as VP of DevRel at Ionic, I worked at normal as the VP of developer marketing. And before that I was the director of developer relations at Gatsby.

Before that, I was the head of developer relations at Auth zero, and I'm actually going to talk about issues with using the title head of a little bit later in the session.

Before I became head of DevRel at Auth zero, I was the manager of both the technical content and the community teams. And these were developer relations focused teams that sort of had more of a position online rather than speaking at conferences and that type of live interactions. And before that, before I was given leadership of the community team, I was the manager of technical content alone. And this is basically I was the manager of the content team that writes engineering articles for the developer blog. And before I became a manager of that team, I was a content engineer who worked on the team writing technical content for the blog, and that was where I started my deral careers. So prior to that, I was a software engineer. I worked for many years doing development, and then I worked for some time as an engineering manager.

Before that, I was a field biologist. Now the field biology, although it was fascinating and I totally loved it, it's somewhat less relevant for this talk because I'm going to talk to you about forging your career in developer relations. But contrary to what the slide says, not solely for advocates, I'm going be talking about how you grow from an individual contributor level scope to an executive scope.

Like I mentioned, I started my developer relations career as a content engineer, but you might've begun walking the DevRel path as a developer advocate or maybe as community manager or a programme manager or another developer relations, individual contributor role. Regardless, there are two overlapping areas that I'd like to cover in this talk, and one is growing your personal career. And the other is about how the scope and impact grows for developer relations through leadership roles. As I mentioned, these topics are not mutually exclusive. They're things that are more specific to one objective or to the other, but also there are a lot of parallels and a tonne of overlap.

So I want to start out with growing your career. First of all, what does growing your career mean? I mean, this is a thing that people say all the time, and they usually have some idea of that means stepping up the promotional ladder or something like that. But honestly, in the very simplest terms, as we move through our careers, we strive to be successful. But what does that mean? What does success mean? Career success has slightly different meaning for everyone, but in a general sense, it includes things like personal fulfilment and satisfaction, feeling good about what you're doing because you could make a tonne of money and then get promotions. But if you don't feel good about it, then you probably don't really consider yourself that successful.

It's also about expanding impact, and this is a pretty broad topic, but it includes things like having the means and opportunity to progress your career, to be able to continually set and then achieve new goals, to grow your scope, grow your influence, and increase the impact that your responsibilities have on your workplace. And then finally, for a lot of people, for most people, probably success is defined in addition as an upward trajectory for rewards and compensation. Because honestly, we work for money. If we have a fancy title, but we make less money than people in roles that we work with who have the same or less influence, we're not going to feel particularly successful.

So I want to dig into expanding impact because this is the big one, right? And more specifically, expanding your impact in developer relations in your career and at the organisation that you represent. So let's revisit the idea of that developer relations career path. Now whether your organisation has an established and well-defined DevRel career ladder or not, you can expand and grow your influence in the impact of your role at your company in a number of ways.

And the work that you do every day is most likely a mix of strategy and tactics. And then the distribution of each likely depends quite a bit on various things like your experience, your position, and the overall influence of developer relations on the business at your organisation.

So if you think of this as kind a sliding scale along the career path from individual contributor to an executive level scope, we see the influence of strategy being the most significant at the company leadership level. Let me put this in slightly more concrete terms. Tactics are specific actions or steps that we execute in order to accomplish a strategy. And examples of tactics that are relevant to developer relations might include things like speaking at events or writing blog posts, building sample applications and sharing them with the community might be recording videos and live streaming, managing community programmes and forums or organising or supporting community meetups. And there's a large variety of other activities that we do in developer relations, and largely these vital tactics are executed by individual contributors.

Now, if we go back to this diagram here, what are some examples of strategy?

Well, something like increasing developer satisfaction might be a goal that drives a specific strategy. Things like crafting and refining the positioning and the messaging for the products and the software that we try to bring to developer audiences. It can also be about balancing resources, efforts, and bandwidth across different target audiences. For example, how much do we put into reaching net new groups versus what kind of efforts do we put into the activation of current champions? And our existing community can also be around strategizing how to maximise the company's return on investment across all of the campaigns, the programmes, the sponsorships, the initiatives, the conferences we speak at and more.

There's a component around scaling the team and scaling the projects and understanding how to prioritise our efforts while balancing things like importance versus urgency. And of course, we're always trying to increase Dell's impact on achieving the company's primary goals as an organisation. So when we start thinking about how we're going to grow our careers and increase our impact in developer relations, we need to think both strategically and tactically, and we need to do so in the way that's most effective.

And this applies to your personal career growth as well. Now the work you currently do might be mostly tactical, or it might be a mix of people management or it could be strategic at various levels, but it's probably some mix of one or more of the above. And the strategies that I'm going to share next apply to you no matter where you're at in your career.

It could, you're a junior developer advocate trying for your first conference talk, or you could be already a senior director. And these things will still apply. The strategies may differ, or the tactics may differ a little though. So in order to measure your progress, you want to see how you're stacking up. So you should definitely compare yourself to you yesterday.

Compare your accomplishments and the progress that you've made to where you were yesterday or last week or last month or last year, and you're going to be surprised by how far you've come and how much you've grown, how much you've learned, the way you've expanded your skills and knowledge. And then the tactics for this involve doing things like acknowledging and celebrating your progress and the accomplishments. In order to do that, you sort of need to know what you've done right and be able to look later.

So write down your successes and your achievements as they happen. Benchmark your current self against your past self because this is really the person that you want to be measuring up to. Then go back in a month or three months or six months and review what you accomplished. And I guarantee you will impress yourself. The thing is, you can do all of this and it's great for your sort of personal satisfaction, but you also want to regularly share the progress that you've made with your manager or with leadership or with stakeholders at your organisation, for example.

And leadership really wants to do right by their company and their team members. And a good boss will always try their best to know and reward your successes. However, so much happens outside of their line of sight. Many things that you do, they'll be aware of, they'll have knowledge of and many other things they won't know about unless you share your wins with them. So as you record or review your accomplishments, make sure you're also sharing notable achievements or milestones with your boss, and then have a conversation about it. Collect their feedback, discuss what's gone well discuss what could be improved, talk about what you think your next steps should be and see what they think your next steps should be. And make sure that you're aligned, think and act strategically. And this is really where the scope of your strategic thinking starts to grow significantly as you move along the developer relations career path.

Growing your impact and influence involves thinking about the bigger picture and setting increasingly strategic goals while also at the same time understanding and planning the tactics that are necessary to fulfil your strategies.

So on that note, let's get a little bit more specific. Let's say that you are a developer advocate. You probably have a tonne of tactical responsibilities and priorities on your plate, and you most likely are required to jump from one another very quickly, probably even multiple times per day. So when you're thinking about this, think about how you can organise your work to be both more efficient and also more strategic. For example, maybe you built a sample application to demonstrate a feature or a capability with your organization's software. You then add that demo to a repository on GitHub to share the code publicly with the community. You could then create a presentation sharing what you did and how you did it, talking about challenges that you overcame in the code and how other people can overcome similar challenges.

Then take that talk and present it at external events. You could write a blog post about it. You could even go into greater technical detail in the blog post. You could record and upload a video summarising what you did or use the events video after you've presented your talk externally.

You can then take that blog post in the video and share them on social media. But you can do more than this. You can take the content and share quick tips and takeaways in more bite-sized formats, put them in a series and release them over time. In this way, you can create a much more robust social campaign that will yield higher engagement from folks on your social media.

You should share and discuss your topic with members of your community programmes. Leverage that content as training or maybe as inspiration for how the community programme members can create their own content.

You can highlight and link to the content in a developer newsletter, or you could share that content with the field team and sales to do sales enablement so that they can take your content and demo the capabilities of your software to potential customers. You could provide your slides, your video, or your code to organisers of your community meetups so that they can create content around it to present, or you could even present it yourself at those meetups. Then take that content and share it in your organization's developer forums. Share it in your real-time chat communities. And in this way, you can gather feedback from the community, feedback on your sample application on its execution, feedback on the product features that it's demonstrating, and then you take that feedback and communicate it to the appropriate product leadership and product teams.

So I then encourage you to consider the higher level strategy that drives all of these tactics.

Think about what other projects and what other campaigns you can execute to continue to drive that overarching strategy. And this ultimately leads to bigger picture thinking. And it does this while you refining the vital tactics and increased impact at the same time. And remember, continue to review your accomplishments, share them with leadership and think in act strategically coming up with new projects, initiatives and improvements can really advance you a senior level individual contributor and pave the path for you in developer relations leadership, which brings us to learning about the scope and strategic impact that managers of developer relations need to think about.

So consider the tactics of our developer advocate and the higher level strategy that their tactics roll up into. Deral managers are responsible for the coordination of multiple strategies across the team. And then in addition, managers of developer relations are usually people managers too. This means they're responsible for the team members who are executing the tactics that are associated with those larger deral strategies.

And I want to take a little bit of a closer look at these responsibilities. Deral managers have individual contributors who report to them, and some DERAL teams have distributed internationally in a BI region, and global teams may or may not have regional managers. But here are some of the people management responsibilities that are familiar to many DevRel managers and indeed many managers across the board in tech, working with team members to create strategically aligned individual goals and determining how to measure progress towards those objectives.

Conducting regular one-on-ones and annual semi-annual performance reviews appropriately delegating ownership of projects, programmes, execution tactics across individuals in the team according to their skills and their interests as well. And people, managers not only need to be responsible for hiring and scaling their teams, but also for navigating interpersonal team dynamics because every manager at some point is going to have to make hard decisions. Now on the strategic side, what are some examples of team goals that the manager of developer relations might be responsible for? Well, this might be things like increasing web traffic and page views to the developer blog or reaching more people through talks and videos. It could be something like creating documentation and sample applications for developers to download to get started quickly.

If you're an open source company, it might be around engaging with users in the community who submit issues, pull requests, ask questions, and otherwise contribute to the org's open source code and its repositories. And the triage and communication with community members and contributors on open source repos is a really vital and important component of developer relations and developer experience for open source. Another team goal might be to expand and scale the community initiatives, programmes like experts, maybe ambassador programmes or guest author programmes. And really, these are just a few examples of overarching DevRel team goals. I'm sure you can think of many, many more. But what this does too is it brings us to the next level of scope, and that's driving the strategy around the achievement of organisational level goals while still being a champion for the developer relations team and its members. At some organisations, DevRel can be pressured by leadership or by other teams to do things like drive revenue or pipeline or to prioritise free customer support over other kinds of DevRel activities. And obviously, I can't speak for every company or every situation.

Sometimes some of doing some of these things is appropriate and other times too much pressure to do these types of activities can jeopardise the team's relationships with the developers in the community. So senior developer relations leadership has the influence to establish and to clarify re's philosophy and practises at the company.

Now, some companies don't have DevRel leadership beyond the manager level and developer relations managers report to another department head or another director. But the evolution of developer relations has now paved the way for senior leadership like directors and senior directors of developer relations. And to be honest, if manager is the highest that your orgs developer relations career ladder goes, and the DERAL manager is responsible for driving company goals, they should really hold the title and the leadership influence of at least a director. On that note, I want to take a quick moment for a little bit of a time out here. Remember when I said I talk about the title head of I really dislike this title. Head of is basically a CYA title.

It's a cover your butt. It can be a way for companies to give too many responsibilities and not enough influence to a manager.

Head of developer relations could potentially be equivalent to anything from a manager one to a senior director. But the title is so purely subjective and it's highly ambiguous both to the people outside the company as well as to internal leadership. So the companies out there, I strongly recommend that you not call any title head of instead level your positions appropriately, level them accurately so their scope is clearly understood both internally and externally. And for those of you folks who are looking for deral jobs, particularly if you're looking for deral leadership jobs, if a company has an open job rec listed as head of, make sure that you ask about the expectations and the true scope of that role. Then ask if the role can be called something more aligned with its description. And if the role is really a director level role, get that director title because titles do matter.

Okay, time in, like I said at the director level, you're responsible for driving company goals. So let's return to the scope of a manager of DevRel briefly. If we take team level goals and the associated strategies that are created to achieve them. At the director level, a developer relations leader thinks about the next level of strategy. Above that, they help set goals and strategies for the department as well as cross-functionally, and they establish and determine the metrics to drive overall company directives.

So what do the goals and strategies at these levels look like? Well, the collective developer relations strategies might be working towards goals like reaching some number of downloads or number of users per month, whereas departmental strategies might function toward things like increasing the return on investment for department initiatives. Cross-functional strategies could contribute across multiple teams or even across multiple departments to achieve things like increasing the net promoter score or maybe growing the number of deployed projects that depend on the company's products, software tools by some percentage month over month.

And then alignment with, and the driving of company goals means the director ensures that all the strategies contribute toward business objectives from company leadership. And this could be something like maybe becoming the fastest growing software choice in a particular market sector or in a development category. And again, your own company's team department and organisational goals probably come to mind here. And directors operate heavily on the strategic level. They're also people managers. They may manage individual contributors or they could manage other managers depending on the structure and the size of your developer relations team. And your organisation directors are also accountable for the team mission, the processes, the operations, like career ladder for example, and budget. They're also responsible for dre's cross-functional relationship and its collaboration across the company.

And this kind of brings us up to the level of the whole picture, the whole picture and executive developer relations roles.

Executive DevRel is still pretty new in the tech industry, but it's rapidly, very rapidly becoming more common. And the executive role that's been appearing the most often is vice president of developer relations or developer experience. And while the specific details and the reporting structure of individual executive leadership roles are pretty particular to each organisation, vice president roles are often characterised by several specific responsibilities and a level of influence. VPs of DevRel are expected to be experienced and have a lot of expertise in the strategy and the execution of developer relations, and they need to have extensive knowledge of their discipline.

Developer relations executives are also responsible for understanding the really close up macro view all the way up to the thousand yard wide angle. And at this stage, most organisations with developer relations senior leadership don't have both a director and a VP of DevRel. So how do we kind of distinguish between which one your company has or should, based on responsibilities?

Let's revisit the director of DeVeres scope and see how it differs from an executive VP role. The team in cross-functional operations move into the strategic network and people management is still really, really important. In addition, VPs also manage external collaboration with partners or vendors or contractors. They may manage partnerships with other similar companies in the same industry or the same tech space. They may also meet with the board of directors regularly. VPs are also responsible for additional strategic decision-making. And this brings us to the company goals and business directives and kind of solidifying that dotted line there. Rather than following the strategy that's already been defined by other leadership.

Executive DevRel helps to create and plan the strategies that are required to move the entire business forward. So in addition to goals like the one I mentioned earlier, like growing in a software category, this might include things like rapidly and efficiently scaling the organization's staff and resources or creating a business model and then effectively realising it across the entire company.

A developer relations at the executive level should also expect to have a close collaborative relationship with company founders and stakeholders, CEOs, CTO and so on. They help to create and drive the organization's roadmap, and they're attuned to changes in the market, changes in leadership decisions, changes in product direction and more. They're able to pivot their strategies effectively when necessary, and they also know when to push back as well. So we're coming up on the end of our time here. What are the takeaways I'd love for you to leave with Grow your career by tracking your progress and sharing wins with your leadership? Think and act strategically to increase efficiency, impact and influence.

Forge your career by expanding the scope of your strategies while delivering world-class execution, and learn about and really understand your organization's larger goals and how your strategies and tactics move them forward.

And finally, be an advocate for yourself. I'll advocate for myself here for just a moment. I'm on Twitter at Kim Mida. I also have a blog@mitta. kim where I write about things like what department I think DevRel belongs in. And as a hobby, I make miniatures and key caps for mechanical keyboards that you can check out at me mini studio. And if there's only one thing that you take away from the stock today, it should be an advocate for yourself and for your career.

We all work in developer relations. We know how to prove value. We know how to win hearts. We know how to change minds. We know how to be champions for something. So go be the number one champion for your career and your personal success.