Managing your first developer relations team

Bear Douglas: Hi everyone. My name is Bear. I currently lead the DevRel team over at Slack and I've been there for about five years. Before that, my first management role was at Twitter where I led DevRel team for the mobile product fabric, which eventually got sold to Google as part of Firebase and also the team that worked on Twitter data. That was my first managing role, and so now I've been a manager for just about seven years and I wanted to look back a little bit and think about some of the lessons I've learned along the way that might've been good to know if I were starting again, what advice would I give myself? So first of all, congratulations to those of you who are in this position where you're going to be managing your first team. It's really exciting and it's also pretty scary. It is a big shift in how you work.

So I organise my thoughts into a deck that will be way too verbose to be as engaging as I want it to be, but I wanted it to be an easy takeaway. So if you didn't make this talk live or if you just wanted to skim the notes, everything is in here and you'll be able to just remind yourself of some of the things that we talked about. So I broke it up into five things, categories that I think are good to go over when you're just starting your first management role. The first is hiring. Hiring is really hard, especially if you've never done it before, even if you've been on an interview panel and you've interviewed lots of people, trying to pull something together and source people is super difficult. So we're going to talk a little bit about hiring. Second is about team practises.

I really like that Brandon kind of gave this smart segue into talking about good team practises and meetings.

His final tip about reviewing meetings on a quarterly basis to see what's working is a really, really great one. No matter how robust a process that you think you're setting up, what's working for a team of two is not going to work for a team of 20. And so you have to continually revisit what practises you're doing as a team and make sure that you're being intentional. A section just about the day-to-day, like literally what are you supposed to do when you're managing somebody. We're going to talk a little bit about promotions and performance management, always fun for everyone involved and a little bit about what it's going to be like to make the transition yourself and some tips about managing your own time, managing your expectations of yourself as you make a shift into this role.

First up, hiring. One of the pieces of advice that I give lots of people who are trying to hire their first DevRel person but applies if you are creating a team from scratch, is that the best thing you can do for somebody that you're hiring into this role is to work really hard to create clarity about what they're going to be there to do. So if you've been told, Hey, we need you to build a team, we are going to give you resources that you ask for, but tell us what this team is going to do, it always helps to ground it in the work that you need to do in the next year to make the business successful.

Is it writing a bunch of content? Is it going out and spreading the word about the programme or the product in different forums that you might be part of?

Is it something like doing a bunch of developer support because you have early users who you need to really give that handholding, that white glove support? Start with that and then figure out who's at the company who can already help. Maybe there are some engineers who are really passionate about helping out with support. Maybe there are some people who are good writers and they want to contribute to documentation. Who is the network of people who you can work with already and where are the missing skills that you need to shore up with a new hire? Then I really push people to think about what level of experience this person needs to have.

I talk to a lot of people who want to see somebody with 10 years of experience in DevRel. How many people have 10 years of experience in DevRel? Not very many. And so when you think about what level of experience a person needs to have, be realistic, think about what you'll be able to teach someone on the job, what skills can transfer and what that person is really there to do that may or may not need to have a DevRel background specifically.

And when you've created this job posting, this is a pro tip that I did not put on this slide, it's a good idea to put your job posting through a language analysis tool that we'll see if you're coding anything unintentionally when it comes to gender or anything else that makes the posting more or less appealing to various candidates. Once you've established that clarity for yourself, make sure that you get buy-in from your management chain. So ideally at least your direct manager, if there are more people up the chain that would need to be approvers on your headcount, socialise your plan with them so that they understand what it is that you're hiring for and who the candidates are that you're going to be bringing in. Last piece, do they need to be a software engineer by schooling?

This is something that has actual implications. Sometimes legally, if you've got a job posting and you're requiring a bachelor's degree for example, I really mean that to be different from not how technical do they need to be because that word just drives me batty.

There are lots of ways that people can be skilled up in software engineering and some of them may or may not be formal software engineering schooling. So figure out what you really need from this role before building out your team. Next thing is that hiring always takes longer than you think. For hiring a role for somebody relatively junior can take probably about three months and some of you who are hearing that for the first time might be like, yeah, that sounds about right. And for people who have never done this before, you might be like, that seems like a wildly long time. There's so many people looking, there's so many talented people out there and it's totally true.

But the process of interviewing people, making sure that you are creating a diverse candidate pool, socialising the role with the team, making an offer going through the whole offer process can take a long time.

