First year managing a DevRel team

Matt DeNapoli: Hi everyone. My name's Matt De Napoli. I am one of, and my colleague is actually speaking later, one of the senior managers of developer advocacy with Cisco DevNet. And these are the top 10 lessons I learned as a new DA manager or how I learned to stop worrying and love developer relations. A little call out to Dr. Strange over there. Without further ado, let's get started. Oh, goodness gracious.

So just to give you guys a little context and background on me, so you kind of know where I'm coming from. From the lessons that I've learned. I've been at Cisco for 14 years, which I know within this tech space is a long time to be with one company. But don't worry, I've held a number of different roles within the organisation as I've been there. I started out in developer support helping out wireless network engineers, implement an SDK to work with Windows Vista.

So that's how long I've been doing this. I moved through, did some systems architecture, some systems management, and then I kind of fell into developer advocacy. Or actually at the time we were calling it developer evangelism, so I'm not sure if that's a bad word in this space, but it was interesting to start to get started in that and be able to do talks and learn about technologies and be able to share all the things that I was excited about.

I was kind of used to doing internal implementations, putting stuff out there as far as production was concerned, but not really being able to talk about it. So it was really exciting to get into that space. And then in the last year or so, I was able to procure a job as a manager of developer advocacy. And so now I'm senior manager of developer advocacy.

And let's get into the top 10 things that I've learned in the last year by hook or by crook. The first one is that change is inevitable and learn to embrace it. So I'm going to add a little more context here to our developer relations programme so you kind of understand where we're coming from as far as when I talk about change. So our developer relations programme started in late 2013 as kind of an experiment.

So for those of you that aren't familiar with Cisco, we make most of our money by selling routers and switches, but that's just kind of the topical level of things. We're actually one of the larger software companies in the world, and we tie into collaboration. We tie into application performance monitoring, we tie into service provider areas, enterprise, networking, campus, all that stuff. And so a lot of times people didn't even know they're interacting with Cisco and we're kind of there behind the scenes.

But understanding that Cisco historically had been a hardware company when the idea of building out a developer programme was floated, it was how would that actually work? What does that actually look like? And what kind of bubbled up to the top was we realised there was a really large desire for network engineers to adopt network and infrastructure automation and programmability. And once we kind of glommed onto that, since then every year, every quarter there were new initiatives, tweaks, aim for growth, but we always had the same leadership in place and understanding of our audience.

And so we were able to kind of cater that to that, and those people that kind of led the way became the face of our organisation. That was until three months ago or three months into my situation as a manager, it was about nine months ago. So I had an interesting mix of veteran developer advocates and newbies coming into our team as direct reports.

And so I kind of had to guide them through all of this change where our organisation, which we now call developer relations, was splitting away from our sister organisation that provides formal learning paths and certification. New leadership came in and they added direction to expand our audience from our traditional network engineer audience and automation engineers to application developers. And so as a manager, I realised that I had to address these concerns that were coming in from my team, any negative talk, any speculation, so that people on my team didn't panic. I mean, they were used to seeing a programme that was kind of getting pretty mature in its development and was something that they were excited to join and seeing a lot of change coming that way. And so the first thing that I did and I thought was helpful was just listen to their concerns, understand where they're coming from, where that potential negativeness could potentially come from.

And then once I listened and understood what people were worried about, I was able to talk to them and reset their perception. And that actually was pretty helpful. I was able to tie the things that they were used to doing into these new directions. And I think that everyone on my team got a little bit of a comfort level in what they would be doing and how their roles would be potentially changing for the better moving forward that ultimately guided us to tasks that supported these new initiatives. And really ultimately what I wanted to do was set a positive example for my team. And so I would like to think that for this one, the approach that I took worked because I had no attrition on my team, and we are actually, I feel a stronger developer advocacy group for it. So that was number 10 onto number nine, seek a mentor out that you trust.

And this one actually started out before I became a developer advocacy manager.

This was something that I wanted to get moving forward. I had no experience with people management, but I had some really solid ideas about what I thought people management was. And so I started working with a gentleman that was a product manager for another organisation that I worked with closely, and he turned out to be wonderful. He helped me gain confidence as a people manager. He helped me validate my ideas, he helped me bounce ideas off of 'em. And so it really felt like it strengthened how I engaged with my direct reports because I had the mentor to bounce ideas off of. Now, fortunately, we had worked together in similar technologies, and so he had a good framework for what I had to deal with. And so it made things a little bit easier when we had those conversations.

But having that mentor and I still talk to him monthly, having that mentor I can trust really helped me out in that first year. Number eight, your task list isn't as important as your team's task list or the task that are important to your directs. So in my mind, the primary task for any manager is to clear the way for your teams to do their work. So now for developer advocacy, that's clearing the way for them to build their sample code, write their blog, shoot their videos, prepare for their podcasts. Now of course, there's administrative work that needs to be done.

