DevRel the heck out of internal partnerships

Mano Marks: Alright. Hello, world. So there's a real reason I'm going, directly to hello hello, world. A very common DevRel approach is reducing time to hello world. I initially had this slide much later in the deck, but I wanted to give you something tangible right away both to make this point and also to underscore that this is the direction we're going.

Typically, when we think of time to hello world, what we're thinking of is the amount of time it takes somebody to to get started, to get to something kind of tangible with your developer products, API, SDK, tool, VMs, hosted Kubernetes, or whatever, and see some results. At hello world itself is not particularly meaningful, but it is an initial proof that something is happening. When you work with internal partner teams, one of the approaches is to keep in mind that you wanna show them something fast. So the rest of this talk will be talking about applying other DevRel principles to working with your partner teams. But first, I wanna talk about what I think of is one of the most, if not the most fundamental question in developer relations, and that is why.

So let me get to the why first. Why partner with other teams? Why take DevRel approaches to working with internal teams? So the first reason is relationships. Developer relations is at its core about establishing and maintaining relationships, Approaching internal partnerships with intent, with a structured framework, set of principles helps peoples people and teams understand you and relate to you and want to work with you.

Nurturing these relationships, even the short term one, pays off in richer relations, more productive work, and easier workflows. And these are people who will be with you for years, even the ones you meet only a few times. I still interact with people I met fifteen years ago when I first started in developer relations. They may be on different teams or different companies, but they will help me grow my career in within my company and without, which, of course, takes me to the second point. It's about your career.

There's one person in charge of your career, and that's you. Everything you do at at work in a work context, influences or impacts your career or has the potential to. I'm not just talking about performance ratings or promotion, but the whole arc of your career. What you work on, who you work with, what your next job is, it's all in there. In the day to day of your work, it's very easy to lose sight of this.

It's something I've seen bite people time and again. They focus on doing the thing or finishing the project without considering how they will do it will impact their career. How you structure your engagement with internal teams allows you to do the same work or the same kind of work, but in a way that helps you as well as accomplishes the task. Short term or long term, that will pay off. I'm gonna talk a little bit more later about some ways you can do that, about the how.

Okay. So we're gonna start defining some terms. What is an internal partner? Internal partner is any coworker or any team that you work with who doesn't report to you and you don't report to them. This kinda gets to another DevRel principle, which is influence without authority.

Right? You are having influence on and working with partner teams in order to accomplish goals that you both hold in common or accomplish goals both of which help both of you. Okay. So here are some of the common partner teams. Engineering, marketing, product management, sales teams, other developer relations teams, particularly at a larger company, may be split into different kinds of roles where you have to establish these partnerships.

User experience design, a whole there's a whole list of different kinds of partner teams that you could potentially engage with. I wanted to mention this, and and this is not meant to be an exhaustive list. At any company, there could be many different teams that you work with. Wanted to mention this just so you can, you know, frame in your mind. Some of the most common ones are these these top three, engineering, marketing, and product management.

In fact, your DevRel organization or the DevRel person, if there's just one, may sit within one of these teams. And I I I'm gonna drop this in here. I'm not gonna talk too much about it, but really, I I wanted to drop in this is my current iteration of how I explain the DevRel engagement model and the value that it brings. Basically, you're you're working with external teams in order to understand their use their usage of particular products, and you give them content and ideas and all this sort stuff. Of And then you pass that on filtered through and qualified by your expertise to product and partner teams, and then work with them to create your next your next strategy.

And, of course, when we talk about developers, we're talking about all developer practitioners. So developer relations is a term of art, but really what we're talking about is a whole range of people who are hands on keyboard with with our technical products that's that that cover a very wide range of these of products. Okay. So here are the developer relations principles that I'm going to focus on here. Zero to hello world, know your we already talked about.

So I'm gonna go right into next, know your audience, and then talk about best practices and fail fast. This is one of the most common things I've heard in developer relations, and it's usually in the context of how do I create this video or what do I what do I create for a particular external audience? And it's important to know who your your audience is, both for your external your external audience, but also internally. Some of the questions that you can ask in here, and this is not exhaustive, again, is what motivates them? What problems are they trying to solve?

Where do they gather online or in person? And how do they consume information? So let me, give you an example of a of a product team that you might partner with. This is genericized. This is not an actual partner team.