And then after you've had an offer accepted, it might be a little while before you've actually got somebody in a seat to start doing work and then before they're ramped up, that takes even longer. So when you're thinking about how you should be hiring, if you're going to be managing this team for a while, it's a good idea to start looking at people who might be passive candidates. So people who may be in a year's time will have the skills that you're looking for or who might not be looking now but might be looking in the future because the opportunity to hire will always come up in a growing team and you might not have a role for somebody immediately, but you might in the future. And a note about that is that creating a diverse pipeline takes time. If you want to hire people from a variety of backgrounds building your network and figuring out who's looking, they may not always be ready at the time that you're looking for them. And so having this longer term vision and longer term pipeline is really going to help you make sure that you are hiring up a diverse slate of people.

The third bullet point, hire and haste repentant leisure.

It's a big deal to hire somebody and hiring somebody who is not a match, it can be very difficult to manage them out or to fire them. That's never fun for anyone. So when you think about the slate that you're building and how you're evaluating people's potential fit for the role, spend some time on it. It always, always pays off some notes on interviewing. First thing for fairness and for reduction bias, it's really important to standardise your process. You want to make sure that candidates are getting not necessarily literally the same interview, especially if you're going to be talking about interesting details of their experience, but generally the same interview you should have maybe a standard technical question that you're asking everybody. You should be asking about particular details of their experience in the same way so that you can actually compare apples to apples when you're talking about different candidates.

This also goes for if you have an open role where you're not really sure how senior or junior you need to hire somebody at decide and be clear with candidates about how senior this role is because there's nothing worse than under hiring somebody and then finding that they are upset at how they've been evaluated and they're going to leave or doing a bait and switch where someone interviews for a senior position and you say you didn't make the cut for senior, we're going to offer you something at a lower tier.

So be super clear about the role you're interviewing for and the standards for the level that you're hiring at. Next thing, assemble your panel. Who else is going to work with this person on a day-to-day basis who you think will be able to gather useful signal about whether or not they're going to be a good match for the team?

Who else should have a say in the process? And then minimise your time to signal and refine and retro your questions. All of this is about creating a reasonable candidate experience that still gives you the signal you need to make a decision. So I recently talked to somebody who had not one, not two, but three separate homework pieces for a single interview process. To me that is absolutely beyond the pale, it's not okay to ask for that much of somebody's time when they're preparing for working at your company.

Be considerate of the fact that they're probably looking at multiple companies and you want to be able to craft something that's going to be, that's going to give you the signal you need to make a decision but is not going to take up a tonne of their time. So I realised that the first and the last bullet points might slightly be at odds where if you create a standard process and then you find a bunch of these questions are not actually working, revising the process might seem like a bait and switch.

Hopefully you'll be able to winnow out those questions that aren't really working soon enough that you can come to a pretty good set of questions. So what are good questions? These are three that I use that generally give me pretty good signal. So the first one is a role play. I come to a candidate and I say that I'm a developer in this software community and I describe to them an idea that is just full of anti-patterns and I try and pick ones that are glaringly obvious, whether it's a security hole that I would imagine that people at that level of skill would be able to spot or things that blatantly won't scale, something like that. And so then I ask the candidate to give me some advice and what I'm looking for in this question is whether the candidate can spot the things that are not great ideas, explain them to me and explain them to me kindly.

Any developer advocate that you are hiring is going to be your representative in the community. And so it matters a lot if they are going to lose their patients or not be able to explain a technical issue to people at a bunch of different levels of seniority. Next question that I like to ask is, what products developer experience did you find troublesome with an orientation towards? And then what could you do if you were on that developer relations team to give your community a better experience? I like to dig deeper by also asking how would you know if it was actually better? How would you know if it was better for the community? And see the kinds of strategies that they're able to employ to get in with the teams. And then the last one is just asking people to explain an abstract concept that they find interesting.

It is really hard to explain things that are kind of mushy. I used to just say, what is recursion and what's the difference between recursion and iteration and one boring? No one was passionate about that, and two, it didn't always give great signal because it turns out recursion is excruciatingly hard to explain and there are many other things that you can ask people to talk about that will still give them an opportunity to showcase that they can communicate with clarity to a developer audience. So once you've actually hired people, what do you do? You want to make sure they have a good onboarding plan. So think about the first time you entered a company. You're probably a little bit nervous about meeting people and you're probably also a little bit nervous about wondering, am I doing a good job? And to be honest, as a manager within a week or two weeks, you may or may not actually have enough signal to be able to tell somebody honestly whether they're doing a good job.

