“Process is often a bad word in engineering teams and carries a lot of negative connotations… 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.

Most developers (ourselves included) want to run for the hills when they hear the words “engineering process.” But it turns out, the biggest danger to your team may not be having enough process.

You don’t have to take our word for it. This week’s guest made a believer out of us and we’re willing to bet she’ll make a believer out of you too. 

Julianna Lamb, co-founder and CTO of Stytch, understands that engineering processes can be a sensitive subject for developers. But she argues that the right amount of process can actually boost your team's velocity and empower them to take ownership. Julianna shares insights on how to right-size processes for teams, implement effective project life cycles, and address friction points to ensure smooth workflows.

Show Notes

Transcript 

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, 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, that caught my attention recently that you've, 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, we'll give a link to that, talk in the show notes. 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 in fear 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, and doesn't really sort of like, end up helping the team or people don't understand like 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 like finding what works for you. But I think, we often don't spend enough time kind of like. 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 hoping I can, I can maybe change that a little bit and tell you why, process can

Ben Lloyd Pearson: 2:01

Yeah. Well, as someone who's a big fan of documentation, I've, I've long been used to being really like caring very deeply about something that no developers want to spend time on. Uh, so that, that's, that's great. So, so let's maybe try to help break down some of that fear around this concept of process, because, you know, I have been in positions in the past where I have to help engineering organizations with process and, you know, I have felt much of that resistance that, that I think comes along with it. But, you know, from my experience, like when you get it right, it's like you're sort of, 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, like on their own, I think often. So let's talk about like how you right size processes for teams. Like what is, what is the way that you go about evaluating how much, like whether a team needs more or less process, for example?

Julianna Lamb: 2:58

Yeah, so I'll start with a case where, teams need less process, so I think that's Often a more common case. and I think the way that this ends up happening is like things just evolve over time and you just keep kind of like layering on additional processes. You try new things and you just sort of never re evaluate 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 at 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, you know, 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 that there's too much, but that the reason behind the process is, is not clear to people or people don't really see the value in it. So maybe it's, 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 sort of like understanding the value of what they're doing. I think on the flip side, uh, in terms of Not having enough process. Often what that will look like is, people having to spend a bunch of time kind of on, wrangling different stakeholders. Uh, maybe if you have a cross team dependency, you have to wait weeks until like that team frees up or something like that. And you're just, you feel really out of sort of like lockstep with, you're sort of like peer engineering teams that probably like signals that, you know, maybe. you're not being sort of like as thorough in the like planning process at the beginning of the quarter or whatever time period you're planning for, not identifying those dependencies in a way that like lets you kind of get in sync with others. So you can really reduce that sort of like cross team, coordination. I think if you're having to spend like 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 like a careful balance of like, we use a quarterly timeframe, which I think is, is fairly common. And I think we want to get like directionally correct for the quarter. But if we a hundred percent predict what we did in a given quarter, like that probably means that we spent too much time on planning. And if we get you know, 10 percent right, 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 like be able to reduce coordination costs, but we also don't want to like cause a bunch of thrash if we don't do enough planning or spend so much time on planning that, uh, we get it perfectly right. Also, we probably weren't adapting to new things as they were coming in. Cause 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.

Ben Lloyd Pearson: 6:51

Yeah, awesome. That's a ton of wonderful insight. And one thing that really stuck out to me, you know, I hear a lot of like, right sizing things for the inputs and outputs the engineering organization has, because we frequently hear that Very common source of frustration with developers, are things that are viewed as like outside of their control. So that could be like, you know, your product design inputs, not being complete enough for what the engineering team needs, like just as one example. but then there's also a lot of processes like on the backend and engineers, uh, responsibilities. And like, if you're not getting those, like that balance, right. Then that typically creates a lot of frustration within the developers life, So let's, let's talk a little bit then about, you know, how you apply this to your role at Stitch. you're a CTO there. So first of all, like how big of a team are you overseeing right now?

Julianna Lamb: 7:46

Yeah. So Stitch as a whole is, around 70 people. the, engineering product and design teams are around 35 people, and majority of those are, are on engineering as well. And so I, I definitely spend a good chunk of my time kind of focused on like the engineering org as a whole, in addition to kind of like the EPD teams that I oversee, in its

Ben Lloyd Pearson: 8:08

Yeah. And is this a, like a mostly remote team or is it hybrid? Do you have an office?

Julianna Lamb: 8:13

Yeah, we are hybrid. So yeah, I'm in our office in San Francisco today. we also have a small office in New York and then we have people spread out throughout the United States. So we're, we're fairly limited on time zones, but then hybrid, within sort of, yeah, the U. S.

Ben Lloyd Pearson: 8:28

