My dream job would be go around conferences, inventing new stuff and talking to devs and then writing new tools to solve everyone's problems
— Gleb Bahmutov (@bahmutov) November 22, 2016
That tweet resonated strongly with me. I feel very fortunate to be able fight for developer success at a great company that is fortunate enough to have large platforms that both rely on developers and can also reward them. I am bloody lucky. You can say that in your head with an Aussie accent as I am flying back from a fantastic experience with great friends that I have on the DevRel team, including the local Sydney DevRellers.
DevRel as a discipline is still pretty new, and it is something that I am constantly thinking about. Different situations require very different DevRel strategies, but there are many core values that we have across all of our DevRel teams.
Engineering
Developer Relations at some companies is marketing-driven. Some cynical companies consider this akin to developer marketing, but they use DevRel as a way to stay away from the marketing label, worrying about negative connotations from developers. Google DevRel is engineering driven. This isn’t surprising, coming from such an engineering driven company as a whole, and it is very akin to the way that we have applied DevOps. You could argue that we pioneered the DevOps discipline through our SRE teams. If you read the book you see how we have strong opinions on how to run and implement SRE in a way that massively scales. SRE teams are interesting in many ways, but one of which is that they have ties to both the product teams (e.g. Gmail SRE wants Gmail to be successful) and also users and production (Gmail has to be reliable, and user privacy is key).
Our SRE teams are the result of attacking ops issues from an engineering mindset. It is important to note that this is holistic engineering, and not the same thing as “so you just write code all the time”. Solving the problem from an engineering perspective allows you to scale non-linearly.
With DevRel we look to scale this way too. Rather than having to rely on scaling armies of evangelists, we have smaller teams that do high leverage work for developers, the community, and their areas of focus. If you work on the Android DevRel team, for example, you are looking for any areas to help developers in that ecosystem. A fantastic example of success here is Chris Banes looking at fragmentation and building support libraries. You wouldn’t write an app without them.
Another good example is the Lighthouse project that stemmed from Paul Lewis and has spread throughout the team. What if developers could run a tool on their codebase that proactively tells them what they should be doing for users? The initial focus was on performance (still a major issue on the Web), but it has grown skills across the PWA spectrum and beyond. Guidance through docs, samples, and talks are vital, but they are amplified by tools like these.
I could go through every DevRel team and share stories like these where DevRel was able to improve the lives of developers at scale. One area that you may not know about is how we have shared services folk who help domain knowledge experts focus. For example, when I was doing videos back in the day they were very low-fi and simple. Over time the team built up a competence and we have a Google Developer Studio that isn’t just able to have top quality production values, but understands how to work with the developer audience. These central teams enable scaling whilst also pushing on universally high quality outputs. Another one of these teams is partner engineering, a group that works across the areas that Google has to offer. The team of world class engineers, being separate from one area, is able to focus on the success of partners.
Advocates
Long, long, ago, I wrote about the name advocates instead of evangelists and I still agree with myself (although there are many things that I would disagree with Young Dion on). It is really important that DevRel is a two way street. We do what we can to help developers through outreach for sure, but we also do so by bringing in their feedback to product teams. We are the bridge between the teams. When done incorrectly this can have some bad side effects. A product team can think “ok, my devrel is on that so I don’t have to think about it at all!” but that is not going to lead to the best success, just as if a development team ignored their architecture wrt ops. If a product team disconnects you run into situations where they begin to wonder “do developers really think this or is this just what devrel thinks?” To make sure this doesn’t happen we make sure to bring product teams and developers together. We bring them to events, run internal programs, etc…. but then know that while we are living in the community, the product teams have to spend more time making and improving on the product.
Ecosystems
We naturally think about long term ecosystems. Product teams are working on the next version, whereas we are much more naturally tied more to the now of developer pain. Our best work is done when we have strong metrics on the ecosystem at large and the problems that we are looking to solve in there. We try to understand the ecosystem deeply, to be able to fight for developers needs.
Healthy ecosystems are sustainable and allow for success much beyond a platform. Microsoft may have had a ruthless streak back in the day, but I always appreciated Bill Gates’ thinking about the platforms. He talked about how he didn’t want to be taking too much of the profit else the other players wouldn’t be able to benefit and it wouldn’t grow. The best long term platforms have enough for everyone to thrive (including users) and the ones we worry about at the moment at those where business models aren’t fully working. DevRel fights for developers getting what they need from a platform, and making sure their model is sustainable.
Walk then talk; Develop then Relate; Repeat
It is easy to get soft and lose your way. In SRE they protect their teams from getting stuck on manual admin tasks by watching to make sure that they are engineering at least 50% of the time. In DevRel it is important for everyone to be engineering on their platform. This is how you keep your empathy with the developers that we are trying to help. It is how you find the rough edges. It is how to deeply understand issues well enough to be able to work with your product teams. Always Be Coding. The flip side to this though is that there is a “relations” aspect to DevRel. It isn’t enough to be coding in the corner, we need to get out there participating with the community and sharing our information.
We are definitely a new discipline with much to learn. I love looking around the various devrel teams who are all different, but who share the same passion for developer success. We love working on an area that we deeply understand as we are developers ourselves. It is very humbling to see the people on the team who are world experts in their fields, but they decide that DevRel is their path to help developers, a path that has huge leverage.
In a world that is being eaten by software, we want to help fuel the developers to improve that world using all that Google has to offer.
p.s. I should also note that the term “Developer” has broadened over the years. It doesn’t just mean “Coder”. For example, we have a Design Relations team 🙂