So just keep a few things in mind. The first is that they're going to need a buddy, ideally that buddy is not just you who can give them a lay of the land, tell 'em how the company works and then make introductions on their behalf to the team. It's always nice to have a warm intro to the people you're going to be working with. And if you're working in a larger company, figuring out who's who can take a long time if you're brand new, especially in a remote world, onboarding tasks, creating useful ones that have a first deliverable that you can actually use in your community is a great way to learn something and also give people that first like hello world sense of accomplishment. I built something that the team is actually going to use in this onboarding plan. It's a great idea to have a first quarter plan for somebody.

So what do you expect in the first 30 days? What do you expect this person will do in the first 60 days and what do you expect in the first 90 days?

You'll find that as the people you're hiring are more and more senior, they're going to be interested in co-writing those goals with you. So maybe you just plan out the first 30 days and then you say, well, I expect that around day 60 you're going to be articulating our strategy for events for the next nine months. So that's my expectation around day 60, but having that onboarding plan can help level set and make people more comfortable as they're getting their feet wet in a new company.

All right, setting up good team practises. There are some great resources for this that I'm going to point you to online later, but a couple of things that really help once you've got people in the door and you're trying to build a sense of team process and team cohesion. The first is doing goal setting together. So as a team sit down and decide what are you trying to accomplish right now and also what are you trying to accomplish in general? What is the point of what you do as a team?

I think it's useful sometimes to have a North Star metric, but I personally at Slack have a difference between what I think is our spiritual North Star metric and the metrics that we can actually measure spiritually. We care a lot about developer satisfaction, developer NPS, whether people are having a good time and also whether they're hitting a bunch of process holes, that means that they fall out of the funnel so they never actually get to success.

And so those are both measurable, just not on a cadence where we can really say this particular sample that I shipped improved developer satisfaction by three points. So when you're thinking about the types of things that you can measure, there is a difference between project level measurement. You can evaluate whether a project was successful without necessarily, for example, tying it to company ROI. So when you're setting goals, think about not just what you can measure because what you can measure might pigeonhole you in a direction that's not actually what your team cares about. And be clear about what you're trying to do for developers for the company and what a particular project is trying to achieve Charter writing, it is a very trite feeling thing to do to say, this is my team, this is what we care about, this is what we're here to do.

But it's a really useful clarifying exercise.

I did this with my team at Slack and at Twitter using the V two mom from Salesforce and I completely misunderstood what a V two mom is supposed to be. But what we did by accident was use it to write a charter that got us all to talk about the things that we care about when it comes to serving our developer communities, the ways we want to measure ourselves and little pieces of team character that we want to make sure we preserve. We haven't looked at that document again ever, and that's fine because the thing that was helpful about it was getting everybody on the same page at that point in time. Team level agreements are about how you work together, how are you meeting, what information goes in, what channels, how do we interact, when do we expect each other to be online?

And I've got a great resource for you and one more slide about how to start writing those given where we are in the world and in the pandemic, continuing figuring out what remote or hybrid means for your team and how you operate is a good conversation to have. And the last bit is making time for fun. This is your job now you have part of the role is to do some amount party planning. Does your team need some swag?

Do you need to have a mandatory fun D together and what does that look like As a manager, it's very good for you to be organising that stuff. So when it comes to team level agreements and building these frameworks, there is a great resource on the future forum. com. If you lose this super long URL, just go to future forum. com and then it's under the blog.

And this actually includes a template for the questions that you might want to ask for building these team level agreements. That includes things like personal operating manuals, which I think personally are terrible if you write them in isolation and then hand them to somebody and say, this is how to work with me, figure it out. If you write them as a team, it can be a powerful way to make sure that everybody's on the same page and understands each other.

So read through that if that's something that you want to be adding to the way your team operates. Alright, the day to day, what is it that you are supposed to be doing every single day? Well, here is a literal checklist of things that you can be doing. The team at Team Bit has pulled this together and includes things like setting up recurring one-on-ones checking, giving people meaningful feedback and a few of the daily practises that if you just want something to nudge you to do it, like have I given somebody meaningful useful feedback today?