Awesome. So, I understand that you have a, a, a way of coming up with a life cycle for every project. walk us through, like with this team that you just described, like what's, what's the typical life cycle, uh, within your engineering organization?

Julianna Lamb: 8:42

Yeah. So what we've tried to do is basically define some sort of like interfaces that are standardized across the EPD team, uh, and then give teams and individual projects, flexibility on kind of, like, how they want to adhere to that interface. Um, so the, like, week to week planning, is very much, up to the individuals on a project. Um, week to week planning is very much up to the team. And then at the quarterly level, uh, we try and be really consistent across EPD. Uh, and then there's some things on an ongoing basis that, that we also try and keep consistent. and the reason for that is to be able to, uh, make sure that we're getting ahead of like those cross team dependencies, that people have enough context on what other teams are working on, status of projects, that teams external to engineering have the context they need, whether that's like our sales team, our developer success team, et cetera. so we try and be really consistent at that level, but then give people that ownership of figuring out, okay, how do we want to run this project? the other thing that we do, I think, part of this is because of the sort of like hybrid nature of our team. We started the company in 2020, so we started fully remote and then moved to hybrid once, we could be back in an office. we're pretty doc heavy and spend a lot of time on sort of like upfront, figuring out what we're building and then try and be a lot more kind of like lightweight on the process side once you get into implementation. So we think if we are all aligned on what the goals are for our project and, sort of like the major technical decisions, the rest will, like, easily work itself out. as things come up, if you're aligned on kind of, like, the overall direction, there might be some questions or, like, some decisions you have to make, but overall, you're able to kind of just, like, focus on execution once a project gets going. so what that looks like is we We'll spend time on, what we call one pagers during quarterly planning. A one pager is basically to say, okay, t shirt size this project, what is the overall kind of like motivation for this, why are we thinking about building this. what are maybe some potential solutions, just so we have enough to say, okay, is the, scope of this project, uh, for the impact that it could have worthwhile to try and bring it into this quarter? If we do prioritize it, what does that mean in terms of what the team's, quarter as a whole looks like? How much time is it gonna take? That sort of thing. Once we decide what we're going to work on for a given quarter, we kind of do this, stack ranking of projects, and we draw what we call a cut line. So we say, okay, here's like the top, ten projects this team could work on. We think we're going to get through the top eight of them. but in case we have more time, here are the next two that we want to be thinking about. Then what we do is we do what we call tiling. We basically have, Google Sheets for each of the teams with everyone on that team listed out and we kind of like Week by week, roughly estimate what people are going to be working on. This is super helpful when there are those cross team dependencies, so maybe project that our web team is working on needs infrastructure support. For example, kind of knowing like when in the quarter it's going to be tackled. It's meant to be pretty low fidelity, but give kind of like directional estimates. So we've done that, we're like ready to kick off a project. We have that one pager. what we'll do is, expand that a little bit into what we call a project brief, uh, and have a project kickoff meeting. It's really focused on just, like, making sure everyone's aligned on kind of, like, what we're doing here, any, like, limitations we might have, any sort of, like, timeline constraints. what are the problems we're trying to solve for our customers? and then from there we go and sort of flesh out if there's the need for a PRD. If this is a more like customer facing product, product team will work on, on fleshing out that PRD. And from there, we'll go and write the tech spec for a more sort of like engineering driven project. We might skip the PRD phase and just go from that project brief to the tech spec. So it's kind of like how we set up projects and again, spend a lot of time. Like these are quite a few docs, like this is fairly involved. And I think that's designed intentionally so that once you get going, once you have that text back and you have sign off, you're off to the races, you figure out, how do I want to break this down, do I want to do stand ups, synchronously, asynchronously, nothing at all, what is, what does that look like, uh, people have a ton of freedom there.

Ben Lloyd Pearson: 12:57

It's fascinating because it sounds like you have like lots of like habits and rituals that are sort of ingrained into your culture that. So, you know, the feedback or the, what I'm sensing is there's a really tight connection between your engineering team and your product team would like, would you say that that's pretty accurate?

Julianna Lamb: 13:15

Yeah, that's definitely the case, and I think, as a DevTools company, like, that is, uh, Easier in some ways, but also I think really critical in other ways, because we're building for engineers, our engineers are going to have some of the best ideas about what we code and should Tell us, if this problem sounds familiar to you. You want to use engineering metrics to improve your work, but every time you try. You realize there's a gap between the metrics world and your team's reality. And even with all the frameworks that already exist, is there enough context? Text to make an informed decision about what metrics to focus on. That's why LinearB is teaming up with refactoring. Together, we're creating. A comprehensive industry report about how engineering teams use data. And metrics to improve their practices. But we need your help. launching a community survey to collect real world stories that will help us. Us build a practical playbook for tech leaders everywhere. The best stories. We'll be quoted and published with the final survey results. To share your story. And get a chance to help engineering leaders everywhere. Visit refactoring.fm. or head to the link in the show notes.

