Dion Almaer

Software, Development, Products

Developer Relations

Embrace and Opine

Leave a Comment

How do you embrace all of the great work that a community is doing, and also share strong opinions on the health of an ecosystem and guide developers away from the paradox of choice?

We often struggle with this at Google. I have seen a trend occur, which is the title of this post: Embrace and Opine.

We want to be part of the community, understand it’s needs, and help foster the creativity abundant in it. We are reluctant to be kingmakers (or queenmakers etc!) and thus have to be delicate not to squish anything in the ecosystem. We can’t allow this to paralyze us though, so we have worked to detail the outcomes that we feel are important and we invite the community to offer solutions.

For example, the Web isn’t widely experienced in a way that highlights what it is capable of. Web DevRel works to not solely offer guidance, but also share tools such as Lighthouse, which can help you walk the path to a good experience. This isn’t just about performance, but helps share best practices across security, a11y, PWA, and more. Lighthouse has been written to be extensible, so you and the community can write audits.

There are also great examples across our other developer platforms:

  • Android has become much more inclusive of the community. The most obvious example is the embrace of Kotlin, and how we are collectively working to make it as great as possible on Android (it’s got a great starting point, but we can always do better…. and we will). There are many other efforts here too, where we are talking about how to best solve problems, and being inclusive of how great open source and community libraries can be part of the solution.
  • The Assistant team acquired API.AI, which thinks developer-first by recognizing that you don’t necessarily want to build things differently for every platform out there
  • Firebase has a vibrant third party ecosystem that the team fosters. We open sourced much of the Firebase SDKs at the recent Google I/O (and this was just the start).

Setting guidelines on the outcomes that are important and embracing the community is great, but it isn’t sufficient.

We often hear from developers that they want to understand our opinions. To that end, we are trying to delicately walk that line without closing down options, and being humble when we don’t know.

Building on some of the examples, you can see how this works as the other side of the coin via:

  • The fact that we have highlighted Kotlin, when there are plenty of other choices on the Android platform. Our high order bit is helping you build fantastic experiences for your users. This can be done in a variety of ways. With Kotlin we felt that we could join forces to deliver more. We are also sharing more opinionated positions and libraries for how to best build your apps via the Android Architecture Components (side note: I am really enjoying Florina’s series on exploring Room)
  • AMP is very opinionated in using constraints to enforce performance. Polymer is very opinionated in how best to build Web applications as close to the platform as possible. We are excited when companies such as Wego put these together to great success (in terms of user engagement, dev productivity, etc), but we also highlight success of other companies using other frameworks, such as Twitter. With HNPWA we provide a way for everyone to play the game and compete, which is great. We are seeing more and more frameworks supercharging their mobile support, and showing how to build web apps that work for users. If many frameworks are pushing on this, more users win.
  • Firebase is obviously very opinionated itself. The Firebase team has a high bar for developer experience, and thinks about how the sum of the parts result in more value for developers. The notion of being *part* of Firebase it an opinion in of itself. Hopefully developers are learning that if they use Firebase, they are getting a high quality developer experience across platforms.

I am growing to like this balance. I don’t like the extremes of “heres the one true path from the ivory tower”, even though it is so tempting (because of the paradox of choice again). By setting the rules of the game clearly and allowing many to compete we allow for unexpected outcomes and developer choice. By strongly sharing our opinion you can understand what we care about and our direction, and we can share proof, with real world numbers, on why we feel a certain way.

I look forward to doing much more of this. Of us being more involved in the community, and also sharing more of our opinions and products.

A deep thank you to the communities that fight to make a better craft to deliver a better world.

Tech writers are underrated

Leave a Comment


I have long seen the Bay Area (and tech industry in general) hold up the engineers, or the designers, as the heroes of Silicon Valley. There is the mythology of Steve and Steve in a garage, or Jonny Ive in a pristine design lab, creating the future.

In my own experience I have seen how important all of the roles are to making sure a product, and a company, is successful.