You can set yourself a reminder in Slack, especially if you're remote and you're not seeing people, it can be a good moment to make sure that you're not just checking in on people who are new to your team. Maybe you're also checking in with people who have been on your team for a long time. Other things to consider here is that different people on your team will have different needs for you as a manager. When I was first starting in my management career, I've had a very clear picture of what I wanted to do where I was like, I've learned habits I really didn't like in other managers, things that I really admired and what I kind of missed was that I was modelling the manager that I wanted and that is different from what people on your team might need.

So somebody who is coming in fresh out of college is going to want different amounts of guidance than somebody who is coming in at staff.

Level one person's micromanagement is another person's clarity. So what you need to figure out with your team is what they need from you and what they want in terms of communication as well. Another easy trap to fall into is when things are going poorly on the team or you're hitting some rough spots, it's really tempting to take all of your energy and focus on the things that are needing help, things that are on fire. The trouble is when you do that, you neglect the people who are doing really well and those are the people who you want to invest in. Those are people you want to retain, so remind yourself and it's also a nice thing for you too, just occasionally look up, regularly look up and see what is going really well and how you can give more fuel to the things that are going well instead of just fighting anything that is on fire.

Other things to know about day-to-Day management of your team is that you're not the only leader. I think there's a section later on IC leadership peers can be mentors too.

Peers can help you project management, people can learn from one another. So you don't have to think of yourself as the be all end all for your team. You're not. You're very much not. You are one person with a particular set of expertise and hopefully you've hired a team that have complimentary skill sets. So between multiple leaders on the team, you can have a lot of people covered. The last piece is important too. Self-advocacy helps your whole team.

So when you look at what resources do I need, what does success look like for me, you're creating opportunities to lift up your whole team. When you think, you know what? My team should have this expansive charter where we're going to be working on these 15 different things.

You are going and grabbing new and exciting areas for people on your team to own. So there is a benefit to your team for you to be occasionally a bit self-interested in thinking about how you can succeed as a group. So when you're figuring out how to advocate for yourself, it is also an altruistic movement away for your team. Speaking of which, promotions and performance, this is one of the trickiest things for first time managers because what I have to be able to advocate for other people now maybe I don't even know how to get myself promoted, and that is one of the first things that you should definitely figure out as you are coming into the management role as a manager, you have an outsize amount of influence on the careers of people who are on your team. And so it is your duty to them to really understand how that works at your company and how you can be an effective advocate for them.

So the first thing is to understand the landscape. What does your company process look like? Is there a committee? How do packets get written for evaluation by the committee? Is this a five person startup where everything is kind of loosey goosey and you just kind of ask the CEO, whatever it is, understand how it's all going to work because you're going to need to know that in order to be able to be a good advocate for your team. The next thing that can be really helpful is an actual artefact A doc that will help get everybody aligned about what expectations are at different levels and how you can calibrate people to them. So I published our DevRel ladder on Slack down engineering a couple of years ago so that you can have something that you can see as an example. Important recent edition that I don't think is on that one from a couple of years ago is anti-patterns.

So here's an example. Suppose somebody is clearly at the technical calibre that makes them senior, but they are an information hoarder. They never teach anyone around them and you have a single point of failure on this one person who is a solo rockstar and then never levels up anybody around them that would hold them back from promotion because that is a negative behaviour in the context of a team that really means that they're not performing at the senior level. So once you've written that career ladder, it's really important to actually get buy-in from your management chain because if you find that somebody is checking all the boxes and your management chain doesn't agree that checking all those boxes means promotion, your ladder's meaningless. So that is something that is really worth your time socialising with senior leadership When it is promo time, look at the slate of people that you're interested in promoting and it's helpful to go through and say, should I be promoting this person?

Why not? When I say they're not ready, what does that mean? Gender and racial bias can factor into decisions that we make here.

It happens. Recency bias can be things like someone is in general doing very well and then recently they hit a wall with pandemic stress or whatever it is and they're not doing as well. So do you think that you need to performance manage them just because of the last two weeks, whatever it might be. Angel and devil means you have just sort of confirmation bias about how somebody behaves. So if you really like somebody, every good thing that they do adds to that reputation. If you don't think somebody is great, every bad thing they do is gets disproportionate attention from you and looking in at potential versus performance, this is something that all of us fall into. And I will say that one of my biggest regrets as an early manager was not promoting somebody who deserved it and was at 11 months into the role and technically according to the company rules, you cannot be promoted until 12 months in and instead of being a good advocate, I was a good rule follower and I regret that to this day.

