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

0:00You'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?

0:20Hey, Dev Interrupted listeners, I'm Ben Lloyd Pearson, your host. And today I am extremely happy to be joined by Juliana Lam. She's the co-founder and CTO at Stitch. Juliana, thank you for joining us today. Thanks so much for having me on. 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?

1:06Process 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 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.

1:45Are 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 process can begin. Well, as someone who's 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, you know, I have been in positions in the past where I have to help engineering organizations with process.

2:24And, you know, I have felt much of that resistance 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? Yeah. So start with a case where teams need less process.

3:02I 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. 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.

3:42And 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.

4:18And 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.

5:02So 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 sort of like 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 kind of on wrangling different stakeholders. 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 your 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 happy to spend like a ton of time week after week, like figuring out what you're working on.

6:01That 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 time frame, which is fairly common. And I think we want to get like directionally correct for the quarter. But if we 100 % 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 % 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 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.

6:50Yeah awesome 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 back end and engineers responsibilities. And like if you're not getting those like that balance right, then that typically creates a lot of frustration within the developer's life.

7:33So let's let's talk a little bit then about, you know, how you apply this to your role at Stitch. You're CTO there. So first of all, like how big of a team are you overseeing right now? 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 on engineering as well. And so 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 entirety. And is this like a mostly remote team or is it hybrid? Do you have an office?

8:13Yeah, 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 fairly limited on time zones, but then hybrid within sort of, yeah, the US. Awesome. So I understand that you have 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 the typical life cycle within your engineering organization? Yeah, so what we've tried to do is basically define some sort of like interfaces that are standardized across the EPD team and then give teams and individual projects flexibility on kind of like how they want to adhere to that interface.

8:57So like week to week planning is very much up to the individuals on a project. Week to week planning is very much up to the team. And then at the quarterly level, we try and be really consistent across EPD. And then there's some things on an ongoing basis that we also try and keep consistent. And the reason for that is to be able to 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, the teams external to engineering have the context they need, whether that's like our sales team, our developer success team, et cetera.

9:32So 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 dock 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 a project and sort of like the major technical decisions, the rest will like easily work itself out as things come up.

10:13If 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 will spend time on what we call one pagers during quarterly planning. for one pagers 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 for the impact that it could have worthwhile to try and bring it into this quarter?

10:51We 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 going to 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 10 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.

11:27And 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 infra support, for example, kind of knowing like when in the corner 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 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.

12:09And 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 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 uh that project brief to the tech spec so that'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 tech spec and you have sign off you're off to the races you figure out how do i want to break this down?

12:50Do I want to do stand-ups synchronously, asynchronously? Nothing at all. What does that look like? People have a ton of freedom there. It's fascinating because it sounds like you have lots of habits and rituals that are sort of ingrained into your culture that the feedback or what I'm sensing is there's a really tight connection between your engineering team and your product team. Would you say that that's pretty accurate? Yeah, that's definitely the case. And I think as a dev tools company, that is easier in some ways, but also I think really critical in other ways because we're building for engineers.

13:26Our engineers are going to have some of the best ideas about what we could and should build. 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 to make an informed decision about what metrics to focus on? That's why Linear B 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.

14:02But we need your help. We're launching a community survey to collect real-world stories that will help us build a practical playbook for tech leaders everywhere. The best stories will 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. With process, there's always going to be friction in some form or another. So 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?

14:43I 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 redo the infra team roadmap because we uncovered this dependency or whatever it might be. try and kind of like get a sense of, okay, maybe there's something here.

15:18And, 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 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.

15:58And 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 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 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. through like how can we cut down on those silos?

16:35How can we push more communication async so that we can make quicker decisions 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?

17:08What 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. I'm 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. So when you're thinking about adding like a new process into a team or 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-ins and the people that will be impacted by it?

17:47Yeah, 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, 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 up front. 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, OK, what are we doing and what is the impact supposed to be?

18:28communicating that out being really thorough 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 time frame 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?

19:02Like 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. I definitely think developers in particular, they really want to feel like they're being heard when changes are being implemented. You know, it's just and I think part of it is, you know, developers just tend to be like very opinionated for whatever reason.

19:36There's a lot of reasons I think they 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. And you've already shared one example of where blowing up 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 you weigh changes like that versus something that might be more incremental? 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?

20:16Or 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 like push more communication to like async collaboration and Slack. And so if everyone's not doing that, it's like not going to work. So that kind of needed to be like, OK, this needs to be a reset and this needs to be over our chain. 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 spec or something and people would be like unsure, like what we were trying to solve for.

20:52Who 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 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 ruled that out kind of gradually where we're like, hey, try this project brief. It's 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 bigger, newer thing that we're tackling. and it's not like a sort of small incremental feature.

21:27And we kind of like gradually just sort of adopted doing that. And we've continued to find opportunities where like 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.

21:59How important in all of this is like standardizing behaviors as well you know so if you're asking someone to to do like 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? 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.

22:36We 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. And they post those in their projects we run in linear that pipes up 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 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.

23:10And a lot of times people are interested in kind of like the progress. DevSuccess wants to know when like they can open it up to beta, for example, 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.

23:46Some teams super detailed and have more of a sort of formulated 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?

24:21Are 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. Awesome. Well, I hope there's been a lot of really valuable information for our audience here in how to set up effective engineering and products processes. Juliana, thank you again for coming in and sharing your time with us today. If people want to follow you or learn more about what you're working on, where's the best place for them to go? I am on Twitter and LinkedIn.

24:55My at is Juliana, two ends, E-L-A-M-B. I wish I'd chosen something shorter, but here we are. It's very long. Juliana Lamb, pretty easy to search. It's a uniquely unique name. And then Stitch, S-T-Y-T-C-H.com, that's where you can learn more about what we're working on. All right. Well, wonderful. Thanks for listening, everyone, and we'll see you next week.