Made by
Made by
22 March, 2023
In this episode of DevRel Book Club, Adyen’s Amy Mbaegbu shares Sarah Drasner’s ‘Engineering Management for the Rest of Us’.
This jam-packed, easy-to-read book provides a practical guide to engineering management both for first timers and long term managers. In the book, Sarah draws on her experience leading engineering teams at Google, Microsoft, Netlify, and elsewhere to share human focused advice and practical frameworks. In Sarah’s words: “This book provides some organisation for collaborating with networks of people, working together towards a common purpose.”
Join DevRel Book Club presenters Matthew Revell and Ramón Huidobro as they talk about the central themes of the book with Amy: thoughtful leadership, individual and company values, trust and vulnerability, boundaries, transparency, negativity, motivation, career ladders in the field of DevRel and clarity in the workplace. An insightful episode viewing the book from both the eyes of the manager and the ‘managed’.
With thanks to Common Room for sponsoring this episode.
Ramon: Hello, and welcome to another episode of the DevRel Book Club. I’m Ramón, and as always with me is the wonderful Matthew. How are you, Matthew?
Matthew: I’m very well, thank you, Ramón. How are you?
Ramon: I’m very well as well. Thank you. Also a big thank you to our sponsor Common Room for making this episode possible. Very much appreciated.
Matthew: Yes, and if you want to find out more about Common Room, which is a data platform and a kind of an intelligence platform for your community, you can go to common room.io. So, Ramón, what are we covering today?
Ramón: Well, we have the joy of having with us Amy, who will be talking to us about the book ‘Engineering Management For the Rest of Us’ by Sarah Dresner. Super excited to have you. Thank you so much. I’d love to ask you if I may to tell us a little bit about yourself, where you’re working and what kind of stuff you’re doing.
Amy: Thanks. Yes, I’m Amy. I work with Adyen as a developer advocate. I work as an internal developer advocate, so kind of special in that way. Yes, most of my responsibilities are internal facing. So, developer advocacy is traditionally external, working for the developers that use a company’s product. But my team’s responsibilities are targeted within, so it’s more inside. We are looking inward basically.
Matthew: Why this particular book then? ’Engineering Management for the Rest of Us’ by Sarah Dresner is the book we’re covering. Ramón, thank you very much. This is one of those topics that I don’t think we talk about enough in developer relations. How do you go from being an individual contributor to actually running a team? For a lot of people that feels like a natural progression, but actually they’re entirely different jobs. So, why this book?
Amy: Yes, very much so, Matthew. For a lot of people it feels like a natural progression. I am passionate about thoughtful leadership. Passionate about how we can be more intentional with managing experiences, because I understand that engineering management actually defines how people experience a company. How they experience a team. The line is very, very direct. Like how I experience my company is very much linked to how I am managed within my company. So, I’m passionate about having these discussions about how we can be more thoughtful in leading teams and how the skills needed on the path from individual contributors to managers may differ. Of course, DevRel does have a management path. So we start out as practitioners, individual contributors, and there’s also that path to management. We are also engineers. So, yes, it just seemed like a no-brainer. The book was quite helpful.
Ramón: I really appreciate you saying that, Amy. I think it’s that thoughtfulness that not only goes into leadership, but I really noticed how thoughtfully this book was laid out as well. Full context – I have never been a manager myself, but I’ve got to say this book kind of made me think I can do it. Props to Sarah for that. Making me believe in myself is no small feat. But seriously, I think the way it’s laid out, it brings in so much humanity. It’s also a very smooth read as well. It’s well typed out. It’s got great typography. It’s one of those books that you read and it feels like you’re just coasting through it really, really well, but also absorbing so much information.
Matthew: Yes. Do you want to know what I appreciate about it? It’s short. It doesn’t waste a word. So the way that Sarah structured it is, she’ll teach something, then give you a couple of examples, and then that’s the end of the chapter. You know, some books go into a real yarn and they go into a lot of detail to illustrate a very small point. There’s none of that. This is lean and to the point. I think when we were discussing it previously when we were both reading the book, I think you said it was dense, but not in a way that was unpleasantly dense. I kind of think that’s a good way of describing it.
Ramón: Yes. It’s a really packed book. I think, just like you both said, it’s human, right? It’s the thoughtfulness that I really enjoy about it. And I also like how very practical it is? There are tips that you could just pick up immediately. You don’t have to think. You could just pick them up immediately and then implement them into how you manage or how you’re thinking about managing people. I really agree with that. It was a very good read. In fact, I’ve read it twice because I kept going back to it. So it’s really a good book.
I really like what you said, Amy, about it being something actionable. There were so many sections of the book where I was like: ‘Hey, wait a minute, I could start doing this now’. Even as an individual contributor, I guess it kind of makes me understand how to be better managed as well, if that makes sense.
Amy: Yes, absolutely. Absolutely. It does.
Matthew: It’s interesting that you say that it makes you feel like it’s easier for you to be managed. That’s really interesting.
Ramón: Yes. It kind of made me take a look back and think how can I make being managed easier for my manager? That’s what I meant to say. It was cool.
Amy: I kind of like the title, ‘For the Rest of Us’. So, I identify as the ‘rest of us’ in that title. So yes, it’s kind of easier, like you said, Ramón, to take on being managed also. You can see both ways, she covered both perspectives. You could actually see it from the perspective of being a manager or being managed. It’s quite dense, like you said. Packed. Very good.
Matthew: So let’s look at one of the themes that are covered in the book, and let’s start with values. I really like how Sarah sets this out. I’ve been thinking about company values a lot personally, recently. This is probably really obvious to everyone else, but the realisation I got from reading this was that values are a shortcut for scaling a company. The medium through which a company can grow without losing the thing that makes it that company. Sarah gives an example of someone who worked at Rackspace, and back in the Rackspace mantra, I guess their core value was fanatical support. Sarah describes in the book a meeting where people were asking at Rackspace, ‘is this fanatical’?
Honestly, if I’d have been in that meeting a few years ago, I think I’d have felt a bit awkward, because that just sounds a bit too much like cult-like thinking. But then the way that Sarah presents it and demonstrates the practical value of values, I think actually that clicked for me. I was like: ‘oh, okay, yes, I get it’. So I really liked the way that she talks about values. Amy, has that been something that you found useful from the book?
Amy: Absolutely, I did. I think it was an underlying principle or concept throughout the book. I like that she handled it or addressed it first because it kept coming up in conflict management, feedback and one-on-ones. She kept bringing it back to the values and I liked the way she layered it. At a very deeper layer there is the value of an individual like me who is being managed. Then there’s the team values, defining them or making others aware or the team aware of the values held as a team. Then there’s the company values, and then how they all intersect in various spheres. I think it’s very, very, very useful to have that in mind in dealing with humans.
It’s engineering management, but it’s really human management. So I like that it was addressed first before getting into the other concepts that were actually addressed. I have also done a workshop. Sarah talks about values workshops. I have a therapist who made me go through that values workshop some years ago. And Sarah also mentioned how values sometimes evolve. Sometimes they change. You have core values that change or maybe fear of different things. I found that useful actually. Talking to myself and saying, ‘okay, these are the values I hold dear’. Even when dealing with which company I should work for, for instance, my values come into play. Or in dealing with addressing an issue, my values come into play. So definitely I see very useful tips in valuing values.
Ramón: I love that. It kind of reminds me of how you need to essentially sum up this sort of stack of values. I find this something very prevalent in developer relations where a lot of our work revolves around those values, not only internally, but also externally. But going back to management, Amy, one part that really stood out to us was the issue of trust and vulnerability. I’ve been a little bit nervous about, for example, the things that I can do to do a good job and do well by the team that I would potentially manage. One of those is trust and vulnerability, which I think could go even into transparency and picking the right layers for that. I’d love to know how this has impacted you and how you look at your work endeavour?
Amy: With developer work, I think trust is not something you can do away with. You have to have developers trust you. First of all, they have to have some kind of confidence in you to be able to really manage dev experiences. I think trust also plays a very important role in making people grow. So there is confidence. When there’s trust, there’s an atmosphere where people are able to show their true selves. They can be authentic in any environment. Then they can see ways of how they can grow. They can easily pick up ideas on how to grow.
I think trust plays a very huge role in DevRel. Even internally, I’ve seen how you have to build trust with developers to have them say, ‘okay, we will gain some confidence in this initiative’. Usually it’s trying to help them see the ‘why’, trying to help them see why we are picking up an initiative and why we should do that. They have to have some trust in you to believe that this is exactly what we should be doing and this is the direction we are going in. And it also relates to vulnerability within the team. I think it’s a very useful, very important point.
Matthew: Vulnerability as a manager is a difficult one, I think, because I wonder if you can be too vulnerable because your job as a manager is to some extent to protect your team from the things that would make it harder for them to be effective in their role. At its most basic. So if you are vulnerable, then that’s good for being a human being and it’s good for building trust. But also, I’ve worked with managers who, frankly, a couple of them overshared at times. That was fine for me. But I know that perhaps at earlier stages in my career, I might have started freaking out about things that they told me. And so I wonder what is the line to tread?
Amy: Yes. I think it differs basically depending on context. Just like everything, it depends. But I would like us to see vulnerability. There are other limitations. If you consider the whole context, some people have to consider things like identity, for instance, being a woman in a majorly male field. Being black or a person of colour. Those identities actually affect how you present yourself in management and how you manage the people around you. So there are other things to think about, but I would like us to see vulnerability. I see vulnerability more in terms of transparency at work. Like ‘this is how we are moving and this is what I think, we should move in this direction’.
And also it being mutual. So, you’re transparent, I’m transparent to you about how I work and transparent to you about the direction I feel we should be going in. So to me, that’s more vulnerability. There’s a personal angle to it where people get very, very comfortable with you and want to be more personal. I think that’s fair. There is some connection. I think you can pick up on when people are more comfortable with you. I think you can use that. She also talks about boundaries, about how you can build boundaries. So I think that might be a point to also pick up and enforce. But I see vulnerability very, very much.
For me, it’s transparency. When I’m working and I feel like it’s moving in the right direction, I say: ‘yes, we are doing well’. When I’m working and I feel like it’s not exactly how we thought it would be, I can be honest and say: ‘okay, I thought this was what was gonna happen, but right now it’s not working this way’. I can’t be transparent enough. So to me, vulnerability is interchangeable with transparency in that way.
Matthew: Is transparency a luxury that we have during the good times? A lot of our friends and colleagues in DevRel have been through layoffs and similar situations recently. As a manager, often you are given privileged information, and as a human being, you want to say: ‘go and apply for jobs now, get your resume polished up’. But as a manager, you have a responsibility to the company and your people. You have a responsibility two ways. I wonder if transparency is something that only really works when everything’s going smoothly.
Amy: I really don’t have an answer to that! I’ve actually been in situations where my manager called me up and said: ‘okay, this is where the company is going and I think you should start looking elsewhere’. It made me build so much confidence and trust in that person as I felt like he had my back. This is exactly the person I want to be in meetings talking about me. I felt almost as if I were being sponsored. So I feel that yes, it’s probably a luxury for good times, transparency. What do you think, Ramón? What would you say?
Ramón: I’ve been caught in a mind loop trying to figure that one out because there’s a degree of responsibility towards your team that I think is also due. As you said Matthew, just to provide a different perspective, you have a responsibility not just to your team, but to the company as well. In that sort of inverse way, if there’s a component in your team that’s causing friction, you also owe it to the work that you’re doing to figure that out. I think transparency with, of course, a lot of discretion, plays an important role. I don’t know if I would say it’s a luxury for the good times. The degree of transparency, sure, there has to be some. I think it falls down to being discreet and respectful as well.
I think that when responsibility is due, then transparency is key in the bad times as well. Amy, there’s a moment where I was like flipping through the book, looking for the chapter on setting boundaries. It was chapter 22. I think that’s such an important component to vulnerability and I think that that’s where the balance comes in. Something that I find a lot in developer relations as well, at a bird’s eye view level, a lot of it involves putting yourself, your personality, or your spirit into your job. Especially for marginalised folks, this becomes a lot trickier to navigate. So I think stating out loud: ‘listen, be vulnerable, but set boundaries’. Protect that core component of you that can afford that vulnerability. I think that balancing is quite critical. So I really appreciate you bringing it up.
Amy: Yes, it is very, very important I think to set boundaries. The truth is, if you don’t do it explicitly, you are doing it implicitly. So boundaries would always be there but they sometimes are not really defined. So if you don’t set boundaries explicitly, they’re already set, they’re already there. You just haven’t labelled it or made people aware of it, basically.
Matthew: I’d encourage people to read the book, but I’d love some practical examples of boundary setting for those that haven’t read the book.
The reason I mention it’s just because it’s something that sounds very, very good in the abstract, but I’d love to think about, as a manager, what sort of boundaries do I need to set? In a lot of teams, alcohol is a big part of the culture. Maybe it’s taking a step back from taking part in that kind of thing because you need to maintain your dignity and your authority. I think there is a weird line. Particularly in tech, everyone’s trying to get along in a friendly way. There are hierarchies, but it’s not like a traditional workplace where you have to lift your cap to the foreman.
A lot of us work in quite flat hierarchies. So as a manager, I’ve seen people fall into the trap of completely erasing the boundaries. Then when it comes time to pull someone up on something, or even get into a disciplinary situation, they’ve lost their credibility and their authority. But at the same time, as a manager, you should be able to sing karaoke at the Christmas party. So I don’t know quite where the boundaries lie that we’re discussing here.
Ramón: So if I may, I think I can think of a couple of examples. One less related to DevRel, is, for example, with community leadership. I have thought of myself as somebody who can take a negative person acting out towards me, but because we have a code of conduct, I need to say outright: ‘I’ll take it’, but, for the community’s sake, I need to say: ‘Hey, not cool’. You know, enforce that code of conduct accordingly. I think as a person, I would have the tendency, on a personal side, to just let it slide. That’s kind of related, but in a more working and developer relation sense, I think when it comes to things like being responsive on messaging, if I message my manager at 10:00 PM their time, I know they’re not gonna get back to me until the morning, which is a good thing.
That’s a boundary? Same goes for taking time off. Same goes for saying, for example: ‘listen, I’m kind of swamped right now. Let me get back to you. I’m really like, sorry about that’. I think that those are the kinds of boundaries. I think it would be overdoing it to say something like ‘be the change you want to see’. But I think setting that example for your team helps you also enable them to set those boundaries that you want them to set, if that makes any sense.
Amy: Yeah. Absolutely. It does. There is also the tendency to be dragged here and dragged there. In DevRel especially, everyone wants your input everywhere. I was thinking of setting boundaries in terms of: ‘okay, this is the direction our team is going’. I think Sarah also mentioned about saying no. ‘Okay, so this is the direction our team is going’. If you are being contracted for another thing, it’s okay to say, ‘we can’t go in that direction right now, so we would have to give you a no’. But on a personal level, it’s also a balancing act to set boundaries.
Ethically especially, it’s not so clear sometimes to people. I was thinking in the sense of setting boundaries professionally, setting boundaries to say: ‘okay, this is what we are doing. This is exactly the pace we are going, this is the direction we are going. If we want to scope out, we’ll have to do that after we are done with what we are doing’. Personally, boundaries also work very well, in the case of someone being maybe too open, giving too much information.
Setting boundaries to say: ‘okay, I understand that we have this connection, but for a work setting can we make it more professional? We don’t have to talk about work all the time, or we have to set some boundaries to say: ‘okay, we can’t take this angle for this meeting’. I feel you can address boundaries in so many ways. If you have someone on your team who is prone to sharing too much, you could have certain meetings also. There could be just meetings where you share and you set that up with that person and say: ‘okay, this time is just for chit chat’.
We can do that, but we have set meetings where we have to focus on work or focus on something that we are doing directly on the job. In that way you are setting a boundary. You are setting your own mental space. This time I have for this, this time I have for that. It sounds very robotic, but I think it helps in helping people to see where you are at this point in time.
Matthew: So, one of the things that you touched on earlier, Ramón, was negativity in a community. I’ve certainly worked in teams where they end up in a bit of a negativity spiral. Someone doesn’t feel appreciated or they don’t feel aligned with the company goals or maybe the company is doing the wrong thing. Misery loves company is the phrase. It’s a cliche, but it’s kind of true. One negative person in a team can end up spreading negativity, and that’s something that Sarah covers in the book. She talks about the ‘undoing effect’. So how can you work towards undoing that negativity? I just think that a really key thing to be aware of as a manager or a potential manager is that the reality experienced by the people in your team is a product of the inputs that they put in.
So if people do start to become negative, then it becomes a cycle of negativity. It’s for you as a manager to acknowledge that it’s happening and then address the causes of it, within your power to do so. Most people aren’t being negative just because they want to ruin everyone’s fun. It’s coming out of something else. So I think it’s a really key part of being a manager to understand where that’s coming from, and then find a way out of it so that the team doesn’t spiral into inability to do anything because everyone’s so demotivated.
Amy: Yes. The motivating angle of being a manager is very key. Team morale is really key. I love the way Sarah addressed it because as managers, I feel it’s key to make sure that your team is happy. She also addressed humour. Teams that laugh together actually are healthier. I think that’s actually really, really true. I found that most of the teams that I have been with, we could laugh easily together. It also creates an environment of psychological safety. You know you can just be easy around people on the team. So I do think it’s important and I think it was a key point also in the book, addressing negativity.
Ramón: This kind of reminds me of how sometimes I notice at times during work when there’s been a little bit of a negativity cliff, let’s call it that? Where you’re almost going to go into that spiral. Reading this book helped me with it, to sort of try and inject a little bit of joy or humanity into the situation. Taking advantage of some of the things that I can provide.
I really like what you said about injecting humour, just occasionally making jokes about how bad my CSS is. I found that that sort of alleviated a lot of it. This book really helped me clarify that, and thank you so much for bringing that up. On that note of motivation, and this is gonna sound silly… It wasn’t until I read this book that it dawned on me that it is possible as a manager to help your team architect what their career paths look like and how you could help them achieve their career ladder. In my spare time, I will mentor folks, but it never occurred to me that, of course, that’s what my manager does with me as well. So, I’m curious, how did that impact how you look at career laddering for developer relations?
Amy: Yes. I think for developer relations in some companies that are just adopting the role, it’s not too clear what the career can look like. I think one of the key points in the book was from the chapter about getting input from people. As a manager, I think Sarah mentioned drawing out a 30, 60-day, 90-day, or even five year plan looking into the future. Sitting down and saying: ‘okay, where do you see you? Where do you think you want to be in five years?’ She also brought that back to values and how that would also say a lot about what that person particularly values.
We have these ladders. We have the juniors, we have seniors, we have staff principals or even the manager role. It’s key, I think, to have a vision of what exactly the people we are managing want. It’s key to know what exactly you want in the next 30 days? It would help inform how you can support that person’s career. It would help inform how you can think of that person in the next five years. How you can draw a path or support or sponsor their career. I think it was key for me that there is that awareness. Let it be known that I care about what your career is going to look like in the team and getting the input from that individual.
One of the things that has just come to mind now is how to deal with situations when team members decide that they no longer want to be on the team. I don’t know if you’ve ever had a situation and how you’ve had to deal with it when you’ve tried all your tactics or your best management skills, but this team member is saying: ‘okay, I don’t think this team is for me’. I don’t know if any of you have had to deal with that as a manager before and how you handled that.
Matthew: I think the only way to handle it is to have an open, honest conversation and find the best transition for everyone involved. Years ago I had a developer advocate in my team who came to me and said: ‘look, there’s a technical writer position in the company. I want to do that. I don’t want to be a developer advocate, I’ve realised, and I want to go and be a technical writer’. So we had a discussion about it and, in that case, I wished the person had come to me sooner because that would’ve helped with planning the transition. But in the end, it worked fine. They went off and they were happy, and we carried on as a team. So, yes, I’ve dealt with that, but I don’t think I’ve got any particular insights other than just creating an atmosphere within your team where people feel safe coming to you to talk about things that traditionally might have been awkward.
I’m sure we’ve all heard stories of people where they expressed some doubt about whether they wanted to be in a role, and the next day all of their accounts are closed down and they’re put on gardening leave, and that’s it. Goodbye. From a very selfish point of view in DevRel, the last thing you want to do is annoy a member of a very small community of people, because we’re all going to work with each other again at some point, or know someone who does. So, as managers in DevRel, I think just be open and honest and let people feel safe coming to you. Now, you can’t control what the broader company policy is, but at least as a manager, you can decide how you deal with it.
Ramón: It makes me think of how important that aspect of trust and vulnerability is. Not just as a manager, but as a team member where, like you said Matthew, you wish they’d come to you sooner because of course that transparency and open-ended conversation could be made smoother. In my opinion, there’s nothing wrong with saying: ‘listen, it’s going to really be horrible not having you with us. What can I do in order to persuade you to stay with us or what can I offer?’ Try to meet a middle ground. If that doesn’t work, that’s totally fine. I think that the transparency of knowing that you can talk to your manager is important and tell them: ‘Hey, I’m thinking of taking on this role’, or, like you said, Matthew, ‘I want to stop being a developer advocate. I wanna go into something else’.
I think being supportive and maybe even asking outright: ‘Hey, listen, if you know anybody who could take your place, that’d be amazing’. Stuff like that. I think it’s that communication aspect, which is such a core skill in everything we do.
Matthew: Yes. One of the key words that’s throughout the entire book is clarity and clarity of purpose. Clarity of communication is key to being a manager.
I know I said earlier that there were some managers who maybe shared more than you’d expect on the topic of vulnerability. But the managers I’ve worked with best have had that clarity of purpose. They’ve been able to communicate and interpret the company’s strategy as it applies to our team and to me as an individual. I think that is great. If you have a culture of clarity, then everything else I think kind of falls into place to an extent. Now, obviously, there’s going to be times when external difficulties prevail, but yes, clarity’s important.
Amy: Yes. Especially in these times. I think clarity is very, very necessary. And also to avoid burnout. You don’t want your team members just doing things just for the sake of it, and it’s not meeting company goals or company general objectives. So I think as an engineering manager, I like that the theme of clarity was across the book. Make sure there is some clarity, that you let your team members know the direction in which you are going, the purpose of the team. I like that. In some way, Sarah kept emphasising the importance of this. Highlighting it maybe on the Wiki, making it the top link there so that you can see where the team is going and where it is headed. This gives some focus to the team. You have a way to make sure that your input is very, very targeted. I think managers, we do have a very key role in defining clarity and also repeating it. Sometimes people veer away from the purpose and you want to bring them back and say: ‘okay, this is where we are. We are going this way and not the other way’. I think it’s very important. Today, much more important. Very important.
Ramón: Totally. This makes me think how I love what you said about defining clarity. A little thought that started cropping up in my mind as I was listening to you two, was overdoing it on clarity to the point of becoming, not condescending per se, but it’s about delivery, it’s about tone. Of saying: ‘I just wanna make sure you understand what you need to do’. How that’s deliberate. That’s why I really like what you said about defining clarity. Super important. I think it’s something that we can… definitely something I can practice more of. Wonderful. Listen, folks, we have barely scratched the surface of this book. Like Matthew said that I said before, this is a dense book. It doesn’t look that thick if, for those listening, I’m holding it up and it’s maybe a centimetre or two thick. It is extremely jam-packed with really good stuff. So I highly recommend checking it out. Amy, is there anything we might have missed from our conversation that you wanted to cover?
Amy: I think we covered the major things. I also liked the key notes. She spoke about prioritising. You have to say: ‘okay, this is what we should prioritise’. Even for yourself. I actually like the cadence of how the layout of the book was. It started from your team, and then it ended at you, because, like you said, Ramón, you have to manage yourself. You have to manage yourself because you are also managing people. So, one keynote, I think I would like to end with this. I liked how she talked about prioritising and how you can go about it. I like the practical tips she gave about giving priority to work that should be done at a particular point.
Matthew: Amy, thank you very much for bringing this book to us. It was a delight to read and lovely to talk to you about it. Where can people find you on the Internet if they want to follow your work?
Amy: I am on Twitter @amystrings. Yes, you can find me on the Internet. I will try to respond, I’m not on social media so much, but definitely you could reach out to me @amystrings on Twitter, if you want to follow what I am doing.
Matthew: Great. Well, thank you so much.
Ramón: This has been absolutely wonderful, Amy. Thank you for this once again. Thank you Matthew, as always, and folks for listening. It’s such a joy to do. Thank you.
Amy: Thank you. Bye.
Ramón: See you next time.
