The power of partner DevRel

Mohammed: Okay, welcome everyone. Thank you. That was a great intro. It's a miracle that I'm here thanks to my wife and my in-laws who are covering the new partner in the family. So just to set the stage and the context, we're talking about partners, right? And I don't think there is one size that fits all when it comes to partner engagements when we're talking about partner DevRel is really just how do we change or adapt the DevRel function to assist with the larger business objectives within your organisation of contacting and working with partners. I'd like to share my experience working for two years with Google Workspace. I hope that you will get some benefits out of this, some tips to creating your own engagement, but it's really customised for you based on your culture, team size, et cetera, all of that. So don't take this as the ultimate goal, but as tips and pieces and tips that can help you with your own programme.

With that, yes, no worries. Cool. So on the agenda today, we're going to be talking about definitions. What do we mean by partner? What type of parts exist? We'll talk about the benefits of partnerships both for the partner and for your organisation across all the different teams that are involved. Will talk about a typical partner engagement lifecycle. How do we engage all of these teams when we start pitching to our partner to the point that they launch an integration with our platform? And I'll talk about giving you some tips on how to build your own strategy for partner engagements. We'll talk about navigating some of the challenges and we'll talk about the S word scale whenever you are good at something. The first question is like, how do we scale this? So still a problem that I haven't solved, but I'll share some of the tactics that I'm working on and I'd love to hear from you on your experience as well.

So a bit about me. I've been working as a partner developer advocate for Google Workspace. Google Workspace. As you may know, it's the collaboration platform that includes Gmail docs drive, et cetera. And it's not just the end user product, but it's also the APIs that sits behind that, the add-ons frameworks, the chat APIs and chat apps that you can build. So my role is to enable strategic partners to build platform integrations, which means that I work with partners from start to end on building third partner. We'll talk about what kind of partnerships exist and which ones we will focus on to be released on the platform. Now, prior to joining this role, I worked with Google Cloud as a customer engineer, so a technical pre-sales. And prior to that I held different roles that involved cloud solution architecture, product development, software development, and project management.

I'm married with the two lovely childrens here. Maryanne met our new addition. Omar, my cultural background is Palestinian Jordanian. I've been living in Canada for the last 12 years or so, which means in addition to loving Middle Eastern foods like falafel and kfi, now I get to add maple syrup to everything that I eat. And for those of you who don't know how important maple syrup is, fun fact, Canada has the only maple syrup syrup reserve on the planet that can hold up to 113 million pounds, like 216,000 barrels. And it was actually stolen from like 12 years ago in what's called the great Canadian maple syrup heist. Some crazy stuff. It's real. So before we dig further, I just wanted to do a quick check-in. By show of hands, how many of you work with partners today in one shape or form? Great. Okay. Out of those, how many of you are part of a larger DevRel team? So you're not the DevRel team. Okay, so you've got some support. Okay. And can somebody share any challenges that you have with your partners today? I'm going to mention a few, but I'd love to see if there is anything specific or a trend. Yes.

Audience member 1:

[Unclear]

Mohammed: I love that. Alright, communication and different business priorities. Yes. I

Audience member 1:

[unclear]

Mohammed: Yes. So finding them the why they should build with you. Yes.

Audience member 2:

It's a symbiotic relationship instead of feeding off.

Mohammed: Yes. Yeah, having a symbiotic relationship instead of feeding off. Yes, I With internally or externally as well works thing. We're all saying the same thing. So alignment within the team and the org. Yes.

Yes. So maybe more communication, how do you say up to date with what they're doing. Okay, these are all great points. I'll mention some of them. Anything else? Orris? Good to go. So first of all, let's talk definitions. What do we mean when we say a partner? A partner can mean different thing to different orgs, to different teams. In my case, I'm going to use the Google Cloud Partner Advantage definitions. So Google Cloud partner Advantages partnership programme and they divide partners into three different categories. So there are the sellers who are basically resellers of your products and services. There are the service partners who are mostly the service integrators, sis, who provide value in consulting services, implementation and other value added services to make sure that your product works for the customer they're building it for. And then we've got the build partners, and those are the ISVs, the independent software vendors who build integrations with your platform for their users and your users.

