Are you a developer who loves to build relationships with developer communities? Are you looking for a transition from a coding role to one that involves developer relations? In a conversation with Rahul Chopra, Niraj Sahay and Abbinaya Kuzhanthaivel of OSFY, Prashanth Subrahmanyam, developer advocate at Google, sheds light on this hot role with some practical advice to help you kick-start your journey.
What does the term ‘developer relations’ mean?
Developer relations is a term that is probably overused or has different interpretations. There are cases where it’s aligned to the sales or marketing department in different companies. Some of them even term it as developer evangelism.
At Google, ‘developer relations’ is a part of a larger core engineering team. We work closely with engineering teams and with product management teams. We are expected to be technical experts in specialised topics and products and are uniquely positioned to work closely with the developer community.
We talk to developers and try to get their feedback. I am a developer advocate for Google Cloud and we try to understand how developers view Google Cloud products and how they use them. What is it that they are looking for? What is their feedback about the Google products they are using? What are some use cases they work on, and how difficult or easy is it for them to use these products? What are the likes and dislikes? And so on…
We work both ways. We also give feedback to the developers based on their inputs. What are they finding issues with? What do they want to know more about? What will help them in their usage of Google tools and Google products? This is the kind of information we give back. It could be in the form of articles, blogs, videos, code snippets, and architecture documents, or maybe connecting with other people who have been in this space and are ready to share their experiences to benefit the larger community.
This two-way scenario becomes important because we are the zeroth customer for engineering teams. And as the product is being built, we work as advocates on behalf of developers to the product team work. We try to use the new features that have been released and channel the feedback to product management and engineering.
What are the skills a developer advocate needs?
Looking beyond the necessary tech skills, I think empathy is the most important soft skill for developer relations.
Google Cloud is not one single product, but it encapsulates a whole suite of products. There is no single tech or list of skills required. As a developer advocate, I could select a product like Google Kubernetes Engine (GKE), for instance, and create videos and documentation on how it is built and how it should be used. Then the developers are forced to use it the way I am telling them to use it. This doesn’t cut it. Hence, when I say empathy is important, I need to understand what the developers want to do with the product and how it will be used further. Hence, empathy is crucial.
With respect to technology skills, I will start by picking (say) three technologies and deep dive into those. For example, I personally enjoy containers, serverless, and AI/ML. We have a lot of serverless products in Google Cloud, and many that are available from other cloud vendors. If I just create tutorials on how to use the serverless products, it is probably not enough. I need to dig deep into my topic; for example, why should somebody use serverless?
I need to help users come to serverless given where they currently are. If I am a desktop developer, why is serverless important for me? If I am an on-premise customer, why is serverless important for me? If I want to move to serverless, how can I do that? What are the steps to do it? Does it take six weeks or a year? This is the depth in technology that is expected from someone in developer relations.
One should take up a few areas that one is passionate about and delve deep into them — how will somebody use these, how can someone that wants to use them get to the desired state, and so on.
How has the developer relations role evolved over time?
Developer relations has been a core part of Google. For consumer products, we typically do user research and arrive at a good experience. However, there are products that don’t hit end users directly, but somebody in between (developer) has to use the product and build something for end users. This is the way Google Cloud, Android platform, etc, have been developed.
How do developer advocates maintain authenticity when balancing the needs of their company with that of the tech community?
To ensure balance, Developer Relations is a part of the engineering teams. When I am talking to developers, explaining something, I am helping them understand the space and what the product can do. So, for example, we work towards identifying the need – why they want containers and what is the problem statement they are trying to solve. Are containers really important for them? If not, we stop the conversation there.
For example, maybe what they are doing actually needs compute/VMs and not containers. We educate developers and help them understand what they need. We make people love our product and that’s the way we approach any query.
How is the success of a developer advocate measured?
We have to show our impact and the value we are bringing in. On one hand, there is the external feedback we get from developers. When we create articles or videos, the number of views is an important metric to note that people are consuming our content. We also get requests for doing sessions, events and community meetups, which indicate the demand for a product; these are measurable numbers.
On the product side, we try to help improve the product. The feedback that is accepted by the engineering or the product team is the impact we create on the product, and is measured as our success.
There are various ways to measure this. For example, some products have a Net Promoter Score. The more people want to interact and work with us, it indicates we are contributing something valuable.
If one part of your role is interfacing between the outside world and the engineering team, does it give you the power to suggest the tech stack for the latter?
I wouldn’t call it a tech stack. We help influence the external interface of the product at the level it is going to be consumed. If you look at an API or the SDK, we will influence how the community wants to use it. For example, say there is a product where we do the steps in the order of A-B-C, but find that the world outside is probably using the flow as A-C-B.
So we give that feedback — that developers may want to use it in this way and we should allow our product to be used in the same way too. We should not say that the Google way is the only way to use the product. This is what we influence.
The engineering team will choose what tech stack it feels is the best for that particular problem and product, for example, Java, Python, frameworks, containers, etc.
Google is very cognizant about security and privacy and we ensure that every library we use — third party or open source — is vetted, secure and has gone through all the penetration testing and scans.
The development team has a choice from this buffet of approved libraries and languages, and is free to choose whatever it wants. So, as developer advocates, we don’t get involved with this, but do help ensure the final product is successful.
‘Community’ seems to be the buzz-word these days. What does community mean and why is it important for companies?
Community is important for us to scale. We cannot hit the end users or the developer users one on one. Communities are the way to create this group kind of approach or a tiered approach. The whole idea of promoting a community is that people help each other and are not dependent on one person.
No one needs to be dependent on Google. Otherwise, one has to file a bug and then somebody in Google has to prioritise the backlog and then fix it. Whereas in the case of a community, when somebody knows what to do with a bug, they will send a patch, and then all it takes for us is to review it. Even that is easy because we ensure good code quality with test cases and unit tests, and nothing breaks when a patch is accepted. As long as it makes sense in the general direction of how the feature should look, it’s easier to just accept the patch. This is also a community effect.
The word ‘community’ in DevRel is used more in the context of local communities and local groups of people, and is a way to get like-minded folks together. These people can also share anecdotes and knowledge among themselves. So when we have to reach out to them, it is one community we need to work with and not 500 developers individually.
What are the tools and tactics DevRel experts use to start building these communities?
As developer advocates, we rely on analytics as it helps to understand the psyche or perspective of the users. What are they looking for, what’s working, what’s not working etc. So we do real-time analytics with respect to user engagement, and realise which content is not valuable or maybe we are not reaching out to the right audience.
The ecosystems team also conducts focused bulk outreach programmes and engages with people who are responsible for the local communities that are running. Their whole idea is to promote, support and grow these communities.
What are the biggest challenges you have faced as a DevRel expert?
The scaling is definitely one. India has so many developers and reaching out to everyone is impossible, but it is important to help users. We expect feedback from developers and would like them to raise issues that need to be addressed. That kind of feedback definitely helps us to fine tune the way we do things. We also definitely want people to realise that we are here to help them understand the topic. That’s basically where I am stepping in and trying to help out. It’s not a very difficult thing, but the more effort we put in and the more we connect with developers, the better it will be.
What is the path for career growth in a DevRel role?
Different companies have modelled the role differently. DevRelers are expected to be technical. They need to know their products. People who are experts in containers, Kubernetes and building systems with containers could probably go into a solutions architect kind of role in that space, depending on how deep they are into it. But if somebody was just creating client libraries, that person may not have got the needed exposure in architecture and designing systems. So a solutions architect may not be the right path in that case.
There are multiple streams of growth. One is the sales engineering side, where you are spending time, working with people, learning their problems, and explaining technology.
At Google, we are expected to be really hands-on and have technical depth, and hence we are close to technology and code. In such cases, growing as an engineer can also be a career path.
Because you are influencing the product – understanding the user’s needs and impacting the way the product should be built – product management is another possible path.
If you enjoy teaching, maybe you can start your own consulting firm and teach people. There are lots of interpretations of what DevRelers do, but there are definitely multiple paths that you can grow towards.
And within the DevRel role itself, one can expand the scope of impact. For instance, if I did something for India and it worked out, I could probably take it to other regions and make this more global. So that way I am growing in the role itself, by increasing the scope of my influence.
How can one move into a DevRel role from an engineering function?
If somebody is an extrovert, it’s a great role to move into, but may not be as conducive for someone who is extremely introverted. For example, if someone has stage fear, events can be avoided. But there are many other ways one can work with developers, like writing articles, blogs, or maybe recording a YouTube video.
Communication and empathy are critical across all roles. A frustrated user may tell me a product is terrible. But if I go to my product managers and say this product isn’t good, they will ask me for more information on what happened. What failed? What did the user want to do with the product? So there’s a way in which I need to give feedback too. I put it up to my team stating that these are some of the things that are working the way the product has been built, but are probably different from the way the user expected them to work. Maybe this feature is not reliable. Are we monitoring this? What is our expectation in terms of reliability? All this needs good internal and external communication skills in oral or written forms.
The other aspect is the intention to spread knowledge. If you want to educate developers then you should take up such a role. This was important for me and that’s what led me into this DevRel journey. I have grown as a software architect and as a tech lead. I mentor developers and engineers to ensure that they know how to use technology and match it to problem statements and requirements.
If you are the ‘zeroth’ customer for your engineering teams, does the element of open source make things easier?
I wouldn’t be able to call it either way. Working with open source has been a part of Google culture. Many of the products that we have built started off as open source projects, for instance, Kubernetes, Knative or TensorFlow. We approach building products in this way and we feel this is the best way to do it. If it is not an open source project and if any developer needs more information, they have to come only to us. Whereas, if it’s open source, others can work on and contribute to the project, as well as create articles and documentation. In this way, the community becomes more collaborative.
We also want to learn what developers and what the community outside want, and how they want to use these products. We might have our opinionated ways of building systems, but the world outside may want to use it in many other ways. Hence, we typically follow a two-pronged approach — for many products we have an internal fork to have tight controls and security in terms of the way we run things, and at the same time, also make these available as open source so that we can work with the community and make them more robust.
What is the one channel or medium for developers to connect with developer relations?
The easiest way to connect to a person one-on-one is through Twitter, and most of us are all there on it. We also have a developer advocate directory (https://cloud.google.com/developers/advocates), which lists the team members.
If you want to reach us about a topic, then you can use YouTube channels or our blogs. Comments are always open and you can also reach out directly there. We will get the notifications and can then engage with the developer. Even if you reach out directly to me or any other developer advocate, we will definitely try to pull in the right people and get the answers from the experts.
India has a large community with a huge interest in Google platforms. How do you handle so many developers reaching out to you?
The scalable way to do it is through teams called ecosystems. These are teams that actually manage the communities. So they have program managers who run and support various communities. They support Google Developer Groups (GDGs) and these, in turn, have local leads.
So we have this hierarchy of functions where we try to channelise and funnel the feedback through multiple sources.
How does the GDG team attend to queries?
GDG is in the public domain and we connect to them via an outreach. The ecosystems team works with event organisers and plans meetups during weekends, where we discuss topics for an hour or so. The ecosystem teams help ensure that communities are running and take care of their needs. They get feedback from the communities and reach out to the developer advocates if some topic needs to be addressed. So, we connect, probably deliver a session there, or even talk to them in person and find out what’s happening.
Who manages the Google open source community in India, and does that team work with DevRel also?
We do have a team — the open source programs office. It takes care of open source needs within Google and also the external facing industry or industry events.
On the ground, it’s a distributed responsibility. There are engineers who work entirely on open source products. Somebody in Kubernetes would inherently be spending a lot of time working on open source. As part of what we do and because we are interested, many of us work on open source projects.
In terms of the developer landscape in India, what are your insights on the roles of and expectations from developers?
India is currently home to the majority of global developers. You can think of companies being present in countries in two different ways — one is where the purchasing power is, and the second is where the developers are located. India is where many MNCs have their development and implementation teams. India is also a place where startups are being created. The purchasing decisions are also being made here now, and the implementation, too, is being done here.
Developers need to be up-to-date with what’s happening in the field. They need to ensure that their own productivity keeps increasing. Learning about a new product is important, but what’s more important is to fit it into the right purpose. A developer needs to focus on writing code that delivers value to the end users versus writing code that ensures the system is running fine.
In recent days, my team here in India is focusing a lot on practices like DevOps, SRE (system reliability engineering), monitoring, observability, and so on. There are cases where I have seen developers building systems, but not implementing enough logging and monitoring. So when something breaks, you have to go back and debug and figure out what happened. This (debugging) is not what developers should be spending time on. The systems that you have should deliver value and you should know exactly what the system is doing at any point of time. I would encourage developers to think more in terms of building their tool chain and tool sets around their development so that many of these things can be automated.
As an example, if you are building systems where concurrency and multi-threading are important, then choose a language that is built for this purpose rather than choosing an older language and retrofitting it the way you want it. As I said, you need to be aware of where the world is going, and what the new products and technologies are. But, most important, ensure that you have your tool chains and environment set up right, so that whatever you build delivers value.
When comparing India with the global scenario, how do you see the developer community adopting migration to the cloud and containerisation?
I think that way we are in a very good place here. India is a more nascent market and doesn’t have to contend with legacy technologies and replacing them. Our developers understand the newer technologies. The first thing a startup does is choose a cloud provider and pick up some cloud services. We are starting at a much higher maturity level, compared to the rest of the world when it comes to cloud adoption.
But there is also a trap we must avoid. It’s not just using the latest buzz-word technology but fitting what we have into the right purpose. In terms of adoption and maturity, we are using the latest technologies and so we don’t have to think about how to migrate from what is existing.
India has global development centres, which are captive as well as independent. Are you also supporting them, and does your role involve building a relationship with the enterprise customers, where you understand their core problems?
It’s part of what we do as well. Google has a program called DORA (DevOps research and assessment). We have written a lot of books penning down all the knowledge we have gained over the years, which are available as a free download. So that’s something that the enterprises are definitely looking at, and we have also done some sessions and workshops with them.
We have also helped them when they came with queries like how can I move to the cloud or what can I do to reduce my operational costs. There are folks that have come in asking: How do I do DevOps? How can I achieve maintainability? And so on.
We do have a lot of content for the enterprises. We have captured information on how successful companies do things. What are some of the failures? What are some of the pitfalls the others have encountered? This information is also published in the State of DevOps report. All this is useful for enterprises looking to reinvent themselves.
How do you see India adopting Google Cloud, and what has your experience been in this respect?
I see growth — there are a lot of people who are taking interest in Google Cloud. It is also perceived as the first choice for people looking into data analytics such as machine learning and AI. Most of Google’s own products have been built around this. Google Cloud is also the first preference of those looking to use the products that we have built and open sourced (like Kubernetes). What companies or developers choose to use is left to their discretion. We have been working on the mindshare, and showing that our products are built on technologies that we have made available on Google Cloud. Because of this reliability and trust in Google products, we are seeing growth.
Are there any myths that you would like to bust about Google Cloud?
There definitely could be a lot of myths. As an end user, I am concerned about security and privacy of data. There is a concern about companies taking users’ data. But Google Cloud is a product that we give out for developers to use. For example, if you use one of our ML libraries — say image recognition — there may be a perception that Google is storing those photos, but we don’t do this. Whatever be it — documents, images, proprietary data or an application you built on Google Cloud or using Google Cloud’s databases — the company does not see your data.
Systems are not built that way and the regulations help protect users’ data. We are putting greater emphasis on this with products like Confidential Computing that we launched recently. Here users can have complete control of their environment and no one outside it can do anything on their machines. So even the data that is stored in a machine or the data at runtime is in your control as a developer or as an enterprise; Google has no access to that.
There is some hype about government policy and the requirement to have data centres parked in India. Is that a cause for concern?
No, not at all. I think there are two parts to this. One is that you want to run your applications on data centres that are close to your end users to give them the minimum latency. To provide better and secure services to our customers we have built two data centres in India – Mumbai & New Delhi.
Can Indian customers assume their data is going to be in the Indian data centre by default, and is the pricing linked with the location?
The account is a global account like Gmail. You create an account, and then create a project in Google Cloud, where the project is the umbrella artifact that you use to manage whatever you are building. When you create the resource like a virtual machine, compute or create a database instance, you are allowed to choose the region.
Pricing is the same across the board. We have parity both in terms of the services that are being offered across the globe and also in the price.
From an API perspective, what is your strategy on how to engage with developers and bring them into your ecosystem?
We have a body of knowledge from all the products we have built over many years and know what makes developer-friendly APIs. So we ensure some of these criteria are met. We also do launches in a phased manner – Alpha, Beta, etc, and we get feedback from developers.
If it’s something in a very new area, we depend on the industry experts — organisations or may be a meet-up. For example, Open Banking has published its API spec and if you have to build banking APIs, there is a reference you can use and start from. I believe we know how to build developer-friendly APIs which are not overly complex. We use different technologies — we have GRPCs and REST APIs. Typically, we release APIs in both formats so that developers can consume them based on the systems they are using. DevRelers then collect feedback and help ensure that the APIs are meaningful and are in a consumable format.
How is an API versioned?
Different products do versioning in different ways. If you look at libraries and SDKs, the different versions of the API are available for download in major, minor and patch versions, and the right version can be pulled in using a dependency management system.
If you use Web based APIs, then we have a versioning system in the URL or in the payload. So when you send the request, you specify the version number. I personally prefer the URL based approach
You also need to adapt to the industry standards. Let’s say we came up with Kubernetes APIs, and hypothetically, say, other companies have already built Kubernetes APIs and are using a specific format. It doesn’t make sense for us to change our API structure because we have done things in a different way.
That’s where DevRel also comes in. One would understand how developers consume the API and what specifications they are looking for, what are their use cases, etc.
How do you handle API feature deprecation and things like that?
These are some API patterns or standard practices that anybody should follow. If you look at APIs, you can deprecate features as well as add them. API is an interface and when somebody has started consuming the interface, you should be super careful to not break what has already been built. So I would recommend that a versioning strategy is used.
You need to have some sort of version in your APIs, and you can have this in the URL itself. It could be a cloudapi.google.com/compute/v1 or */v2 or */v3, so that those who are consuming the older APIs are not impacted.
As a service provider I must ensure that the implementation is running fine. There’s no point in maintaining the URL if the implementation is not maintained.
The second thing to focus on is non-breaking changes. You may do a */v1.1, */v1.2, */v1.3, and so on for non-breaking APIs. Those who are using it can continue to use the old API, but the rest can use the new version and get additional features, attributes or methods.
Coming back to deprecation, we need to let developers know that something is changing and that you need to move. For example, we try to ensure that at least one prior release is actively maintained. Before deprecating the API, enough notice should be given to the developers.
For example, in an SDK, you can throw a compile time warning that you are using an API method that has been deprecated and ask the developer to use the latest version. Let the warning be active for a month or two, as the developer may update the SDK only once in a quarter or so.
If it is a security issue, we need to be more proactive so that people really understand these advisories and warnings. Communication is important, maybe via doc sites or via mailing lists.
To begin with, ensure that nobody’s implementation breaks, in order to maintain reliability and trust. So make sure that you have a good versioning strategy without breaking your users who are on an older stack. However, if something actually breaks, communicate and reach out as much as possible.
