Relicans host, Ali Diamond chats with Director of Developer Experience at Kong, Michael Heap, about transitioning from coding to managing and building a DevRel team up to around 45 people. It wasn’t his technical skills, ability to present, or charming wit that made him successful, but it was the fact that he focused on the question, “why does the business care?”

Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.

Do you have ideas about how we can make our show better? Or would you like to be a guest on an upcoming episode? Reach out to our #devrel team at devrel@newrelic.com. We would LOVE to hear from you with any questions, curiosities, and/or feedback you have in hopes of making this the best show possible!

Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.

Ali Diamond: Hi, everyone. Welcome back to the Polyglot Podcast. This is your host, Ali. You can find me everywhere on the internet @endingwithali. And today, we have a super awesome guest here, Michael Heap. And to start us off, Michael, why don't you introduce yourself to everyone?

Michael Heap: Cheers, Ali. Hi, everyone. I'm Michael Heap. I'm mheap on Twitter, GitHub, just everywhere on the internet. I'm the Director of Developer Experience of a company called Kong. And prior to this, I was at a company called Nexmo, which was acquired by Vonage, where we built up a DevRel team of about 45 people, which was awesome. I'm hoping to do that again at Kong.

Ali: Oh my God, 45 people? Were you doing management at Nexmo?

Michael: I was. I started out as an individual contributor. So for my sins, I used to be a PHP programmer. I joined as a PHP developer advocate then our documentation lead left. And I said, yeah, I know I can do Ruby. I ended up taking on the documentation team, growing that to five or six people, then took on the SDK team, then the design team, then the dashboard teams. By the end of it, I ended up with an org of 25 people reporting to me, with the other 20 being developer education and community.

Ali: Oh my God, wait. That's so many people. How did you manage organizing and managing so many people? What was that breakdown like, especially having an organization of 20 people? How many people were direct reports? How did you make sure that you gave everyone the attention that they needed?

Michael: So at the peak, I think I got to 11 directs, which is too many, definitely too many. And it was a learning journey for me. I've always liked to be very hands-on. And at one point, we had someone leave, and I said, "Oh, don't worry, team, I will take it. I will get the work they were working on finished. And I did but didn't do any of the management things that I should have done.

And that actually had a bigger impact on the team than not doing the individual contributor work. And that's what taught me actually I can't get in the weeds anymore. I was very fortunate. I ended up having five managers reporting to me by the end of it, each with a team of between five and seven people each.

Ali: And you said that you originally started off as a PHP developer advocate. What was that transition like transitioning from coding to managing?

Michael: I've always been...actually, that's a lie. I've not always been interested, but I've been thinking more about business and product over, say, the last ten years or so. I used to be an engineer's engineer where, oh, why aren't we doing this? It's obviously the correct way, technically. And I actually got frustrated in one of my roles when I was in my early 20s because all my ideas weren't being picked up by the business.

And I got really lucky; I got to spend some time with a coach. And she asked me a question that sticks with me to this day. And she just said, "Well, why does the business care?" And that was like a hot knife through butter. And in fact, I gave a talk called “Why Does the Business Care?” at DevRelCon in 2021. And my thinking went 180. Like, okay, it's technically correct, but it's going to make everything take twice as long to do. So that's why we don't want to do it, or the server bills is going to increase, or this just isn't a pain point compared to everything else we're doing.

So when I went from being an IC to a manager at Nexmo, I took that with me. And I started thinking, okay, what's going to have the biggest impact for our customers, the biggest impact for our customer retention? And then as I progressed from manager to senior manager to director, that just became more and more detailed, not just is this going to help improve retention but by how much and how much revenue will that also bring in?

Ali: I really like how you phrased that: why does the business care? When you were transitioning from coding to management, how did you balance that with what your direct reports wanted to do?