And for the remainder of this presentation, this will be our focus build partners or ISVs. So what do build partners want? As we get requests and as I deal with them, they want really two things go to market enablement. So they want to do call marketing. They want to be announced with you, they want to be on stage, they want to be involved in your events. And that's something that is usually handled by marketing, partner managers, business development. And the second is technical enablement. And this is what DevRel really excels at. So doing the one-on-ones onboarding, all of that. But this is what a partner wants and this is what they get. But what do we get as an organisation? So across all the different go-to-market teams, for example, I know yesterday I love the fact that the theme of linking DevRel to business has been all over the place, said the Joyce talk about it, Carrie and Sean talked about it.

Kayla talked about product partnerships later on, who we'll come to. But everybody is talking about how do you align with the business. So business benefits from those partner relationships by amplifying the impact of a new product releases and new feature releases. If you release a new feature and you just say like, Heyward, this is a new feature, it has less of an impact than you saying, well we're launching it with X, Y, Z partners who have already built integrations or built solutions. That depends on this. The other thing is demonstrating the adoption and adding trust to your platform. For example, Google Workspace is an end user product plus the platform. And as we add more partners who are building integrations with us, this gives both developers and end users more trust that our platform, our solutions are used and adopted by many others. The product team loves partnerships because they get to do one-on-one close relationships to hear more about the user feedback and new use cases, but also to keep a pulse and keep it up on market trends.

What Arean is looking for, are we building the right thing? Engineering loves those partnerships because early on if you engage even while you're developing your solution, they get to also get that direct feedback, but also because they can catch bugs early. And we all know the value of catching bugs early on before it's actually released into production and all. And most importantly for DevRel teams like DevRel team I think benefit the most because this shows direct business impact. When we talk about measuring success and metrics and how do we show value to the org, working with partners is a direct one-on-one relationship that shows, hey, I'm contributing to the business, I'm aligned with your business OKRs. The second thing that I love is you can take all of these learnings that you take from working with partners and you can scale them to all the other developers in your platform.

So if I go back to our product team and say like, partner X feels that this feature is needed, that can prioritise it on the product roadmap and everyone benefits. So you're really using partners to give you more support to drive all within the platform. And the last one is really just living up the relationship endeavour. When we talk about skill, sometimes you don't get to spend time on one-on-ones, but working with partners, the business wants you to spend that one-on-one time. So whether you need to travel to meet partners, whether you need to spend more time digging deeper, that's all within your partner derail mandate. So let's talk about how all of these teams actually participate with partner engagements. We'll start with the first stage, which is pitching an idea. So when you ask about how do I show them the why do they need to build with us?

Typically the business development or the BD team, department managers within the organisation works with DevRel to do what we call the art of the possible. So this is the massive presentation where it talks about our platform, what can you build on it, why should you build on it? But we also help as DevRel by sharing some of the other integrations that exist. How did other partners leverage our platform to build good solutions? And after the partner show us some interest in building with us, then we moved to brainstorming use cases. This is where product managers, deral and business development also are involved. And it's really around thinking, okay, what can we build as a common integration between us? Our role here is also just validating all the use cases that come up. Can you actually build this with all these innovative ideas? But also making sure that we can also help partners expand their usage of the platform.

The next one is building the integration itself. And this is where DevRel shines, not just partner DevRel but all of DevRel because this is where we do our one-on-one onboarding where this is where we do the technical enablement deescalation of bugs, feature requests and you act as the glue between your team and the partnership team. And then when it comes to launch, this is where we involve marketing. So product marketing, business development, again us again in terms of supporting the partner with best practises. How do you actually publish an integration? We have our own marketplace for example. What's the best way to add your listing if you already have an integration, how do you add this in new integration but also in collaboration in collaborating internally between the teams. So if you're launching a new integration, you want to make sure that you get the reviews in the right time, you need to publish the press announcement or the blog post that talks about it at the same time and that's where we jump in.