So when you're thinking about what it is time to do for promotion, really spend some time thinking about can I fight for this person?

Should I fight for this person? Who am I considering and is there any sort of pattern in who is and isn't coming onto my list? When it comes to making promotions that are successful, there are a couple of things to know. One is that you should be able to get access to a template in a more established company about promotion packets that have been successful. What type of evidence do you need? What points of argument do you need to make work with your own manager to make sure that that case is really, really strong As part of this, understand when it is not a good idea to put somebody up for promotion. If you have a slate of six people on your team and you put all of them up for promotion and you do this every cycle, you're going to get a reputation as being somebody who is indiscriminate about putting people up for promotion and it will get progressively harder for you.

And that's something that kind of sucks to say openly, but it's true.

So when you're thinking about who you're putting up and how you argue, spend some time thinking about how you can argue successfully. And promotion is not the be all, end all. Find out what your total rewards landscape can be for people who may be just want to raise and promotion doesn't necessarily matter. Spot bonuses for people who have been putting in absolutely extraordinary effort and quality of execution in something that is just completely within the scope of what they should be doing, but they just did an amazing job at it. Maybe what this person cares about is executive face time or exposure, getting to talk about their work and getting recognition for it broadly. There are lots and lots of ways to reward people that aren't literally promotion but don't pass the buck on promotion. People deserve promotions. Performance management, this is a reason I put uncle fester up is because it is really important not to let these conversations fester.

It is tough. This is one of the hardest things of management and it is really tempting to be conflict avoidant when you are first in a position of being a manager and it is really to remember that other people's poor performance affects people on your team. People are picking up the slack from them, people are not getting things done that they need it to be and it can really, really harm them. So when you go ahead and have these conversations with people you need to have hard conversations with, it really is for the benefit of the whole team. The first thing to look at though is critically why you think they're underperforming. Is it that they bit off more they can chew? Do they not have the skills that you assumed that they had or that they need in order to be successful in some of the work that they're doing?

Do they actually just have a different definition from you about what constitutes good and thorough work?

There are different courses of action to help these various different scenarios. Like for example, if you aren't aligned on what constitutes good work, start giving people a template, have those discussions with them so on. And you have to ask yourself honestly, what have I done to create or contribute to this situation? It could be a lack of clarity about what was expected. It could be that you give this person work that they were just not ready for and did not give them adequate support. There's plenty to be analysed there and sometimes the answer is you did your design just to set them up for success and it didn't really pan out. But you have to go through the exercise of asking yourself that question to even begin and before you come up to somebody and say, Hey, why didn't you do this thing?

Avoid the shit sandwich.

When you're talking to people about things that didn't go well, it's really tempting to say, but this other thing that you did well was really great. And so sometimes people don't hear the criticism or the important feedback between the two compliments that you gave them and they can end up being really surprised or that it's coming out of left field that you're giving them a criticism for the first time. It is really useful to rehearse any of these conversations. Grab a buddy grab, say it aloud to your pet, rehearse to your dog, rehearse in the mirror so that you don't end up saying something that you don't mean because you're doing it off the cuff. And if you have time, I recommend looking at crucial conversations. It's a book that I think also has a course attached to it that gives you a general framework about how you can be direct with people while decreasing the emotional risk for them.

In these conversations and because I know I'm a little over time and we're going to breeze through the managing yourself part, it's a big shift moving from being an IC to being a manager. And so it's going to require a little different peer support because when you're working through tricky people issues, you don't want to be blabbing to people inside your company like, oh hey, Jane Doe over here is really struggling with time management and it's driving me nuts.

I can't really get through to her about how she needs to manage her calendar. Whatever it is, you need to be discreet about things that are happening on your team. And so building your manager support team is really going to pay dividends for you in the long run. So a good person is your own manager. Can you lean on them to talk about any sort of personnel issues, things that you're dealing with on the team, things that you want to bring in their help on.

It's helpful to have another manager inside your company who is maybe your organisational cousin who has enough context to talk through some amount of problems with you but isn't in the day-to-day enough that they'll be too overlapping with you. And then it also helps to source somebody in a similar role at a different company who can understand structurally the types of problems you might be dealing with and to give good advice there but is completely separated from any of the organisational issues, interpersonal issues, and can just talk to you a little bit more objectively about some of the management work. Second piece of advice, and this is I'm going to call myself out for hypocrisy here, handle your calendar.