It's based on my my accumulation of experiences working with product teams, but it's it's just an example for this purpose. So a product team may have a motivation of adoption. So let me stop one second here. Every company has a motivation, which is to make money. That's that's how that's how it works.

Now you may work for an organization that's not about making money, maybe a nonprofit or something like that, but there is a top level motivation that the the organization has. Most developer relations people that I know work for a company whose motivation is to make money. Even some nonprofit organizations, their motivation is to is to drive money. But what an individual product does in order to help with the the overall mission is different. So in many cases, for a product team, what motivates them is adoption, getting more people using the the product.

So for this product team, I'm gonna project the problem is perhaps complexity. So there's many different kinds of of problems that the the product team might encounter, one of which might be people don't know that they could use this product. They don't know it exists. That's a that's an awareness problem. In this case, I'm thinking about complexity.

So complexity is, you know, the product is too hard to use. And one other thing I wanna mention here is the product team may not actually know what their their problem is. They may know that there's a product out there. Lots of people are know about it. They have an awareness background.

They have people knowing about the product, but they may not get be getting a lot of adoption. And one of the problems can be complexity. So then thinking about where does the product team gather. So for instance, they might gather in an internal Slack. There's you know, they they may gather they may be physically co located in a particular location, but online or as in a product team, how you they interact is through an internal Slack.

And like lots of product managers, they like interacting through slide presentations. Now at a at a company, as you're as you're getting used to to doing the work that you're doing, developer relations within the company, you are added have an added problem that you don't generally have in the external community. The external community, you're generally not looking for individual people to interact with. Generally, you're interacting with people in a one to few or one to many way. You may want to interact with somebody who's a professional in a in an area just to get their feedback on it, but you're not usually looking for the exact right person.

However, within a company, you you often do. You have to know who is the right person for you to work with, who do you partner with. Now when you're when you first start, your boss, somebody like me, a manager, will tell you probably, okay. You're working on this product. You should join this mailing list and reach out to this person.

In other cases, once you've built up your internal network or you built up your reputation, people will start coming to you to act to interact with you, to get you to engage with them and help out with their their products. But fundamentally, the what what you end up doing in almost all cases is you ask people. If you haven't built up an internal network, this can be the hardest part. Often, turns into this kind of chain. Right?

You speak to one person. You figure out what they need and if you can work with them. And if so, they'll bring you into other other people, or they'll send you to other people. You end up walking down org charts, asking for direction from your manager, learn where you can about the different teams and the different people. In small companies, this is pretty easy, especially if you're all physically colocated.

If it's an in office kind of situation, you just walk over to somebody's desk or, you know, set up a meeting with them. But with large companies, it can be a little bit harder to do this, and it can take some time to identify who's the right people and who who are the right teams to work with. Very importantly, though, don't stop at just one. Particularly in large companies, individuals and teams move around and change a lot. You can be very you can be very successful working with one person, but when they're gone or they no longer have the kind of work that they need or the kind of problems that you can help them with, you can get stuck.

Don't create a single point of failure for your career or for your team. Build out your network. Okay. So best practices. When we have a complicated set of tooling, developers want to know what are the best practices for using them.

So for instance, you may be talking to somebody at a telecommunications company, a telco company, And they will wanna know what other telcos do to use your true your tooling. What tools should they go? Which particular sets of tools should they do use? What kind of workflows do they have? How do you select the best options that are, to use for, say, Kubernetes or setting up, you know, individual clusters?

How do you do backups? What kinds of things that you, that you can apply? These are known as best practices. They may be industry specific or they may be very generalizable. We we can use our knowledge and best practices that work with developers, and help them design their better workflows, their better practices, and we can do the same for our partner teams in developer relations.

Knowing your partner team and what motivates them, what problems they're trying to solve, lets you design an opinionated model for how your team can engage. Let's look at a couple of examples. But first, I wanna ground this again in your career since that's what what today is about. Right? In a small company, you may not have a clear job ladder or it may not be regarded, but really one of the things that you wanna do is make sure that you are aligning with what is rewarded with your job ladder.