And last but not least, support. So as you launch the integration, one of the sticky points that I'm going to talk about later is support. How much time do you spend supporting that integration? And we make sure that we set expectation that we'll support you in the short term. It's almost like next 30 days or so, but not really. But if there is any bugs come up, if we receive feedback from some of our users saying this integration or this add-on doesn't work as expected, then we communicate that back to the partner. So it's really about maintaining a balance between talking to the partners and staying in touch with them while you're protecting your bandwidth and being ready for the next engagement. Alright, so let's do a quick case study. So last year we launched a new feature that's called third party link preview with smart chips.

So how many of you use Google Docs? Yes. Okay, few. So I don't know if you've noticed this, but if you paste a link to another Google Doc or slicer sheet in Google Doc, it will pop up a small prompt that says, Hey, click tap to convert this into a Smartsheet, right? And it converts this ugly URL into a nice chip and if you hover over it, then you get a preview of the file, et cetera. So that was launched as a first party feature way back, but we wanted to operate up for third party, which means that you can now for the partners that have launched with us, add their integration as an add-on to docs and slides and sheets for some of them. And if you paste a link on one of their properties, you can also log in through that ISV and get a preview of that link as well.

So reflecting on the lifecycle that we mentioned before, how did we engage with several? Well first of all, with daily engagement, even before the function or the feature was developed, we engaged with select partners to end the business development team to pitch their idea, seek interest, and then share early design documents like this is how we think this should be implemented, this is how you're going to build it, it's not ready yet, but tell us if you see anything that is off. And as we went into validating and building the actual feature, I was working as a developer zero, right? So the feature is ready now, it's going into better testing, I'm going to test it from A to Z to make sure that we have a frictionless experience for our partners. This means reviewing dev docs, testing all the samples, and we did catch some bugs and it's good you work with different teams including tech writers, the engineering team, just to make sure that when we launch it into this public be programme, which I'm going to talk about next, it's flawless and it's ready to enable developers to build on it.

So we have something that's called the developer preview programme, the DPP. And it's a programme that they've launched to help engineering teams have a public data or a public review programme that's open to the public, which means that before we go GA with a feature, there is still a period of time where anybody can sign up, they get reviewed, they get approved, and then they get access to this feature so that they can test it, file bug reports. And it's proved really helpful for both product and ENG teams. And again, making sure that what we're releasing into GA is something that is solid. So as we launch this, we share it with a partner and then we go into the onboarding and the one-on-one. And this is really cool because I remember one of our partners was having an offsite in New York and they're like, Hey, what is that idea?

Do you want to travel from Toronto and come and do onboarding? And because they're a partner, I got them and we spent like half a day taking them from knowing nothing about the platform into developing a hello word example and then helping them further build that integration. And of course we fixed bugs, we logged feature requests and we improved dev docs before the whole thing win ga. And this is a QR code if you want to learn more about our own developer preview programme because I think it's also another crucial component in the whole strategy. And as we launched, we shared best practises, we did collaboration between the team and we did post launch checks and feedback with a partner support. We continued to again file any bug reports that came up both ways, either with their integration or with our APIs. And we shared the new feature. So when a new feature, for example, third party link previews was there for Google Docs a while after it was launched into slides and sheets. So we kept in touch with the partner to keep them informed of what's coming up and whether they're interested and build some a be great docs that help them build the new feature. Alright, I'll pause here for a second before I jump into the next section, which will give you more tips and tricks on how to do your one. Any questions? Anything that's burning that you want to ask?

Yes.

Okay. Alright, cool. Okay, and I'm sorry, I know I'm the only thing standing between you and lunch, so I'll try to go a bit quicker. So I'll share a few tips about how to develop your own playbook based on my experience. The first thing is how do you select your partner? Think about the different attributes and the different things that you want to consider in a partner. First of all, aside, are you looking for a big logo that can add credibility and trust to your platform? Or are you looking for more smaller niche partners that focus on a specific industry?

Industry is the next thing. Are you thinking of a particular vertical, for example, healthcare or finance or hr, where you want to build integrations with or are you open to anything use cases? Sometimes there might be a particular use case that is of benefit to your developers, your users, and the third party ISV users. And that can be a highly focused area. And of course KR alignments with the business based on your own organisation growth, is it product growth, marketing, et cetera. The business development team usually sets to us priority and say this is the set of partners that we want to work with. But that's something where you can also influence based on your own reading of the industry and what's going on. The second point is protecting confidentiality. So you'll be dealing with a lot of unreleased free GA stuff and you must have some kind of NDA in plates.