Michael: So I was very lucky. A lot of the direct reports thought about our users as well. As a focus in our hiring, the number one thing was always empathy. It didn't matter what else you knew, like, can you be empathetic to yourself, the rest of the team, and our customers? And that really showed with the team that we hired. So we didn't have much trouble convincing them, yes, Python 2 is dead. Let's upgrade to 3.6, so you can use this fancy list comprehension expression. I'm not a Python dev; sorry if I murdered that.

I've worked with developers that will be like, "Well, I want to use all the latest and greatest, shiny things." And we'd have to have the argument, "Well, we've still got large enterprise customers on Python 2.7 that we need to support." Well, let's upgrade to Python 3 because it is end of life. I think that's a good line in the sand to draw. But can we go for 3.4 rather than 3.6? Because that's what is in the Debian long-term stability release. So that's what most people have by default. And that's what the team already felt like.

Ali: I was looking at your Twitter before this. And one of the things that you were tweeting about was priority and setting that as one of your intentions for this year. And I'm super curious to hear how that ties into your managing style and how you're going to make actionable steps towards implementing that.

Michael: Funnily enough, I was on a call just before I joined you on this one where we were talking about priority. And so, at Kong, I manage our docs team. And I asked them all earlier this week, "If you had a magic wand, what would you do this year? Don't worry about cost, the number of people, if it's even technically feasible, just what idea would you want to have?

And I got them all to write them down. We collected all of those ideas, shared the full list with everyone. We said, "All right, you've got five minutes. Go on, make a drink, and then come back and just put a number against all of them, 1-2-3-4, and let's see what the team wants to do." And then we chose the top 10 and worked out, okay, which of these are actually the most valuable?

And that's how we balance what the team wants to do with what will also be best for the business. Because if you've got a team working on things that they're really not interested in, you're not going to have a team for much longer. So you need to balance that engagement with benefit for the business. So that's an example of how we prioritize as a team.

Ali: And what about for you personally?

Michael: This one is a lot tougher. It depends if I'm at work or just in my personal time. I'm a little bit of a magpie in my personal time, like, oh, this looks interesting. Let me just try that out. I still like to scratch that coding itch. And I do a lot of open-source work to get that done. But when I'm prioritizing at work, it is the urgent versus important metrics. So when does this need to be done by, and how important is it?

A lot of our work is opportunistic. So it's very urgent and sometimes important. To give you an example, the Log4j vulnerability in December was all over the place. That's not something that we'd scheduled. And we had a lot of conference talks that we also had to focus on. That became a priority. How can Kong help you mitigate that? And just communicating to customers that we weren't vulnerable. That was super high priority, so we just dropped everything.

Apart from that, we tie everything back to objectives and the key results that we're measuring. So yes, we want to redesign our template slide decks for our talks. But is that going to increase the number of people that we meet when we go to events? Probably not. So let's scrap that. Instead, let's spend that time investigating what the hot topics are in the industry, take a look at the new Kubernetes Gateway API and how we could apply that to our product so that we're compatible with everyone else because that's a better use of our time.

Ali: Yeah, definitely. One of the things you just said I think is super interesting is how you called yourself a magpie and that you are always trying to do different things in your own personal life. And you mentioned committing to open source. So I'm super curious, what are some of the projects that you actively contribute to?

Michael: So I write a lot of GitHub Actions. I tried it out back in 2018 when it was… before they moved to YAML, and it kind of spiraled from there. I write a lot of actually GitHub tooling. So when the default branch changed from master to main, I wrote a CLI that would do it for the whole organization. It would retarget your pull requests, draft releases. It would update the badges in your README to show your build status, all of that kind of thing.

That was probably one of the most popular pieces of open source that I've done. GitHub Actions-wise is everything from enforcing the specific labels that are present on pull requests to stupid actions that will fail a build if you're committing at the weekend because you shouldn't be working at the weekend.

Ali: [chuckles] That's so great. I love that. When you made the CLI that changes from master to main, what was your biggest challenge with that?

Michael: People.