I highlighted project managers and QA engineers in the past, and today I want to speak about tech writers. Being back at Google I have once again gotten the opportunity to work with incredibly experienced tech writers, and I want to tell the tale of two (hypothetical ones): Robin and Pat.

First up is Pat

Great tech writing requires an immense understanding of the engineering product, as well as knowledge of the range of developers (or others!) who will be using it. The writer is the bridge between the product and the engineers knowledge who built it, and the end user developers. Pat takes the time to build the relationship with both sides and go deep with the product and its goals before getting to work. By embedding with the product team, and devrel experts, she immerses in this information, and is also able to help define the product.

By working with the product team she is able to get the insights and deep knowledge, but the understanding is that the audience is not the internal team, so the job at hand is to educate and help the external developers.

Too much documentation happens at the end of the production line “and now, can you writeup some docs?” This can be natural. You don’t want to waste time redoing docs while the product is undergoing massive iteration, but by having Pat there from the beginning gives the opportunity for the information to iterate and tweak, and then it can be deeply baked at the end. Pat is very strong when it comes to information architecture and taking massive amounts of information and prioritizing and shaping it based on what is really needed.

Many tech writing teams from various past lives felt stuck in the 1990s. Their process fit a “and now we need to write the manual” type style. Books are great, but not only are they not the way that many dev learn, but they have limitations. These days, for technical products, you can bring together a slew of tools:

  1. Being able to play with the products live can be an amazing learning tool, and we all know that most people learn best by doing
  2. Video, and various widgets (including tools, playgrounds, etc) can be embedded and composed with written content
  3. Customization for the developer (e.g. show the sample API client usage using JavaScript vs. Python).

Another huge difference is that the entry point, and path, is so much more dynamic. Many developers are ending up on your content based on a problem they are having:

  1. Ugh I can’t do X
  2. [X] <= search for answers
  3. End up in a doc, potentially very deep into the docs.

The default case isn’t “I want to go visit the home page of the documentation today!”, and Pat knows that all too well.

Next up is Robin

Robin is an empathic educator. Robin loves to code and build things, going as deep as possible on not only the product, but also the competition and ecosystem.

This gives Robin a ton of context on where to delve deep. If we aren’t consciously shaping the documentation experience, then it is easy to default to equal weight on small docs in the small. In the real world every API and method is not equal, and there are tasks that developers want to accomplish that don’t line up directly to documenting code.

As Robin looks at what the developer is trying to accomplish, and both feels individual pain and witnessing the community, a slew of solutions come up. Robin is able to drive change to the developer product/platform itself this way, is able to envision new tools or fix existing ones, and the result of the work tends to be in less verbiage yet more solutions.

When working ideally, the tech writers work hand in hand with their other devrel counter parts to drive this change. Together, they prioritize the work and how best to attack the needs of the diversity of developers that use, or may use, their products.

Doing it all with style

Context is varied throughout our tools, but consistency is important too. To that end the writers and editors have built a style guide for developer documentation. This is a living document that works as a collection of best practices and contract for how documentation can work best.

This is really important work as developers naturally bounce around through various documentation and use a variety of developer products. If we can do a better job here, a developer that jumps between docs on Firebase and Android will be able to intuit a lot along that way, versus having the feeling like these words are vastly different, and having to learn the cultural norms of the docset. I am happy to see the style guide public, as we see more and more projects in open source, and the community cares more and more about documentation. If someone wants to jump in to help with TensorFlow or AMP docs, they can easily see where the writing team is coming from.

Educator

It has been really exciting to see the tech writers in our DevRel team really take on the role of educator. They care deeply about developer success, akin to the other roles. This is something that ties us all together.

We want developers to be successful, so they can build experiences that enable people in the world. This is what gets me out of bed in the morning, having the platform to help in a small way.

Developers know how important docs are, and tech writers now have a massive impact there and much beyond.

And, I want to say thank you to the tech writers who help this mission, every day.

Others in the series:

What I love about Google DevRel

Leave a Comment

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 🙂

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