Ben Lloyd Pearson: 14:24

with process, There's always going to be friction in some form or another. So when, when your team is starting to experience friction, you know, between all of these different like processes and ways that you have of doing things, what's your method for like uncovering where that friction is and resolving it?

Julianna Lamb: 14:44

I think, digging into kind of the problems that you're seeing and just like often talking to people is like the best way to kind of uncover. Where there's challenges. I think sometimes, someone will flag something for me and be like, Hey, this is like taking us a really long time to like get alignment on this or something like that, other cases, it'll be like, me just kind of like observing patterns of Hey, we're having to like. Mid quarter, re do the Infrateam roadmap because we've uncovered this dependency or whatever it might be. try and kind of like get a sense of okay, maybe there's something here and, you know, it doesn't always mean that there is something, but maybe one project like had a small hiccup and it's actually not a widespread thing type of issue. other times it's okay, I start digging in, I start talking to people and people are like, Yeah, it's like really hard, to get feedback from, certain stakeholders. This is something we went through recently. I'm spending a bunch of time like waiting for sign off or waiting for feedback. takes a few days, uh, to get that turned over. so that was a recent sort of like thread that I was, I was pulling on. and I think what we uncovered is that, managers, including our product team, were just like locked up in meetings. basically all day, every day, and so they had like, no downtime to like, review a spec, or like, respond to like, Slack threads, or whatever it might be. and so we ended up doing this thing a few weeks ago, where uh, we basically did a calendar reset, told everyone to cancel all their meetings, and then rebuild their calendar. and I think, This wasn't meant to, like, change too much of, the day to day of, IC engineers. I think we've been pretty good about being pretty, meeting light in that, those cases, but managers and product had just, like, so many meetings, so many one on ones, all of these, siloed conversations that were happening. So, like, how can we cut down on those silos? How can we push more communication async so that we can make quicker decisions, uh, and more efficiently make those decisions? Favor, like, ad hoc meetings, to get alignment on things versus, Scheduled recurring meetings and that's been really helpful. It's been about a month of this so far So we're still kind of like feeling it out and figuring out what like rebuilding calendars look like but I thought that was like a really helpful kind of Hey, there's something here where like people are not getting the feedback that they need in a timely manner and digging in and kind of Like trying to figure out. Okay. What is the root cause what could we do and do something drastic too? because I think in the case of meetings like it's so easy to just like You have a meeting, you've always had a meeting. You're like, this seems like a fine thing. I don't know. I think I get value from it. And really forcing you to like, take a step back and be like, okay, is my life better, different, worse, without this meeting? Do we need to bring it back? Has been super helpful.

Ben Lloyd Pearson: 17:30

so when, when you're thinking about Adding like a new process into a team or to, to change an existing process. what's your sort of strategy for rolling that out with the team to make sure that, you know, in particular that you have buy in from the people that will be impacted by it.

Julianna Lamb: 17:47

Yeah. I think starting by kind of like figuring out what the process is by trying to work as like collaboratively with the team as possible, like getting as much feedback early on of what's working and what's not working. What are the challenges you're facing. I think that can be really helpful to make sure that, you're designing a process that, like, is going to work and solve the problem that you need, but also people feeling like they have a say in that. we, will sometimes solicit ideas from, the engineering team as a whole. Upfront, sometimes it'll be, like, digging in, in, like, one on one conversations or team meetings to figure out what are some of the challenges. And kind of like using that to figure out, okay, what are we doing? And what is the impact supposed to be? Communicating that out, being really thorough, uh, in terms of explaining the why behind what we're doing. So we just did this for this like new meeting sort of process. we did probably, it's probably like a. three to four page doc, basically explaining like the goals of what we're trying to do, like how to think about different scenarios, how to kind of like test this out. and then we also sort of like set a timeframe of a month where we were like, okay, let's like try this for a month and then let's like get feedback and check in. And like, you don't have to keep doing this forever if it doesn't work, right? Like we want to hear your feedback. And so kind of like finding those opportunities to make sure that people know, That this is something that's supposed to help them, how it's supposed to help them, or in some cases, maybe it doesn't directly impact them, but it's supposed to help a bunch of other teams, supposed to help customers, whoever it might be, explain that why and then make sure that you have those opportunities for feedback.

Ben Lloyd Pearson: 19:22

I definitely think developers in particular, they really want to. You know, it's just, uh, and I think part of it is, you know, developers just tend to be like very opinionated for, for whatever reason. There's a, there's a lot of reasons I think that go into that. but yeah, so I think, you know, as long as they're involved in the changes, like there really is a great way to get buy in. you've already shared one example of where blowing up a A process or a group of processes might be effective, like telling everyone to just do a meeting reset and clear their calendars and start over. But how do, how do you weigh changes like that versus something that might be more incremental?

