Bryan Berg (Stripe)
Staff engineers may not get much time to code anymore, but this does not mean problem-solving and system design is not an integral part of their day-to-day. Today’s guest is Bryan Berg, Staff Engineer at Stripe, and he joins us to talk about the nuances of his position and his unique approach to the many challenges it entails. As a Staff Engineer, Bryan acts as Tech Lead of the Traffic team, and we begin our conversation by hearing about how he landed in this role. Bryan describes the ambiguous challenges he faced during earlier days at Stripe, and the knack he had for finding and working on processes and systems that were previously underinvested in. We then jump forward to the present and dig into what Bryan’s current role entails, hearing him describe a wide range of tasks from reviewing documentation, communicating between teams, writing vision documents, and ensuring the work he directs falls into the company and stakeholder requirements. We also explore the interesting concept of when to draw on past experience versus keeping an open mind when facing new challenges. On top of all this, our conversation covers how Bryan judges the success of his work, sustains faith in his ideas, pitches to colleagues, debugs difficult pieces of code, and finds inspiration to be a great technical leader.
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 sets staff plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. My name is David Noel Romas 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: Sure. Today’s guest is Bryan Berg. Bryan is a staff engineer at Stripe working on the Traffic team. He’s worked for Stripe for over seven years now. Before that he was a founder and CTO of App.net where I had the opportunity to work with him. I’ve learned a lot from Bryan, so let’s get into it.
David: Well, Bryan, thank you so much for joining us. I obviously know a bit about you, as does Alex, but for the benefit of listeners, can you tell us who you are and what you do?
Bryan: Yeah. Cool. My name is Bryan Berg. I’m a staff engineer at Stripe and I currently lead the tech lead on our Traefik team. Traathik owns the vast majority of ingress from Stripe’s customers to our API and other properties.
David: Got it. And what, how do you think of like the tech lead role or what does a tech lead role look like at Stripe, or what does a tech lead role look like for you, etc.
Bryan: Yeah, I have been asking myself that same question for a very long time. It’s something I’ve always struggled with, to be honest. I have found that I spend a reasonable amount of time just sort of trying to. Trying to organize us as a group. The role to me is really about ensuring that everyone around me is successful, to try to make sure that the work that we are doing is aligned with what the rest of the organization needs. And really just to be out in front of things to try to think six to 12 months ahead of where we’re going and make sure that that work is going to line up with what the rest of the Org needs from us.
Alex: Awesome. Just to give people some context, I actually worked for Bryan almost a decade ago now. A decade? Oh my goodness.
Bryan: Was it really that long ago?
Alex: I think so. But in the previous role you were the cto and now you’re a staff engineer at Stripe. And I’m really curious, what did you learn as a CTO that you apply as a staff engineer or a tech Lead?
Bryan: Oh, that’s a great question. I think I learned just so much as a CTO about what’s required to get things kind of started. Right. So what I think is really interesting about being kind of a small company founder, CTO type person is that you just have to create almost everything from scratch all the time. And that’s. It’s really substantially, I think, different than what you have to do as a staff engineer, as a tech lead type person, where really you’re sort of taking this set of things that you have and applying it to the set of problems that the folks around you are coming up with. I guess that in a way is also kind of similar to being a CTO as you grow a bit. But it’s interesting in that the challenges that I think we were running into back at the little startup that you and I worked at, Alex, were sort of substantially different than the things that I think about every day. But at the same time, the job of kind of rallying and figuring out how to sort of wake up every day and be inspired and try to do our best work are really similar. So. Sorry, that wasn’t a particularly articulate answer, but it’s in a lot of ways just a very different thing, but plenty of similarities.
Alex: Yeah, no worries. So when you joined Stripe, was there a staff engineering role at that time?
Bryan: No, no. So Stripe was really pretty flat at the time. So when I joined, the way our organization was laid out was that we just kind of hired a bunch of engineers, kind of threw them into an office, had them kind of organize around things to do, but there wasn’t a sense of, we didn’t have levels or anything like that or roles. We had folks on the ENG team and a whole bunch of other amazing sort of other teams, but sort of your kind of an engineer or like, you know, in very, very small number of cases, manager. And everyone was just sort of expected to kind of fit in and slot into the roles they needed to be in at any given moment.
Alex: Nice. Do you, do you remember at all sort of like what spurred the creation of the staff engineering role and any sort of like conversations around what those expectations were?
Bryan: Yeah, that’s a good question. I don’t actually recall when, when I think we were coming up with this sort of idea. It was long after we had internally. We’d internally sort of defined levels and ladders for engineering. And at Stripe, levels are private, so we don’t sort of publish levels. And I think there was a desire to create some gradation, some very coarse Distinction between sort of folks who are newer in their career and folks that were a bit more tenured and create some, I think, recognition and distinction there. But I don’t think they’re. I don’t have a ton of the context. Cool.
Alex: It’s really interesting to hear. So from your perspective, what do you feel like a staff engineer does at Stripe? What are sort of like the common expectations for a staff engineer?
Bryan: Yeah, yeah, I think it’s a. That’s a good question. I think as you sort of find yourself in one of those roles, there’s a lot more coordination across teams. We sort of expect folks to be more proactive at seeking out other folks and sort of building more connections across organizations, across teams. We do have, you know, an expectation that folks will sort of be, you know, running projects, doing more project management, sort of doing more design type work as opposed to, as opposed to sort of spending all day, every day coding. There’s, you know, an expectation around, you know, code reviews, around design reviews, around sort of document reviews, that sort of thing. Stripe, we have a pretty extensive culture of writing written documents for many, many, many things. And the text editor that I spend the majority of my time in is the Google Docs editor or the Dropbox paper editor, depending on what day of the week it is. Cool.
Alex: And do you feel like you have a particular spin on being a staff engineer at all?
Bryan: Yeah, that’s another good one. I don’t necessarily identify too much with being a staff engineer. I think my early time at Stripe was largely focused on finding things that I thought we were under invested in and going and just sort of trying to get them off the ground. Right. So I think the way I ended up sort of at Stripe as a staff engineer was that I just found a bunch of things that it really seemed like were going to be strategic for us or we needed to invest in and, and that we just weren’t putting enough energy into. Right. So Stripe was pretty sort of focused in its early days on thinking about product. We sort of were working on building infrastructure. We had a few, like I said, very coarse sort of like segments of the company who were working on a few different large problems. But then there were these like this big collection of small things that no one was kind of working on. So early in my time there, I noticed that there was like one engineer in the corner kind of who was like spinning up laptops for everyone. Every time we hired someone, it’s like, I think we’re going to like hire a lot of people soon. We should probably figure out how to scale that process. And so this was not a novel thing for me to figure out, but it was something like, you know, okay, you know, I think I can be helpful here, given some of my past experience trying to figure out how we can like, build ourselves like an IT team, a corporate engineering team, to sort of build some of these things and automate this a bit more. I kind of was the sort of security mole in the product organization. So I like, you know, spent most of my time hanging out with the folks on the infra teams, on the security team. And I kind of was like just keeping an eye on what was happening in the product world at the time. I got sort of, oddly enough, deeply involved in sort of setting up corporate security. I helped us sort of dig into some of the, sort of, some of the infrastructure challenges that we were facing that were not sort of the. In the purview of like the specific org that I was in. And, and as a result, I think I did the bare minimum set of things to get those, those organizations, those functional areas going and get some momentum and sort of get the organization to understand their importance. And then, you know, for the vast majority of those things, like, they just, you know, there’s a team around them now. But instead of that team starting from absolutely nothing, I tried to make sure we started from a little more. So, yeah, I think one of the things that I try to do as a staff engineer is to just go find the things that in six months we’re going to be worried about and try to get something in some of those areas or get some things started. And so that may be potentially a bit unconventional because it’s not, oh, we’re going to run out of capacity on a primary database instance somewhere or something like that. It’s like, hey, we’re going to need this as a function. And no one here has experience integrating our corporate directory with a badge system or something like that, so someone should go learn about that. I think I’m a super sort of voracious learner. One of the reasons why I’ve been managed to stay at Stripe for sort of this long, they haven’t managed to get rid of me is that I just love reading documentation. And I spent probably way too much of my time going through and reading those big, long, meaty documents that Stripe writes and digging in on things and digging in on partner documentation and digging in on the vagaries of badge systems, things like that. And so I was able to use that context and create connections across the Org.
Alex: That’s really cool to hear. I remember from my experience working from you, one of the things that happened a lot is that from some various previous position to the one that we were working together, you’d be like, oh, I know this one because I did it here. And I’m curious, do you feel like, besides your voracious learning, that your varied experiences of doing networking really early on and then doing one of the very early consumer music startups and then what we were working on really sort of gave you that understanding that you can then apply experientially.
Bryan: So I think I had a set of skills and experience that were a little bit rare at Stripe. So I think we had a lot of folks at the time who were quite experienced at the sort of set of products that Stripe was building that we had folks who sort of knew the financial industry and were digging into that. But when it came to sort of networks, I was able to kind of be an expert or be a person that folks would lean on. So I was, interestingly enough, kind of listening to Will’s episode of this podcast not too long ago, and he was talking a bit about how one of the things that happens is when senior folks sort of show up and like kind of over index on their past experiences in terms of like solving the problems of their new employer. And I found that to be like, just absolutely true. I sort of went into Stripe with a. Having learned a little bit about how I kind of over indexed on my learnings two companies ago at the, you know, company that you and I work together on. There are plenty of mistakes I made there and I, I kind of reflected on those. And I made this sort of conscious decision when joining Stripe to say, I’m going to kind of table a lot of my past experience and say, you know, I want to learn a lot from the way these folks are doing things because they’re. It’s so different from the way in which I had operated in the past and the things I knew. And so I was just like, I’m going to, I’m going to sort of purposefully kind of turn the, turn the humble up to like, you know, 100 and just go in and learn as much as I can from these folks and not show up and say, oh, ha ha ha, you know, you’re like using this terrible database, we need to change this immediately or, or whatever. And the interesting experience that I’ve had at Stripe as well on that sort of thing is that, you know, there’s been so much change in our infrastructure in our sort of company culture. And I now find myself sort of sometimes being almost too fixated on the way things used to be at Stripe as my, you know, where like, sometimes I’m like, ah, you know, we’re relearning a bunch of lessons that we learned in the past or what have you. And in general, that’s good. Right? Like, I think the organization sort of needs to sort of not be scarred by the things that happened even in our own sort of recent past. We need to sort of continue to try new things and try some of the same things because they may work now. But I think that one of the places that I’ve been able to really sort of offer things to the company has been in places that I’ve had relatively unique experience.
David: Do you have a heuristic for deciding between the moments where past experience is going to be a useful shortcut versus the times where a useful shortcut and can avoid reinventing the wheel versus the times where, like, reinventing the wheel is actually warranted because the roads have changed?
Bryan: I think that it comes back to reevaluating some of the, like, invariants that your model is sort of built on top of. Right. I think that one of the places that I often find myself sort of thinking about this exact thing is when some dependent component has changed. And I’m not kind of tuned into that. Right. And so it’s not necessarily a heuristic, but it’s really. It’s in sense of a tactic. Right. Which is like, I really sometimes force myself to like, you know, stop, pause, and sort of act a little bit more slowly in some of these situations. Right. Like, so much of communication at Stripe sort of happens on slack, and there’s always sort of can be a tendency to sort of jump in and help people quickly. And one of the things that I’ve really found myself trying to do more of is to sort of really pause and use my initial reaction to certain sort of questions and things where it’s like, oh, this is. This is obviously wrong. If I have an initial reaction that something is like, sort of obviously incorrect, I’m usually like, okay, this is a good sign that it’s time for me to like, pause and really be like, okay, is something changed? Because this person that’s coming to ask this question is obviously incredibly smart individual. Like, I should probably go and think a little bit harder about this. And so that’s not answering your question precisely. Right. It really sort of depends on, like, you know, how. What are the consequences of getting this Kind of thing. Wrong. Right. So, you know, there, there are the systems that I tend to work in. There, there’s. There isn’t a ton of margin for error, let me say. Right. Like in that. That’s not to say there are a bunch of systemic faults, but it’s the kind of thing where if you’re sort of bumping up against sort of some massive change in the threat model for a system or something like that, you have to be really explicit about evaluating what is changing and how any assumptions that are built on top of that are going to change. And so when I sort of am thinking about, okay, should we kind of go down the path of really reevaluating this or should we not? It’s like how much load bearing stuff is built on top of this assertion or assumption. And usually that’s a good place to say.
David: So when a component supports a lot of load bearing stuff, does that add to or detract from sort of the impetus to reevaluate it from first principles rather than sort of defaulting to your priors?
Bryan: In the case of a load bearing component, when there is just a lot of infrastructure built on top of something, it tends to be. People tend to have an opinion about the thing, right? Like, is this doing a good job, is this doing a bad job? Is it meeting the requirements of what we have? Is it not? And I think that there are a number of places where you can sort of decide to throw something away or rebuild it because it’s not interesting, or it could be built in a more sort of interesting way or could do some more stuff. But if it’s a relatively simple thing and it does its job reasonably well, and it’s sort of meeting the set of metrics and things that you need, then it may work. And so you have to sort of decide whether to graft a new bit of functionality onto this thing to either completely slot a new thing in its place and either migrate old stuff onto it, or say, okay, this is a net new application, we’re not going to migrate anything onto it. I think that it’s very situationally dependent. If it’s a thing that no one owns and no one thinks about and it does its job, but, you know, no one really understands it anymore, that that can be like a good opportunity to either investigate or build something new. But I think we sort of often tend to, you know, look at those components and decide to build a new thing just because it. No one understands it. And in a lot of cases, like things that are, that exist in that space of like, maybe they aren’t super well understood, but they’re kind of quietly doing their job well, you know, those things can last a long time. Yep.
David: I want to switch gears a little bit. So you mentioned you gave some examples earlier of like the type of work that you did, especially early on at Stripe, where like you were sort of looking ahead and finding sort of the things that needed to exist or like the examples you gave were kind of teams that needed to exist. Right. And I’m curious how that maps to your work today. Like, are you, is that still a big part of the work is like, okay, this whole area is understaffed. Let’s sort of like make a case for staffing it. And if so, is that primarily like within the Traffic Org or is that like throughout all of Stripe? And then also what are some examples of other work besides that? Like how are you engaging with specific projects that are happening inside the Org and things like that?
Bryan: All right, so that’s a two parter. So as far as the way that that has shifted over time is that I think we think about it less in terms of teams these days and more in terms of whether the things that we have built are going to meet the needs of like our future selves. So when I, when I’m doing that sort of exercise of like looking into the future and trying to, you know, take a, take a, sort of, take an eye at the systems that we have built and whether they’re going to stand up to, you know, either changing requirements or sort of future regulatory or security standards, that sort of thing. It’s not necessarily about, you know, okay, we need to do this thing and we don’t have a team for it. We haven’t funded that. Instead it’s like, is there some aspect of this system that’s just not going to hold weight because there’s going to be a functional requirement change somewhere down the line. The interesting thing about engineering at Stripe is that there are so many different stakeholders in many of the things that we build, Right. There’s like what the product teams want to deliver, but then we also deal with so many different audits and compliance type sets of requirements. And that environment is changing just so much. And so what is interesting about that is that it’s really about requirements changing and sort of going and finding the things that we’re going to have to contemplate 12 months down the line, six months down the line, 10 months down the line, what have you, and making sure that like, you know, if we’re making trapdoor decisions today that we are really sort of thinking about those future cases. It’s hard to look too much further out. But you know, it’s always, it’s always easier if we have a good understanding of what’s coming to be able to kind of build some flexibility in early on. And the challenge is just figuring out how to build enough flexibility in without building something that doesn’t actually solve for any particular use case. I dig into it pretty deep in terms of the projects that our team is doing. I’ve always found it’s best to have sort of strong partnership with the EMS in our organization. I know personally that, that I just don’t enjoy solving em shaped problems, but I think that, you know, the most valuable partnerships that I’ve had have been sort of with you know, the ems that that sort of support the teams that I work with. And so usually what, what sort of happens is I, I spend a lot of time working sort of directly with either EMS or ICs but kind of use the sort of signals that EMS are sort of sharing on the ground as to this person needs a little bit of help with this thing or they’re not sure who to talk to or it doesn’t feel like they are confident in their design or they’re confident in sort of one aspect of this or like they really can’t figure something out. And so we’ll sort of engage directly in a lot of cases. I also sort of spend plenty of time reviewing design docs and project briefs and things like that and trying to give both constructive feedback. And I think that’s where that forward looking stuff shows up, right? Where like the way that that feedback tends to show up is I’ll just sort of be like okay, hey, have you contemplated this thing that I think is going to happen? And maybe here are a few folks you can go talk to about that. I try to give constructive feedback on those documents in that way and dig in and help folks be rigorous in thinking about what they’re doing. I tend to get involved quite a bit in incident response and follow ups to incidents to try to help folks figure out gaps in the way they’re thinking about remediating certain, certain aspects of incidents. That’s sort of all lateral and downward, right? Like a lot of that is, is how traffics projects are organized. But we have a lot of sort of partner organizations, we work with a lot of other folks and I think engaging with, you know, my peers across those other orgs is something I spend a lot of time Doing do like a lot of one on ones. Like probably an excessive number of one on ones, but I find them to be just super helpful. Cool.
Alex: I’m going to change gears a little bit. One of the things you talked about is that your early time at Stripe, you were looking at projects that you felt like were under invested in and then you chose to start investing in it. I’m curious, from then until now, when you choose to work on something, how do you know that the work that you’re doing is aligned with the organizational goals? We’ve talked a lot about this, but I think there’s a lot of nuance in once you’ve chosen what to do, how do you make sure that you’re doing the work that is most valuable for the organization?
Bryan: Gosh, I wish I had a good answer to that question. I check in with my manager a lot on that and try to make sure that he is aware of what I’m doing and gut check most of that stuff with him and say, hey, does this seem like the right thing to be investing in? I tend to kind of, I jump around a lot and so maybe I just sort of hedge my bets there in terms of where I dig in, work on just like a lot of different things all the time. I think in general, a lot of it goes to having sort of a vision and an understanding of what I think we should be working on and trying to sort of check it against that, Which I could say it was more methodical and intentional than that, but I think I’ve sort of managed to establish a reasonable amount of trust within our org and sort of with our sort of partner orgs and kind of can drive things with a reasonable amount of agency.
Alex: There’s cool, is there, when you look back on the investments you’ve made, are there any signals that you use to be like, oh man, that was a great decision. Is there a consistent set of signals that you can index on to know that you’ve done something valuable in the past?
Bryan: That’s a great question and a really tough one to answer. I think in retrospect, one thing that’s sort of part of Stripe’s culture tends to be kind of writing these shipped emails where we kind of send out a note after completing a project that kind of describes the work that went into the project and the results. When you can write a great shipped email, you sort of know that the project went reasonably well. Some folks take that to go write the shipped email ahead of time and use that. I think that’s a common Tactic is to sort of write the celebratory press before you actually complete the project because then you sort of know. Not sure I believe in that approach just because I feel like no plan survives contact with reality. And I think that sometimes the initial sort of exciting draft can get sort of ratcheted down when you like, find out all the constraints that you run up against and that sort of thing. But you know, in my mind, like, the best things that I think I have built have been things that have been enduring. So they’ve sort of stood the test of time, not necessarily without augmentation. Right. So we’ve, I’ve, you know, worked on plenty of things at stripe that have been, you know, the basis of new things that we have built. But I’ve also worked on a couple of things that have largely survived intact, for better or for worse, since I sort of last worked on them. So I think that when you are able to build something that stands or survives or isn’t sort of immediately replaced, it’s a good signal. I guess that’s an obvious one. I think often, and this is maybe something that’s interesting, is that my sense is, my experience has been that it’s been sort of a counter indication of early interest. Right. Like, I think the best things that I have built people have not really been excited about until they shipped, which probably means that I’m terrible at marketing. I think that sort of many of the things that we’ve worked on, that I’ve worked on with other folks have just been. We’ve extracted a substantial amount of value from them, you know, sort of after they were delivered. But it was like upfront, it seemed. They seemed somewhat risky. So I don’t know, I don’t have a great idea of like what makes a project great. I think I have some intuition and, you know, I can get really excited about things and sort of how they can sort of nicely slot into systems. But, you know, I think that it’s unclear that that excitement is a leading indicator of success.
Alex: I think that totally makes sense. Do you feel like in a sense you feel like your batting average is what it should be?
Bryan: Right?
Alex: Like not everything going to work, not everything’s going to fail, but you are going to do enough things right that things result in value over time.
Bryan: I think I’m sort of bewildered by the fact that I managed to seem to manage to do that. I really, I think, struggle from pretty crippling imposter syndrome. I’m not sure why I’m on a podcast talking about the work that I do, like, I have no idea. And I think that getting some sort of validation after the fact is really helpful and useful. But I think if I were, you know, I think I come up with a lot of bad ideas and I’m wrong about a lot of things a lot of the time. And occasionally a good one sort of like comes out and we, we manage to do things. But I just, my batting average is probably pretty low. Like I, you know, I’ve been, I’ve had a lot of bad ideas. I think it’s just that I managed to like course correct very quickly when that happens.
Alex: I appreciate, I think we all understand that feeling of imposter syndrome, but I have to tell you, as someone who’s worked with you, you’re doing a pretty good job, dude.
Bryan: I mean, that’s really nice of you to say, but you know, it’s, it’s a real challenge. I think at times I think it is, it is just one thing that I sort of do to combat that or at least do that is to sort of be explicit when I am like when I, when I take a position, I’m like, I like very much could be wrong about this, but like, here’s why I think this is a thing or here’s why I believe this to be true. I may be wildly wrong, but let’s talk it out together. And usually in a one on one situation, a key there is just sort of making yourself vulnerable and typically the person you’re talking to is sort of experiencing the same thing. I think that there are personalities that can loom large and I don’t believe that I’m one of those personalities. But I think my experience with other folks have been like, oh, you came into this meeting and I was really intimidated. I’m like, who am I? Like, I don’t know who I am, what I’m doing here. And you know, I try to spend a lot of time just when I work with folks just be like, okay, look like I don’t have, I’m not blessed with any magic understanding. Like I just read a bunch of emails a long time ago and so I’m happy to be able to like talk this out with folks. But yeah, I am just intimidated by a lot of the folks that I, I meet and work with because. And I try to just sort of make sure that I’m separating any reactions that I have to things and being rational as best I can. But it is a really hard thing to sort of overcome imposter syndrome and value your ideas. And your work.
Alex: Something that I am having this conversation, something that I’m struck by, sort of like an experience I had multiple times over our time working together, was that I was a fairly inexperienced engineer at the time. And so, like, sometimes I would run up against at the end of my technical knowledge and I’d be like, oh, I’m at the end here. I can’t see past this point. Like, there was a problem in the C code or there was a problem with the server that I was using, or the browser wasn’t working exactly the way. And the experience that I remember having is I would talk to you about it and you’d be like, oh, it’s cool, let’s just go look. Let’s dig a little bit deeper, let’s dig a little bit deeper. And I remember times we would end up deep inside some C code base and you’d be like, oh, here, this is where the problem is. And it really impressed upon me personally. I was like, oh, well, there’s always a level below this one. There’s always another level we can go. And as long as our problem is defined, we can keep digging and we’ll figure it out. And I was curious, is that something that you feel like you have learned over time? Is there a specific experience that taught you to do that? You know, or is that just, Is that just the Bryan Berg special?
Bryan: I don’t know. I don’t know. I still do that today. Right. Like, that’s like. I think that one of the things I spend plenty of time doing is like, trying to figure out how to get folks unstuck by just being like, it’s just, there’s just some code there. Like, let’s just go dig a little bit deeper and find out what’s under there. Or, you know, I have this intuition about how the system on the other side of this, this, you know, network socket works, even though we don’t really, it’s not operated by us. But like, you know, here’s how I think it works. Let me, you know, dump some state on my mental model and like, maybe with, with some of that context, we can kind of figure things out together. I honestly, I think that is a skill. I think that some of the folks that I have seen possess that skill just like, astound me at how good they are. Like, I’m a rank amateur when it comes to that. Like, I can read code, it’s fine. But like, I, you know, when I, I think the stuff I’m inspired by there is like reading, reading Project Zero blog posts and things like that. When it’s like they build the sort of enormous exploit chain, you know, or something and like they’re like picking through assembly and like are able to make these amazing inferences and I am like nowhere near there, but I don’t know. That skill of being able to sort of just push forward and pierce through an abstraction and dig into the code underneath or spend a lot of time kind of trying to form a mental model of a system and reverse engineer it or whatever and then do that I think is very much a skill. It’s one I, that’s what fun in engineering is. That just entertains my brain and that’s why I gravitate towards that work. It’s gratifying to unstick people when you’re like, cool, let’s go figure this out. That’s fun. It’s a good nerd snipe. Really interesting thing to figure out, but I don’t know where I acquired that skill. For me, my early experience with computing was being on the other end of a really slow dial up link and trying to sort of piece together the world on the other side. And you know, I started using the Internet in like early 90s, right. And it was just a wildly different place. And there were, you know, if you sort of start your career today, you start your career sort of in the, in the near future or just in the recent past. There’s so much the world so welcoming, I will say, right? Like there’s so much open source out there where you can dig into things. And I feel like I started my career in a world where I didn’t barely had access to sort of dig through those things, you know, like there was a lot more proprietary software, there was a lot more sort of multi user systems where you like weren’t able to kind of see the, the sort of the bounds of what, of what was out there. And I think, you know, again there was that curiosity that I just found myself with a surplus of. And so that I think that’s where that skill came from for me was just having to sort of sort of tread, you know, survive in the world of like, you know, I’m being so, so fascinated by what was available out there, what was there and seeing so much potential in it, but also not really feeling like someone’s going to go explain it to me or whatever. I had this really interesting experience with someone at Stripe really early on when I was explaining that the first programming language I’d ever used was Logo. I remember pretty vividly Being in kindergarten, my school had these like little like TRS 80 computers, color computer 2, pretty exciting stuff. And there was like a little, you know, it was like a game cartridge, like a pack with like a logo interpreter on it. And you know, I just, I sort of knew and it clicked for me when I could draw, you know, a triangle or a square with the turtle. And they were like, oh wow, like you grew up writing logo. Like that’s just like Lisp. And I was like, that wasn’t like lisp to me as a six year old. That was like I draw a square. And there wasn’t a way to make that leap in terms of going from this is a thing that lets you draw squares or a star or a circle polygon on the screen to learning scheme or whatever. There wasn’t a way to make that jump at the time. And I feel like if you start today, the sort of abstractions you get are so powerful that you, you don’t necessarily have to kind of brute force your way all the way up. And I think again, that is a very long winded way of saying that. I think where I got that that particular skill was like just very early in my career having to, having to sort of figure it out without having a lot of manuals or documentation or whatever and you know, having to go sort of like figure stuff out from. Not from first principles, but without a lot of, of that to help. And it feels different today in a really cool way, honestly, but just different.
David: I’m tempted to pull at the string of sort of the differences in generations of programmers, but I feel like, yeah, that might devolve. The question that I have is actually going back and this is sort of getting away from unfortunately the fun hacky bits and getting back to sort of like the organizational hacking. But you’ve mentioned a couple times now that like, you might not phrase it this way, but like you’ve identified these areas of ownership of like problems that exist that currently nobody is focused on and you think someone should be focused on. And like, it sounds like you’ve sort of solved that problem enough times or seen that situation like unfold enough times that I’m curious if you sort of have a playbook around it. Like, I think that ends up being something that staff engineers run into a lot in their organizations is like, there’s this thing that someone should be working on. No one’s working on it. And now what? I’m curious how you approach it.
Bryan: Yeah, in general, I think I just try to really present a consistent message There, right. If I’m going to go, I want to make sure that as many people as possible who are responsible for making a decision around that, hear the decision here. Advocacy for the creation of, of this thing. I think in the early days of Stripe, when I was finding a system or an area that needed sort of development, it wasn’t like I could create a team to work on it. It was like, okay, I just have to go like, make some progress on this thing. And you can’t own something if there’s nothing there. And so if we kind of created something, then it would be like, okay, well, it exists enough that someone has to take care of it. Now as far as doing this, I think that you can go and write Charter a vision for a team, create it kind of by fiat where you say, okay, well this team needs to exist. Because I think it needs to exist. And I don’t think tech leads typically have that power. I certainly haven’t acquired that power. There are managers that can do that, I think, but it’s not something that I’ve ever been able to snap my fingers and make that appear. But instead I think talking about the impact that that might have, building the sort of the narrative and really telling a good story, I think is really key to that. So if you can sort of have a pitch and have a focus for like, okay, this thing needs to exist. And here is why. That to me is like the most powerful tool. Is it a playbook? No, it’s very situation dependent, I think. But my sense is that if you can kind of whip together a compelling narrative for a team and then just tell it to anyone that will listen, it eventually kind of just becomes a thing. I think that there’s a big difference between saying we need to do something and writing down some metrics to optimistically talking about the impact and the, and the sort of good things that can come out of something like that existing.
David: So in the process of sort of like identifying an area of ownership, so to speak, there’s I guess this handoff that needs to happen where eventually, like, you know, there’s a new set of people that are going to take that concept and run with it. How have you seen that play out?
Bryan: Yeah, so I’ve had an experience doing this a few times and one of the things that I’ve found, one of the tools that I’ve found that’s sort of most important is to kind of write this sort of like optimistic state of the team in X months. So usually it’s like 18 months and usually it’s wildly optimistic, but what I have done in the past is like sort of worked with folks on a given team and written this sort of like optimistic view of Team X in 2023. And you kind of write this document in the present tense. So you say you’re wildly optimistic, you write in the present tense, you say all of these great things that are going to be true about the way that it’s going to be. If this team was wildly successful at all the things that it was going to do, what is the state of the world? And that’s not necessarily writing a shift email that says, oh, we did this X, Y and Z. Said in the case of one of the teams I did this for was one of Stripe’s security teams. And so we were able to sort of lay out all of this beautiful sort of sci fi future where we understood or we are able to outline what was great about that world, what were the amazing things that we had accomplished such that the experience of the average person interacting with the system was so good. So we talked about managing credential storage and so here’s the flow that a typical user goes through to create a new credential that needs to be in our secret store as an example. And we were able to create this narrative in this thing that we were like, oh, wow, wouldn’t it be great if that actually happened? The document did not get the timeframe that I set on the document. Definitely didn’t meet it. But as I. It was this enduring sort of artifact of like, here’s how good these things that we could build would be. And I talked to one of the engineers who like, you know, two years later was kind of working on building some of this stuff and he was just like, yeah, we just kind of executed on that, that plan. We like kind of had this thing. And so, you know, it was something that we formed in with the team. It wasn’t something that I came up with on my own or anything like that, but I laid the framework and then we filled in a lot of details and we wrote a pretty detailed sort of description of the future state. And it was super helpful for us to kind of drive things along. So I would, I would recommend that to anyone as a way to sort of create vision and create like excitement towards, towards the future.
David: That’s very cool. And it’s a really good approach. I think people think about vision documents and it’s like hard to understand sort of what, what that concretely is. But I think it’s just as you Say it. Just zoom ahead a little bit into the future and write down what the best version of everything would be. And there you go. That’s your vision. I like that.
Bryan: Yeah. Visioning feels very abstract, but if you can actually like, go and sort of concretely feel out some of the details of the thing that you’re going to build, what the state of the world is going to be, it just feels more real, like it feels attainable as opposed to being something that is. Is, you know, more abstract.
David: And it also simplifies every planning process until then because it’s like your roadmap is already there. You know, where you’re. You know, where. What your North Star is. That’s pretty cool. We’re rounding the bend on time here and there’s two questions that we generally ask everybody. The first one is, are there any resources? And this could be, you know, people, blogs, books, whatever, but any resources that you’ve encountered in your sort of path that you would recommend to other folks who want to be really good technical leaders.
Bryan: So I’m going to answer this question in a weird way, which is to say these are not necessarily technical resources, but, you know, in my mind, being able to be persuasive and sort of convince other folks of the sort of merits of your ideas is an incredibly sort of important and powerful thing. And being able to take ephemeral conversations and make them sort of last and be shareable is really important. And so, you know, in my mind, being a good writer is like, sort of actually one of the most important things to do. And so I don’t have any, like, specific resources. There’s like a number of like, writers that I sort of really enjoy. You know, I don’t know. I really enjoyed Matt Levine, who’s a writer for Bloomberg, writes a great comic called Money stuff. I really enjoy some of the writing that sort of he has done in that it’s just like punchy and funny and like, sticks with you, like. And like, I sort of aspire to come up to be able to write like that. I think that Will Larson again, is like another person that sort of has managed to kind of. His blog is sort of great about finding like, he’s good at sort of capturing anecdotes is really supposed to be pretty fantastic. And, you know, just I think generally most of my things about like, find your. Find your voice and figure out how to sort of like, write well, I’m a much better written communicator than speaker, as everyone listening could probably attest, or at least attest that I’m not a great speaker. But. But yeah, there’s just a lot. I take inspiration from interesting writers rather than necessarily writers on technical subjects, if that makes sense.
Alex: Yeah, totally. So the last question we like to ask is how much time do you spend coding nowadays?
Bryan: What’s coding again? So I spend a little bit of time. I think what I tend to do is I will try maybe once a week to go find some sharp edge of a system that someone else is going to spend a ton of time trying to sort of figure out and then refactor and fix and clean up. And I still enjoy the dopamine hit of committing a change and deploying it. It’s second to none. And so the places where I try to deploy my coding time are on things that I can probably try to. That no one’s going to have to deal with ever again and try to sort of clean up things and fix small sort of annoyances. And so that’s where I spend most of my coding time. But it is pretty, pretty rare that I get to do those these days.
David: The number of services that we deploy to today versus what it was like when you started this stripe is probably different. So maybe it counteracts you maybe spend less time coding, but you get more of a rush when you’re done. I don’t know.
Bryan: I find it particularly satisfying to just like kind of clean up, you know, tiny, tiny pockets of debt. I don’t know. I love that. It’s great.
David: Awesome. Well, Bryan, thank you so much for taking the time today. It’s really been fun to chat with you.
Bryan: That’s it.
David: Thanks so much for listening to staff Inch. If you enjoyed today’s show, please consider adding a review you on itunes, Spotify or your podcaster of choice. It helps others find the show and is a really useful signal to us that folks are finding value of this so that we keep doing it.
Alex: You can find the notes from today’s episode at our website podcast.staffing.com the website also has our contact info. Please don’t be shy.