From Fear to Function: Rethinking Engineering Processes | Stytch’s Julianna Lamb

**Ben Lloyd Pearson** (0:00)
You've already shared one example of where blowing up a process or a group of processes might be effective, but how do you weigh changes like that versus something that might be more incremental? Hey, Dev Interrupted listeners. I'm Ben Lloyd Pearson, your host. And today, I am extremely happy to be joined by Julianna Lamb. She's the co-founder and CTO at Stytch. Julianna, thank you for joining us today.

**Julianna Lamb** (0:35)
Thanks so much for having me on.

**Ben Lloyd Pearson** (0:37)
You know, the big thing that caught my attention recently that you've been working on came from this talk that you gave at Lead Dev recently about various processes within engineering teams. And we'll give a link to that talk in the show notes. But I really want to get your thoughts around how to build processes for engineering teams. But before I get into that, I really want to ask, when you bring up this concept of engineering process, do developers ever just run away and jeer from you?

**Julianna Lamb** (1:06)
Process is often a bad word in engineering teams and carries a lot of negative connotations, I think. And I think part of the reason for that is people really often do process wrong in a way that is hurtful, slows down velocity and doesn't really end up helping the team, or people don't understand why they're doing the processes that they're doing. But I also think sometimes people are suffering from not enough process and it can be good, and really comes down to finding what works for you. But I think we often don't spend enough time digging into our processes, figuring out on an ongoing basis, are these working for the team? Are these helping engineers feel like a sense of ownership over the work that they're doing and all of these things? And so, yeah, definitely not most people's favorite topic as a result. So hopefully, I can maybe change that a little bit and tell you why the process can be good.

**Ben Lloyd Pearson** (2:01)
Well, as someone who is a big fan of documentation, I've long been used to being really caring very deeply about something that no developers want to spend time on. So that's great.
So let's maybe try to help break down some of that fear around this concept of process. Because I have been in positions in the past where I have to help engineering organizations with process. And I have felt much of that resistance that I think comes along with it. But from my experience, when you get it right, it's less about forcing developers to do something just because it has to be done, and more about unblocking them and giving them the best path forward to be successful on their own, I think, often. So let's talk about how you right size processes for teams. What is the way that you go about evaluating whether a team needs more or less process, for example?

**Julianna Lamb** (2:58)
Yeah. So start with a case where teams need less process. I think that's often a more common case. And I think the way that this ends up happening is things just evolve over time. I mean, you just keep kind of like layering on additional processes. You try new things and you just sort of never reevaluate whether like all of these different processes and the ways that you're sort of going about doing them are the best way to do it. And I think what ends up happening then is people get really focused on kind of like, you know, the metrics related to processes, like really obsessing over kind of the process and celebrating the success of adhering to the process versus celebrating the success of like the work that you're doing, the impact you're having on customers. And so I think whenever a team feels like so rotated on process that those are the things that are coming up, you know, in like performance reviews and like really commonly sort of like talked about in terms of whether a team is performing is like how good are they adhering to the process, right? Like at the end of the day, what you're trying to do is you're trying to ship software. And so process can be helpful in doing so, but can also kind of like get to the state where you're just like so bogged down.
I think another common symptom is just like having to go through so many steps to get something across the finish line, you know, get sign off from so many different teams, have to like produce all of these different artifacts. And like, you're just like wrangling these processes and spending time as an engineer, like significant time week over week on sort of like planning and status updates and that sort of thing. Like your time as an engineer should be going largely to like writing code, designing solutions, that type of thing, right? Updating your like linear tickets is helpful to a degree, but if you're spending hours every week kind of like on that piece, that's probably an inefficient use of time. I think another symptom is that people just like really complain about the process. That might mean that not necessarily there's too much, but that the reason behind the process is not clear to people or people don't really see the value in it. So maybe it's just the wrong process versus too much in that case, but that just signifies that there's some sort of mismatch there of people not really understanding the value of what they're doing. I think on the flip side, in terms of not having enough process, often what that will look like is people having to spend a bunch of time on wrangling different stakeholders. Maybe if you have a cross-team dependency, you have to wait weeks until that team freeze up or something like that, and you feel really out of lockstep with your peer engineering teams. That probably signals that maybe you're not being as thorough in the planning process at the beginning of the quarter or whatever time period you're planning for, not identifying those dependencies in a way that lets you get in sync with others, so you can really reduce that cross-team coordination. I think if you're having to spend a ton of time week after week, like figuring out what you're working on, that also probably means that you didn't plan out quite far enough in advance. I think there's a careful balance of like, we use a quarterly timeframe, which is fairly common and I think we want to get directionally correct for the quarter. But if we 100 percent predict what we did in a given quarter, that probably means that we spent too much time on planning. If we get 10 percent rate, that also probably means we didn't spend enough time on planning because finding that balance of like, okay, we want to invest some time to be able to reduce coordination cost, but we also don't want to cause a bunch of thrash if we don't do enough planning or spend so much time on planning, that we get it perfectly right. Also, we probably weren't adapting to new things as they were coming in, because I don't think, especially at a startup, you can perfectly say, okay, this is what we're going to do for the entire quarter.