I moved from regular full stack web development (C# and JavaScript, mostly Angular) to the world of content, developer relations, and developer advocacy in August 2018 when I joined Auth0. It's a lot of fun, but no one tells you just how much stuff there is to do. At any given time, I could be:

• Writing a blog post
• Answering questions on Twitter, Slack, Discord, or various Discourse forums
• Making videos, either as a side hustle or for work
• Figuring out how to integrate Auth0 with X language or Y framework
• Building and improving programs like Auth0 Ambassadors
• Collaborating with other companies on content
• Streaming
• Building a talk
• Applying to events
• Giving a talk (whether in person or online)
• Appearing on a podcast
• Working with other teams in the company (like the SDK team or product marketing teams) to provide developer feedback and improve the product

It can be dizzying! Without some good systems in place, it would be incredibly easy to work all the time. In fact, that's how I was starting to feel as I finished my first year. I felt like someone could wake me up in the middle of the night and my first response would be to start typing at an invisible computer or give a talk to the chickens.

I'm about 18 months into this and I feel like I'm finally starting to get some traction on prioritizing and being productive without losing my mind. So, in this article, I'm going to write out what's been working for me lately in my unending quest to balance life and dev rel. I don't pretend to have all the answers here, but I do hope I can save you some time.

My favorite way to write about what I've been learning is by first laying out some "cloud level" overarching principles that I've been noticing and then getting down to the nitty-gritty "street level" strategies and tactics that are working for me. As always, this is the stuff that has worked for me. Adjust to suit your own needs and personality!

Note: I'm just going to use the term "dev rel" from here on out for convenience, but this could be any iteration of developer advocacy, evangelism, content, community, or anything else. Think of it as a synonym for "that part of being a developer that involves building relationships and creating content," whether that's your full time job or a side gig.

Principles for Dev Rel Sanity

As I've moved through this last 18 months, I've picked up on some high-level principles that are making my life better. Think of them as signposts along the road: they don't tell you exactly how to get to your next destination, but they point you in the right direction if you pay attention to them.

Principle 1: Dev rel is a new set of skills to learn — embrace it!

When you first transition to dev rel, it can be incredibly overwhelming. Most of the time, the reason we have moved into dev rel is because we were reasonably good at our engineering jobs but wanted to do more teaching and community-building. Suddenly, we've gone from "competent engineer" to "brand new developer advocate" and that sucks. This brings me to the first principle I want you to remember: dev rel is a new set of skills you can learn.

You are once again a beginner! You're back at square one (or square zero since we're all nerds here). If you feel totally overwhelmed or like you suck at your job, this is not because something is wrong with you as a person — it's because you need to learn and practice a new set of skills! Once I realized that, I felt so much better. So, first and foremost, cut yourself some slack (not Slack)!

The real magic comes when you not only accept that reality, but learn to embrace it. It's not that often in life that we get to learn new skills (though as developers we are incredibly lucky in that way). New skills mean new opportunities for creativity, new ways of looking at things, and new relationships. And that feeling of discomfort and discontent? That's growth as a human! Growth is good!

Principle 2: Focus on shipping and improving instead of waiting for perfection.

Perfection is the enemy of getting things done, but this seems to be especially true for dev rel. It's really easy to start a dozen projects, blog articles, video course outlines, and open source libraries — it's way harder to finish them. Why is that? Often it's because we like the idea of a hypothetical, perfect version of something more than the reality of the hard work it takes to execute something. When we go to work on that project, we get so overwhelmed by the disparity between our Perfect Vision and the blank page that we give up and go back to daydreaming.

This is a great way to get fired. It's way better for your job and your mental health to build and ship something — no matter how small — so you can start getting feedback, achieving some results, and improving on it. I love how Amy Hoy and Alex Hillman call this stacking bricks.

A good rule of thumb here is to ship something when it's 80% done and you're stll a little bit embarrassed about it. You can always improve on it later!

Principle 3: Don't try to automate too quickly.

I don't know if this is a developer thing, but I have a tendency to overcomplicate things and try to automate them way too quickly. This usually comes from a desire to be efficient or elegant in my implementation so I (naively) add (unnecessary) complexity. I'm sure you know what I'm talking about: after six months or a year, you come back to the code you wrote and realize you can drastically simplify it. Why is that? It's because you know what's important and what's not due to experience.

The same is true with dev rel. My first response to being overwhelmed was to TRY EVERYTHING and THROW EVERYTHING AT THE WALL:

• Download all the productivity apps!
• Set up complex email filtering!
• Buy all the gear!
• Over-engineer systems to automate everything!

That was a quick road to burnout because I was giving myself way too much overhead. Instead, what I've learned is to go slow now in order to go fast later. I needed to slow down and figure out what was bringing the biggest return in order to find the ways I could systematize and automate it.

Incidentally, I went through this exact same cycle when I was learning about camping, hiking, and backpacking. I overcomplicated things and, over time, watched as the gear I needed eventually shrank to exactly what I needed, when I needed it.

As you venture forth in dev rel, look for those three signposts to keep you on the right path:

• Be kind to yourself and embrace that you're learning new skills
• Focus on shipping and improving
• Resist premature automation

