Career Switch Lookahead

I have finally resigned from Facebook Singapore and joined Google as a Developer Relations Engineer in the Bangalore office. It wasn’t an easy decision for me and certainly not something I could help everyone understand. I have moved on from all those questions and thoughts which kept me locked in Singapore. Now I feel much free and much aware of what’s happening around me. This blog is not about me explaining my decisions!

I happened to read a book called Getting Started in Developer Relations - Sam Julien and I got motivated to write about my thoughts. I was amazed at how I was applying developer relations skills into my previous role as a Solutions Engineer at Facebook and discovered that my role now has a much deeper significance in the developer’s world. While I just happened to grow myself into that role previously, my role in Google demands me to now perform as a part of the larger developer relations organization at Google.

I have already submitted a review in Goodreads. But I wanted to share my high-level thoughts on how I applied dev rel skills in my Sol Eng role and some learnings out of the book reading exercise.

Firstly, my whole team was distributed geographically, depending on where its easy to manage relations with clients. Say, US clients are likely to be managed by Sol Eng from North America and APAC clients are likely to be managed out of Singapore. Facebook being a super lean company, unsurprisingly hasn’t yet expanded its engineering workforce into several countries where it has some business as of today. The geo split brings a bit of management overhead but also adds agility to the market demands as I explain below. My team’s performance was tied to three basic pillars of the role.

1. Build work - My team was expected to code and develop digital advertising solutions for certain alpha clients (read as big corporates in various industry verticals). I was expected to meet the marketing teams and their hierarchy of various companies, often having c-level executives for a 1:1 discussion. My team was supposed to catch up on what’s trending in the ad tech world (some really cool auto ads management system) and develop solutions to enable clients to build up upon them and continue ads with Facebook. These days messaging ads (WhatsApp and Messenger), third party advertising cookies deprecation by browsers and privacy-aware advertising were hot topics.

2. Scale work - My team was expected us to unblock ad tech solutions adoptions at a scale that our team or other product teams have developed for a global audience. This often involved my team in seminars, workshops and office hours. One could have found me in countless Retail and CPG industry seminars where we would often talk about how companies are using Facebook to tell a story or drive their brand engagement/sales.

3. Teamwork - FB expected us to bring about initiatives that help the team move faster (like creating content for onboarding new folks, taking interviews) or build a bigger social aura (like giving talks in tech conferences). I loved speaking in meetups, especially demystifying questions on facebooks ad targeting and delivery systems. It took almost a year before I could understand so much that I could speak confidently.

Coming back to the book, I think Sam has given a very nice summary of my previous role. A Dev Rel role essentially contains four aspects:

1. Awareness of what problems do we solve.
2. Education on how to use the product and where to seek help.
3. Feedback to gather the experience while solving problems.
4. Fostering Community partnerships to celebrate successes and help others win!

I completely echoed that the whole process of dev-rel enlightens an engineer to see the bigger picture from the customer’s lens. Even when one is a junior engineer, dev rel skills certainly helps in the annual reviews. Knowing and sharing the key metrics that matter for a product or a customer is always a great value add for insiders.

There’s a simple mental model Sam shared to analyze any product.

1. Dig into the wins and friction and pains associated with it.
2. Research and Create a strategy around them.
3. Suggest potential impact and user feedback to support them.

It is easy to visualize that having such a list of things to improve is a much better situation to be in for learning or for growth than just being amazed at the awesomeness or smellyness of a particular product feature. I am personally a type of person who gets swayed by the possibilities and thinks less about the ease of enabling them. So, it was great feedback for me to keep an eye on! I will keep track of this while writing my first friction log.

So, if one asks me one big takeaway from reading the book, I would say I got motivated to look deeper into these questions:

1. What cant I do with a product?
2. What am I unable to do easily?
3. What is the level of documentation?
4. What is the level of support?
5. Are there alternatives offering better stuff?

I also got validation that my way of creating blogs and short videos is probably the most optimal (seemingly best!?) way of getting the content out especially when I am learning the topic itself! I was under so much stress about not having learnt much about google cloud before joining google itself! But I believe I would be a better developer relations engineer by not knowing that. Although, my output in terms of improvements might be lesser than someone who’s a pro. I certainly won’t be an undercut in terms of performance! I feel confident of having a fruitful career and doing good for my team and career.

Being overwhelmed, was a smaller issue for me. I was probably less overwhelmed immediately after joining Google’s developer relations team (compared to FB) which is similar in terms of work from the previous role but much specialized in nature. Mainly because Facebook had previously thrown me into the overwhelm state for far too long and I am now probably comfy to be in the state of “not knowing it all”. But it was nice to know that there are still so many folks that have these problems. I just feel for them and hope that with time, they will get better like everyone else does.

Thank you Sam Julien for writing such an amazing book - VA