You wanna make sure your strategy aligns with the product strategy, of course. But also, you wanna make understand how what you're doing helps you in your individual career. It's gonna help you get a better performance review, help you get promoted, all those kind of good things that happen when you're doing well in the eyes of the company. So there's ways you can do this. One is, particularly, if you're if you don't have a clear job ladder or if if you're not getting clear direction, you make sure that your manager is aware and approves, and you make sure that other people on the team that you're working with, your partner your partners both within dev DevRel and without, understand what the plan is and how you're going to move forward and who's going to be responsible for individual things.

This looks very planful. It looks like you're being intentional about the work that you're doing, but it also makes it really clear to everyone what's happening and You produce in this process best practices. So let's take, for instance, a problem that a product team might have, which is, I mentioned before, awareness. Product team has a new product and not peep enough people know about it. So you can design a content and social media strategy.

You make sure that that content is designed for the external audiences. You know that audience, and it reaches them where they're where they're at. It helps them at the starting points that they're going to commonly have. So for instance, if you're trying to reach an audience of enterprise developers, you might be helping them work on monolithic app applications. If you're having reaching an audience of of people working on Android applications, you have to understand what their general starting points are, what the common skill sets for the types of people that you're trying to reach are.

But internally, then you also make sure that that you're you're working with the messaging that the that the team has itself, that it's that you're trying to reach. And your engagement models with the team can look like getting sign off from the team on the list of content topics that's built. Maybe that comes from marketing or product management. You work with the engineers on the team to make sure that the content matches what the the product actually does. And for the your career, you make sure that that plan is in place, everybody's signing off, that you or your team are an author and a lead, and that your reviewers and stakeholders are clearly spelled out.

And you identify the metrics for success. You might have, for instance, instead a problem around complexity. So complexity, this is the one that I'd, identified in, knowing, knowing your audience, a product that's that's difficult to use. Product team has this difficult product. People aren't using it.

They want to understand how they can make it better. Because one of the key things is that product teams typically don't engage in the same behaviors that your customers or your users do. Because your most of the companies that you want to have consume your your product aren't tech companies. That's not true for everyone. I wanna make that clear.

But major tech companies, particularly when they produce a product, they have a whole set of internal practices that are very different from the way a developer in in a external enterprise might do it. So say somebody in banking or or energy or some other kind of company. So you develop an you can develop an engagement model with the community where meeting them where they're at, whether it's online or conferences, you engage them with customers, not necessarily as sales, but just as a subject matter expert. And you engage with them and you help them understand you help the company better understand what their the problems are that they're trying to solve, what kind of feedback they have on the product, and how their what kind of pinpoints they have in adopting the product. And you up level that feedback by extracting use cases and testing against your product, and then demonstrate that through whatever method your partner teams will respond to most, whether it's a presentation, a demo of here's all the things I have to do to get a common use case going, Or it can be through creating a log of friction, a document that's at within Google, we have a common friction log format.

Other companies probably have the same kind of thing. You might do a customer empathy session where you have a bunch of engineers and product managers walk through the the common use case and try and solve the problem themselves and then help them identify where where things fall down. There's a variety of different ways, but the important thing is you're taking what you know about your audience and what's going to reach them best. And this may take a few tries to figure out, and then you get them to engage with your feedback. And for your career, again, you wanna make sure that there's a plan in place.

So I wanna give you an example here. This is a screenshot of the example. If you I I posted my to my Twitter, my slide deck. There's a text version of this in the speaker notes. Just plain text.

No no formatting. If anybody wants, you can reach out to me for this is a highly genericized version of a kind of plan that you might adopt. And the point here is that you have clearly delimited who the authors are, who the approvers are, who the reviewers are, And you have a summary of the projects, the major things that you will do, and the responsibilities of individuals, not just yourself, within the within the project. What the metrics are for success, and then what what is not a goal. This is commonly spelled out in a lot of plans.

What you don't want to what what you're not going to try and accomplish. And the reason this is important is because if somebody comes back later with one of those things, why didn't you do the thing? You can say explicitly, this wasn't our our particular goal. We weren't resourced for it or whatever reason that you might wanna give for that. And this helps you later not only when you have to have a performance review or discuss with your manager what you're doing, but also when you're interacting with the next team, you can say, here's what I did for product x.

Here was my engagement plan that I used for this team. And you can see how I all the things that I did, all the things that they did, and how we measured success. Now you may not want to do that, but this is sort of a best practice. I gave this as the approach that I've used for other teams. And then you can also use this as a resource if you're later gradually adopting your own engagement model.