This protects you and the partner as you discuss anything that's not public yet. But also when you are dealing with multiple partners, that can be a tricky situation because you know that each partner is building something else but nothing is released yet. So you really can share that between partners. So just something to keep in mind. Next is setting the right expectations and that works both internally and externally. Externally as we talked about, how is your support going to help the partners and up to what extent when you launch are you still going to be here for them? If they have a problem with a totally different unrelated integration, can you help them? Yes, maybe just be clear about your role and the expectations that you're going to offer, but also internally as you work with other go-to market teams, sometimes more they want more of your time, they need more of your help at the pitching stage, but you're already busy with more partners building.

So just make sure that you set those expectations right and that you work with the different teams to make sure that the alignments are aligned. And then cultivate your support network. And this is where you build networks internally. First of all within your team. So if you're part of a larger team, for example, we have a person who does YouTube videos, we have another one who works even more closely with engineering, you're going to need them all as you work with your partners. So as we launch partnering integrations, we want to showcase them on your YouTube channel. As we get more support requests and black work requests, we need somebody who is going to work closely with engineering team but also build them across the org. So again, product partnerships, like Kelly mentioned yesterday, marketing, you're going to be working with teams that you rarely work with in your day-to-day work as deral.

So make sure that you build those relationships so that you can use them. When the time comes creating reusable assets, as you work with more and more partners, you're going to begin to see trends. For example, we talked about the art of the possible, that now has become a standard presentation that we have and we share with other teams that they can give on their own onboarding. That's another thing that we are now building as onboarding slides that can also be shared, how to guide best practises, build reusable documentation that makes it easier to share with others, to share with partners instead of you having to do the one-on-one each time, scale your learnings. And this can happen when you share what you've learned with partners, with other teams that are partner facing or developer facing. And by updating the assets that exist online, we talked about updating dev docs.

This happened when we worked with a partner who wanted to build some third party or a integration that wouldn't have I think as much details, but then that triggered another effort internally to add dev docs just specifically for that use case. So take those learnings and scale them up to the rest of the developer community and don't be shy to showcase your impact. This is really, really important. We have an activity tracker. So anytime I have an engagement with a partner, I make sure that I list which APIs or your integration points they're working on. Was this a one-on-one? Was this even a pre-engagement? Was this initiated by the business development team by a different team as we grow to support more partners, but also most importantly, what did we actually build? What did we do so that when the end of quarter comes, the end of year comes, you can easily show the number of engagements across all the different criteria.

When we have external newsletters, for example, we have a developer newsletter that goes out, we sometimes share some of those integrations. We talked about YouTube, we have a channel, we showcase some of those as well there. But even with events, we have a developer summits where we also showcase some of those partners and we invite them over just to also talk about their relationship and the path to building an integration. But even internally as well, we have an internal newsletter that talks about everything that DevRel does that is distributed to different stakeholders internally. So if you have the data and you track everything that you do, just shout it at everywhere. I mean we're all talking about showing the value of DevRel and the value is there and this is your chance. And last but not least, if you remember one thing from this entire presentation, it's about nurturing relationships. Again, whether it's the internal relationships or the external ones, keep in touch with your partner, learn more about what they're doing, tell them about what you are doing. If you are having events, invite them over, do reception, take them out for lunch, for dinner. Just make sure that that relationship exists and continue to exist because they may have built one integration with you, but they're partner for life, like they're going to be there for your next integration. And you need to keep that relationship and make sure that it doesn't become a transactional.

And of course nothing is all roses. There are some challenges that comes from dealing with partners. And the first one is competing priorities. When a partner make a request, whether a new feature request or they want you to help them with something, there is the internal struggle between the teams. Like the product wants something, engineering wants something, marketing wants something else. And your role is to act as that glue and as the internal advocate for your partner to help them get what they want. So most of the time you have to talk the language or whatever team you are trying to get their help. Service engineering, yes, we want to develop a bug free product that's a given, but if it's product, how does this new feature request help other partners that can utilise this? The second one is how do you stay up to date?

