I still get to enjoy the views from the Google office in SF, now as a visitor 😎

One year a sourcerer

Francesc Campoy
Nov 6, 2018 · 7 min read

On November 1st 2017 I gave back my phone, laptop, and other fancy hardware back to TechStop (Google’s IT department), said good bye to very sad music (thanks Broady) to my many friends I was leaving at the office, and got on my way to SFO right on time for my flight to Paris to talk about dotGo about Machine Learning and Go.

That was my first flight as a Xoogler (Google alumnus) and as a sourcerer (source{d} employee). This blog post is my attempt to recap the many experiences I went through since that day.

Note: if you’re wondering who I am, days before leaving I published Thanks, and good bye Google friends and a month later I wrote source{d}: why I left Google. Those two articles might give you some extra context!

Rediscovering Developer Relations

At source{d}, I became VP of Developer Relations. The VP part of the title, although nice, wouldn’t have any value if it didn’t mean the CTO, COO, and I all are exactly at the same hierarchy level, reporting directly to the CEO. This meant I had the opportunity to have enough power and freedom to put in place the practices I sought necessary, taking risks as well as their consequences.

I gotta admit that since I joined, my opinion on what Developer Relations is has changed a lot. Developer Relations is, in my opinion, a field of work that connects a range of other domains: from software engineering to developer marketing, support, technical writing, and, of course, public speaking.

If you are in Developer Relations and you’re not writing any code, you’re probably not doing Developer Relations: you’re doing Developer Marketing. But if you’re only writing code and not thinking about how your users might feel while using your product … I’m sorry to tell you that’s not Developer Relations either! Finally, if you’re not writing blog posts answering the questions your users might have … not DevRel! Oh, and are you making sure the pizza makes it on time for your meetup? If not … probably not DevRel enough.

So … what is Developer Relations?

I think that the common skill involved with all Developer Relations is about empathy towards your users. You’re not trying to convince them of using your product (Marketing) although you really are a little bit. You’re trying to find the best way to empower your users to achieve their goals, sometimes by figuring out which features should be part of your product (Product Management), sometimes by making sure the interactions areas intuitive as possible (Developer Experience), or sometimes you’re giving talks with cool demos to show the potential of your product (Developer Advocacy).

I might write a follow up post on this topic, so if you’re interested on knowing more about this make sure you comment below asking for more details.

One of the ways my impact shows at source{d} is the creation of source{d} Engine, a product created as a result of crafting messaging around the many Open Source projects that we had created over the years. It is my opinion that good Developer Relations lead into good Product Management and that the two fields should work together as much as possible.

If you’re interested on knowing more what source{d} Engine is, I recently created this five minutes video that might answer some of your questions.

justforfunc: a worthwhile effort

The resulting video was a huge success with over 63k views so far.

This proved to me that there was a clear interest on more developer content on YouTube. Soon after I started justforfunc, and over the years it has become a biweekly (as in once every two weeks, otherwise I’d be dead by now) series where I share my successes and failures while trying to code cool stuff mostly in Go.

When I left Google many thought I would stop publishing new videos, but I decided that even though it would be a huge effort to keep the pace while becoming an executive at a new startup and trying to get up to speed with Machine Learning, Language Analysis, and the intersection of both fields: ML on Code.

Three years ago, the first episode of justforfunc came out.

This was a great idea in hindsight, because thanks to the audience of justforfunc I’ve been able to broaden my brand into Machine Learning without losing visibility on the Go community. This has allowed me to teach Go workshops at conferences and companies while meeting the people I wanted to know to discuss on topics like Code as Data and ML on Code.

My piece of advice here is the following piece of totally obvious idea:

If you’re successful at something, don’t stop doing it.

If a personal project is successful, but changes in your career make it seem like a less profitable way to invest your time, you need to consider much more than the direct benefits of the project itself. Consider how the success of a project could be used as leverage for your new adventures. Successful companies like Google use successful projects like Google Ads as a way to fund more risky but potentially very beneficial projects. Similarly, you should not let go the audiences you create along the way, instead make sure your changes are communicated clearly and implemented smoothly and you’ll be able to keep them as your partners for your future projects.

Today, over 18k people subscribe to justforfunc, and they have supported me all the way while migrating into more Machine Learning oriented episodes. I like to believe that honesty and openness on my career are to be thanked for this.

ML on Code

As I was saying before, Developer Relations is about many things and one of those things is Developer Marketing and … social media! Yes, it’s important to have a following when you work in Developer Relations (no, it’s not OK to make it your only hiring criterion). Not for the obvious ego boosting reasons, but because in Developer Relations having an audience is very powerful, both for communicating with them and getting help when you need it.

Hashtags are part of that social media / influencer thing you need to play with when working in DevRel, and I gotta say that creating the hashtag #MLonCode and some months later seeing it adopted by members of academia feels like a nice achievement.

I could spend hours talking about what ML on Code is and what it entails, but instead I’ll just invite you to read this post:

Or, if like me, you’re more into watching videos:

Last, but not least I wanted to talk about what leaving Google really is like.

Leaving Google vs leaving Googlers

One of the relationships I’m lucky to keep is my friendship with Greg Wilson, my previous manager and now Director of Cloud Platform Developer Relations. I like to think of Greg as a mentor since he supported my decision of leaving for sourced{d}. The free lunches at Google are another perk, and the conversation never fails to inspire me to do better.

In addition to all of the personal relationships I kept there’s also one more way I stayed connected: by becoming a Google Developer Expert. It wasn’t too hard to become one after a hundred episodes of Google Cloud Platform Podcast!

The future

Our product keeps on evolving while its adoption keeps growing and more and more big players start noticing us. The coolest part of ML on Code is still to arrive!

Oh, and guess what!? I’m hiring! If you’re interested in working with me in Developer Relations or you’re a senior manager looking for a fun challenge contact me at francesc@sourced.tech.

Happy 1st year at source{d} to me, cheers to many more 🎉

Francesc Campoy

Written by

VP of Product at Dgraph 🏳️‍🌈 Catalan