Human Skills 025: Improving Processes as an Engineer
with Loren Verheyden
Loren Verheyden is a long time engineer who started getting involved in process improvements, and eventually became a manager after realizing that most of her learning focus was on people and processes.
In our conversation, we talked about a number of parts of that journey. We talked about planning, ways to improve communication and shift updates from push to pull... but the biggest theme that emerged was this focus on process. How broken processes shows up for an engineer, how to get changes unstuck and moving through an organization, and then as a manager how to empower your engineers to do the same.
What is an example of a process change you tried to make while still an engineering IC?
We always had a problem on my team of too many tickets in the code review column. And so I started debugging, like, why is that? And we would talk about it in retros over and over and not ever try to figure out the root, which was: why aren't people reviewing other people's code.
And it turns out there were some, like we weren't given enough context, like all these things that you see now about what is a good PR, right? Write a good description, review the PR yourself as the person who's putting up the PR review it yourself, add comments, smaller PRs are often better than gigantic ones.
That's something that we had on our team. So people just didn't have the context and couldn't find time to invest two hours to review a certain PR. And so we did a couple of tactics. I don't know if you've seen these, where you kind of prefix as you're going through, you prefix a comment with like nit or education or like edu or suggestion or recommended something like that and that would help the feedback loop as well.
Did it work?
I think so, yeah, to an extent. I mean, that kind of change takes a long time. And teams change as well. So we get new people and they're like, "why are we doing these prefix things?"
And it's like, "well, let me tell you a story..." And then it's a good way to kind of educate them and to what makes a good PR.
The context thing I think was a big one, like have empathy for your teammate and that they haven't been staring at this for as long as you have. And what context do they need that they might not have coming into this PR?
You said this had been stuck in retros for a long time, why had it gotten stuck?
I think probably a similar reason why a lot of things get stuck in retros. I don't know if you've noticed this before, but there are a lot of things that come up over and over and over again. And so that could be people don't feel empowered to go and solve the problem, right?
An engineer might be like, "well, like this is a process thing and that's not my role." And maybe I don't have the experience to debug this problem or figure this out. Maybe I just don't observe it happening. I don't understand the impact. Like "so what we have too much, too many cards in code review. What's the problem? We'll get to it when we get to it."
And then also in retro, I find it hard to balance how deep we dig into a problem and not spending all of our time talking about one retro item. We do want to dig deep that, requires vulnerability and trust and all of these things. And so, I mean, imagine jumping into a retro and then like, "okay, everybody, how do you feel about this thing? And what can we do?" People aren't just off the bat ready to talk about this stuff.
And so I think it's all of those together and us maybe trying something and it not really working out in observing what the impact was of that change and then iterating and iterating and iterating, which is fine.
How did you end up getting the problem unstuck?
I think for us, the big reasons why things would get stuck was because people didn't have the context for some of these PRs and the PRs were so big. I mean, developers didn't even know this stuff was getting worked on sometimes and then would just see the PR come through and they're like, "well, I guess this isn't my repo, put up by my teammate. I don't know what, why, how important, what's the impact of this thing, I'll just put it off.
And so making sure that people have that context is something that we decided to address. And I think I just kept bringing it up, Kevin. I just kept bringing it up and over and over, like these PRs are taking me half a day, like two hours or something, and I need focus time, and then that impacts my other work.
I think I cared a lot about spending time and being meticulous with these PRs. And I think it's hard for me to say like, "Oh I'm gonna just let that sit there for another day." So it impacted me a lot. And I was, I think proactive about going and spending the time... it was like half a day, every day, you know, with these large PRs. And so I just kept bringing it up to my manager and talking about the impact.
How do you think about empowering engineers on your team to make similar changes?
I think it means to give people a lot of space to do whatever it is that needs to be done. And I do still sometimes go back and forth and struggle with this a little bit because how much is too much space, right?
It kind of goes back and forth between the mentoring versus coaching model. I prefer the coaching model and just asking questions and having people arrive at the solutions, like have them figure out what is the root cause of whatever problem that we're talking about and what can we track.
Like, how can we figure out how to solve this problem? And I think that method shows the engineers that they can solve these problems and they can figure this stuff out and they can do it without me. I don't need to be the one to take the action.
Yes, I want people to come to me and talk about problems that they're having. More often than not, it's not even something that I can solve myself, right? That I can figure out myself. And so I try to be like, "okay, so what can we do about this thing?" and see where it goes from there.
And sometimes they take the action and sometimes they don't. And they're like, "can you do this thing? "And I'm like, "yeah, I can do it." And then next time I'll be like, "okay, so you know what to do now, right? Now you can do it."
How do you help your engineers empower each other?
Yeah, that's a great question. I think having a culture of collaboration is automatically going to help here. And if you have certain engineers that already do feel empowered and do feel like they can just go out and solve whatever problems themselves themselves, and they do feel that ownership to fully own the code and our processes and the way our team works, then collaborating with other people, like whenever people come together to solve a problem, it's going to be much better, right?
Like they're going to come up with more ideas and also have more support in whatever changes they propose. And so I'll often say like, "oh, ask so and so for help," Or somebody will come and ask me a question and I'm like, "oh, that's a great question for a team chat." Put it in our team channel, and work with the team on it.
Even stuff like having an engineer set up a meeting to talk about something. When they set up a meeting, they're going to own that meeting. They owned the agenda. They own guiding the conversation, they own figuring out what they want the outcome to be.
And all I have to do is be like, "yeah, set up a meeting." And then the next time they're just going to do it, they don't need to come to me to say whatever, they're just going to be like, "Hey, Loren, I set up this meeting" or not even tell me, just put me as optional on the meeting. I'm like, "Oh, great. You're solving this problem. Awesome."