I've seen plenty of advocates after, you know, a year of doing a particular kind of activity write up a doc that says, you wanna get me to do a kind of activity, here's the steps that you wanna do. Here's how you engage with me. Here's what I do. Here's what I'm interested in caring about. That becomes a best practice for you.

Okay. And then this is another common thing that I hear in in developer relations, fail fast. Not all relationships work out. Not all relationships are at the right time. You may be working with a team that's that's resistant or uncommunicative or it's just they're not ready to work with you.

That's fine. It doesn't there's there's nothing wrong with that. There's nothing wrong with them. You may really want to, but if they're not going to help you achieve the goals that you need to achieve for your career, don't get stuck on them. Pull out of these unproductive relationships.

Sometimes they're just sometimes it's just not the right time. And when you do get to the right time, you'll have you'll you won't have ruined the relationship by or or poisoned the relationship by repeatedly trying a bunch of stuff, getting them to expect a certain way of interaction. When they come back to you, say you give them some advice. You say, I really think we should take the product in this direction. We should start engaging around this.

And they say, no. We just need you to we just need you to turn out a bunch of videos. You're like, okay. That's not really what I do. And this is an example.

Maybe that is what you do, but for this example, that's that's not. A year later, they can they might come back to you and say, look. We we realize now we have this complexity problem. We'd really like your feedback. This has happened to me before where I've had a team say straight up to me, hey.

We totally understand the Kubernetes community. We get it. Go work on something else. Go work on Istio or Knative or some of the related open source projects. And then a year later, a new product manager comes in and says, wow.

We have a really big problem with our we really need feedback. We really need to understand our users better. Please start engaging with us. And then we did. And in the meantime, we worked on other things because that was what was productive for our career.

In developer relations, particularly at a large organization, there's almost never enough of you. Right? There's always more work that can be done with different teams that will help you with the career with your career goals. So if somebody's not ready to work with you or they're not the right people, these things will change over time. You can find other work.

There's there's plenty of other teams to work with. You don't have to work on just that one team. Alright. So finally, there are plenty of other developer relations approaches. Within half an hour, obviously, I couldn't I couldn't cover everything.

But there's plenty of other things that that you can do, and you can take and apply these skill sets that you are starting to or you have developed over years of working with external communities and start approaching the internal communities this way. These these this skill set is something that is extraordinarily valuable and extraordinarily productive. So I I really encourage you think about what you do. Treat your internal partnerships in the same way that you treat your external partnerships. Find ways to use the skills that you've developed to help you help the external developers and help your internal partners achieve what they need to achieve.

Alright. And I think we now move over to q and a. Thank you very much.

Speaker 2: Excellent. So fantastic. And, I know we've got Steve Pusty here. Wave to me if you wanna join our q and a. Alright.

Mano Marks: Hi, Steve.

Speaker 3: Hi, Mano. Long time no see.

Mano Marks: Yeah.

Speaker 2: Cool. I'll keep this slide up a little bit longer because you got your handle there. And, yes, I was tracking questions on our Discord. Well, I had a question, first of all. Thank you so much.

I'll probably be going through these slides a couple more times. So my first question was like, okay. All these things I mean, all these relationships, these internal networks, especially, you know, as if you're in a company that's very large. A friend of mine had joined IBM and left in two months because they said, oh, here. It's gonna take you five years to build all the relationships to do the thing you wanna do.

And my friend said, alright. I'm out. Oh, and Lizzie's here. You wanna join? So I'll add you to stream.

Speaker 4: Hi, Lizzie. Hello.

Mano Marks: I'll Hi.

Speaker 2: For now on.

Mano Marks: You know, I I think that's you know, the the it'll take you five years to build all the relationships. I I don't know that your your friend's person particular experience, but but really delivering quickly helps you this zero to hello world really starts helping you build that internal network more quickly. Because the more you can succeed, the more you can get other people who care or interested in the kinds of work that you do. I mean, you can see this with people that you think of as as DevRel superstars, you know, people with large Twitter followings or internally, they may have a really big impact on things. As as they become more prominent, more and more people start wanting to work with them.

You you your network generates itself over time.

Speaker 2: Yes. I would.