Julianna Lamb: 20:04

Yeah, that's a really good question. I think depending on you know, maybe how overarching the change needs to be. Like, is this something that kind of like everyone needs to be, you know, bought into and thinking about, or is this something that like on a project by project basis, for example, we can try out? I think the meeting one, like part of the goal was to like push more communication to like async collaboration and Slack. And so if everyone's not doing that, it's like. so that kind of needed to be like, okay, this needs to be a reset and this needs to be overarching. there's other things we've done, like rolling out the project brief. We did that about maybe six to nine months ago. and the reason we rolled that out is that we found that. we'd get sort of like to like halfway through a SPAC or something and people would be like unsure like what we were trying to solve for. who are the types of customers? what are their pain points? even if we had a PRD that maybe went through some of that, I think not having kind of like that check in on alignment, was, was causing some kind of like disconnect there. People not quite feeling like they knew like the why behind what they were building. and so we rolled that out kind of gradually. We're like, Hey, try this project brief, if you're working on something and, you feel like you need to get multiple people sort of like aligned on it, it's maybe, a little bit of like a, a bigger, newer thing that we're tackling. It's not like a sort of small incremental feature. and we've kind of like gradually, just sort of adopted doing that. and we've continued to find opportunities where I. We look back in a retro and we're like, Hey, that would have been helpful. And just like hearing that over and over again, we've sort of like, established that as a more sort of expectation where if you're not doing it, that should be the decision versus you shouldn't opt in. You should opt out basically. and so I think that's been one that kind of like, we tested the waters on, we waited to see if it was valuable and like, if people like were drawn to it and that ended up being how things went.

Ben Lloyd Pearson: 21:59

how important in all of this is like standardizing behaviors as well, you know, so if you're asking someone to, to do like a, a more detailed design document, One developer may have a very different approach to it versus another one. And expectations can vary from person to person. So like, how do you go about like just making sure that people have like consistent behaviors around stuff like that?

Julianna Lamb: 22:22

Yeah. So I think it starts from figuring out like when that's necessary versus not necessary. What we've decided is that that is necessary for this sort of quarterly planning process, the spec phase, the PRD phase. we have One other sort of like consistent checkpoint, which is we do Friday updates where people just like talk about what they've been working on, on the project, how things are going, uh, and they post those in, their projects we run in Linear that pipes out to Slack so everyone can see what other teams are working on, helps like engineering just like have a sense of like what other engineering teams are working on and, and whatnot. And it's up to the project lead to kind of like own that, which we felt like was a really important piece of having ownership over kind of like how your project is going and sharing that out and a lot of times people are interested in kind of like the progress, dev success wants to know and like, They can open it up to beta, for example, for, for some customers and whatnot. But then everything else in between, we've said, we actually don't care exactly how you run this, like trying to have sort of like consistency in terms of how engineers break down a project into their linear tickets. how detailed those linear tickets are, like, it matters in that you need to be able to, like, work collaboratively with the other people on the project and work within sort of like how your team operates, but, from my vantage point, I don't really care how you do that, some teams, super detailed and, have more of a sort of formulaic way of doing it. Others are kind of like, let's just break this down, and however makes sense for, you know, the two of us on this project. And, as long as that's working, that's like totally fine. so I think in those cases, we're kind of like, up to you, figure it out. For something like the spec, where we do think there's some important things to be thinking through, we have a pretty detailed template, so that you don't have to like, think of all those things every time you're writing a spec either. you can kind of go through the template, and like, there's stuff about, you know, Are there any, monitoring and alerting things you need to be thinking about? Are there, any sort of, like, customer comms that need to happen? All these little things that it'd be a lot of effort to probably, have to come up with for every single project. standardizing that actually makes that a lot easier.

Ben Lloyd Pearson: 24:32

Awesome. Well, I hope there's been a lot of really valuable information for our audience here in, in how to set up like effective engineering. And products processes. Uh, Julianna, thank you again for coming in and sharing your time with us today. Uh, if people want to follow you or learn more about what you're working on, where's the best place for them to go?

Julianna Lamb: 24:52

I am on Twitter and LinkedIn. my, at is Julianna two N's E LAMB. I wish I'd chosen something shorter, but here we are. It's very long. Julianna Lamb, pretty easy to search. It's a, it's a decently unique name. and then Stitch, S T Y T C H dot com, uh, is where you can learn more about what we're working on.

Ben Lloyd Pearson: 25:13

All right. Well, wonderful. Thanks for listening, everyone. And we'll see you next week.