Strategies for Managing Time as a Developer Advocate

Okay, so we've got some principles. Let's get down to the street-level implementation for daily work.

Strategy 1: Determine your priorities.

Given that we could be doing a million different things at literally any time of day or night, it becomes impossible to do everything. You have to create some sort of decision matrix or rubric for prioritizing. If you've got a boss, I'd highly recommend you talk this out. Define priorities and "big wins." When Kim Maida was my boss, we did just that, and here's what we came up with.

Prioritize projects that:

• Other people depend on (e.g. that internal tool that other people need)
• Involve collaboration with other team members or internal teams (a lot of developer advocacy work goes here)
• Involve collaboration with other companies or create those opportunities (streams, joint blog posts, open source collaboration, etc)
• Create opportunities for other people to learn or advance their career (programs like Auth0 Guest Authors run by Kapehe and Auth0 Ambasadors)

Notice the trend? It's other people, which is really what this whole job is about. I had lunch with Jason Lengstorf in Portland a few months back and he gave me the exact same advice: collaborate as much as possible. Dev rel can be extremely isolated at times, especially when working remote and traveling alone. Collaboration not only dramatically increases your impact (and thus helps more people), it also keeps you from losing your mind.

Of course, there are tasks you must do alone:

• CFPs, building solo talks
• Experimenting with new tech
• Working on your "personal brand" (I hate this term because it's so overused, but here I mean your personal site and email)
• Creating most types of content
• Learning new things to keep your engineering skills sharp

How do we prioritize and schedule all that? I'm glad you asked!

Strategy 2: Block out your schedule.

Being remote and mostly autonomous can be great, but it can also lead to a sort of paralysis as you become solely responsible for your scheudle. I wrote in my article Surprises in My Switch to Remote Work that it's kind of like getting rid of the governor on an engine.

Here's what I've figured out so far (and I'm still learning).

First, I make all meetings 30 minutes by default if I can help it. If it's going to take longer than 30 minutes, it's more of a brainstorming session. Nine times out of ten, 30 minutes is plenty of time to hash out who needs to do what to make progress. The rest can happen asynchronously on Slack or via email.

I've also started time-blocking my calendar roughly every Sunday night. Generally I have three types of blocks for working on projects:

• 2 hours: dedicated focus time. I find that the difference between "completely overwhelmed" and "I know the next step" is nearly always 2 hours of focused work.
• 1 hour: maintenance. This is stuff like documentation, program maintenance, or tasks I need to get done.
• 30 minutes: admin or communications. This is the stuff I'm terrible at, so I book it in 30 minute chunks to stay focused and knock things off of my to-do list.

When it comes to actually deciding where to put things, I follow the "big rocks" approach:

• Anything that involves other people, whether meetings or high priority collaborative work, I prioritize 4 days per week from 9 am to 2 pm.
• We have Thursdays set aside as "no meeting days" on our team, so I use that day to do anything totally solo.
• I do that same type of solo work in the afternoons from 3-5:30, especially admin or communications stuff. I do have an advantage here because I'm further west than most of the company, so it's pretty rare for me to even have a meeting after 2 pm PDT anyway.
• I do side hustles like making egghead videos and Thinkster courses from about 7:30 - 9 am every day. Your mileage may vary, but I can't do creative work at the end of the day.

It's not a perfect system, since, with team members around the world I'll have the occasional 7 or 8 am meeting which wins over side projects. But it's good enough to produce results consistently.

Notice that I'm working from 7:30 am to 5:30 pm every day and I take an hour for lunch with my partner — I am not working 60 hours weeks! I try really hard to stick to this when I'm home since when I'm traveling for conferences I basically work for 72 hours straight other than sleeping. I block out as many distractions as I can during my normal work hours and then get on with my life.

Strategy 3: Repurpose content to prefer depth over breadth.

One of the best lessons I've learned so far is to use your content in multiple places. This can mean giving a talk multiple times, but it can also mean splicing and dicing that talk into blog articles, emails, videos, or anything else. Every time you iterate on that content, you can improve it based on feedback you're getting. For example, I noticed I was getting a lot of questions in my main NgRx authentication talk about where to store tokens, so I added a slide for that. So far, I've found Twitch to be a great proving ground for conference talks, videos, or articles.

I know some people are hesitant to re-use talks, but I think that goes away fast when you start doing dev rel full time. The idea that you can make a brand new talk — which take me about 30-40 hours to build, I don't know about you — for every single event is not realistic. Trust me, I tried to do it this first year and it was very stressful! The other thing I've noticed is that audience overlap is very rare, and even the few that see the same talk twice don't remember everything from the first time you gave it. I'd much rather polish something repeatedly and give a really great version of a talk than keep testing out raw material. It's honestly better for everyone.

There's a hidden lesson here other than just content re-use, though. In dev rel, it can be really tempting to chase the latest and greatest tech, endlessly running on the buzzword hamster wheel. Some people do this really well. It seems like they come out with videos on a new framework or library within minutes of a release. (They have a secret, though: they've spent time building a system with low friction. More on that next.)

This type of content can grab attention in the form of views, likes, and retweets (which is a necessary part of any type of marketing, really), but it's actually not the most important long term play. The folks creating the content know this, but until you know the secret, it's easy to think that your main goal in this field is chasing followers and becoming popular. Remember: popularity is not the same as impact, which is your real goal.

The invisible, long term game is actually one of quality and depth. This leads to greater success both in positively impacting other people and in revenue (or whatever you or your company chooses to measure). With the insane amount of content being created every day, there is a massive flight to quality. People can totally tell when you phone it in versus when you take the time to do your research and help people solve real problems. If you look at the people who are truly at the top of this field, you'll notice that they do both: they are great at moving fast on popular topics, but they also genuinely provide deep knowledge and value.

I'll give you two examples from my own work so far as I slowly carve out my path.

First is my ngUpgrade course Upgrading AngularJS. I spent all of 2017 pouring my heart and soul into this thing and released it in early 2018. It was my first ever video course and I was terrified to put it out in the world. Looking back now with my current experience, there are things I would change about it. The videos aren't HD, I didn't have nearly as good of an audio setup, and I've learned a ton about writing good copy, email marketing, and creating accessible content. Yet, to this day, it is still an order of magnitude more successful than anything else I've done in terms of positive impact and revenue. I still wake up to emails thanking me for making something so comprehensive and detailed. I was at a conference in Las Vegas in 2019 and someone from Norway came up to me and thanked me for saving his job!

Why is that? It certainly wasn't because of how fancy my technology was or how great my marketing was (especially because I'm kinda terrible at self-promotion). It's also not a particularly hip topic. Looking back, I can understand that the reason it has worked so well is because I stumbled onto an extraordinarily painful problem in my day job and set out to make the thing I wish existed to the absolute best of my ability. And people are still using it and getting value from it! I'm getting ready to do a big update to it based on what I've learned, but that core fact will remain: deep problem solving is the key. The rest is just gravy.