Speaker 3: Yeah. About the that IBM thing too as well, I mean, I'm not quite sure what your friend was hired in for, though, also. Like, to me, if you need to make a network that's gonna require five years, you are probably to do what you want to do. There's a difference between what you want to do and what you were hired to do. And you may want to do those things.

And if you try to do those things, you're probably gonna get yourself in trouble at a large corporation because you're gonna bite off more than you can chew. You're gonna insert yourself into places you may not be welcome. It's just a so, anyway, I would say like, because I just joined a very large corporation, and I have a very small team. So it's not like I suddenly had this huge network. But what it was was they said, hey.

Go work on this. And so then I go work on that. I get in the Slack channels, and I talk to people. You bite off that chunk, then you bite off another chunk, then you bite off another chunk. Five years to make a social network means you were probably asking for too much.

Yes.

Mano Marks: What is what what what would be the five years to become an overnight sensation. Right? Exactly. So

Speaker 2: that's a an example from my friend. And but then my question was that I feel like so there's the let's say, you get so you you get some momentum and and people are interested in engaging. But then, like, how do you scale? Because the reality is that means you've got more meetings on your calendar. You're asked to be in more conversations.

And especially if your job is to I mean, you're doing these things to do your job, but then your manager expects you to also have these outputs that you're creating. And then often you're asked to have relationships outside of the company, and then you're also managing a team. Yeah. So my question was, how do you scale this? And and then really tactically, like, maybe what kind of headcount do you ask for?

Like, you know, I was starting to say, I really need an assistant, or do I need a project manager, or, you know, what what how how can I roll this out into something tactical?

Mano Marks: This is where a senior person can really help bring in new new, more junior people to the team, more people earlier in their DevRel careers, where the kind of work that might need to be done in developer relations, particularly, I I was about to say particularly at large companies, but it's it's true everywhere. There's a lot of tactical work that needs to be done as well as the strategic work. And this is where you kinda you you start up leveling yourself. You do a bunch of the tactical work, then somebody's like, we need more more and more more. And you're like, okay.

Here's my backlog. Here's a list of all the things that I am working on right now. You go to your manager. Which one of these things should I drop, or can you give me more people to help me do this? And it may take a while.

Right? I mean, headcount is one of the most scarce natural resources at a large corporation. So getting people to work on your team, it may take a a while, but you can you can prove that by keeping a backlog of, like, here and drawing the line. Here's here's everything I can do. And over time, you understand where these where these these boundaries are.

It's not a natural, I understand right away. I can do all this thing. You join a company like Google, and you just you're like, oh, I can do all the things. I just you get really excited, you learn about all the internal projects that are going on, and they're just it's so cool and exciting. But you need to you know, at some point, you figure out, okay.

I need to stop. I need to scale and or I need to set these limits on the things that I can do, and I can go at these things in order. Or you can take another approach, which is I will do a little bit for a bunch of people, right, all all in parallel, and then a whole bunch of stuff lands all at once, and that looks fantastic for your particular performance review or whatever you're you're trying to accomplish. Yeah.

Speaker 3: Yeah. And to echo what Mano said, I would also say the you have to get comfortable with saying no. And one of the things I've learned I'm I'm have a hard time with saying no. One of the things I've learned is that's exactly what Mano talked about, like, going to your manager and saying, k. These are my priorities.

Which do you want me to cut? It's very it's much easier for me to go back to that person and say, you know, I really wanted to work on that, but I you know, I've got too many other things on my plate, my manager won't let me work on it right now. Yeah. Right? And so then if that person wants that to happen, they can go talk to your manager and make it happen, but they don't put any more pressure on me.

Right? Like, I'm just doing what I'm told. So that's an easier I find that an easier no than a nope. I don't wanna work on that.

Mano Marks: Or you find a very high decision maker. Right? At Google Cloud, we have general managers, GMs. So you may say, okay. I have a bunch of product managers telling me these are the things that I can work on.

Here's my plan, and you go to general manager and say, these are the things that I wanna work on. And they may say, you know what? Actually, I would prefer you choose one, two, and five and drop out three and four. Just focus on those things. And you can go back then to say, look.

I'm working with your team, but the higher level person on your team says, this is what I should focus on. I'd love to support it. I will do what I can to leverage other resources on my team to help you out, but I personally can't can't do this. And this is where as a manager, it is my job to really make sure that you don't have this kind of block. You don't have to you you my I'm the fallback.

