Last August, I moved from Software Engineering to a role in Developer Relations at Google Cloud. Since then, I have helped users adopt technologies like Istio, moved across the country (twice), spoken at multiple conferences, turned twenty-five, and became my team’s tech lead.
It’s been a fun, challenging year. Here are four lessons I’ve learned along the way.
When I started in this role, I was worried that I didn’t have enough experience. I had only been a “real” software engineer for two years, and at Google, I was immediately surrounded by smart, qualified people, many with years of experience. I felt like I had an impossible amount to learn in order to catch up.
sourceBut here’s the thing. You don’t have to know everything about a certain technology or product in order to do effective DevRel. Developer Relations is about empathy - listening to users - and then forwarding their feedback to product teams. It’s also about creating content, whether that’s building new tools or samples, writing a tutorial, running an empathy session, or giving a talk. So usually, by the time you’re creating content, you’ve already built up expertise about the product or feature in question.
In my case, listening to why customers were interested in Istio, and the successes and challenges they had adopting it, was one of the best ways to learn about the project. I learned quickly what a service mesh was for, and in the process of reading the docs, had fresh eyes for where gaps existed in the product.
I think that for DevRel, more important than having a brain full of knowledge is a readiness to learn from users. The tech industry can change quickly, and you might do DevRel for many products over time. I don’t think you need many years of experience to create impactful content. But I think you do have to invest the time to continuously pick up new technologies.
Still, there will always be questions you can’t answer - how does Firestore work with Kubernetes? What is SOAP?? - and for those questions, I can turn to one of my awesome colleagues. Almost always, they can point me in the right direction. Which brings me to:
DevRel can sometimes feel solitary. Because there are a lot of users to hear from, those connections can be short-lived. There is a not-insignificant amount of travel, and often, my teammates and I are working on different projects, with different teams.
I think the nature of DevRel raises the stakes on the people you work with. Why? Because I think that in order feel supported at work, you need a safe place to land: places where you can share triumphs and struggles, ask for feedback, engage in off-topic discussions about baking.
And these relationships can go two ways: you can TA your teammates’ workshops, summarize articles for a group chat, help other DevRellers practice their talks, answer their questions (What’s a PVC??). I have been lucky to have multiple mentors since joining Google, who encouraged me to start communicating feedback to product teams within a few weeks of my start date. I am so grateful for them, and for the confidence they helped me build early on.
In DevRel, there are also lots of other people, internally, to talk to. For me, this means the partner teams for the Google products I represent externally. This includes product managers, engineers, tech writers, marketing. These are the people I usually talk to most during any given weekday. For this reason, it matters a lot to work with a product team that is receptive to your feedback, interested in DevRel’s help, willing to answer questions, willing to invite you to customer meetings, and excited about improving their product.
When I moved into this role from Software Engineering, the most drastic difference in my working life was not the programming languages I used, or the products I worked with. It was meetings. On an average weekday, I have 6–8 meetings: with users, the open-source community, product managers, engineering leads, UX researchers, and my own team within DevRel.
I’m an introvert, so meetings drain my battery, even if in a good way, and they can also disrupt uninterrupted time to write code, create new content, and otherwise think deeply about things. This means that I have to protect my time.
Because I sit on the east coast and most of my colleagues are out west, I usually have a few quiet hours in the morning to get things done. But I certainly have not mastered time management for DevRel; I find it especially challenging to decline meetings with people I’m actively working with. I don’t want to let them down, or make it look like I don’t care! If you have advice about this, do comment down below.
DevRel is a people job. My job is not to sell products, or to build them. It’s to connect people to Google’s technology, hear from them about how they’re using it, what they don’t like, and then to make things better. This means that often, you might hear more about the “bad” than the “good.” I think this can lead to a mindset of obligation to fix all the things. Especially true if the total DevRel footprint for a certain product is small.
Also, there will probably be an endless backlog of things to do. There will be features to champion, bugs to file, docs to review, tweets to compose. All of this, coupled with the fact that I really like my job, makes work-life balance much harder than it was when I was a Software Engineer.
The best strategy I’ve learned to cope with this is pretty simple, which is to leave work at the office as much as possible, not have anything work-related on my phone, and use my weekends to actively spend time with friends and family, do fun things, and sleep. Sleep is important. But again, I haven’t totally figured this out. Actually this is the thing I definitely have not figured out.
Working in Developer Relations has helped me grow in many ways, and I’m grateful to all my colleagues for making my first year a great one.
That said, no job is perfect. There are tradeoffs. I’m definitely writing less code than before. But every day, I get to flex a different set of muscles - writing code, writing prose, trying out products, active listening, engaging a customer, debugging bad YAML, public speaking. For me, at this stage in my career, DevRel is the right place for me to be, and I can’t wait to see what the next year has in store.