One year as a developer advocate

Posted on April 22, 2021  •  6 minutes  • 1239 words

I posted last year about what it was like to move from a full time development role into a developer advocate (DA) position. I wanted to follow it up with my experience after one full year for anyone interested in this type of role.

Everything I said in my six month post is true and I can sum up the last six months with.

Devrel puts the I in IC

For those of you not aware IC stands for Individual Contributor and generally is used to describe non-manager roles.

I work with a great team of other developer advocates and directly with our product teams. At many times I feel more like a contractor than a team member. But fundamentally I need to add value to the organization and products on my own.

Even though I write more software as a developer advocate I haven’t reviewed a PR for a critical bugfix in over a year. I haven’t had to debug someone else’s code. I don’t have to re-read someones convoluted comment about what a snippet of code is supposed to do.

Most of the code I have written I wrote completely from scratch on my own and I’m the only one who touches it. That gives me a false sense of my abilities to develop good software. My scope of development is much easier than developers working on large projects on critical business applications.

The risk is much lower for the code I write. Worst case scenario is my demos won’t work in front of a live audience. I won’t take down production or cause loss of revenue directly.

I’m able to write a lot more software because I’m not burdened by coordinating with other people, I don’t have to worry about scale or long term maintenance. What frameworks and languages I use are entirely up to me.

This is honestly great for me. I learn a lot with this experimentation and I can build and teach things faster which is needed with multiple talks, streams, and articles in flight at all times.

I also realize that my ability to contribute in a complex environment with business critical software will atrophy over time. That’s not a bad thing because my days of doing that work are behind me. But if I wanted to move back into a full time engineering role it would take me some time to acclimate.

I’m also aware of that limitation and I try to approach problems from the mindset of an enterprise developer and not a developer advocate. I’m able to provide more business value bringing that knowledge closer to the products.

I’ve been able to help more people

This has been great! I don’t mean helping people through talks and streams but actually 1-on-1 talks with people learning and building a career.

My time is up to me to schedule and prioritize and I haven’t had that freedom for a long time. I’ve been spending extra time mentoring people and joining community calls to help people learn.

Going into this role I was hoping that would be a freedom I would have and it has proven to be a reality over the past year. There are times I can’t focus on this but as product waves come and go I fill a lot of that time on calls with people to hear their stories and help where I can.

Saying “no” is hard

There are situations I should have said “no” to things and didn’t. There is a fine line between helping and burnout.

Because my time is mine I need to do a better job at focusing on my goals and shedding anything that doesn’t align with them. Amazon does a good job with this by making principles and tenets part of our core structure as an organization.

My team has tenets. As long as what I’m doing aligns with those tenets it doesn’t matter what the task actually is. We have a lot of trust on the team and within the org that people are doing what they think is the best thing.

Maintaining relationships is hard

There are opportunities I’ve wanted to pass along to someone I think could benefit from it. But it’s hard to know who that person is.

I have a lot of acquaintances and with the speed and different directions of this role it’s hard to keep in close contact with people. If our paths don’t cross often we usually just see each other in passing as we start the next thing.

COVID has exacerbated this problem but I’m sure it still exists in a world where we’re not all stuck at home. Attending in person conferences as an attendee was a time to connect with friends, but now I’m in a position where conferences are part of my job which takes some of the fun out. It’s kinda rough.

I miss the close bonds I had with people dealing with the same big projects and troubleshooting the same bugs. I don’t think that exists as a DA and it can get very lonely. I only imagine it’s worse for people who travel often.

I’m sure in a world without a global pandemic you have great experiences and amazing memories, but without someone to share the journey with they turn into stories instead of meaningful human connections. I’ve seen that play out with far too many developer advocates who spent years on the road because that’s what the job asked.

I’m a part of multiple devrel slack channels and small groups, but they’re all only haphazard meetings with like-minded individuals. I don’t feel a connection in those spaces the way I did with my previous teams.

I’m not sure how to break this cycle or feel more connected with people. I “fly” from one virtual conference to the next and no virtual hallway track or happy hour has helped.

I’ve been sucked into the echo chamber

I said in my last post that devrel can be an echo chamber and I’m afraid I started to fall down this hole. Most of my Twitter feed and YouTube recommendations are from other devrel people. My ads are for camera accessories and streaming gear. My search history is littered with OBS how-tos and social media automation.

I tried really hard to avoid this trap, but I think it was inevitable for someone like myself who dives deep in any role and community. There are some things I tried getting better at and failed (subscribe to my YouTube ). There are other things I didn’t finish, and there are things I never started.

I still try to be a customer first. Have empathy for the people I represent and understand their constraints. It’s not always easy to do this and directly impact the products I support.

I need more data. I need more hands on experience. I need depth in the technologies and services they’re using. I need more time.

I’m still excited

Even with the downsides I still can’t believe I get to do this for my job. My weekly tasks vary from testing new services, writing and reviewing docs, creating videos and gifs, and coding.

I enjoy all those things and wouldn’t want to do any of them full time. I like the variety. I get energized by the diversity. I love helping people. I take pride in my impact.

Photo by Cookie the Pom on Unsplash