Are you a developer who loves to build relationships with developer communities? Are you looking for a transition from coding role to Developer Relations? If you are seeking an entry into the DevRel industry, Prashanth Subrahmanyam, Developer Advocate from Google, sheds light on the hot role with some practical advice to help you kick start your journey.
What does developer relations mean?
Developer relations or developer advocacy is a term that is probably overused or used at different interpretations. There are cases where it’s aligned to the sales or marketing department in different companies. Some of them even call it developer evangelism. 
At Google, developer relations is a part of core engineering. We work closely with engineering teams and closely with product management teams. We, as developer advocates, are expected to be technical experts in these topics and products. We are uniquely positioned to work closely with the developer community.
We talk to developers and try to get their feedback. I am personally a developer advocate for Google cloud, but we have developer advocates for all the other Google products as well. I try to understand how developers perceive the Google cloud products and how they use them. What is it 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? What are the likes and dislikes and so on. 
We work in both ways. We also give back to the developers based on their inputs.  What are they finding issues with? What do they want to know more? What is going to help them in their usage of  Google tools and Google products? This kind of information is what we give back. It could be in terms of articles, blogs, videos, code snippets, architecture documents, or maybe bringing other people who have done this, who 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 with product management. We try to use the new features that have been released in a way that an external developer would use and channel this feedback to the product management and engineering. 
What are the skills that you are looking for in developer advocates?
Looking beyond technology, I think empathy is the most important soft skill for developer relations.
Google Cloud is not one single product, but 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 for instance and create videos and documentation on how GKE 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.
In Developer Relations, we are expected to be experts at the topics that we want to focus on. Google cloud has different products and I cannot learn all of them. I will choose a few, where I can become an expert. I can do all my research and understand technically from the user perspective. It is important for me to understand how others would use it and what are the problems they are trying to solve with it. Hence empathy is important.
But looking at technology skills, I would start by picking (say) three technologies, and I would deep dive into that. For example, I personally enjoy containers, serverless, and AI/ML. We have a lot of serverless products in Google Cloud, also 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 be deep in my topic – eg: why should somebody use serverless?
I need to help users come to serverless given where they currently are. If I were a desktop developer, why is serverless important for me? If I were an on-premise customer, why is serverless  important for me? So if I want to move to serverless, how can I do that? What are the steps to do it? Does it take six months or a year? 
This is the depth in technology that is expected from someone in Developer Relations. One should take a few areas that they are passionate about and go really deep into that – how will somebody use it, how can someone that wants to use it get to the desired state.
How has the developer relations role evolved over time? 
Developer relations has been a core part of Google. I think we have been doing this since at least 2006. For consumer products, we typically do user research and arrive at a good experience. However, for a product that doesn’t hit end users directly but somebody in between (developer) has to use the product and build something for end users. This is how Google cloud, Android platform etc is. 
Let’s take the Android APIs. We are end users of Android OS directly on the phone, but somebody else is building the apps. If Android doesn’t allow the developers to build user-friendly apps, Android will not be successful. So if I was a developer advocate at Android, I would ensure that developers who are building these Android apps have the right tools. It shouldn’t take them one week to create a new project (for example) but they should be able to create a project soon and get started. 
How do developer advocates maintain authenticity when balancing the needs of their company and tech community?
That is why we are a part of engineering. We don’t have KPIs associated with us in terms of getting sales numbers. When I am talking to a developer, explaining something, I am not telling them that you should use Google cloud. I will not be selling Google Cloud to them. I am helping them understand the space. I am helping them understand what the product can do. So for example, if somebody asks me to talk to them about Kubernetes, I am not going to start by explaining GKE and its features. I first understand why they want containers? What is the problem statement they are trying to solve? Are containers really important for you? If it’s 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 are not here to push products to them. 
So bottom line – we don’t really need to balance between the company’s needs and the community.  It’s a virtuous cycle – if I take care of the developers and ensure that they like our products and it’s easy to use, automatically they will use more of it. 
Yes we are a business, yes we have a product, but DevRel does not sell it. The way we do it we make people love our product and that’s the way we approach. 
How to measure the success of a developer person or team? 
It is a big question and that’s always something asked by our leadership. We have to show our impact and the value we are bringing in. On one hand, there is external feedback we get from developers. When we create articles or videos, then the number of views are accounted for as important metrics to note that people are consuming our content. We also get requests for doing sessions, events and community meetups which also indicates demand and these are measurable numbers. 
On the product side, how am I helping improve the product. I could comment on a particular feature and did the feature change based on my comment. There may be a hundred different things pointed out in a product. It will not be tangible to do those things, but maybe a few can be revised . Those are the feedback that is accepted by the engineering or the product team. This is the impact that we have created 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 the people want to interact and work with us, it is also an indication to us that we are contributing something meaningful. 
If one part of your role is mostly interfacing between the outside world and the engineering team, does it give you the power to suggest the tech stack for engineering teams?
I wouldn’t call it a tech stack. We will help influence the external interface of the product at that 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 say we find out that the world outside is probably using the flow as A-C-B. and not A-B-C.
That is the feedback we give – that developers want to use it in this way and we should allow our product to be used in this way. We should not say that the Google way is the only way to use the product. This experience is what we influence. 
The engineering team will choose what tech stack they feel is the best for that particular problem and product – eg: Java, Python, frameworks, containers etc. Google is very concerned about security and privacy and we ensure that every library – third party or open source we use is vetted, secure and has gone through all penetration testing and scans. 
The development team has a choice from this buffet of approved libraries and languages and are free to choose whatever they want. So as developer advocates, we don’t get involved with this, but do we help ensure the final product is successful.
The word ‘community’ seems to be a lot of a buzz term. 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 to one. So the communities are the way to create this group kind of approach or a tiered approach. The whole idea of promoting community is that people help each other and are not dependent on one person. So as we spoke about open source, it brings in a community effect.
There are people who look at the code and say, maybe these things need to be fixed and they would submit a patch. You don’t need to be dependent on Google. Otherwise you would have to file a bug and then somebody in Google has to prioritize the backlog and then fix it. Whereas in the case of a community, when somebody knows what to do with this, 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, 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 like, 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 it is a way to get like-minded folks together. So, these people can also share anecdotes, knowledge within themselves and 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. Analytics helps to understand the psyche or perspective of the users. What are they looking for? What’s working, what’s not working and things like that. So we do real-time analytics in terms of the engagement analytics and how many people are seeing a kind of tweet, which tweets are not being seen at all? So, maybe we see that this content is not valuable or maybe we are not reaching out to the right audience.
The ecosystems team also does more focussed bulk outreach programs and engage people who are responsible for the local communities that are running. Their whole idea is to promote, encourage and grow. 
As an advocate, I must  be a technical expert on my topics in order to help people. I need to be up-to-date with any new feature that’s been developed. So the outreach is one part of all this, because unless I am an expert, why would the community want to listen to me? So, this is the part that I am (as a Developer Advocate) spending a lot of time on. Whereas for building communities we rely on the ecosystem team to manage this.
What are the biggest challenges you have faced as a DevRel expert?
So the scaling is definitely one. India has so many developers and reaching out to everyone is not possible, but it is important to help the users. We expect feedback from Developer, we expect developers to be critical in raising topics 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 and not sell Google cloud. This (sales) is the way many of them perceive developer relations in India. It is not so in the rest of the world. We need folks who are present locally who can understand the developer’s needs in India and that’s basically where I am stepping in and trying to help out for India. I think it’s not a very difficult thing, but the more effort that we put in, the more we connect with developers, and it will get better.
What could be the path for career growth in a DevRel role? 
In general, companies have modeled the role differently. Whether DevRel has been modeled as a sales function or as an engineering function, the growth path is dependent on this. 
DevRelers are expected to be technical. They need to know their products. So, let’s say somebody who is an expert at 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. If somebody was just creating client libraries, that person may not have got that exposure into architecture and designing systems. So a solution architect may not be the right path.
There are multiple streams and one is the sales engineering side. It is something where you are spending time, working with people, understanding their problems, explaining technology and one of the natural ways for somebody to move forward is actually through the sales function.
The other way as in Google, we are expected to be really hands-on and have technical depth, and hence we are close to technology and code. So in such cases, growing as an engineer would also be a path. 
The other thing that you could do is, because you are influencing the product – understanding the user’s needs and influencing the way the product should be built – Product Managementh is a path.
If you enjoy teaching, maybe you start your own consulting firm, where you are teaching 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 organisation 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, 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 being an extremely introverted person it may not be as conducive.
For example, if somebody is having stage fear, all it takes is don’t do stage events. But there are many other ways you can work with developers, like writing articles, blogs, or maybe recording yourself and do a YouTube video. Those are ways that you can reach out. 
Communication and empathy is important across all roles. A frustrated user may say a product is terrible. But if I go to my product management and say this product isn’t good, they would 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 should give feedback too. 
I will put it up to my team mentioning – these are some of the things that are working the way it has been built, however this is probably different from the way the user expected it to work. Maybe this feature is not reliable. Are we monitoring this? What is our expectation in terms of reliability? So, you should have 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 basically what led me into this DevRel journey. I have grown as a software architect and as a tech lead. I mentor developers, engineers to ensure that they understand 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, start off as open source projects, for instance Kubernetes, Knative or TensorFlow. We approach building products in this way and we feel it is the best way to do it. If it is not an open source project and if any developer needs more info, they have to come only to us. Whereas if it’s open source, others can work on and contribute, create articles and documentation. In this way, the community en masse becomes more collaborative. 
We also want to learn what developers and what the community outside want and how they want to use these things. We might have our opinionated ways of building systems, but the world outside might use it in many other ways. Hence we typically do a two-pronged approach – for many products we have our internal fork to have tight controls, security in terms of the way we run things, and at the same time, the product also is available as open source so that we can work with the community and make it more robust. 
What could be the one channel or medium for developers to connect with DevRels?
Easiest way to connect to a person one-to-one is through Twitter and most of us are all there on it. Also we have a developer advocate directory ( where you know who the team is. 
If you want to reach us on a topic, then you can use YouTube channels or our blogs. Comments are always open and you can also reach out directly here. 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 larger community with huge interest in Google platforms. How do you handle developers reaching out to you?
As developer advocates, we are few in number compared to the number of products. For example if we have 50 products, I can’t handle all 50, but only a few from my scope of expertise, and each of these products will have millions of developers. 
One way is general engagement, via platforms like Twitter. People would ask questions and while I may not be able to reply to everything, many of these questions would be similar. I would reply to a few that are important or those which gain a lot of attention from developers. We also reply to YouTube comments to the best of our ability and time availble.
The scalable way we 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 they 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 queries? 
GDG is in the public domain and we connect to them via an outreach. The ecosystems team work with event organisers and plan meetups during weekends where we discuss topics for an hour or so. The ecosystem team helps ensure that communities are running and takes care of their needs. They get feedback from them and would reach out to the developer advocates if some topic needs to be addressed. So, we will 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 then work with Devrel also?  
We do have a team – the open source programs office.  They take 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 is no single team.  I do my bit as much as possible working with open source and there are many other engineers who are passionate about it. 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. There’s no fixed set of teams who only focus on open source. As part of what we do and as part of our interest, many of us work on open source projects.
In terms of the developer landscape in India, what are your insights on roles and expectations of developer professionals? 
India is currently the home of 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 are having their development and implementation teams. Another landscape is that India is also a place where startups are being created. Now the purchasing decisions are also being made here, and also the  implementation is being done here. 
When thinking about skills, developers need to be up-to-date with what’s happening in the field. They need to ensure that their own productivity keeps going up. It’s not about learning about a new product but whether what you are implementing is fit for purpose. If you are in a company, think about those companies requirements and the company’s end user requirements. What technology can be used best to meet those user needs and so on. 
A developer needs to focus on writing code that delivers value to the end-users versus writing code that takes care that the system is running fine.
And in recent days, my team here in India are focusing a lot on practices like DevOps, SRE (system reliability engineering), monitoring, observability and so on. There are cases where I have seen developers build systems, but have not implemented 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 system is doing at any point of time. So I would encourage developers to think this way. Think more in terms of building your tool chain and tool sets around your development so that many of these things can be automated. 
In terms of the open source contribution, if somebody sends a patch and if I have to test all scenarios before I can accept the patch, it’s going to take me a month, andI still may not cover all the test scenarios. Having a solid unit test suite around this means, even though the patch is 10 lines of code or a hundred lines of code, I can accept it as long as all my test cases pass, and my test coverage is close to a hundred percent. Okay. So there shouldn’t be any gaps in my test coverage as well and as long as all these surrounding things are taken care of, I can just focus on the business value that I deliver. 
Example, if you are building systems where concurrency is important, where multi threading is important, then choose a language that is built for purpose rather than choosing an older language and retrofitting the way you want it.  As I said, you need to be aware of where the world is going towards, what are the new products, what are the new technologies that are coming out, but most important is to ensure that you have your tool chains and your environment set up right, so that whatever you build is delivering value.
From India versus global scenario, how are you seeing the developer community adapt migration to cloud and containerisation? 
I think that way we are in a very good place. India is a more nascent market and don’t have to contend with legacy technologies and replacing them. Our developers understand the newer technologies and when a new startup starts, the first thing they do is they just choose a cloud provider, pick up some cloud services and start working on it. We are starting at a much higher maturity compared to the rest of the world when it comes to cloud adoption. 
There is also a trap for us to avoid. It’s not just using the latest buzz-word technology but using what we have fit for 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 centers, which are captive as well as independent. Are you also supporting them and your role also involves a play 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 come 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 that others have encountered? This information is also published in the State of DevOps report. All this is useful for enterprises who are looking to reinvent themselves.
How has been your experience and how do you see India adopting Google Cloud ? 
I see growth, and there are a lot of people who are taking interest in Google Cloud. Google Cloud is also perceived as the first choice for people looking into machine learning and AI. Most of Google’s own products have been built around this. For products that we have built and Open Sourced (like Kubernetes), Google Cloud would be the first to mind for those looking to use this. What the companies or the developers choose to use it up 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 have concern on 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. So 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 more emphasis on this by having products like confidential computing that we launched recently. Where users can have complete control of their environment and nobody beyond can do anything on those machines. So even the data that is stored in that 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 a hype about the government policy and requirement to have data centers parked in India. Is that an aspect that comes up at any point with developers? 
No, not at all. I think there are two parts of it. One is that – you want to run your applications on data centers that are close to your end users to give them the minimum latency.
So that is why we do have data centers in India starting with Mumbai. You want a failover data center and that data centre must also be in India or close by. You can’t failover from India to the US. Hence, the Delhi data center was launched. We are consciously building data centers across the globe, and we are focused on India. Among the newer countries – Southeast Asian countries, very few have two data centers. India has one now. This is something that we had done for the users because of demand. 
The other part is regulations. We have regulations in the telco, finance and payments that certain user data should not leave the country and its jurisdiction. As a country we should protect our users and their data. There are also legal requirements that make people choose a provider with data centers in India. 
Can an Indian customer by default assume their data is going to be in the Indian data center and are they priced with respect to location? 
The account is a global account like gmail.  You create an account, you 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 – a virtual machine, compute or create a database instance, there you are allowed to choose the region. 
Pricing is the same across. We have parity both in terms of the services that are being offered across the globe and also in price.
From an API perspective, what is your strategy on how you engage with developers and bring them into your ecosystem?
We have a body of knowledge from all the products we have built over the many years and understand what makes developer friendly APIs. So we ensure some of these criterias 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. So it may be organisations or it may be a meet-up. For example, open banking has published their API spec and if you had to build a banking APIs, then there is a reference you could use and start from there. 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 based on what systems they are using. DevRelers then collect feedback and help ensure that the APIs are meaningful and are in a consumable format. 
How do you Version an API?
Different products do versioning in different ways. Like if you look at libraries, SDKs, where you have to  download it, 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 would 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 API and they are using a specific format. It doesn’t make sense for me to change my API structure because I have done things in a different way.
That’s where DevRel also comes in. I 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 of the API patterns or standard practices that anybody should follow. If you look at APIs you could deprecate features as well as add features. 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 anyone to use a versioning strategy.
Have some sort of version in your APIs, you can have in the URL itself. It could be a or */v2 or */v3, so that the ones who are consuming the older APIs are not impacted. 
It’s on me as a service provider to ensure that the implementation is still running fine. There’s no point in maintaining the URL if the implementation is not maintained. 
Second thing 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 of the folks can use the new version of the API 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 release prior is actively maintained. Before deprecating the API, enough notice should be given to the developers.
Eg: in a SDK, you could 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. So communication is important, maybe via doc sites or via mailing lists. 
Firstly ensure that nobody’s implementation breaks to maintain reliability and trust. So ensure that you have a good versioning strategy without breaking your users who are on an older stack. Second thing is if something actually breaks, then communicate and reach out as much as possible.

This site uses cookies to offer you a better browsing experience. By browsing this website, you agree to our use of cookies.