It's no secret that dulling or even losing your production development skills is perhaps the biggest risk of moving from a developer job to developer relations (abbreviated as dev rel, sometimes called developer advocacy or evangelism). As I wrote in Managing Time as a Developer Advocate, dev rel requires sharpening many skills outside of coding: public speaking, writing, video production, customer service, content marketing, product feedback, and a bit of project management.
The problem is that most of the code you actually end up writing is related to combining Product X with Technology Y for the purposes of developer advocacy and product feedback. Without a deliberate strategy, it's easy to disappear into a Tutorial Fairyland where no real world problems ever occur, everything is greenfield, and there are no tests (okay, that one is realistic). Videos and tutorials that hand-wave over details, use contrived examples, or ignore issues like maintaining legacy code get lost in a mountain of mediocrity. Quality pays ten times the return and helps ten times more people.
Keeping your engineering skills sharp isn't just important for your own education, then: it's critical for being good at your job! So what's a developer advocate to do?
Three Strategies to Stay Sharp as a Developer Advocate
In my experience so far, I've discovered three ways to mitigate this.
One way is to work as a team to build internal tools that get used on a regular basis. When done right, this strategy can sharpen skills like project management, Agile, and deployment (not to mention the skill of working on a development team!). On the Auth0 dev rel team, we're working on an internal dev rel tracking tool built with NestJS and Svelte. It's a lot of fun!
Another way to keep skills sharp is to work closely with the teams that build SDKs or developer-facing APIs from time to time. I'm doing this right now with one of our upcoming SDKs and it's been awesome. It lets me keep my open source skills sharp, it puts my code in front of others for review, and it reminds me about the balance between feature development and API stability. Some dev rel teams also do periodic rotations into product engineering teams. This sounds like a fantastic idea!
There's a third way that I'm working through right now: developing a personal learning strategy and system. It's sort of the inverse of a "content marketing strategy," but could also be used as the start of the pipeline for that process. The temptation for first creating both a personal learning system and a content marketing strategy is to ask, "What's new and shiny and will get me clicks and engagement?"
While I agree that new, shiny tech is part of a balanced dev rel breakfast, I see two problems with only chasing new tech. The first problem is for the developer reading or watching. Shiny tech doesn't necessarily get used in the real world for complex problems in production right off the bat. We're back in Tutorial Fairyland, which is the whole reason we're trying to figure this out in the first place. The second problem is for the developer advocate. Chasing new tech feels a lot like bouncing around like a ping-pong ball. It can be difficult to ever feel like you're ever getting any deep knowledge, it can be very overwhelming, and it can lead to burnout.
To combat both of these problems, I prefer to ask instead: "What are the real problems facing developers right now and what are the technologies they are using to solve them?" This leads us right back to our original problem: how do we know what technology is solving problems in the real world when we're not writing production code anymore? Here is where we have to keep our ear to the ground. We have to listen. We have to hang out, help out where we can, and learn what others are learning. This process is similar to the customer research system developed by Amy Hoy and Alex Hillman called Sales Safari, and in fact Sales Safari has been tremendously helpful to me in developer relations in addition to my own product business. Sales Safari is all about hanging out where your customers or users are and listening to their pain and frustrations. Don't just create a product (or tutorial or service) you think is a good idea! The same goes for developer advocacy.
By the way, two additional really good resources I've learned about for knowing when a "new shiny tech" is crossing into a highly used one are the ThoughtWorks Technology Radar and InfoQ.
Building a Learning System to Stay Sharp as a Developer Advocate
Right now I'm designing and building an effective learning system for myself that I can then pass on to my team and the Auth0 Ambassadors (and anyone else who wants it). I need to build processes and infrastructure to project manage myself from knowing nothing on a subject to being "conversationally fluent" in it and able to build meaningful projects with it. I also need to be able to gauge the potential return on investment of that time and decide when to go deeper on a topic.
Here are my "user requirements" for a learning system:
- It has to yield measurable results. I have to be able to know whether I'm doing a good job and how I can improve.
- It has to result in deliverables that can be shipped. This could be open source contribution, videos, articles, or something else, but it has to be something outside of my own head that can benefit other people.
- It has to be fun and natural in order to be sustainable and efficient.
I have two major obstacles I'm working through right now in building this system.
Obstacle 1: Getting Better at Learning in Public
I need to get better at thinking and learning in public. (Spoilers: this article is an attempt at that!)
This might be a strange thing to say as someone in developer relations, but I don't particularly like being in the spotlight. I never want to be seen as some narcissistic egomaniac who thinks the very sound of his voice is a gift from the heavens. I can't stand self-proclaimed "thought leaders." I've been that guy before when I was younger and looking back I get so embarrassed about how insufferable I must have been. I'd much rather spend my time now working behind the scenes for other people, bragging about them and helping them find opportunities.
At the same time, I think I've gone too far to the other extreme. Whenever anyone asks me about how to get a job in either web development or developer relations, I'm quick to praise the method of "learning in public." Write down what you're learning on a blog of some kind (don't overthink the platform!), get involved in the community, and share your learning process with others. I realized, though, that even though I promote this approach, I don't do it myself very often. That's partially because I spend a substantial part of both my day job and my side work making tutorials and talks, but that's a slightly different thing. Those projects are more like sharing what I've just recently learned or know very well, rather than sharing my learning process itself. They are "finished products."
I write a ton in order to synthesize information while making videos, talks, and articles; I just never share my notes or my production process because they never feel good enough to publish. I'd like to start getting better about that for two reasons: 1) it will help me document my own progress publicly and 2) it may help others trying to systematize and share their own learning process, whether to get a job or just move to the next level. I love of throwing open gates for others, so this may be one way I can help with that.
Obstacle 2: Reducing Cognitive Setup
Right now, context switching takes an enormous amount of cognitive setup for me. I have to make progress on projects in roughly 90 minute chunks. A solid half hour of that is often just remembering where I'm at in the project, getting my head in the game, and muting all of the social media and chat apps so I can get some work done. If I can reduce that setup time, I can be more efficient in my "time to production." I'm not willing to work 80 hour weeks; life's just too short. I've gotten much better at increasing my throughput by shipping faster, but I also want to reduce my mental setup time.
I've been getting into Tiago Forte recently and learning about Building a Second Brain (abbreviated as BASB) and the PARA method (PARA stands for Projects, Areas, Resources, and Archive). Essentially, building a predictable knowledge management system eliminates the need to fumble around looking for resources or the status of a project.
I think this might do the trick in conjunction with some improved tooling. Tiago talks about the shift from a "heavy lifting" approach to project management to a "slow burn" approach. Instead of needing to block off large amounts of time in order to move the needle on something, you can spend consistent short blocks of time because you need less time to context switch. You know exactly where everything is and you can quickly check on the status of things using some visual techniques like highlighting, color-coding, and kanban boards (think Trello).
Over the last couple of years I've been running experiments with several productivity tools and approaches. I'm a long time fan of Getting Things Done and I've been using OmniFocus for many years for task and project management. OmniFocus is perfect when it is time to move a project into the pipeline and ship it because it's geared around the concept of the "next available action." Unfortunately, it's not great for "back-burner" or "archived" projects. Projects that are blocked or not quite ready end up languishing in OmniFocus and taking up space as I repeatedly snooze the review for them.
I've recently gotten into Notion and I think that, in conjunction with BASB/PARA, Notion solves both of these problems. What I like about Notion is that I can group things together by project and area, but also cross-reference and add boards and tables to keep track of status and references. Notion's only downfall is that it's a bit slow for composition, but Drafts is basically unbeatable for that. So, the tooling for my learning system and second brain looks like this:
- Drafts: quick composition and meeting notes that can then be processed and moved anywhere.
- Notion: research, notes and resources database, project boards, big picture overviews of where things are at
- OmniFocus: immediate project and task management for shipping
Where I'm Going Next: Learning Snapshots
With my tooling and philosophy figured out for productivity and knowledge management, it's time to move on to the actual core of building the learning system. I've come up with what I think is a good format for this called the Learning Snapshot. For any given area I am currently working on, I can track:
- Why I want to learn it
- "Anchor resources" — core courses or tutorials I'm working through
- "Reference resources" — any other collateral learning material I've come across
- Notes on what I'm learning (especially whatever context I need to jump back in quickly)
- My progress in each of the anchor resources
- Ideas on content to create in this area
- Next actions I need to take
This will allow me to quickly jump back into a learning area without a ton of mental setup (Where was I? What was I learning? What do these words mean? Why do I even care about this again?). Each month, I can review my Learning Snapshots and what's working and what isn't.
I'll be building Learning Snapshots out in Notion and sharing it publicly. I'd love your feedback. I'll also be sharing my learning snapshots through my newsletter. I'd love for you to send me yours so we can hold each other accountable!
That's all for now. If you're curious about developer relations or interested in becoming a developer advocate, check out my book Getting Started in Developer Relations.