Ali: People? Tell me more.

Michael: So the move from master to main was reasonably controversial, and that was all the feedback that I got. People saying, "Well, why do we need this? That's not the original meaning of the word master," so it was people making it difficult. My Twitter mentions were basically unusable for about three days after it was released, and then it died off.

And it became quite a good conversation like, well, I wish that it would also update my GitHub Actions tree because of my Travis CI tree because I wish it did this, I wish it did that. I think the biggest users were the WG, the browser rendering engine people. They had some requirements they couldn't use until they were fixed. So we had a really good conversation there. But yeah, tech is never the hard part; it's always the people.

Ali: It's never the hard part, but it's always the people. That kind of reminds me of one of the statistics from cybersecurity where it's like, I believe over 80% of cybersecurity mishaps are due to human error and not necessarily technical error. So I just feel like that totally, deeply relates. And kind of on that note, let's jump in more to creating CLI projects. What is your process for coming up with new projects that you want to create?

Michael: I always start with I've got a problem. So a couple of the other CLIs that I've built include a Trello command-line tool for listing go boards, lists, moving things between different states. Actually, one that I use all the time is called Markdown to JIRA. So when I'm thinking about work that we need to do, JIRA is just way too slow for me to go and create a new ticket, add a description. I tend to think very quickly then iterate. So I like to automatically just add in a text file. And I found that I was copying and pasting from this text file to JIRA, this text file to JIRA.

So I built up a little project where it takes markdown lists. Each list is a new ticket. You can use hashtags to add components. And if you add a blank line and then add some more text, that's the description. So I found I could add ten tickets in just a couple of minutes in the CLI, and they all magically appear in JIRA. So I always start with, hey, this thing's annoying me. I wish there was a better way. Let's see if I can automate this. And that shows, like, I've got Markdown to JIRA.

I've got a CLI that shows me all of the GitHub Actions being used in an organization because I had to audit an org, and they didn't want to click through every single repo, a CLI that updates a secret value across all your repos. So instead of going through each repo one by one, again, just point to your user. And if that repo has a secret, whenever you specify, it will update the value. It's generally things that I'm too lazy to do over and over again by hand. That's the common theme.

Ali: Yeah, that makes total sense. So it kind of sounds like you live in your terminal almost, true or false?

Michael: 90% true.

Ali: 90% true. Let's unpack that a little bit. What's the other 10%?

Michael: I did give up using Vim and moved to VS Code.

Ali: Why?

Michael: Extensions.

Ali: Extensions.

Michael: I spent a long time getting my vimrc configured properly and all the right plugins and the language server protocols. And I just tried VS Code, and it just worked. I thought, how many hours could I have saved here? And then things like running projects in Remote Containers that's been a game-changer with a dev container that you can also use with Codespaces. Once I switched over, there was no going back.

Ali: Yeah, I know what you mean. So let's throw out a theoretical hypothetical here. You're teaching someone how to code, and they've got a fresh new laptop. And they're like, "What kind of things should I put on my laptop?" What terminal are you telling them to install? And what extensions are you recommending to them?

Michael: Terminal-wise, it's iTerm2. There are lots of new ones that I like the idea of things like Fig. But I've just used iTerm for so long that that's my go-to. Use Zsh as your shell. Don't go for something like Oh My Zsh as a framework. I like to build the config file myself, so I know exactly what each piece is doing. I think my config file is less than 100 lines, and it does 90% of what the frameworks do.

The best plugin that I've seen recently is alias-tips, which if you run the command and you've got an alias configured for that, it pops up and says, "Hey, don't forget you can type this." So if I'm using Kubernetes and I write Kubectl, apply -f and then the manifest path, it'll say, "Hey, don't forget you can just run K-A-F, and then the path." So that's probably the best plugin that I've seen recently.

Ali: That's awesome.

Michael: Plus, of course, Vim Key Bindings. So you can use J and K to move up and down and things like that.

