Here are my learnings based on my first year running developer relations at Sanity.io. I guess they are rather obvious, but I think they’re worth sharing as they can be helpful for someone starting with developer relations/advocacy.
Cover Image: I was a fan of Syntax.fm’s Scott & Wes before I became a developer advocate. Here I got to meet them at JAMstack_conf San Francisco in 2018.
I’ve been in developer relations for about a year now. Actually, I’ve only known that “develop relations” and “developer advocate” have been specific things for that long. The first time I consciously encountered these titles was when I was offered the role as "Head of developer relations" with my current job at Sanity.io. It seemed to encapsulate with what I could contribute with.
Even though I had never worn such titles before, I had experience in teaching, mentoring, and dissemination, and I had been promoting aspiring developers before. I have a lot of training from teaching theory and methodology at University, I have run web development courses for retirees and beginners, and I have been writing about technology for a long time. I just didn’t know that that was a dedicated job in tech, and not the least, a “scene”. With T-shirts, stickers, books, and Slack groups. With the title, I was also joining a community and a discourse.
1. Find yourself a team that cares
I joined Sanity when they mostly were the developers from the original Bengler team. They made the platform because they wanted a real-time content backend for OMA’s website. In 2017, they converted Bengler into a startup for Sanity. Since I joined, I had to figure out how to do the developer relations part, but also contribute to how we should communicate Sanity in general. I’m very fortunate to be working with some fantastic people, both in terms of talent and experience, who also give an excellent mix of constructive feedback and praise.
That’s perhaps the most crucial part of what motivates me as a developer advocate: It's much more fun when you and your colleagues feel that there’s a stake, that there‘re care and attention given to almost every detail of what we do. I get the sense that we have made this cool thing that we want people to use, because we think it makes their day better, and they will make cool things with it. If you want to work as a developer advocate, be on the lookout of a team that cares. It’s easy enough to forget if the product has a cool flair, or the perks are awesome.
2. Learn to take feedback
That stake, and care, comes with a challenging side too. There will be a lot of opinions, inclinations, ideas, and feedback on whatever you do. The feedback may even be conflicting or just not feasible to follow up. Your job is to mediate the feedback that you get within the company, with that you get outside, and turn it into something constructive and actionable.
I try my best to communicate why we are doing what we do in the weekly all-staff meetings. I also make sure to include nice things people have said about our work to remind the team that they’re doing work that's appreciated by real people. That's the “relations” part of the job.
I give much consideration to the feedback I get from my colleagues, but I don’t always follow it. That's partly having to follow my gut-feelings from all the impressions and observations I've, being "out there", and partly because the advice you're given is for inaction (“We shouldn't do x, y, z”).
I remember that we had a lot of discussion and indecisiveness around creating a new developer community. All the services had drawbacks for sure. My job then was just to pick something, and get it going. So I did. A year after we’re over 1.100 developers in our Slack. Yes, the message retention sucks, yes, it would have been handy to have all our answers indexed by Google. At the same time, the feedback, enthusiasm, and all the questions have been invaluable. We don’t regret it.
3. Talk less, listen more
Speaking of the community Slack. I also remember being super worried about trolls and people that would object to our Code of Conduct. It’s super interesting to see that many of us in tech are occupied with figuring out how we can make sure that people feel welcome, included, and safe. Since I became more aware of people’s shitty experiences, and my own mostly hassle-free experience in tech, I must admit that I many times have been afraid of inadvertently saying something that may cause someone discomfort.
Because I used(?) to be much more of a "here’s my five cents”-guy on Twitter and such (well 600 words in, I guess I still kinda am), but I have consciously abstained from posting and replying to stuff that may have irritated me. I use two thought technologies (which I picked up from the Back to Work podcast). The first is saying out loud: "I will not let this bother me." The second is to question "Is this the hill I want to die on?". They actually work — most of the time.
Instead of being such a smart ass, I have been trying to observe and listen instead. It is something I still work on being better at. I have been listening in two ways. First, I have made sure to follow a more diverse cast of people, and I have been trying to take in the stories of those who display concerns about the inclusiveness of tech. I’ve also tried to contribute with some thoughts and took part in organizing Global Diversity Call For Papers Day. And it has been humbling. And frankly, it’s nice not being the one offering the hot take or glib tweet (well, there’s still some occasional ones).
4. Learn how to take time off
Honestly, I’m still rubbish at this. So I write this as much as advice for myself as for you. Thing is, there’s an infinite amount of tasks you can do as developer advocate: there’s always another talk proposal, demo, blog, or some documentation you could improve. There are always people that need help with something. So you have to draw some lines. Now, it’s hard to offer exactly what those lines should be because it also is highly dependent on where you live, whom you live with, if you have a family, how old you are, etc.
I’m fortunate in having gotten professional help for recurring depressions, and have mostly figured out how to live with it (CBT worked for me). I’ve been through a burn-out experience when I did my Ph.D. studies at University and got into tech after that – where I felt much more at home. I’m also fortunate in having a spouse that rides dressage. I often tag along to the stables to get some honest off-screen time with our two horses and help her out with grooming, and the many tasks and sorts that you have to do there. I also do my best to get some exercise, jogging and such. Doing something completely different seems essential.
Taking time off is partly on you, but having a workplace that understands that highly motivated people often need help with setting boundaries and be reminded that they need to take time off to not burn out at the office, is important as well. We’re regularly reminded of this at Sanity, and we’re trying to build structures (everything from how projects are planned, to setting expectations) that enable and ensure this as well.
I also think it’s vital for us that has the roles of being a developer advocate to communicate this as well, and to our own discretion share those part of the daily life. It's easy enough to feed into people’s impostor syndromes and impression that you have to work all the time to belong in tech.
5. Take it seriously, but don’t be too serious
As a developer advocate you do an important job. You’re both responsible that other people are successful at what they try to do, and on relaying back to your team what you learn. You are inevitably tied to your workplace and — excuse the marketing term — its brand. If you are approachable and helpful, that will contribute a lot to your company’s success. Even if I had put “opinions are my own” in my twitter bio, my behavior will reflect something back on people’s impression of Sanity, and the work being done there. So I owe to my team to be mindful of how I act and communicate. This position is very different from coming from the Humanities, where you are much more your own agent (at least, this was the case where I was studying).
This connection that you have with your workplace, and the fact, let's be honest, that much of what you’re doing can fall in under the term marketing, also means that people will have certain reasonable expectations of your biases. The serious part is not trying to be coy with whom and what you are representing, and be transparent when you’re discussing things where you obviously have an interest if promoting whatever you do.
At the same time, you are also a person with all the flaws and particularities that comes with that. Sometimes, people will say disparaging things about whatever you’re working on. Or they will dismiss you as a just a biased representative of where you work. That is the time where you shouldn’t be tempted to go into arguments or make a big fuzz. Try to distill whatever legit criticism can be found, and move on.
Being a developer advocate is probably the most exciting job I have ever had. The range of different things you can do and the people you encounter is ideal if you’re motivated by learning new things and are excited by learning what other people are creating. It has been an absolute blast being part of launching the developer community for Sanity, and we have a pretty interesting year ahead of us opening a new office in San Francisco, hiring more people, and preparing for the next step.
I look forward to looking back at the coming year with a new blog post like this. Stay tuned (e.g., by subscribing to the RSS feed)!
Top comments (2)
I've been asking for years and I still am no closer to understanding what a developer relations person does.
Setting aside that searching for "developer relations" on Google would give you a good selection of concrete answers on the first page, and that I also mention what I do in the post above, here's a short list of stuff that a developer relation person might do in their job:
I hope you're now enlightened 🙇♂️