So you are busy helping partners and building artefacts and doing all of that. And at the same time the engineer product teams are busy just giving out in new features and you will quickly fall behind. So what I did is I blocked Friday off, there are no meetings. Friday, I call them build Fridays, I roll up my sleeve, I'm a builder, dig deep, build into using whatever is coming up. The second thing is make sure that you do one-on-one internal syncs. So I have syncs with the product, different PMs, the product managers, the engineering managers, just to check in and see what is coming up. So you don't get blindsided by that and join any offsites If you know that the engineering team is having an offsite, ask politely or crash it, whatever works for you and just make sure that you are still relevant because as deral, we sometimes most of the times get left out.

They have all the parties that are like Deral is just sitting on the side and they don't remember us. So you have to work to stay relevant. Overwhelm and burnout. I did not learn this when, well, I learned the hard way, didn't know this when I first joined, but managing expectation is one thing. And we talked about that. You will have to learn to say no. When I first joined, I was happy, I wanted to help everyone so it was a yes to everyone. And I quickly discovered that even one little question can take me on a spiral for like three days just to try to find the answer for. So one of the things I've learned is no, what do you need to say yes to? These are your priorities and that makes it easier for you to say no with an explanation to work with different teams.

If we don't have bandwidth, we clearly say these are the list partners that we're working with. Do you want us to switch anything? We don't have bandwidth for this. So just manage your load and self-care delegate and communicate. Again, make sure that people know what you're working on so that if they complain, you may get an extra headcount, which is good. Like our team grow from one person to two just for partner dev and that's because we were doing a good job and we just didn't have the path. So it's good to make sure that you communicate that closely. And the last thing is scale and growth. So how do we scale ourselves to support more partners? We talked, I'll talk about this briefly, but it's like office hours training, others sharing and centralising processes. Have time? Yes. All good.

Audience member 3:

[unclear]

Mohammed: Data's all good. So the last slide I think is on scale. So again, the curse of being successful at something is that you're asked to do more. So the first thing is how do we scale? And I'm sure that you've seen this craft, the long tail thing. So partner DevRel is worrying about partners that are really at the table of the head, right? So far left, only very few. And DevRel is looking at everyone else, right? So the scaled version developers online, et cetera. But can we scale to fill in the torso? Can we add more smaller partners who may need that additional one-on-one and more of the go-to-market stuff without bearing out? And we've been experimenting with office hours. So we started doing them internally for other teams that are developer facing and partner facing. And we are slowly opening them up to external people who wants external developers and partners who want to ask questions.

We are thinking about doing cohorts similar to the accelerators. So instead of helping individuals partners, maybe we'll do a batch of 10 or 15 and that can help us scale shared learning with other teams. So as I mentioned, we established monthly sync with other teams like customer engineers who work with customers who are developers and partners at times and other partner team. So the idea is just to get and share your learnings out so that you can leverage other people's. And developer support is one thing that is available if you are a workspace customer. So we're thinking of just collaborating more closely and making sure that more teams are enabled. I'm not sure if relationships can scale and my way is as we scale then we lose that one-on-one relationship and we lose the close collaboration that we have. So that is a struggle. If anybody has any tips, please feel free to lemme know.

So to recap, we talked about the definitions of partners and type of partners, we talked about how it benefits the organisation and the different teams. We talked about the engagement lifecycle with an example. Give you a few tips on building your own strategy, partner strategy playbook, how to navigate some challenges and how to scale and growth. This last slide is just a personal reflection on the role. If anybody is in one area of DRE and considering doing partner dre, I think it's an amazing role. It really blends in people and relations and technology. And I know this is normal for DevRel, but it's more so for this role. It offers you constant learning opportunities as DE does. You wear many, many, many hats. Sometimes you feel as an event coordinator, other times you are a product manager almost then you're a marketer, then you're in sales and it's crazy and it can be easy to take on too much. So you have to take care of yourself. And the beauty of this is you're still in Dev. So when there is downtime, I can always go back to writing a blog post, doing a YouTube video or doing anything within DevRel. It all benefits the ecosystem. And that's it for me. This is my LinkedIn profile. Feel free to connect and I'd love to hear from you how you deal with partners. And with that, we're done.