If it's really hard to get time with you, you can become a process bottleneck. And it's also just exhausting Talking to people all day is really, really tiring.

I've heard of a good method that some people use where they colour block and they say, this is one-on-one time, and so it's going to require intense interpersonal focus on Zoom. This is going to be a presentation where I'm listening and participating in discussion that requires a different type of energy and again, perfectly teed up by the Brandon code screen ad that said, does this meeting need to happen? Can you go through and Jess in some of these meetings? In general, it's it's a big change. The biggest change that can be kind of strange is that your output is different. You're not going to ship 17 samples in a half, you're not going to be necessarily attending as many events.

You're going to be doing this sort of meta work of people management and that can be really weird to let go of. My biggest piece of advice for that transition is to try not to reach for the stuff that feels safe because you can't get a handle on what is it that I do all day.

Now in a small team, you will need to do some IC work. If you've got one direct report, your whole job can't just be looking over their shoulder and saying, my whole job is managing this one person. That doesn't make sense. But if you have a team of five people, think about whether you doing individual work is really going to help them versus thinking about how you can get them more resources and some of the more managerial tasks that don't have the same easy output to point to the next thing that I think is important is acknowledging the power differential that exists and changes between you and your reports. How you show up every day affects other people. Now people may start telling you what they think you want to hear instead of being super honest with you about how a project's going or how something's going.

And you do have power over their careers. So it's important to know that own up to it and take responsibility for that as well. And last thing is just we'll make mistakes. I've made lots, and we can talk about those in a sec, but focus your energy on what it takes to make those mistakes better. No one is expecting you to be perfect, and when you say, I screwed up, here's how I'm going to make it better. That is the powerful thing that helps you learn and also is important for fixing the mistake that other people are affected by. So with all that said, let's talk. What are you thinking about?

What is scary for you and what can I tell you that would be helpful? Thank you very much for your time everyone.

Tamao Nakahara: Awesome. Hey Bear. Great as always, we'll bring on our COCs as well. I think we've been filling up the discord with various comments and questions and jokes about whether it's a shit sandwich or a compliment. I was like, wait, that's too bad. Things with a good thing in between.

Bear Douglas: It's a compliment sandwich, right? Oh yeah, no, that's a good,

Tamao Nakahara: Because the compliment sandwiches where you're like, Hey, you've been doing really great and lemme give you some feedback, but you're a fantastic person. But anyway, yes, so we'll be looking at these various questions. I think Amara, you posted one you want to start?

Amara Graham: Sure. Let me find it because I was multitasking and I don't want to mess it up.

Tamao Nakahara: Onboarding.

Amara Graham: So yeah, so I was onboarding at the same time as one of my reports was onboarding.

So understanding the landscape like you were describing was kind of definition learn while doing. And I have a feeling that many new DevRel managers will have a similar experience because I've seen quite a few director of DevRel positions that are open and it's like the company's first DevRel hire. They're super excited to give someone the chance to build out a team. So do you have any tips for navigating this situation better or easier?

Bear Douglas: Wow, it's a good question. And for the promotion part at least, hopefully that doesn't become so immediately relevant that that's something that you have to learn and fix in the first three months. Even if somebody just got hired and already they're like, how am I going to get promoted? Calm down.

We all just got here. We're still figuring out our lives and yes, I am your advocate, but we'll get this in time. When it comes to other processes like I don't know, budget requests, resource requests, those can be the kind of things that are top of your list just operationally. And you should also expect some amount of onboarding from your own manager. If your manager is managing managers, they should know that there are certain structures that they should be looping in about, whether it's things like planning your first budget or thinking about your travel and expense policy. All of these things are perfectly fair for you to push up while you're new and say, Hey, I'm new here, manager of mine, help me out with this while I'm getting my feet under me.

Amara Graham: Sounds great. Thank you.

Tamao Nakahara: Awesome. We've got several questions here, so let's get to them how to ask a leading question. How have you dealt with the expectation to produce as a dev advocate while also running a team? Happens a lot.

Bear Douglas: It does. It does. And I think it a lot depends on your team size. If you're managing say three people or fewer, I actually do think that is a fair expectation that you have some amount of output.

