In episode 3 of Swimm Upstream, Host Tom Ahi Dror continues his conversation with Patrick Poels in this special part 2 series. Pat discusses making changes in engineering organizations, communicating those changes, and creating a playbook for building autonomous teams.
Hello, and welcome to the second part of our episode with Pat Poels, SVP engineering at Snyk. Let's continue.
So in other cases where you want something to happen, and you want to make a change in an engineering organization, you know, engineers can, you know, resist change like other human beings. What kind of advice would you give an engineering manager that wants to get a team on board with a new procedure or initiative and, you know, meets that kind of pushback?
So, getting people used to change is something that takes time, and you need to be careful and thoughtful about how you do that. So, I think, you know, it's important to think about things like, when you're, when you're communicating change, you need to over-communicate. Because when you say, you think you said something, and you think that you were clear about a thing, well, actually, not everybody was there in that moment. And not everybody was paying attention, and some people were, you know, drinking coffee and surfing Slack and doing other stuff and didn't necessarily hear in the same way that everyone else did. And so often, you have to be able to communicate those changes in a lot of different places and a lot of different times.
But also, I think it's super important to realize that people can digest change at the rate that they can digest. So you have to build it as a muscle, just like you'd build anything else. And so that means, you know if you can overwhelm people. You can give them too many changes in too short a time period. And you can create, you know, a feeling of like, this is too much, and it's overload. So you need to be very cognizant of, like, how often big changes are happening, and we really kind of grok and swallowed and started to execute against one before we hit the team with another one. And I fall, I still fall into that trap, sometimes of - you know, we, we publish too many changes too, too close together.
But I think over communication and kind of, you know, understanding how to build that muscle, then when you get to places where you have a thing that you really need to do, you kind of have a playbook for how you do it, you kind of have a good way to understand how much change the team undergone so far. And, and I think you also, if you built that up as a muscle, and you kind of - you treated it as something that happens periodically, people get used to that. So it's not all that daunting when you have something that even is a big change, when you're used to seeing change happen relatively frequently, in a certain way. And this is a consistent thing that has happened kind of every so often. It's a bit more easy to swallow into reacting.
Okay, so I want to switch to another thing that's very interesting to us. And that is knowledge silos. So this is a natural side effect of growing and maturing software teams, right? You get these knowledge silos. And sometimes, I guess you see them as a good thing, but a lot of times, they become bad, particularly over time. And I wanted to ask, have you been able to break down these silos ever? Is there, are there, were there silos that you intentionally did not want to break?
Yeah, well, it's a - I think this is a balance, too. You know, you want teams to have autonomy. You want them to be able to, you know, kind of understand where they need to go, give them enough high-level context of what the outcomes the business wants, and let them run in the direction that they want to run. But at the same time, that context does need to be there, and you have to make sure people can get that context. But the difficult thing about being autonomous and being your own team - being very kind of self-dependent, is that you can get to a place where, you know, if it's, if you allow it to happen, you get to a place where it's like, it's us against the world. You know, we're all in the foxhole together.
And we're the ones who are doing this thing. And, you know, and it's, it's great for having that strong bond between the team members, but it creates, sometimes challenges with being able to have any sort of communication out or the connection you need whenever you want to do things that are actually across the team. And I've seen this in a variety of different teams over the course of my career in different places. I think there's, you know, there are strategies for how to break that down. But I think it's important not to just let that happen. You know, when you see it - when you see places where that kind of bunker mentality exists in a certain team - there can be some really big challenges with that. And you mentioned that it's about - it's about the information.
If you get to a place where the communication is not happening out and across the different teams, then the things that that team knows are they're going to die with them. It's not a - it's not a great place to be. So I think it's something from a leadership perspective. You have to try and help make sure that you're identifying where there's places where there isn't healthy communication happening across. And then for us, you know, right now as a company that's been growing very quickly - started off as a very, as a lot of small autonomous teams, a few than many, you know, kind of growing over time - we've had to find connective tissue. We had to find ways to be able to do it via structure, via some people who work as architects in the company where they're embedded inside the different structural units, but they are in specific, very, very much connecting with everyone else, and ensuring that that whole picture exists. And it's, you know, it's, there isn’t one answer to it, but I do think it's important to be observing and watching. And when it starts to feel like there is a bunker mentality happening in a team, that you can try to do what you can to, to fix that - address it.
So I was about to ask, it seems to me, and maybe I'm wrong, maybe the intuition is wrong, that rather than trying to go head to head with someone who's in that bunker mentality - changing the structure, while you know, having its own challenges might be easier to change the communication patterns. Would you say that's true?
I would, I would, and I think that's one of those things, you know, completely shaking up structure can be really jarring. But fairly continually tweaking to structure, you know like, let's say, once a year a company looks at their priorities, what are the things they're really trying to get done. Okay, let's examine if we're structured right to do the things you need to do against those priorities and making small changes - changes that even the R&D teams can participate in. Like, I'm a big fan of once you know what kind of changes you want to make, going back to the team and saying, "Alright, this is what it looks like, this is how we're going to be structured for next year, you're doing great in your area, you're killing it, this team that you've been in for two or three years, do you want to stay there? Or do you want to move to a different area and learn something different?"
And you'll find that the big majority of the time, people will elect to stay where they are. They, you know the engineers, they like the rest of their team that like their problem set, they're learning a lot, they're getting some expertise, like their PM, whatever. But you know, some percentage 10-15% are going to say, "I've been doing this for a while. And I'd love to - that thing over there looks really interesting, I'd like to do that." And I think that creates an environment where people are all participating in it together, and it doesn't feel like it's happening to them as much, but they're a part of it. And so, those are some of the ways that you try to help break down those silos that might get created. Because you periodically are saying, we're going to give you an opportunity to do something a bit different anyway, and you'd like to see a little bit of movement. 10-15% of the team moving to different things is super healthy.
Okay, 10-15%. That's a good, good number. Okay. The last issue I wanted to ask you about is about grooming mid-management. And some of your direct reports became softer managers and leaders. And I wanted to ask what companies should focus on - or what managers and similar roles to yours should focus on when grooming developers to become excellent managers. Because you can have an awesome developer that is either really unequipped or, on a personal level, shouldn't be a manager, right? So, and it's not trivial to think about a certain person as a developer and think about how to groom them to be a manager. So how do you - how do you go about doing that?
Well, one thing that's really good to be aware of, and to communicate and talk about, like openly with people who are thinking about these kinds of moves - is that it's not, you know, the thing that made you successful up to where you are today isn't necessarily what's gonna make you successful tomorrow. And I'm definitely living proof that a person who believes that you can just do the exact same thing, and be successful as a manager, like I did really, really badly for a couple of years, when, when I was at Ticketmaster and first made that move from being you know, someone who was coding all the time to someone who was managing people.
I didn't do it well at all. And, you know, I think, just knowledge from the person who's in that role - who’s going to be moving into that role - there are things to learn. And that you're not going to just keep on doing exactly what you were doing, but now you're deciding what people are paid, and that's the only difference there is to manage. Like it's a, there's a lot that goes into it.
And so you want people who have, you know, have a learning, you know, in a growth mindset, they want to, they want to learn how to do it well, they want to kind of, you know, soak up everything they can from people from a mentorship perspective, from a kind of observation perspective. You want people who are willing to do that. And I think from a, from a company perspective, when you're thinking, okay, we've got to our company's growing, we need another leader, another manager in this, this place, and here's a person who's a great engineer who we think could do it, you need to realize that there's an investment you have to make there because that person isn't going to just inherently be observation, you know, know everything they need to know. It's like saying, I know how to drive a car because I rode in a car one time, and I watched somebody else drive the car. You need to know more than that.
And I think that companies can do a lot to help provide mentorship - mentorship opportunities in all kinds of different ways in coaching and learning. One of the examples I give people around the importance of this: when I took the role at Eventbrite, when I had the VP of engineering role, one of the first kind of huge benefits that I got was the CEO at the time, Kevin Hartz, with close connection with Sequoia. And he set me up with a year of once a month meetings with Bill Coughran. Bill was the SVP of engineering at Google for a long time. The whole organization reported up through him on the engineering side. And once a month for an hour, I got to be in a room alone with Bill, you know, at a whiteboard, saying here are things that we're thinking about. Here are our challenges - what do you think? And getting those opinions, you know, and him, forcing me to give my opinions first, which was always awesome. But it was, it was just great to have someone who'd been, you know, as I talked about the kind of the potholes in the road. He'd been over so many of those things. So I could talk to him about things like, what do you think is better at greenfield development or refactoring things.
And we can talk to him like long, deep conversations about the things he learned over the course of his career about that particular subject. And I think that providing opportunities for people to see what it is to work at the next level, what it is to do the next type of leadership, and then letting them ask questions and getting that direct mentorship is one of the ways that companies can do it. But I do think it's - it's important, and I'm just going to have people translate into "Oh, they were a good engineer, so they're going to be a really good engineering manager."
Okay, that's, that's great advice. Also for the VCs who might be listening to us. Great. So Pat, that's all the time we have for today. And thank you very much again for coming on.
Absolutely, Tom. Really enjoyed it.
Thank you, everyone, for tuning in. And I hope you join us for our next episode. To find additional episodes and full transcripts, or if you'd like to be a guest on our show, find us on our community page at Swimm with a double m dot io. Bye for now.