MC: No, you're totally right on it's q and a time. Alright, do we have any questions for Mohammed? Yes, I got you over here. I got you. Rosendo

Audience member 4:

Ron. Okay, thank you. For the partner and DevRel, do you consider that a separate team or is it just the different hat that you put on?

Mohammed: So for us, we have different people within our Devra team who focus on different stuff. So you've got somebody focusing on YouTube, but there's on engineering samples, et cetera. Partner develop within our team is a specific role. So we have two people who are just doing that. Cool, thank you.

MC: We got it. Craig.

Audience member 5:

Hey. So when you're measuring success with something like a chip integration, what are you looking at in terms of metrics? Are you just looking at usage or what's kind of the needle mover for that?

Mohammed: So for us with that, when we work with the business development team, the OKR is a shared OKR. So if they say launch is really the success, have they build integration, have they launched it and that's it. We do share some success at times and the developer or the partner have access to that as well. But the basic OKR is did we help them launch and build that integration. So it might be a bit simplistic, but that's our OKR.

Audience member 5:

So at our organisation we have a partner marketing team and then we've recently on the Devra team started working with them more closely to see how we can better collaborate and help. Do you also have partner marketing and how do you all work together?

Mohammed: Yes, we absolutely do. I think PMM or product marketing, you said partner marketing as well? Yes, I think we have worked with that a bit. I mean I don't recall a specific title like that, but I know the marketing and specifically product marketing gets involved a lot when we talk about partners specifically at larger events like cloud next cloud io to highlight our partner engagements. They also work on white papers, case studies, and just getting the word out about the product overall and involving partners within that. I think in our world, maybe the partner managers are also more involved in being advocates for the partner and making sure that they are highlighted in every opportunity that comes up.

MC: Hi. What would you say is a choose one of what are the biggest risks and biggest opportunity for a partner DevRel kind of relationship?

Mohammed: Well aside with the opportunity, I think the opportunity is showing direct business impact. I think again, as you show that you are continuously supporting partner and you are unblocking partners so that the rest of the organisation can move on with their go-to market enablement, et cetera, that's all good as a risk. The only thing is I think it's just taking on too much because as you build your abilities to help in the org, you'll just be asked to do more. And at one point you really need to begin prioritising where do I think it comes to this? Which meetings, am I the only one that can contribute to? If I can do art of the possible presentation, somebody else can do it, maybe I can decline that because somebody else can do it. But if we're doing one-on-one enablement and nobody else, no other teams are involved, then it's you. So it's really just having that frank conversation with all the different stakeholders to say, this is really where I feel mostly helpful. So let's just focus on that and that can be a bit friction points.

MC: Any other questions this thing on? Okay, cool. Oh

Audience member 1:

Yes,

MC: I got you.

Audience member 9:

How do you manage subsequent phases once you have partners integrated? How do you proactively set future roadmaps for these partners?

Mohammed: So I think we have partner managers who manage this relationship. So they work closely with the product managers to stay ahead of the roadmap and what's coming and talking to existing partners about all of that. What we deal with mostly is support sometimes. So with that we've also built issue trackers that are specific to select partners that we triage that through DevRel and the engineering teams as well. But we rely on the partner managers to manage that relationship. So we sometimes get engaged when a new feature is coming up, but they carry most of that weight. Does that answer your question?

Audience member 9:

Yes, but

Mohammed: We can talk more offline as well. Yeah, there's actually a technical component too as well, right? Where your technical teams can have discussions with the partner counterparts about here's what will make the most sense for the integration to move forward to the next step. And that way you collect that technical input and it on to your engineers

And that's part of maintaining the relationship. So yes, they can just email us in terms, say like, Hey Moad seeing this, can we do this? And our role is just again, being advocates for our partners, taking that feedback, talking back to the ENG team, the product managers, and just advocating and seeing how we can make this happen.

MC: Anyone else?

Mohammed: Going once, going twice.

MC: Okay, big round of applause for Mohamed, please. Thank you so much.