Right? A more senior person should be the fallback for themselves, but I am the fallback. And the other piece the other thing I wanted to mention, Mike, my somebody on my team taught me Mike Coleman taught me the concept of the slow yes. Right? You you you understand you take time to understand what the project is and that ends and what's being asked of you before agreeing right away to to jump on something.

I think that's another, powerful, technique.

Speaker 2: Yeah. Then I'd say let's say an alternate scenario where you've done pretty good at arguing for head count to take care of the tactical things. So now you really are spending most of your time in all these different alliance meetings within the company. But then now you're like, wow. I'm actually maxed out on that.

Do you also start going, okay. I'm gonna prioritize maybe seasonally, which relationships I'll be more involved in the meetings and others, like, maybe I'll just meet them once a month? Because that's how that

Mano Marks: Yeah. And some sometimes you need to let relationships languish for quite a while. You're not ready. They're not ready. The company priorities are just different, but then you come back to it.

And you you you keep sort of tabs on them. You have coffee with people. You you try and understand. You give them advice on how they can help solve their problems without your direct involvement, but you keep them interested over time in wanting to use developer relations to do this. And then you then when you're ready or they're ready or the company's ready, suddenly the priority shift, there's a reorg, whatever happens, you it's time it's time to start doing it.

And you're ready to go because you're keeping in tabs on what that team wants and cares about. I

Speaker 4: like what you said, Mano, about managers who could kind of, I guess, defend their direct reports and say kind of, like, pass on opportunities. But if the manager knows what the direct report that I see likes to do, wants to do

Mano Marks: Yes.

Speaker 4: They can, say, shield them from PM, from an engineering team.

Mano Marks: Yes. Yeah. There's a there's a mixture. As a manager, your role in here can either be to be a mentor and encourage people to to do things themselves or a sponsor, where you can say, hey. You know who's the right person for this?

Steve or Lizzie. They're the right people for this. Help get them involved in in doing this work. Sorry, Tom. It's this one wasn't for you.

Speaker 2: So I'm monitoring a question on Discord, saying that DevRel can or is super disruptive to the product road map. How do you handle engaging with, I guess, it's the engineering side also, more traditional scrum teams or engaging in some scrum style teams in an effective way. Great question.

Mano Marks: Yeah. That is a great question. And and I I think, you know, some of the more productive relationships that I've seen from that point of view is where the where there's somebody from DevRel in those meetings. They're just a part of the process of of what's happening. And that's that it that can be really effective.

Tried other things like, you know, DevRel has an approval bit or, you know, to if you have a launch process there, they can say yes or no. Those kind of things. They can be a little hard to to enforce when it comes down to, oh, we wanna launch and DevRel saying no. Yeah. I'm just gonna flip the bit to yes.

But it depends a lot on the the company culture and the relationships that you build with the team. If you can if you have the the technical rep, which is part of being, you know, some roles within developer relations. I don't wanna exclude folks like community managers or others who may not come from that background. But if you you're the important thing is figure out what's the best way for you to engage with that team, what they respond to. And it may be you're sitting in their regular scrums or, you you know, you you may not contribute every week.

You may just be sort of, like, passively there. But you're just letting people know in your constant presence. They they will be reminded just seeing your name on that list.

Speaker 3: I also think it depends very much on how open Manu brought this up about team culture Yeah. And company culture. It also very much depends on how the dev rel team is seen within the company. Yeah. Right?

I've been at several different companies where we were talking heads. Right? That's how they perceived us even though we didn't want to be that way. And so when we were giving product feedback, it'd be like, well, that's great. Okay.

And it's a very frustrating position sometimes. So I think it depends. And then the t it's a specific team too as well. There's Like, multiple teams I interact with here, but there's some that I'm like, that's a fun team to interact with because they like my feedback and they ask me in advance. I'm gonna work with them more.

Right?

Mano Marks: Right. If somebody is not taking your feedback, that's fine. You go work with somebody who does, or you find out the what the things that they respond to. One of the best things that I've I've had is, okay. I've talked to five different companies.

Three of them have this problem. Here's the companies that have the problem. Then people, when they can attach it to there's a customer who might be involved in giving us money or there's an important person that that we think of you you're invoking sort of external authority, and your representation of that through gives you that authority.