• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

Archives for March 2017

What I love about Google DevRel

March 22, 2017 Leave a Comment

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 🙂

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • I have scissors all over my house
  • GenAI: Lessons working with LLMs
  • Generative AI: It’s Time to Get Into First Gear
  • Developer Docs + GenAI = ❤️
  • We keep confusing efficacy for effectiveness

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Founders Future GenAI Gender Equality Google Google Developer Google IO Habits Health HR Integrations JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Software Software Development Spaced Repetition Speaking Startup Steve Jobs Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • February 2023
  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

The right thing to do, is the right thing to do.

The right thing to do, is the right thing to do.

Dion Almaer

Copyright © 2023 · Log in

 

Loading Comments...