One of my (only .. slightly delayed!) goals for this year is to not only watch and read more content, but create it — and the easiest way to practice and build the habit could be through writing mini-reviews (Right? We’ll see!).
So, here goes!
Recently A few months ago, I watched the talk Supercharge your career with a tour of duty in DevRel by Jordan M Adler (available here! Go watch it; it’s short!). I’ve always been interested in the sub-field of Developer Relations/Advocacy, especially having watched a couple people in my broader network move into it over the last few years. As an Engineering Manager interested in understanding other career paths, especially if my own engineers could potentially be interested in them, this talk struck me for a lot of reasons. I’ve managed mostly front-end focused full stack teams, but I’ve known engineers interested in eventually pursuing everything from machine learning to product management to design or to owning a coffee farm!.
But as for this talk specifically, I found it interesting not only for its insights into the field of Developer Relations (“DevRel”), but how some of it could be applied to trying out any “adjacent” career change. In a lot of ways it also applies to moving into management from a technical individual contributor role! (I whole-heartedly recommend Charity Majors on this).
Importance of T-shaped engineers
Very early on in my development career, I encountered the concept of “T-shaped engineers”, engineers who specialize in one part of product development, but are broadly familiar with a large portion of the stack. I’ve used this to define my own niche, which I like to work into my broader career pitch – I’m a front-end focused full stack engineer, but I’ve done everything from craft very basic designs in Photoshop (trust me, you don’t want to see them!) to manage AWS resources in terraform.
As part of a stint in developer relations, you would probably have to be somewhat familiar with a broad spectrum of technical skills to complement the product offerings. I have mixed feelings on this overall – I benefited a lot from spending my early career in the same stack until the concepts “clicked”, but also know that for further growth, that broad skill set can be helpful (you never know when you might end up on a team working in a microservice in a language you aren’t familiar with!). DevRel also could help you build up your other “soft skills,” which are transferable back to more “traditional” software roles.
Impermanence of (Certain) Career Path Choices
I think a lot of people are reluctant to move into more “niche” roles like developer advocacy or even, to an extent, engineering management, because there are a lot less openings for them! You might be sacrificing career mobility, have a lot less insight on what the day to day or career path looks like before you make the move, and even in some cases, be limited by company size/evolution. In this talk, he very briefly touched on what the day to day of a larger developer relations organization might be, which having never worked at a company with the defined role, was also super informative to me!
I also really appreciated that this talk focused a lot on the “exit strategy” – in this case, because developer relations could be seen as something you try for a bit, but also, because these career path changes generally have complementary skill sets that you can take back to your main or back up option.
Getting out of your developer comfort zone
Talking to people is hard. Realizing your product isn’t fulfilling a need? That would be even harder. Communicating that back to the rest of the org? Oh dear. These are all hard tasks that have a lot of impact on your overall career capabilities and could accelerate your career growth if you spend time in DevRel and then move back to a different engineering role.
Why not stay in DevRel
I think I was also super interested why this was framed as a transition in and out of DevRel, and why the talk was pitched this way – because it’s super interesting to think about why some of these pros may also be cons, and how that fits into the possibilities of stints in other adjacent roles. As an engineering manager, you know it’s going to take time to boot back into a fully productive senior engineer role, and working in DevRel, since you probably aren’t supporting or scaling products, there are a lot of things you might be missing out on.
At one point does losing your edge for production become a hindrance in DevRel? And is that why so much of the rest of the engineering community, for lack of a better term, feels a bit .. skeptical of the role? The classic “why should I trust the opinion of someone who doesn’t have to be on-call for when the fancy new product goes down in the middle of the night” dilemma!.
I worry about that authenticity, as an engineering manager as well.
Overall, this was an interesting talk that has me stewing over the career paths and pathing, and the pros and cons of taking some of these leaps, and how else can we know more about what it would be like to take that leap, and how some of these leaps .. are recoverable from. As someone who likes to have back up plans for their back up plans, it clicked for me.
(Special thanks to Kath and Lisa for their help with this post!)