Ali: Oh yeah, definitely, definitely. It seems like you're all about efficiency, true or false?

Michael: True.

Ali: True. What are some of the things that you've implemented in your life beyond just a really efficient terminal to be more efficient in your day-to-day and in your job, especially with managing people?

Michael: So planning, time is key. For the longest time, I thought I don't have time for planning; let's just dive in on the next thing but actually sitting back and timeboxing. So I use a tool called Sunsama. It pulls in all my different data sources so Jira, GitHub, I used Todoist as my personal to-do list, stored Gmail emails, and then it lets you drag them on to whatever day you want to so that you can kind of plan out a week at a time if you want and put time estimates against them.

So I found I'd put like 12 things to do in a day and then just not get to half of them and feel really bad or not really take into account that I've got six hours of meetings today. So when am I actually going to get any work done? I'd say, "Oh yeah, no, I'll get that done for you." And then I think, oh, actually, I can't. So I find that much more efficient by going slower and thinking about what I want to achieve, when I can achieve it, and being a little bit more realistic.

Ali: Yeah, that makes sense.

Michael: At the same time, I also like to multitask. So we've got a dog, she's awesome. I take her for a really good walk each morning, and that's when all my news catch-up happens. So all my RSS feeds get read whilst I'm walking the dog. I listen to audiobooks, podcasts. That's where I get all my new ideas.

And I've got an app called Just Press Record on my watch. They’ve got it on the Apple Watch, and if there's something that I hear whilst I'm walking, I can tap it and just repeat what I heard, what I was listening to, kind of what timestamp. And then when I get back to my desk, it's there, it's ready to process. So I don't have to go through the entire thing again. When my dog is getting walked, I'm getting to learn things, and I'm ready to go when I get to my desk.

Ali: It seems like you've got a lot on your plate. How do you not get burnt out?

Michael: It helps that I love what I do. It's not that I love programming or anything like that. I'd say 20% of my work is actually doing things, 30% is strategy and planning, but 50% is building a team. I always tell people that my job is not to tell them what to do or how to do it. It is to make sure that the environment is right for them and to get everything else out of the way.

I'm a big fan of hiring people from bootcamps. I hired a couple at Vonage. I haven't had the opportunity at Kong yet, but I'm working on it. And just seeing the progression, whether it's someone fresh out of a bootcamp that is learning how to program, how to write tests, or whether it's a manager that is having difficulty with one of their reports. Like, role-playing talking through okay, you've got to give this feedback. How are you going to do it?

I'm a big fan of Situation-Behavior-Impact, the Lara Hogan choice for giving feedback. But yeah, how I don't burnout is I just love developing people. That is energizing for me, and fortunately, I get to spend a lot of my time doing that.

Ali: Wait, let's turn back to what you just said, Situation-Behavior-Impact. How do you implement that into your management style?

Michael: So when you're given feedback, it has to be very specific. When I first started working with people, I ask them how they'd like to receive feedback. Do they want it in written format so that they can kind of process it in their own time? Do they want it live on the call so you can chat about it? And do they want it immediately after something happens, like in the moment? Or do they want me to save it up for our chat later that week for our one-to-one? And everyone's different. But the Situation-Behavior-Impact is the one constant.

So let's use you as an example. Say, "Hey, Ali, I noticed that when we were in the meeting with the Alliance's team about commercial plugins, every time they said, 'Hey, this can be a multi-million dollar business for us,' you rolled your eyes. Yeah, I don't think it's going to go anywhere either, but we need to encourage the team here," so situation behavior.

And then the impact is "And actually, Chris noticed. He was trying to show where the business could go. And every time you rolled your eyes, I don't know if you noticed, he stuttered a little bit. He noticed what was going on, and that was knocking in his confidence. We need to be lifting him up. Can you help me understand why you think it's a bad idea, or can we work on the strategy for being more encouraging for Chris going forwards?"