Sorry, I've been asked to increase my volume. Yes, there's administrative work that needs to be done such as reporting, task management planning, but be ready at the drop of a hat to answer your team's questions or prepared to have a conversation with them that could take half an hour, an hour or two hours because what the work that they're doing is foundational to the success of your organisation. And so clearing the way for that is really your number one task.

Number seven, you aren't an engineering team, but maybe you're a little bit of an engineering team. So this is an interesting one because at least in our organisation, and I think this is pretty common across developer advocacy teams or developer relations teams is made up of either engineers or past engineers or future engineers. There's an engineering aspect to it, but we're not all held to these two week feature sprints.

We're not the ones that are grabbing the sticky note off the wall and moving it from one Kanban board to another, but we still need access to those same kinds of pipelines and structures and deadlines aren't as hard and fast as they are in product delivery unless there's an event that we're trying to hit. Of course, the big events are the things that definitely hold those hard timelines, but ultimately we have to bounce delivery on what is important to you, the manager, the organisation in general, and the individual contributor. So understanding that you have engineers, but you're not engineering team, I thought was pretty key to jumping into that role of manager of developer advocacy.

The next thing we are looking at is that the marketing team is your friend. It took me a while to learn this one, and actually in fits and starts, I think at the beginning of things, I had this notion of if you build it, they will come.

That is not true. They will not come. They will come if you tweet about it, they will come. If you have a lot of content that goes out on a regular basis, you have to work with your marketing team to come up with those plans for the content you're building. Yes, most of the effort needs to be put into the content building, those proof of concepts, building those demos, building that sample code, writing those blogs. But once you get that stuff done, you need to have a plan for putting it out there. And working very closely with your marketing team is ultimately key on that. That's what they're good at.

Next, be super thoughtful about team meetings. This is something that I kind of took for granted when I was an individual contributor. I would just join meetings, didn't really think too much about it. There were some times where I was like, yeah, we're having too many meetings. But actually when I started out as a manager, we were just because of the way our organisation was set up, we were having two to three team meetings a week that an individual contributor would have to attend, sometimes even four if I'm being honest. And it was so bad that I didn't feel right holding a team meeting of my own just for my direct reports. And that happened for probably about four months or so and just it felt like too much. So for the type of work that a developer advocate has to do, there's got to be some focus time plus their regular interactions with the technology groups that they're working with, and plus their community outreach.

It's a lot to ask them to be part of these team meetings where there's some overlapping messaging and there's stuff that they've heard about before and it's getting different context. And so it's your job as the manager to push back and suss out what the actual team meetings need to be like.

But that brings me then to my fourth point in my top 10. At some point you got to bring the team together. So in my experience, and I think this is a common experience among developer relations and developer advocacy, this can be a solo job, especially in our organisation, how we've laid out the roles and responsibilities we're globally distributed. We've only really historically, even in non pandemic times, met face-to-face on mutually attended events or annual team offsites. So when I wasn't holding those team meetings that first three or four months, I felt like it was seven teams of me and the individual contributors and rather than a holistic team. And sure, I was holding 45 minute one-on-ones every other week.

But that comradery that I wanted to build didn't really have a venue. We had our messaging platform that we interacted at, but people weren't really necessarily comfortable with having those conversations with each other.

And I had a few new people on my team that really hadn't met face to face, which is an interesting challenge that we've all had to deal with over the last couple of years. And with that thought, I decided, well, I know we have a tonne of team meetings, but what if we paired down our 45 minute and allowed ourselves the ability to meet as a group? And so what I decided to do was at a 30 minute kind of check in, rundown, stand up, whatever you want to call it, where people shared a little bit about their weekend. So we kind of have those personal interactions and strengthen ourselves as a team.

Two tasks that they were to focus on for the week and any help that they needed from the team. And I think that over the past six months or so that we've been doing this, I think our team has really started to gel and become a lot closer.

So that's been really nice. Now the other thing that I did do, 45 minute one-on-ones every other week, didn't really give me enough time and insight into what they're working on. And so now we have kind of 15 minute weekly check-ins to just touch base, see if there's anything I can help them out with, understand what's going on in their world. Sometimes they bleed over 15 minutes, but that's okay. But that check-in with them has really made me feel closer to my team. And the rundown, I call it, the rundown that we have on Monday mornings really helps us all gel as a team.

So that effort to figure out how to bring the team together with the larger organisation within the team meetings we have to manage in the larger organisation is one of the big main things that I had to learn. Number three, hiring is super hard.