Even today, I still manage some of the partners as a IC partner engineer at Slack, and I think it's important. One, because I keep my hand in two, it gives me some perspective on what matters to partners, but I keep my load light. I'm not taking on 15 or 20, I have two, so it's a little bit of a dance, but I do think there is value in keeping some amount of work that keeps you in touch with what people are doing on a daily basis. Never make yourself mission critical though, because if that means that you got pulled into an all day meeting with execs and so this thing didn't get done, that creates cascading effects on the rest of your team. That's disastrous.

Tamao Nakahara: Yes. And related to another great question is how do you deal with a manager who doesn't have the same skills that you have, so can't really mentor you that maybe you are new into DevRel and you want to learn docs and your managers actually hasn't done docs.

Bear Douglas: Totally find pure resources whether it's inside your company or outside your company.

Classic example on my team, the developer tools team rolls up to me, they build our SDKs and frameworks. Should I be in charge of building an SDK? Absolutely not. No. So what we've done is paired the manager of the tools team with some of our directors of engineering inside Slack so that they have touch points and other people who have spent a lot more time doing specifically engineering management and it's working for now. And that is something where I think it's important to acknowledge, one, your own limitations as a manager, and two, when your manager has those limitations, make it not when you're managing up, don't make it any sort of reputation risk. Just be like, Hey, I need a peer who can talk to me about this stuff. I've selected this person.

Or I would love your help selecting somebody who can help me, who you recommend. And it doesn't have to be like, you're failing me as a manager or I know more than you, and so I don't respect you. It's just that you need to source help.

Steve Pousty: I mean, I think it's kind of impossible if you're leading a DevRel team, right? Because there's so many things that fall. I couldn't really help a community manager. I know a good one when I see one, and I know some of the things I like in community management, but I can't like, so when I had documentation under me, I actually started telling them, go hang out, write the doc slack, go hang out there. Here's some doc writers I know.

Go talk to them. I'll make the introduction. But it was like, there's some things I don't know and you, I'm not going to be able to help you with that.

Tamao Nakahara: Yeah, yeah. I'll definitely include that in my interview process as well because I haven't been a product engineer and if I'm hiring developer advocates or developer experience engineers, I'll say, are you okay having a manager that's not going to be deeply in your code and making comments? And when I had imposter syndrome, at some point I realised that there are some people who are like, I'm so relieved that I don't have a manager who we're battling every day over this code and the approach and stuff. And in some ways I give them licence or I connect them with people to discuss and things get ironed out. I feel like I don't have to come in with a strong opinion how you're doing your engineering.

Bear Douglas: Totally. And it also depends how senior people are in their career. If you were fresh out of school and your manager didn't have the same skills that they were expecting you to display, that is kind of scary and can be unmooring for folks who are newer in their careers. But for, like you said, people who consider that micromanaging, they love the freedom.

Tamao Nakahara: Yeah,

Bear Douglas: Get out of my pr, so I don't want you here.

Tamao Nakahara: Yeah, and I've shared this before. I mean, I know people come from different backgrounds and different comfort levels, but for me as a manager, it's been great where I have someone come in out of college and they haven't been as shy at all. They're like, oh, there's this super awesome principal person.

I'm just going to glue myself to that person. And I check in. And that person's, it's like, oh, I do have this on my plate, but I'm really enjoying the mentoring. And it's just really great to see them just being very productive together and it's great.

Steve Pousty: I would say though also an anti-pattern is someone leading DevRel who hasn't done DevRel. I've seen that before. And sometimes what I've seen sometimes is people just saying, okay, you can do whatever you want. I don't really know this field.

Or not being able to talk about, well, this is a valuable activity for us versus this is not a value. Just responding to pressure from the outside. So I do think it's important as we promote people to managers that they at least have some experience in DevRel. Currently.

Tamao Nakahara: I have not observed that, so that's good to remember. Lizzie, I know you had some questions. Did you have a,

Lizzie Siegle: I was going to say pers question about how management seems to require a lot more project management experience than expected. Do you have any tips for growing that PM project management muscle?

Bear Douglas: Yes. Is this before you become a manager or is this, you're a manager and now you need to learn this on fly,

Lizzie Siegle: It sounds like.

Bear Douglas: Okay, well find a template, find somebody who's done things before and see if your company has a standard way of getting things done. You can find people who specialise in this. People have the title project manager, and they can teach you some of the frameworks that people use to do good planning. Let's see. Yeah, I would say tap into your peer network is probably the best advice I can give. And as you're new to something, the more you can lean on established frameworks, the more likely you are to succeed without giving yourself an ulcer.