The second example is a little less dramatic. It's an article I wrote called The Painfully Shy Developer's Guide to Networking for a Better Job. I put a lot of time and care into that article and had a lot of experience to back it up. I went deep into a painful topic I had experienced myself. I still have yet to write something that has gotten as much traction, except maybe for my first article on authentication in Gatsby. I've even reposted the Shy Dev Guide in other places and it still crushes my other writing.

I hope those examples are encouraging for you. Spend less time spinning on the Hamster Wheel of Content Doom and go deeper. To be perfecty honest, I've learned this lesson after spending way too much time on that wheel myself and realizing I needed to go back to where I started.

Strategy 4: Increase throughput by fine tuning your systems.

This last strategy is only for when you've been following the signpost of resisting automation to the point where you've finally identified some true bottlenecks in your work. What you need then is not increased output, but increased throughput. What's throughput? It's the rate of production. You need to be able to move faster.

For some reason, Amy Hoy's writing has an uncanny ability for me to crystallize something that's been on my mind and cause me to take action. At the beginning of 2020, I had sensed that I needed to make some changes to my creative process but I couldn't figure out what it was. I was starting to feel like I needed to double the hours I was working, but I knew that was pretty much impossible (at least if I wanted to have a life and a happy relationship). I read Amy's ebook "Slay Your Schedule" as part of her 30x500 course and it finally clicked. I didn't need more work hours, I needed to increase my throughput by optimizing my workflow and systems.

Here are some examples of that I've done recently:

• Getting a better A/V setup (a mic stand, a better audio interface, fixing some resolution issues) in order to reduce the friction of recording videos. This also drastically reduces my editing time. (If you want recommendations on gear, I basically just do whatever Joel Hooks tells me to do.)
• Adding a trackpad to the left of my keyboard to speed up editing.
• Automating meeting notes creation with Shortcuts.
• Rebuilding my site with Gatsby so that I can quickly write and publish articles that have a nice, accessible reading experience
• Using apps like Focus to block out distractions.

Note that you don't need any of this to be successful or happy. This is just icing on the cake that is letting me move faster. Plenty of people write amazing words or code on an old computer. I made the entirety of Upgrading AngularJS on a Dell laptop with a cheap microphone. I didn't know the first thing about automation and I did just fine.

But, when you see people who seem to be producing content faster than JavaScript frameworks can come out, it's probably because they've taken the time to build systems and optimize them. That's where I'm trying to be right now, so that's where I'm focusing.

In summary, be kind to yourself and others.

We've covered three principles:

• Be kind to yourself and embrace that you're learning new skills.
• Focus on shipping and improving.
• Resist premature automation.

And four strategies:

• Determine your priorities.
• Block out your schedule.
• Repurpose content to prefer depth over breadth.
• Increase throughput by fine tuning your systems.

I hope you find this helpful. Overall, remember that it takes about 6 months in any job to learn the landscape, and mastery of skills takes years. And, of course, remember that you are not the sum of your content production. That's a really weird system of judgment created by marketing and has nothing to do with your value as a person. Make stuff because you love it, or make it to pay the bills, but don't feel some obligation to conform to some arbitrary production standard.

If you like stuff like this, head over to my website and sign up for the newsletter. I write about my journey as as self-taught developer on a constant quest for self-improvement.