Brian Lawler (Iterable)
Today we welcome Brian Lawler, who is a Principal Engineer at Iterable! Brian has a load of experience with software architecture, having worked in the space for over 25 years, at a number of different companies and amassing a large amount of wisdom and expertise in the process. The rise of Iterable stands as a testament to the great ethos and community at the company and Brian generously shares a lot of insider info on how the teams and processes work. We get to talk about his specific role as it stands, his first period of employment at Iterable, and his thoughts on leadership style and problem-solving. Brian underlines the way they approach meetings and the feedback that follows before we hear how he divides his time as Principal Engineer. The conversation also covers how to keep a multidisciplinary organization in alignment, processes for flagging bugs, and the inextricable importance of mentorship in a company such as this. So for all this great stuff and much more from a seasoned pro, be sure to join us!
Links
Listen#
Transcript#
Note: This transcript was generated using automated transcription and may contain errors.
David: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We’re interested in the areas of work that set staff plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, program, providing engineering perspective to the org, et cetera. My name is David Noel Romos and I’m joined by my co host, Alex Kessinger. We’re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today’s guest.
Alex: Yeah, Brian Lawler is a software architect at Iterable. He’s been making Software for over 25 years. I’m excited for you all to hear this conversation with Brian. It sounds like he set up a great community at Iterable to foster the future of architecture. Let’s jump right in.
David: All right, well, Brian, thank you so much for taking the time to join us today. I’m really looking forward to chatting with you.
Brian: It’s my pleasure.
David: If we could start by just having you tell us who you are, what your background is, where you work now.
Brian: Well, my name is Brian Lawler and I have been working in the industry now for almost 30 years. Actually. I started in 1993 back in Chicago and I wasn’t actually an engineer to start with. I was. I actually started with Anderson Consulting, which is now Accenture. And so I was kind of a member of the Accenture army for a few years. So I wasn’t really an engineer per se. I was a consultant. Right. So they dress you up and trot you out to clients and then you do all that. The career path there was basically after four years, they. They decided that everybody was supposed to sort of progress into management at that point. So you had two years to sort of code for a while. You had two years to manage people who were coding for a while, doing small teams and then you progressed in the manager role. I got to about four years in and I was like, well, I’m not. I’m not done coding yet. I thought I was just starting to get good at it, actually. So my background, actually my degree is in electrical engineering. So it was close to computer science, but it wasn’t actually computer science. So I was just getting good at it and I wanted to stick with it. So I left Anderson and joined BEA Systems, which again, as a consultant, though not as an engineer yet. And it was more consulting, but it was more. It was a software company. Right. It wasn’t a systems integration company. And then there’s a whole bunch of time in between there that I won’t bore you with. But Basically there was a dot com happened in 99 and I quit BEA and joined a startup with X BEA people and moved out to San Francisco and stayed there for 20 years and now I live in Colorado. So I’m working at a place called Interbowl right now. Interbool is a. It’s a cross channel marketing company. We sell our product to marketers. Marketers are able to run marketing campaigns that span all the different channels. So email, sms, push in, app push, web, everything. So that’s where I’m at right now.
Alex: Awesome. And how would you sort of describe your role at Iterable?
Brian: At the moment my title is principal engineer. The interable story is kind of funny because I actually joined iterable in 2016 and then I left in 2018 and then I came back last year. So I’ve been there a year again now. When I came back, I came back on as a principal engineer. I wanted that the architecture role first. When I came in, the company had 30 people and I had 35 people when I joined and it was just basically a bunch of engineers in a huddle just trying to get stuff done and that was fine. But there were just things that I wasn’t really able to do that I wanted to do career wise. Right. So I wanted to. I wanted to make sure that was doing architectural things which. And we can get into what that means to me. But my role at Interval now is that. Right. Basically when I came back the company had grown so much that they determined that they really needed to have people that were not necessarily hands on the keyboard as much as they were making sure that the right things were happening. Higher level. Right. So that’s the role that I have right now in really broad strokes. Cool.
Alex: What do you think the main difference is between a person whose hands on keyboard and the role that you want to tackle?
Brian: The interesting thing about problems that come up in applications are oftentimes it’s a bug and you’re one pull request away from a solution. A lot of times though, it’s not just a pull request. There’s a lot more at play. There are larger issues at hand and you can’t just go in and change a few lines of code that are wrong and hope that everything works right. You have to be thinking larger about the implications of doing things and what your scaling strategy is and stuff like that. So the difference is. And it’s hard to be that same person and do both Right. It’s hard to be thinking about the big picture and actually slinging code at the same time. You can do it, and early in the startup, everybody has to do it. But Itable now is pushing 400 people and the engineering. Org is getting really big. We can’t all just sort of be hoping that the right things happen architecturally. Right. So you need to have somebody who’s really trying to work at a higher level and make sure that stuff that is being considered is taking other things into account. And, you know, I do occasionally do some code and almost invariably it ends up being more complicated than we wanted it to be and that takes longer and it’s time consuming as things get more complex. So you can’t basically get to a size where you can’t focus on both.
David: Yeah.
Brian: There comes a time where you have to be like, well, the best things for me, the best projects for me as an architect or as a principle, is when I can go to somebody and say, well, here’s these requirements. I don’t really care how you do it, but I need you to do these three things. There’s a couple of interface points, whatever. Their clouds are sort of cooling and planets are cooling and things are forming out there in the ether. I need you to be aware that those things are going to happen and we need to hook into those. And that’s the kind of thing that you really. You need to have somebody worried about that. Cool.
Alex: Are there other principal engineers at iterable besides 12?
Brian: Yeah, there’s. There’s one.
Alex: Do you feel like you share a set of expectations for what your role is in the company?
Brian: It’s funny because we were kind of the first two that have had the title technically. I mean, it was funny when I left. It was all sort of happening by Platoon. Right. It was sort of architecture by. It was just everybody was sort of contributing and everybody was. It was small enough and everybody was smart enough that the right things were happening. Now that I’m. And then I left and they grew a ton and I came back. I would say that it turns out that the two of us are actually. I think we have pretty different approaches to how we look at problems. And that’s kind of the way we end up dividing the work too. Right. So. And the way I would sort of delineate the way I think, the way the other guy thinks is that I’m sort of more facing the application developers and trying to make. Make it easy for them to understand a mental model for how they’re supposed to build an application. And he’s definitely more kind of on the. On the system side of really trying to squeeze the most out of the components that we have that we’ve chosen to optimize those for throughput. So it’s a pretty complementary setup at the end of the day. And I’ve talked to engineers who kind of appreciate having us both in the room because they’re both. They’re getting these different perspectives on how to address the problems.
David: How does the process work? What does the feedback loop look like? How do architectural requirements get identified? And then it sounds like there’s a process where you sort of describe them to other engineers and then they get implemented, and then presumably there’s some sort of iteration that happens there. Can you explain how that process works?
Brian: That’s an interesting presumption. You’re right. We’ve still been kind of formalizing the whole thing, you know, since I got back. Right. So we had this thing called the asg, which is the architecture support group. And historically, it’s just been kind of a place to just sort of come and bring a problem and maybe we’ll talk about it and figure out an answer. And we’re really trying to formalize it a little bit more at this point to make it part of the. So basically, if you consider the whole process, starting from product, with customer and product requirements, and going all the way through development and testing and deployment, we’ve gotten to a more kind of formalized place where we say, well, you want to bring this to the asg, right? And it’s not me telling them what to do. It’s they sort of bring this thing to the asg. And it could be anybody, see, engineer, staff, engineer we’ve had from all different parts of the engineering org, right? And they come and we’ve kind of made it a big deal to say, well, you’re going to come and present. I’ve got the presentation template. So I try to work with them ahead of time and say, well, here’s how the meeting usually goes. And we have, you know, we have a few dozen people in the meeting, right? So not everybody’s going to participate. But now that, you know, in virtual zoom, like, the conference room is infinitely big and you can come and go as you please. So I want to have as many people sort of experiencing the conversation and seeing the problem as we can. And that’s, you know, that’s becoming a more formalized thing, you know, so we go through that, and then the feedback is. We have sort of immediate feedback which is within the next couple of days, I go, I circle back with the presenter and I say, well, you know, what are your key takeaways from the meeting? Right. Did you get anything out of that? I send out surveys to everybody who was there and say, okay, well, the meeting was supposed to go like this. We were supposed to start at a high level and drive down to a lower level and get into the technical details and have a conversation. And I, I make sure to send the survey out afterwards to get a feel for how everybody. Did everybody get something out of the meeting? Can we do better? And then longer term, there’s also now more formalized process for me to circle back with the presenter and say, okay, here were the things we talked about, here were the decisions we made. If there are any decisions made, and then implementation starts and hopefully they’re at a point where they’re comfortable implementing at that point. Then I circle back later and say, okay, well, how, how’s it going? I mean, is it still look the same as it did? Did stuff change? What changed? Because we really want to make it. I mean, it’s a great point you bring up because we, we didn’t do this as formally before and you start to get disheartened a bit because you hate to have these meetings and you hate to pull all these people together and have these big discussions and then not have anything really come of it. So you really want to make sure that you do circle back and that people are. No, they can come back. I mean, sometimes you bring a topic back to the ASG and say, well, whoops, that didn’t work. Here’s what happened. What do we do now? So that’s. Yeah, that’s an important part of it.
David: Interesting. Yeah. I think the ASG format is something that we’re going to want to dig into again later. But I’m curious just to sort of have a good mental model of what’s happening in those meetings. Can you describe, I mean, obviously to whatever level of detail you’re comfortable with, but like the types of problems that get brought to an asg?
Brian: Oh, well, let’s see. We have a data pipeline, you know, architecture that somebody. We don’t. If we don’t have a data pipeline, we’re going to get one. We need to talk about that if we’re going to integrate with an external provider to do whatever it is, the nature of the problems, it does vary quite a bit actually, because sometimes we talk about, you know, sometimes we even talk about incidents. Right. If there was a bad incident in Production, it’s oftentimes useful to. In this particular instance, I’ll break the incident down and maybe try and draw it out a diagram or something and then bring the whole group together and say, well, here’s the thing that happened, here’s the timeline. Because we have all that, you know, we have the timeline of the whole incident and all the discussions that were happening. If it’s a severe enough incident, that isn’t something that you’re going to fix with one pr, it’s almost automatically and architecturally, you’re almost required to pull it back around to a broader audience and say, well, here’s what happened. And basically the room is full of people who are experts in different parts of the application. Right. So we’ve got, you know, we’ve got a system and we’ve got a elasticsearch system and we’ve got all these different components and we have experts in the room that can sort of speak to what each of these things was doing at the time. Those are interesting. I haven’t done a whole lot of those, but some of them, sometimes people bring. I’ve actually brought and presented my own massive PR that I was doing that was kind of just a refactoring of something and just to explain to people, well, here’s, here’s what I did and I think this is important and I think we should all be doing it. So sometimes it’s more kind of an educational thing. So it really is kind of a wide open thing. I think the topics are more focused. What makes them interesting is the audience that’s there. Right. So because I know I’m going to have this audience, we have a set time every week, every Thursday, one o’ clock in the afternoon. And I know that I’m going to get this group of people every Thursday. And we’ve kind of gotten to the point where that that hour has become important. People know that, well, I have to go to ASG now and they prepare for it and we go through this process and it’s good.
Alex: That’s interesting. Pivoting a little bit to sort of like how you choose what you work on. You know, one of the things we talked to about two other engineers and staff plus roles is that they have a broad purview, like there’s lots of things that they could work on and then there’s always more things that they could work on than they could ever get to do. You sort of have a process for understanding what it is that you’re going to work on.
Brian: Yeah, this is the Thing about Iterable. That’s really nice. And this is a kind of a big point about the whole staff. Eng StaffEng beyond thing is that you have to have good management for it to work. Right. And what I mean by that is if you don’t have management that actually values the role and has expectations of the role, then you aren’t going to have a process for figuring out what you’re going to do and you’re going to pick your favorite thing and you might be, you know, lost in the corner for three months trying to get that thing to work right. Or whatever. You know, I’ve gotten great on the management side. Just people who are very, very dialed into the importance of this type of work. And as far as what I’d end up doing is we also have these, you know, we have a very kind of elaborate process for our quarterly okrs. Right. So, and we talk about ahead of time, like, well, what are the priorities for the quarter and how are you going to measure it? All the stuff you’re supposed to do with OKRs, but everybody has to do that. Right. So I end up having objectives for the quarter that might be dialed into a particular project or this quarter. I’ve actually sort of worked with my and with my Director on getting OKRs around the efficacy of the ASG. I wanted to actually be measuring how well we’re doing at ASG because it was one of those things that was taking enough time where I didn’t want to have it just sort of be a time sink and not have any okrs attached to it.
David: Yeah.
Brian: But on the project side, I’ve got a project that’s also on my list and I’ve only got a handful of OKRs. I have like four and three of them are related to ESG and then this other one’s related to this other project. And that’s great because now I’m on the hook every week to come back to the engineering leadership and say, well, here’s, you know, here’s how that project is going. So I know if I, if I’m getting sucked into other things, I’ve got something that’s pulling me back to the thing I’m supposed to be working on. Right. Those okrs are established beginning the quarter. We’re going through the process, you know, in the next coming month to, for the next quarter’s okrs and everybody’s going to sign off. They’re going to say, yep, that’s an important thing to do. You should be doing that. That’s been Great. But I have to say that the big point there, though, it’s bigger than just how I choose work, is the fact that if the management side of the House isn’t on board with the role of your staff or your principal engineers or whatever, you’re going to run into trouble. Right. Because you’re absolutely right. I could easily get sucked into any number of things that are interesting, you know, because I still like writing code. I mean, I still love clean compiles.
Alex: Right.
Brian: When I. When the compile comes back clean. Oh, my God. I’ve been doing that since I was, like, 11. Right. So I’m talking, you know, it’s a long time. It’s like almost. And start writing code and click. A bio is still a very cool thing, and I still get a razz out of it, and I still like to be able to do it from time to time. But there’s other things that are more important.
Alex: Yeah, I want to touch on organizational alignment in just a second, but I was very curious. Would you be willing to share sort of the ways that you’re measuring the efficacy of your asg? Because that’s always a very sticky kind of thing to measure.
Brian: Oh, yes. I mean, it’s a bear. I mean, for us, it’s a question of. Basically, when I came in, it was a lot less formalized and there was less structure to the meeting. Right. So what I wanted to do as far as measuring efficacy was to say there are three things. Basically, it was like, one was audience. It’s an optional meeting. Nobody has to come. Right. And the question is, how many people are coming? And again, with zoom, it’s really nice because you don’t have to get a big room or small room. You just say, here’s the link, and come if you want. And I encourage people, come stay for 10 minutes if it’s not interesting, if you’re lost, you can leave. It doesn’t matter. It’s all zoom. But what I do is I measure. I measure how many people come, and I’ve got a target. And that target for this quarter is actually, I hope that 30 people come and we’re hitting that without a problem. That’s the one thing. The second thing is the survey that I send out afterwards. And the survey is only really about the structure of the meeting and the question. And it’s rated strongly Disagree. Strongly agree. 1, 2, 3, 4, 5. Did the speaker provide adequate context? Did the speaker dig down into the details, which is basically like, okay, is he doing a good job? He or she? Is he or she doing a good job of establishing context. What we’re talking about and then drilling down is the agree or disagree. If, you know, we then got into a technical discussion about the details and the last one is always like, did you learn something you didn’t know before that you can take back to your job? And that’s. I don’t really hold myself on the hook for actually teaching everybody in the meeting something they didn’t know before. But ideally, if the structure is right and we’re starting in a broad context and we’re narrowing down and then we’re talking about details, anybody that’s interested in being that meeting, in that meeting is going to be learning something they didn’t know before. And that hopefully what I really want is to be reinforcing the right architectural ideas so that when they go back to their desk, even customer success people in there, not just engineers, right? We have other people, product people, customers. I want them to go back to their desk and just have in their head just a slightly more refined idea of what architecture is, how these things work and things you need to be considering when you’re talking about changes. So that’s the measure. So there’s basically the count of people, there’s the survey, and then the last thing is the follow up. I’ve got three follow ups that I want to do for each asg, but that takes time. But it’s the immediate follow up from the presenter. We also like to track in jira, you know, if it’s, if it’s an epic they’re working on and presenting on. I want to have a JIRA ticket that links back to the notes in the presentation from the asg that’s part of the historical record for the thing. And then the third thing is just. Okay, and this is a reminder to myself to go back later and make sure that we’re looking at the results of the thing and seeing if it still matches up with the thing that we talked about in the beginning. So that’s cool. Number of people, effectiveness of the meeting and follow up are the three things that we’re measuring.
Alex: It’s really interesting. So like, sort of my mental model here that I’m thinking through is like, if you bring people to this meeting, they’ll become more aware of architectural practice, making sure that the fit is right for your company and what you need to do and hopefully that would flow into more appropriate architecture. And I’m curious that last that outcome, is that something that you sort of feel? Is there an explicit thing that you’re looking for.
Brian: Well, you know, it’s one of those things where we have a particular project that is happening right now that’s, it’s really like a big refactor of something that was done really badly before. So in that case, it was great to see the engineer brought this design and it was just such, such a better design. First of all, it’s so great. I was like, okay, this is fantastic. And in the course of his presentation, he was sort of referring back to things that, that I’ve been talking about since I rejoined the company. So he was very clear about like, these are ideas that are, they make sense to me. They’re. They’re good common sense things to do. I went and I reread some more stuff about those things and just to make. I wasn’t making it up, right. These are good ideas, stuff about cohesion and things like that. So in that particular instance, it’s going to be very easy to circle back and say, okay. Because the great first thing that happened was he’s obviously taken to heart the things that I think are important in code. Right. And he thinks they’re important in code too. Anything. My job was just to make it to provide sort of a, some type of leadership in that area that says, if you’re thinking like this, it’s the right thing to do, please keep thinking that way. Right. Instead of worrying more about schedules, it’s just evident the way that was done before was a very schedule driven answer. So, yeah. So the follow up on that particular. In that case is going to be really easy to say, okay, this is fantastic. This is so much better than it used to be. And that’s an easy one. Some of these bigger things that run into scaling problems and stuff that gets a lot more tricky to diagnose on the whiteboard and those are more likely to actually kind of circle back through ASG again. If we kind of roll it out and see that it’s not working great, we may have to look at that again. But the great thing about asg, and this was one of the things that when I first was coming back, the CEO was talking with me about, is just my words, not his. I mean, basically these designs should pass the whiteboard test. I mean, if you can draw it up on the whiteboard and it doesn’t pass the whiteboard test, right? If you can look at that and say, nope, that’s not a good idea. Because a lot of times the design looks fine and then when it hits production, something goes crazy. But sometimes it doesn’t even look good on the whiteboard, you know, so that’s another thing that we just want to. We want to be able to stop that right at the beginning and say, okay, we’re not ready. And that’s a big thing too. I mean, about this, about the experience. I could go on for days about this stuff, but 30 years of experience tells you a lot about, like when you’re not ready to code something, right? And a lot of folks, especially younger folks, are going to. You’re going to get the requirements, doc, whatever the design thing looks like, and you’re just going to plow right into it and start coding. And it’s important to know when you’re not ready, it’s important to be able to step back and say, you know what, I’m not exactly sure how I’m going to do this. I better get out pencil and paper maybe, or the whiteboard and just think about it some more before I get into it.
Alex: Yeah, it’s really interesting to hear about the ASG and how it impacts the culture. Going back to organizational alignment, it was really interesting to hear that you talked about how the managers had a really good understanding of what they wanted to communicate and what they wanted from you. I’m curious, have you ever been in a situation where the visions don’t necessarily line up and in that situation, what do you do to impact sort of like the okrs or the outcomes of those sorts of decisions?
Brian: You’re saying that is there a time when the management alignment wasn’t the case?
Alex: Yeah. Well, you know, I think one of the things we see with staff plus engineers is that they’re free to see things in a different way for managers. And that’s really powerful in an organization to allow two different groups of people to have different perspectives. And it’s in that sort of creative collision that like the best. And so I’m curious, you know, when you have a different sort of perspective on things, how do you make sure that it meshes with management?
Brian: It’s certainly on me to convince people because more often than not, it’s not that management has an idea and I have a competing idea. It’s just that I have a very refined idea and they have a set of requirements they’re trying to meet. Right? So if management’s saying, I don’t care how it works, but I know I need to support 100 million users and I need it, it needs to work this fast and I need it by, maybe that’s a set of requirements that are not the currency that I deal in. Right. So I’m more trying to think longer game about how this stuff’s going to work. Really. The question is then to what extent does the organization adopt these? Whatever my truth and beauty is over here versus the reality of how things actually need to work for the business to succeed. And ideally what’s going to happen is that if that aligns early, early on in the company, then that’s great and that’s your culture to start with. I would say that Interval is a company that’s been wildly successful at moving very, very quickly and growing very, very quickly. And things occasionally they’ll burst at the seams because of it. Right. So now we’ve gotten to a point where we do need to sort of step back a little bit and kind of agree on what the right path forward is. And my job is to, you know, to educate to an extent and to convince people that here’s a vision, here’s a way to go, here’s how we should do it. It’s going to take a long time, it’s going to be a lot of work, we have a lot of code that we need to go back and revisit. But it’s my job to convince the management that that’s the right way to do it. And I have to keep in my mind too some of their stuff. Right. So I can’t go dark for two years and recode the thing. Right. That’s just not an option. Right. So you got to be realistic about that. So it’s really on me kind of to come up with the staff engineers too, to come up with a longer term vision that says, well, here’s where we want to get to and you know, let’s not really talk about how long it’s going to take yet, but where are we today? How far are we away from that today? So we’re a very long way away from that today. How do we get there incrementally? It’s almost like more of a sales thing for me, having to sell an idea to the management about it and they might buy it and they might not buy it. That’s kind of par for the course. But if I think it’s drop dead important to do a certain thing, it’s great to have management that will, if these managers and directors and the vp, they’ll set up a process for going through that and saying, well, we need to talk about this. We’re going to have a few meetings, we’re going to hash this out and we’re going to come up with a decision that we’re all behind. So I’ll come at them with my whatever egg heading technical stuff I want to bring to it. I just need to bring to it enough to say, well, this is important, here’s why it’s important, here’s what this change or this different approach is going to enable and here’s how we can do it. It’s either an easy sell if they buy into that because most of these guys used to be engineers too, so they sort of know what I’m talking about, or it’s not an easy sell and then we have to compromise, right? We say, well, we can do part of that, but we just don’t have the time or the money or the whatever to do that whole. To do that whole thing. So. So it’s not really a conflict. I wouldn’t say as much as it is a sale, education process and sales process.
David: I think framing it as a sales process is kind of interesting. Alex and I have observed often that staff folks sort of have experience outside of just being a senior engineer in a big organization. And that can often involve working in startups or driving open source projects or in your case, I’m sure your experience as a consultant has kind of framed some of the ways that you propose changes to management and probably to peers or to the teams that you work with. I’m curious at a tactical level, what does it look like when you sort of, let’s say you need to flag a problem that you see and you want to make sure management is aware of it. What’s sort of the first thing you do? Is it Slack message? Is it a phone call? Is it a Google document? Like, how does it work?
Brian: I would imagine at this point in time that Slack would be the number one way to do it, but chances are that the things that I would flag of that sort that you’re talking about are probably more things that are not a surprise to anybody. I mean, this is like, if anything, the things that come up for me the most often are. Here was an incident that we had and here is my take on what’s going on there, right? So it’s not like I’m surprising anybody with, oh, by the way, you know, this crazy thing happened. It’s something we all know happened, right? So even without Covid, I’m remote anyway. So I’m pretty much like, I’m on Slack. I like it there because I do like that style of communication because it is kind of immediate, but it’s also kind of asynchronous. And it’s also, you have the history of it. Right. So that’s how we generally do it. And if it’s, you know, if it’s a big deal, it might immediately turn into a meeting. If it’s not as big a deal, it might turn into an ASG or less. Right. Just kind of depends. But yeah, that’s certainly the. It’s funny, I never call anybody. I don’t talk on the phone anymore. That’s. I’m done. I’m done with the phone.
David: It’s funny, I didn’t include as an option walking up to people’s desks because Alex and I are also remote, I think. I mean, everybody’s remote nowadays, but I’ve always been remote.
Brian: Yeah, I think it’s, you know, it’s great. I mean, it’s just from being able to focus and things. I also find that like. And this is kind of a bummer about. This might be just particular to me, but when I’m bringing these ideas, it doesn’t always lend itself well to a conversational format because the ideas are bigger. Just like sometimes problems are bigger than a pull request. Sometimes ideas are bigger than a back and forth conversation. Right. I gotta. I mean, I’ll go and. I’ll go and make a deck. I’m very visual. I like to draw diagrams. I like the feeling that people can look at the diagram and come away with something in their head that actually like. So they can start drawing conclusions on their own about the way something works. Right. So, yeah, I’m really into the educational aspect of the whole thing. Right. And that’s. That’s kind of a big deal. Another thing, this isn’t really what you asked, but that I think is interesting is that earlier in my career I kind of assumed everybody wanted to aspire to be an architect. I always assumed that everybody, everybody wanted to draw pictures and everybody wanted to be thinking about itself. It’s kind of important to realize that that’s not necessarily true. I mean, there’s plenty of people out there who really just like solving problems, detailed problems in code. And those are important people to have. And especially if they really like doing it, they really like doing it at a high level for many years. That’s a great person to have around. Not everybody wants to do this and not everybody would be really good at it. Right. Not everybody’s necessarily good at putting it up on the whiteboard or explaining it in terms of dumbing it down, but you almost want to sometimes just draw things back to a more kind of visual representation of what the solution looks like so that people understand. Oh, ok, okay. That’s why that happened. Maybe next time I talk to the customer we can I have this better understanding of what’s going on. So that to me is kind of one of the most fun parts of the job.
David: Yeah, that’s really interesting. Actually. The insight that you just described about realizing that sort of not all folks have the same aspirations that you do was a pivotal realization in my career as well. In hindsight it maybe seems kind of obvious, but I think we often sort of think about groups and make the assumption that everyone wants the same thing and actually usually that’s not the case.
Brian: Yeah, I’m not the best developer at Iterable. I mean, that’s for sure.
David: Oh yeah, no, I’m definitely not the best engineer among my peers either. I think that’s actually pretty common with a lot of the staff plus folks we talk to. People say I am not the most technically proficient person in the room, nor am I sort of supposed to be. One of the things that’s interesting about staff plus roles is that, and you mentioned it earlier, sort of there’s this requirement to lead, but there’s not, there’s not the role based authority that comes with it. You lead by influence. And I imagine in the, I know that the, in the case where you’re trying to drive an architectural refactor or you’re trying to help someone else drive an architectural refactor, you’re often going to be dealing with multiple stakeholders, probably multiple different engineering teams that have different. Their compass is bent in different directions, they have different priorities. Right. And so how do you approach that? How do you sort of get people aligned on the architectural change that you think needs to happen, even if it doesn’t directly match up with everybody’s short term goals?
Brian: Yeah, I mean I think the first thing that’s really, can be really hard to do is to just kind of read the room, right. And figure out, well, how far off am I from what other people actually think needs to be done? Right. So you know, if I’ve got an idea about something and the other thing that usually happens with my ideas, I mean it’s taken me, like I said, it’s taken me a long time to get to this point. Right. So I’ve got a lot of experience for better or worse and most of my ideas that I struggle, that I hold most strongly are things that I’ve actually done. And most of the things I’ve actually done, I’ve messed it up at least once and then I got it right. I feel like I can come at these conversations with a very empathetic view of both sides of the table. Right. I said, I know what you’re saying, you want to do it that way. I know why you want to make a new ORM system. I’m going to tell you why that’s not going to work. Whatever it is, all kinds of stuff like that. So, so really it’s the first thing you do is you come to people and. Because maybe they haven’t even. This is kind of the same thing as the management question. They might not even have a very solidified idea about what they want to do and I might just have a more solidified idea. And then when I tell them, they’d be like, well, wait a minute, does that mean I have to do this, that the other thing differently than I used to? And then again it’s back to me to say, well, yeah, but here’s what you’re going to get if you do that. It’s very helpful to be able to kind of just read the room and understand how far off we are from being, because we might not even be that far off at all. It’s just that I’ve got a more refined idea about what we need to do than you do. Or we might be way off, in which case there are certain arguments that I don’t really want to have that much anymore. I mean, back end code I think should be compiled, it shouldn’t be interpreted. And that’s just kind of my own thing. That’s one of the things that I kind of am adamant about. That’s not really a conversation we have to have that often in interval or a scholarship that’s kind of, that’s done.
David: If you can’t compile it, how are you going to get a clean compile?
Brian: Right. But you know, generally speaking what you find is that especially with refactors, people have probably roughly the same idea and it’s, and it’s amazing how often that you really do end up having very similar ideas as people. It’s just that you haven’t really sat down and talked at, through to the level of detail, to the same level of detail to the point where it actually happens. So that’s, Yeah, I mean, it’s, it’s kind of an empathy thing. It’s kind of a, you know, I, I, you know, I definitely want to, I want to listen first and then try and say, well, to figure out where we are and how different we are from where we need to be and take it that direction. Interesting.
Alex: Outside of things like the asg, outside of sort of like your role as, like, architect, do you see things like sponsoring mentoring as a part of your role?
Brian: Well, I mean, it’s hard not to. We don’t really have a formalized program for that right now. If you’re going to be around as many engineers as we have, you know, we’re up to several dozen engineers, and they’re of varying skill levels and varying experience levels. You really have to take seriously your role as a mentor in this situation. When you see people doing things that you know are just not good ideas, you have to pick that out and say, well, I see what you’re doing. Here’s probably a better way you could go about doing that. Or if it’s really bad, you say, absolutely, do not do that. Do it this other way, or whatever the situation is. Mentoring is kind of. It is a big part of it. And if anything, I keep coming back to this. But after doing this for so long, right, after 30 years of doing this, you see the same patterns over and over again, and you see the same archetypes, right? You see the same types of people coming through, and you can kind of pick them out pretty quick. And some people, you know, some people you can see. Well, they probably, I think they do want to be an architect and they do want to aspire to that next thing. And. And they do have the communication skills and things to do that. And some people, you have to know. No, they don’t. But let’s just try and mentor them and get them further on their path that they’re going. But again, there’s nothing really formal about it. I’m not a people manager, obviously. I’m still an IC technically, but I do have conversations with folks about, like, career wise, like, you know, what’s the next step and how would I go about doing this? And ASG is great for that, actually. It’s a great venue for people who obviously are wanting to level up, even, you know, from junior engineer, senior engineer to staff engineer. And that’s a great venue for it. Right. Because it really is a opportunity to present about your problem and to learn about presenting and to learn about communicating with issues you’re running into and where you want to go. So if there’s anything formal about our mentoring program, it’s that I’m very ready and willing to help anybody with their ASG presentations beforehand and. And to give them some feedback afterwards. That’s cool.
Alex: Yeah. Outside of, like, direct Intervention or, you know, one off. Do you like have any sort of like process for helping someone level up or sort of like help them gain a new perspective or anything?
Brian: Again, I’ll go back to the management side of this. One thing that we’ve been working on at Iterable is just really being crystal clear about the expectations for each role. And crystal clear that just because you’ve been here for four years doesn’t mean you’re automatically going to the next role. Right? I mean, basically I have another roll up, right? I could become a. Whatever it is, a distinguished. We don’t have principles as high as we have right now. There’s two more roles up. But I look at those personally look at those requirements and say, well, do I really want to do that? Right? I mean, if it’s getting away from the office and doing more conferences and thought leadership outside the company, is that something I really want to do? So it’s the same thing for Levels coming in junior all the way up to principal and this is a recent thing, we just sort of got those kind of published last quarter. So that will be my process for saying, okay, well, even for assessing, you know, we do this 360 reviews, whatever, six months it is, or where you say it’s great to have those expectations in your hand so you know that this person actually meet these expectations. It’s very helpful to be able to refer to a document like that. So my process will be like, well, if this person is performing at the level that you know that they’re at. First of all, because the job requirements came after most people got their roles, right? So we were sort of superimposing them on top. But you really want to make sure that now that we all have our positions and we all have our expectations that people are kind of meeting those things. And my opportunity to do that is pretty much, you know, and part of the expectations actually involve asg. Are you an active participant in asg? Do you bring your expertise and spread it around to people who are coming and presenting on areas that they’re maybe new to? So yeah, so that’d be my role. A process such as it is, it’s not a very formalized process, but we all have very clear expectations about what we’re supposed to be capable of doing. That’ll be a critical part of it.
David: It sounds like Iterable is sort of in the phase where, I mean, you’ve recently sort of refreshed your career ladder, as you mentioned, and there’s sort of maybe not roles that are in the process of being defined, but roles that have been freshly defined. And you also mentioned that you, you were at iterable and then you left and you came back. Is it safe to assume that you were a staff engineer at arable before you were a principal?
Brian: Was I a staff engineer? It’s funny, it kind of depends on how you, on who you ask. I didn’t feel like it. I didn’t feel like it because again, when I left, I felt ineffective when I left. And my ineffectiveness was that I wasn’t as good at the, at understanding the code that was there. I mean, I was coding, right? So I was, I was trying to solve incidents. I was trying to make things better, but I wasn’t the best at it. That was like the value chain at that point was like, you know, the people that the heroes were the ones that were good at fixing the problems right now. And I didn’t feel like that person. So if there was a career ladder at interval at that point in time, then the staff level person was the one who was going to be able to fix things and when they broke, got it. And I was aspiring to that, but I wasn’t getting there. And, you know, part of the frustration that led me to leave in the first place was that I didn’t feel like I was being very effective at affecting changes that I knew needed to happen, but I was unable to do it because I wasn’t quite the level of these other folks that were fixing problems as they happened and making things work. I didn’t mean to have a complicated answer to that question. I mean, I, you know, if you looked at my resume when they hired me, I would probably say I would expect that they would have hired me and its staff.
David: Yeah.
Brian: But they didn’t really have it, so.
David: Yeah, that makes sense. I guess another way of framing my question maybe is like, how do you think of the difference between the staff level and the principal level? I’m curious how iterable frames it in general, but I’m also curious sort of how you think about it and how you would describe your progression from sort of from senior engineer through to where you are now.
Brian: Well, I mean, you know, it’s. It’s part of coming to the realization that you might not code and that you might actually have and that there is a need for that. Right. And that you’re able to then kind of go up and fill that need. Right. Of identifying maybe sequencing projects. Right. Doing one thing before another thing is a broad enough, you know, high level enough decision that has to be made that you become better at making. Right. So you become sort of, you know, the big challenge with any startup and any significant software project is I think most people understand how to come up with like where you want to be in five years or what their goal is for the thing. But man, that bridge from here to there is really, really hard to come up with. Right. Especially if you’re looking at a five year plan and you’re saying, what am I supposed to do next week? And the task that you’re doing next week seems so insignificant as far as like where you want to get to. Coming up with that vision is a different skill set than writing the code. So, you know, for me, that became pretty clear that I enjoy doing that. Again, I still enjoy coding, but I also enjoy doing that and then just sort of finding yourself in a situation where you’re in a company that needs it, which Iterable kind of restructured themselves into that after I left. So that’s what they want from me and that’s, that’s what I want to provide. So.
David: No, I think actually I really like that answer because the one insight that I pulled away from that was this idea of like that defining the path ends up being sort of more valuable than defining the vision a lot of the time. I think that’s something that I’ve observed as well, is that there’s a lot of smart people in our industry and most of them are capable of drawing a picture of where we want to end up. Right. But the challenge is always sort of mapping that to where we are now and how do we gradually move the pieces around? You know, the analogy that I always like to use is turn the car into an airplane while it’s running.
Alex: Yeah.
Brian: Right.
David: And so, yeah, I think that resonates really strongly with me. We’re almost at time. There’s a couple of things that we always want to cover with folks before we, before we stop. First of all, are there any resources that you found valuable or that you would refer other folks toward who are sort of interested in understanding more about what it means to be a staff engineer or a principal engineer?
Brian: Wow. I can’t tell you that I read a book and that it made everything clear. Unfortunately, my path has been long to get here, so experience to me is kind of more the thing really. Just what’s a goofy thing to say? It’s kind of goofy to think that you’re. You have to listen to yourself. But like, if you find yourself doing these things where you’re Sort of where you are drawing the pictures and you are interested in. I mean, basically the reason, the only reason I ever even considered the other path into management. Well, first of all, that’s very well documented path, right everybody. There’s a million books about that. And what happens after 10 years or 15 years if you get a manager where you’re like, you know what? I think I can do a better job at that. And then maybe you try it and maybe you like it and you stay there and maybe you don’t like it so much and you go back to the other thing. I would put myself in the latter camp and that was just. Yeah, it was really just a matter of like deciding that it wasn’t something I like to do the other thing and that this thing was going to be the thing that I wanted to do. But I. Yeah, I hate to say it, but there aren’t really any, any books I would suggest for that. The big thing though is you really just have to be. You have to keep learning, right? You have to just keep on learning stuff. If you really like to code and you want to keep learning code, you know, I keep. I mean, Scala is funny to me because I’m still learning Scholar. I’ve been trying to learn Scala for 10 years now. There’s always something more to it that I learn later. Oh my gosh, this is amazing. Again, that’s what I enjoy. So I mean, just learning in that direction and. But there’s nothing specific about being staff plus that I would say, sorry.
Alex: No, that’s fine. What we’re finding is that it’s not well defined. Right. Even though the book that Will Larson put out Staff in just feels very novel still.
Brian: Yeah, yeah.
Alex: So the last question we like to ask folks is hopefully a fun question. How much time do you find yourself writing code nowadays?
Brian: Actually it comes in bursts, it turns out, so I couldn’t give you a percentage per month or week or whatever. Last week we had a hack week, so I spent more than eight hours a day coding last week, which was wonderful. And it was an idea that I’ve had for years so that it was a great together group of people around it. We delivered a hack and hack week over the summer. There was a couple of projects that really required like full time attention. But I would say probably in the normal steady state of things, I probably don’t code at all. I mean, I review code, but when it comes to just keeping things straight as far as the ESG goes and everything else, there’s no code involved with that I’m trying to not get into it, because, like I said, once you get into it, you’re. You’re sucked in and then you’re putting more time into it than you really intended to. So I try not to spend a lot of time coding at all. You know, honestly, too, is the other thing is that sometimes there’s something that kind of needs to be done. It would be good to have it done, but nobody, everybody else is doing, like, priorities that have already been identified. You kind of swoop in and maybe do that. Those are nice. So, you know, that might account for 10, 15% of the time, but, yeah, that doesn’t happen a whole lot. So not a whole lot of time coding. But I do like to keep involved with it. And during hack week, you know, you bet I’m going to be all in. So whatever the stuff like that, it’s funny because, like, it kind of depends on what we can talk to me because some weeks I’m much more into it because we have some things that. The other thing that I’m trying to do, I find myself doing the big thing, just to make the answer longer than you probably ever thought it would be, is trying to make sure that I’m proposing something that makes sense and that people can do and make sure I can do it myself. That’ll sometimes take a little time. So whether it’s this kind of refactoring, I’ve got this thing called untangling that I’m trying to do where it’s untangling the source code base. That process has been interesting because I wrote a big paper about it when I first got back, and here’s the things I see and here’s some measures that we can look at to say, yep, it’s tangled up. Here’s some approaches to untangling. I wrote about that, but then I started actually digging in and doing it just to make sure that I wasn’t asking people to do something that was totally ridiculous. And it’s not. So I’m happy to say. So that ends up taking some coding time as well. Nice.
Alex: Well, Brian, thank you for speaking with us. I learned a lot.
David: Yeah, this is great. Thanks so much, Brian. It was really, really nice chatting with you.
Brian: It was my pleasure, guys. I’m happy to do it. That’s it.
David: Thanks so much for listening to staff Eng. If you enjoyed today’s show, please consider adding a review on itunes, Spotify, or your podcaster of choice. It helps others find the show. It is a really useful signal to us that folks are finding value in this so that we keep doing it.
Alex: You can find the notes from today’s episode at Our website podcast staffevenge.com the website also has our contact info. Please don’t be shy. Sa.