And I was chucked into the deep end When I took over the job. We had an open rec for a cloud developer advocate, which within Cisco is kind of interesting because it covers a wide range of technologies and a bunch of different spaces. And so coming into the job, I didn't really have a good feel for exactly the technologies that would play into this person's role and what they would be working on. And now if I was a hiring engineer, I would a direct engineer, a classic engineer, I would focus mainly on their technical credentials, worry less about if they were gregarious enough to stand in front of 500 people and talk about something and have them learn something engaging and how cool coding is.

Now that mix of technical acumen and engaging personality is hard to come by and even harder to figure out in a couple of interviews. So as soon as I was put into that management position, I had to hire that senior level person and go through and figure out through this sea of people who fit those specific abilities to tie into developer advocacy. So there were two things that I really kind of boiled it down to. I mean, there were a myriad of other things that we evaluated on, but one or two of these things really stuck out in my mind.

The first one of those was, could I have an easy conversation with them if I didn't have to probe for more information? Or they added examples in colour without being prompted. That was a good sign that they could put on a good and engaging presentation.

And so that made me excited when we had those conversations that were just kind of easy flowing and didn't require a lot of pulling information out of them. And then the second one, and this one is something that I've always kind of tried to do in my own experiences, but try and be honest about my technical capability or more appropriately my technical deficiency or their deficiency. Usually those who can clearly identify where they're weak and not necessarily that, Hey, what's your weaknesses question? But pulling out the conversation when talking about the technical credentials, they know then how to strengthen that area when the time is right. It's not something that they absolutely have to know today, but do you get a comfort level that they understand that they're weak in that area and can bolster it when they need to?

It's really that do they know how to learn kind of thing that I've always kind of talked to people about when talking about interviews or jobs, it's always showed that you can learn the thing that you need to learn. You might not know today and be honest about it, but show that you can learn it tomorrow if you need to. Alrighty, we're getting to the last two.

Learn your technologies at least conversationally. So this is something that might be kind of specific to Cisco. I'm not sure how it works in other organisations, but each of our developer advocates tend to focus on one specific technology or a group of technologies that kind of fit within the same space. And sometimes that group of technologies can have sub technologies underneath them that figure that stuff out. Now, when I started out as a developer advocate, I ended up having to focus on one specific technology.

And so I became very well versed in that technology. It was in the enterprise networking, campus networking space around automation on that particular platform. And so over those three years that I was a developer advocate, I really only focused on that and didn't really worry about these other technologies unless absolutely necessary. And so I got fits in little bits here and there when talking to my colleagues, but I didn't know the technologies enough to be conversational about it.

And so when I came to this role, I started to realise that I couldn't do my job effectively if I couldn't have a conversational understanding of those technologies because if they had someone internal to our organisation asking them for something to do, I couldn't really evaluate it appropriately. I didn't know how that technology affected the amount of time that they had to work. So allows us this knowledge, gives us the strength to help out our employees to say, Hey, you probably don't have a lot of time for that because coding against this platform is very challenging. Or if you're building out a sandbox, think about these certain considerations when you're dealing with scope or, Hey, it would be really cool if you built out an example on this because X, Y, Z, and the audience might really like that.

Those kinds of things really come from at least again, conversationally.

You don't need to be a practitioner in those technologies, but at least being able to have a solid conversation about those technologies when dealing with both external community parties and internal engineering parties as well. And that actually brings me to my very last point, and I think I'm going to nail it on the time here. Protect your team. This is the number one thing I think for any manager. It's the idea that I validated with my mentor. I was like, as far as I see it, being a people manager is protecting your team. So that's the same thing for any manager, but this is for das or for developer advocacy is especially hard because as a group of technical subject matter experts, we get pulled in a lot of different directions.

We're advising on classroom curriculum, we're advising on learning labs, we're building learning labs.

We're advising on sand sandbox architectures. We're managing our engagements with our technology engineering groups. We're doing community outreach on several different channels. We're writing blogs, we're building sample code. We're doing all of these things that pull us in a bunch of different directions. And so we have to be very cautious about the amount of time that we spend on them and the focus for the motivation there. And so being able to protect your teams, deflecting, denying requests that don't make sense within the mission of the team, sifting top-down information for both importance and timing is super helpful for them to get their work done.

You're helping build their profile both internally and externally. Any work that you do needs to be in promotion of them. Ultimately, and this isn't the most fun part, and I'm going to end on this note, my favourite thing is being able to delegate projects that promote growth and tie into individual interest.

Being able to say, Hey, this guy over here really loves cloud native development and really likes to work with Kubernetes and being able to give them a project that really stretches that muscle and isn't something that is focused in an area they don't like. That's super exciting today to me. Yes, of course there's work that we have to do, but what about the work that excites people and adds value? That's the most exciting portion of the job. So those are the 10 lessons I've learned.