So that's a very concrete; this was the situation; this is what you did; this is the impact it had. It's not, “I think you're being a jerk to Chris,” because that's my opinion. I'm not telling you how you behaved. It's just this is what you did, and this is the impact it had. So come to your own conclusions.

Ali: Interesting. As a director now, coming from a manager giving such amazing feedback and being so constructive in developing people, how do you manage all of the things you've got to do and saying no when you need to say no?

Michael: It's hard. I am traditionally a people pleaser and used to overcommit. What happened to turn that around is I realized it was having an impact on the team. People were having to work longer hours. They were getting burned out. And I realized that me trying to help others was actually not me helping others. It was having an impact on the team. So now I'm fairly ruthless when it comes to prioritization.

I get a message from my VP saying, "Hey, we need to do this." I say, "Okay, what do you want me to drop? We've planned the time. Something is got to give. Is it more important than project X or project Y?" "Oh no. It's just someone asked about it this morning." "All right, then we're not going to do it." Everything is a trade-off, and there are only so many hours in the day. And I guess I don't really say no. I still don't like saying no. But saying, "Yes, we can do that, but what do you want to give up?" kind of puts it back on them. So it's not me saying no; it's given them a choice.

Ali: You do the switcheroo?

Michael: I do. It's very effective.

Ali: Very effective. And does anyone ever say like, "Oh yeah. Do this. Drop this"? And are you like [vocalization]?

Michael: It just happened, the Log4j stuff at Christmas.

Ali: Of course.

Michael: That was a yeah, just drop what you're doing and get this out. It's important that customers know that we're not affected. And I think that was the right choice.

Ali: Oh, definitely. Definitely.

Michael: Sometimes, I also drop things that I think are important for things that I think aren't important depending on who's asking for it. Let's say your CTO messages you and says, "Ali, we really need this." You're like, "Um, I don't think we do." But actually, I'm going to go and ask them for a new headcount next week. "Sure, I'll do that, fantastic idea. I'll send it to you when it's done." That's an opportunity where you say, "Actually, it's not that important," but to team myself up for success with the next thing I'm doing, it makes sense to make that person happy.

Ali: Yeah, that makes sense. And as we're coming to a close to our conversation and talking about making people happy, do you have any advice? I specifically love to ask for tangible, actionable advice. Do you have any advice from your career that you would love to share with people, that people can act on as soon as they're done listening to this conversation?

Michael: Whatever you're thinking, it will still be there tomorrow. Don't try and fit it in; now I think if I just work an extra hour tonight or anything like that. I have a high cutoff, 7:00 p.m. I work from the UK for a West Coast company. So in the morning, I walk my dog, and then I may start a little bit later. But come 7:00 o'clock in the evening, I'm done. I go I put my daughter to bed. It'll still be there tomorrow. That will be the advice I will give that it will still be there tomorrow.

Ali: Yeah, very poignant. As we come to the close to this conversation, where can people find you on the internet? Where do you want people to find you? Do you have anything you want to share with the world?

Michael: So you can find me on Twitter; I'm @mheap. I don't tweet particularly much, but when I do, you should be following to see it. I tend to blog a lot at michaelheap.com. Today I learned style so how to do crazy JSON processing with jq, how to get all the changes in a pull request with the GitHub API, how to install a new version of Vim on CentOS 5, just one-shot things that were… that I heard at some point in time. In fact, the most popular post I've got is installing a wireless Xbox controller receiver on Windows 7, number one post. I write about a ton of tech things, but that is the thing that most people search for.

Ali: Well, that's great. Thank you so much for joining us today. I had a great time talking with you. For everyone listening, thank you so much for spending your time with us. I hope, and we hope that you got something out of this conversation. And again, I'm Ali. You can find me on the internet everywhere @endingwithali. I'm mostly on Twitter, though. So thank you, all, so much. And we'll see you in the next episode.

Michael: Cheers. Bye.

Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.