You can catch me at the DAP on Twitter. Thank you very much for your time and including me, and I hope you guys all have a wonderful day.

Brandon West: Awesome. Thank you, Matthew.

Matt DeNapoli: Thank you. That was fun.

Brandon West: A lot of that certainly resonated with my experience the first year. Seems like a long time ago now, but things you said about specifically hiring.

I mean, I had the same thing where it's like, wait, I'm hiring people that are going to be good at explaining what they know about technology, so I just need to ask them to tell me stories. And if they're good at it, I don't need to check that they're good engineers or good developers because it'll come through in the communication. So that especially rang true. I'm curious, what has been the most surprising thing for you in your first year as a manager?

Matt DeNapoli: Wow, that's a good question. I hadn't thought about that. So I would say it's probably how individual everyone is. So it's worked with a lot of the people that report to me for a number of years or a few of the people that worked me for a number of years.

And really only when I became their manager did we really connect on a level that I understood their different interests, at least from a work perspective and how they approach work and how they think about work. Because when I was an individual contributor, I was working alongside them, but I didn't really have to worry about, Hey, does this person say yes all the time and dig themselves a hole in the amount of work that they have to do? Or is this person super interested in this technology and I should be helping guide that direction? So that individual portion to it was really interesting to me and surprising. I kind of put everyone in the same bucket I was, and I took that for granted a little bit. It took me a little bit of time to come to terms with it, but once I kind of solidified that, it made it all the more interesting and our engagements have become more positive in my mind.

Brandon West: Awesome. Sorry, Mr.

Revell, I believe I might've jumped the gun and gone straight to q and a before we opened up the whole discussion. So I apologise. I'm so

Matthew Revell: Excited. No, that's fine. Yeah, that's good. I think we've lost that sushi, but it is quite late for him there, so that's understandable. Yeah, I mean that's a question that I would've wanted to ask as well, so that's fine.

Brandon West: So it works out okay.

Wonderful. Yeah, the providing safety to your team's thing, right? That's always been sort of the approach that I've tried to take be the umbrella that prevents all of the stuff rolling down the hill from splashing on the team. It's especially tricky, I think, like you said, for DevRel, not just because of the variety of things that have to be done, but because you typically select for people that are very empathic. So not only do they say yes too much, but they get really excited the thing they said yes to. And so then you have to bring them back and be like, you can't do that. And I know you're excited about it, but here's why. So yeah, that's kind of a common theme throughout some of these talks recently has been providing that safety for your team, but just seeing all the different types of ways that can mean different things has been interesting.

So just wanted to highlight that and say thank you. I think that servant leadership approach is something that more people need to see modelled and talked about.

Matt DeNapoli: Yeah, and I'll give credit to my manager now. He was my manager when I was doing developer advocacy as well, and he kind of modelled that for me and made it easy for that transition to manager to say, I want you to be able to say no to things and feel empowered to do that in the right situations. So that's something I think it's a constant lesson that people need to remind themselves of.

Brandon West: Yeah, it's something that I came up with in the talk that I gave at Alcon a few years back, was the idea of the slow. Yes. And that's something I've been trying to use for my teams when I've had reports, because I think you can often tell people to do less and to say no to things, but if you tell them, just say yes more slowly, you get the same result, but they feel like they are in control, it's kind of a way for them to take a step back.

And I don't just double check the calendar before they say, oh yeah, I've got time between those four flights and four conferences that I still have to write talks for to do that one user group that you're asking about. But yeah, it's super important stuff.

Matthew Revell: One thing I was interested in was that Cisco is, it's a tech company, but it's a big, and by comparison to an older company, have you had to do much internal advocacy on behalf of your team?

Matt DeNapoli: That's probably for the first few years was probably 75% of our job. And still, it's not as bad as it used to be, but still, there were a number of conversations that I had where they would go, well, what's DevNet? I'm like, how do you not know yet? One of the big things that we did was we focused on, Cisco has a very large annual, actually a couple of very large annual conferences, and we kind of made our presence known at the first one that we did in May of 2014 was actually the first one that we did. And we weren't sure, we had no idea if people were going to show up.

We didn't really, we'd kind of done a little bit of our homework about that classic audience I was talking about, but we didn't know if this was actually going to stick because you talk to a lot of network engineers, they go, I didn't learn to code for a reason, and now you're telling me I have to. And it was, I remember I got chill down my spine when I came up the escalator at Moscone Centre in San Francisco and shoulder to shoulder packed people were lining up for our learning labs. People were lining up for our talks. And we've had that same kind of excitement ever since at all of our events, even in our virtual events. And so it's been really cool to see that our idea was validated in that space.