Building scaleups without hero culture

Rebecca: Hey Andrea, how’s it going?

Andrea: Good, good. How are you?

Rebecca: Excellent. I’ve been waiting to get you on this podcast since, I think, the first day I met you was your first day at the job that you’re in now.

Andrea: It was, yeah. My first day.

Rebecca: Let’s start by: who are you?

Andrea: Yeah, absolutely. So I’m Andrea Corey. I’m VP of Engineering for platform engineering at Homebase. And what we build is really the operating system for hourly work. So it’s a platform for owners and managers to manage their hourly work schedules, team roster, even do payroll. And it’s also a legitimate platform for the employees to have a better work experience as hourly workers.

Rebecca: You’ve been there for — I met you in June, so it’s coming up on a year, but not quite. Before we jump into your experience there in those precious first nine months, where were you, where’d you come from?

Andrea: Yeah, before that, I was at FreshBooks, and I was doing probably a similar role, where I had a number of what we call technology teams or subject matter expertise teams reporting in to me as the VP there. Prior to that, I was at a startup, Nudge.ai, and was with a really small crew there. We built that for a while. Unfortunately, it did not last. After about five and a half years, we had to shut it down.

Prior to that, I was at Eloqua for about 13 years. I was there from almost the very beginning through to IPO acquisition by Oracle, transition, fun stuff. So that was really formative for me.

Rebecca: Yeah, I bet. So you’ve seen a lot. Maybe you were just in the AI space, but too early. Maybe now you can bring back Nudge.ai, and just because it has AI in it, you’d be golden.

Andrea: Yeah, I know. We were trying to build a relationship intelligence platform, which is sort of a new space. At Eloqua, we concentrated on the marketing space, so we created the first marketing automation platform. And, at Nudge, we were trying to create a relationship intelligence platform to really help salespeople, and other people who do work through relationships, help them understand their opportunities and how they were selling based on relationships and all sorts of fun data. It was super fun. We couldn’t make it work financially and some other things.

Rebecca: Right. But super fun. I would have paid money for that. I’ve wanted something like that. Even just internally, if you’re working at a large enough company, just being able to understand who’s who and when did I last talk to them and what’s their kid’s name? And I can’t imagine being a person working outside business. Because I’ve definitely wanted that visibility because it matters so much to getting things done.

Andrea: Yeah. And we were able to start figuring out a way to measure the relationship strength, which was super, super interesting. And yeah, potentially valuable, but unfortunately, as these startups go, they don’t always succeed.

Rebecca: So your work at FreshBooks was kind of a scaleup, as I understand it. And now you’re in another scaleup. What keeps bringing you back to the scaleup versus going and doing the startup again or going to the big company?

Andrea: I find startups super fun. It’s really all about the team and working really close together with that team and taking that idea and trying to find the product market fit, which is super fun. The scaleup is fun in a different kind of way. The opportunity to have impact and to take somebody’s idea that’s found to be working well; they’ve figured out a way to make money off of it, they’ve figured out a customer, or several customers, depending on the case. And it’s about making that bigger, more efficient, growing it, just really harnessing that. And I just find that so interesting because there’s such opportunity to make so much impact.

Rebecca: I found for a long time in my career that there was a certain size where companies started to have problems that I found interesting. And I definitely love the scaleup problems because, yeah, it’s like the stuff that used to work doesn’t work anymore. What’s been your experience with what stops working when you get to — and maybe you could even talk about the milestones you’ve seen and how you’ve seen things change?

Andrea: Yeah. I mean, one thing I’ve seen very clearly in several places is that, in the earlier days, you have these one-to-one relationships that work really well. So everybody knows that Maria does this kind of work or Jose is the expert at this or whatever. And people work one-to-one based on relationships. And as you grow, you start to form into teams, and the work has to move between teams, right?

Because A: it can cause a person to get stuck in that role of Maria being the person who does X. And usually, she probably doesn’t want to be stuck in that single point of failure role or always feeling stressed about she’s the one who knows X. And so one of the things I find, it’s a habit that you have to break almost for those who’ve been around for a while, is how to build up that capacity through teams. And how to do those relationships between teams and the communication between teams.

It gets more complicated, right? There’s just way more individuals. And so to work at the individual level starts to explode and you can’t really keep track of the work and the information and what’s going on. And so I’ve seen teams that start to get really bogged down because everybody is slacking different people individually and they can’t see the scope of their work.

And if they’re already dealing with toil or things like that, they can’t even actually get a handle on the amount of toil they have. It’s really about creating an interface to the team, if you will. And it feels heavy, it can feel like a heavy process thing at the beginning, but it almost always makes things better and more efficient because the team is able to better prioritize to the most needy uses. They’re able to actually add things to their roadmap when they see that four different stakeholders are asking for the same thing. It starts to unlock potential, actually, and so you have to implement in a way where you see that unlock, as opposed to creating a wall.

Rebecca: Going back to Maria, who is the one who does X, it seems like there’s two needs here. One, there’s the cross-training on X because you don’t want Maria to be the only one. And then there’s also the freedom for Maria to go pursue a broader career path, perhaps doing Y, which is like X but different. But I’m curious: what other functions do teams serve in an organization? This is kind of a meta question. What is it? What is a team? And how do you think of "Oh, I need a team," or "This deserves a team,” or "This is not a team?"

Andrea: Yeah. Well, I think, in my area, in platform engineering, we tend to have some subject matter expert teams, right? So a team that’s responsible for our front-end componentization and our front-end testing strategy and things like that. And they become both the team that’s creating some building blocks for the rest of the organization to build on top of, they become a source of expertise and guidance. They might be creating some standards. They might be ideally helping to accelerate the development by making things easier for other teams, so they don’t have to wrestle with exactly “how do I implement this style guide? Oh, wait a second. I can use this design system. I can just get this stuff and stop wrestling with my CSS all the time or whatever.”

Rebecca: That’s a great example of a team where you’re providing that subject matter expertise, but also functionality and optimization. What are some other teams in your organization, and what are their remits?

Andrea: In the organization as a whole, obviously, there are other teams that are more focused on a particular domain. So, for us more on the product engineering side of things, that might be our financial services product or payroll product. We’re the team that manages and builds out the product around team roster and scheduling and time tracking, having the domain knowledge and being able to build out those areas with the product owners, the product managers, the designers who really understand those areas, they understand the user and what the user is trying to accomplish. So that’s another type of team.

As companies scale, you know, I used to be a person at a startup who could dabble all over the place. It starts becoming very challenging to maintain that all in your head. It starts really being actually inefficient as well. At the startup phase, lots of people wear lots of hats. They move around seamlessly to some degree. We can pick up an opportunity over here really quick and start jamming on it and working on it. But as the scope of users and as the size of the features grow, it becomes really challenging to start to do that.

And, I think, an engineer, you can start putting them in a position where they’re not actually doing their best work. If they’re having to dabble across a number of different things versus really understand their domain well and work on building that out, leveraging some of the components that maybe a platform team has built. And they can really have a more focused mission, if you will, and understand how their work impacts the organization and the users.

Rebecca: That cycle is really interesting to me. How you started a startup and “you work on whatever you want” and “you better be able to work on anything we need.” Right? And then you do, I don’t know if it’s literally the same engineer, but then you do need to zoom in and, “All right, I’m going to learn about payments.” And then later emerges the staff and the principal engineer, who somehow has learned about everything anyway and can operate across these domains. So, are you at the point where you’re starting to see that?

Andrea: I mean, I see that we now have a forming group calling our tech leadership group. So those staff and principal engineers you speak about. And the way I’ve found those groups to typically work really well is if those engineers have a mix of skills. So they might have deep expertise in one particular area, as you said, payments, but then more broad experience across a number of other facets.

For example, I’ve got a principal engineer who knows a lot about data, data engineering, data science. He doesn’t know a lot about the front end. That’s okay. We don’t need him to do that. I’ve got some engineers who know a lot about software architecture specifically, and they can apply that.

I see almost these, ideally, overlapping skills that come together as a monster Venn diagram that end up covering a space. And so, people’s expertise might be somewhat unique, concentrated in some areas, but then it goes broader and touches on a number of different things. And we can get people working at the intersection of those boundaries or at the overlap layers. “What should be our software architecture?” Great, we have a number of people who can bring their perspective together to start charting a path to our future software architecture, as an example.

Rebecca: I’ve been in those senior ICs, sits in a room with a bunch of other senior ICs and talks about all the great stuff that we should do. How does that turn into reality?

Andrea: Yeah, that’s a hard one. I’ve been at this a bit before, and there’s often an early phase of the storming and norming that happens. I usually find that if you can define some actual tangible wins and start building upon that, that’s really helpful.

So one example of what we’re doing right now is we’re starting to work on some of the ways we make decisions, our decision-making frameworks. And we’re not going to try and tackle it all, but we’re going to tackle one discreet thing and then another discreet thing. And that helps us give the team-forming tools to start to do that. And I don’t need everybody to contribute to every topic, but ideally, a group of two or three go off, and maybe they create the first version and they come back, and then we can all ideate on that further and refine it a bit.

So we’re doing that kind of thing. We’re also starting to chart out some patterns around events and things like this. And so we’re dipping our toes into that, we’re dipping our toes into event storming. And so we’re consciously exploring specific ideas that we think can start to help all the teams, so it helps when the different engineers can see an application to their team.

I should state one thing. All of our principal and staff engineers, they’re in a team. They do day-to-day work with the team and they also do this cross-functional, cross-organizational work. So they’re sort of centered in a team domain, and then, ideally, they can take the things we decide or the learnings we gain, and they can bring that back to their team. They act as champions. They’re also championing with the tech leads, which is a group of folks who are leading projects and initiatives.

So, yeah, I find that that storming and norming, A - just recognizing it and knowing it’s going to happen is a key thing, right? You have to expect it and not get too frustrated. And second, start to get some small wins, start to see how people work, start to see where their expertise is the deepest and what kinds of things do they want to work on? Some people would like to work on more of what I call the engineering practices, these ways of working. Other people might want to work more on the actual architecture, and they’re off creating C4 diagrams and trying to figure out the world. That’s perfect because we want a different mix of motivations.

Rebecca: It sounds like Homebase run this more as a working group and less as a — I think we, in my past, we kind of invented problems to talk about rather than having a set of the problems that we agreed, and the business agreed, needed talking about.

Andrea: Yeah, I think, in this case, I’ve started with a bit of an opinionated point of view of, “Hey, here are some things that it really would benefit us to solve for.” And I think people have largely agreed because they’ve seen those problems manifest. I’m sure we’ll get to a point where we’re going to start having violent debates about something. We’re not quite there. I think we are coming together though, and starting to figure out how to work together, what each person is best at, or is skilled at, and how to interface, like I said, at the boundaries.

Rebecca: So coming back to Maria and actually zooming out for Maria. So this is great, you’ve reduced your bus factor and Maria can go get a new job. How are you facilitating that conversation between teams, or among teams when it’s even more than two? How are you making sure that you don’t become so siloed that they’re cut off, yet experience the benefits of being siloed in that you can focus and understand your domain?

Andrea: We have a weekly meeting with all the engineering managers; folks are bringing up, A: how’s their road map going? And not every single team. It’s a rotation of teams, so it might be three teams every week. What they’re blocked on; what are some of the opportunities? What are they working on? So, it’s information sharing and awareness. It’s also like, “Hey, I’m struggling with this.” So we’re trying to create that mindset of sharing out purposefully, be it opportunities, problems, “Hey, I’m working on this,” et cetera.

So, what I’ve found is sometimes teams go away and work on a thing. And they don’t realize that there’s some other team working on something very similar over here. And neither of them ever intends to do that or go in a different direction or whatever, but it just happens because we’re all busy, we’re scaling, we’re trying to figure it out. We’ve got lots of business pressures. We have things to do. We’ve got roadmaps. So that intentional sharing out of both progress and opportunities and blockers can really help, like, “Oh, hey, I can help with that. Well, actually, we tackled that last month.”

It sounds pretty simple. It’s not a super complicated thing. I mean, it’s a bit like your scrum of scrums, I guess. It just depends which words you want to use on it. It’s slightly different from scrum of scrums, but yeah, I’ve found that a well-run meta group of people sharing that information goes a long way.

Rebecca: And that makes sense in the execution phase to be talking about what are we seeing. How about in the planning phase? What does that look like?

Andrea: That’s somewhere where we are struggling a bit right now, I’ll be honest. And so, we have actually been in some pretty deep conversations over the last month or two about figuring out what is that step from opportunity and awareness of a problem that could be solved into acceptance and getting it onto a roadmap and starting to work on it. And what’s the role of product and design and engineering? And then I’ve got my data team over here, which is sometimes brought in pretty late. So that’s one where we have a lot of work to do. I think we’re at the awareness of the problem stage and starting to figure out some solutions, but yeah, that can often be a sticking point, right?

Rebecca: When you have, and this is such a common thing in scaleups, you have the person who knows all the things. And it’s really convenient to have a person who knows all the things, but that person then can’t do anything except know all the things. So how do you avoid that hero culture where you have to call this person because there’s nobody else who could possibly help you?

Andrea: Yeah, and I think there are different Marias in this equation, right? Because there are some people who kind of thrive on being that person and maybe are having a hard time thinking about what does it look like as these teams grow and as these things get bigger.

Where do they fit in? And some people go through a bit of a questioning phase of “how do I stay useful?” And then there’s other people who actively know that they do not want to be the bus factor. And so I think some of it depends a bit on who this individual is and what is motivating them. So if the motivation is that this person knows they don’t want to be that bus factor and they are actively looking for help and assistance, you’ve got a pretty easy path. You find a way to cross-train, you pair them up with a few people or a team, or you move them around a little bit so they can distribute their knowledge. There’s a few different ways you can do it, depending on the expertise.

But I think you also have the challenge where a person, and, I’ll be honest, I’m a recovering hero myself. I know there was a moment where, at Eloqua, I was the person who knew a lot, and I was the person who held things together on our system, and I was the person. And it felt both like there was a sense of pride in that, and there was a sense of dread of, “Oh my God, it’s on my shoulders.”

So I think there’s a lot of coaching and/or mentoring, depending on the person, that can go on with Maria to help her see that she can provide a ton of value, even if she isn’t that hero that’s called upon in emergencies all the time or that is the go-to person on all these different topics. And it’s about, in that case, slowly peeling them off in a very intentional way and helping her walk through that and understand that she has a ton of value in the organization when she isn’t being called upon all the time and when she can use that knowledge intentionally as opposed to reactively. So it’s giving her an opportunity, really, to take that on.

Rebecca: And it’s not just Maria who benefits here. When you have a Maria, it can be a real process bottleneck when, “Well, I need to talk to her about how to architect the system, except she’s busy resolving the three events from last week that only she knows how to fix”, right? That’s such an important thing, too.

And I have been a hero and I have had heroes reporting to me before. Sometimes, appealing to that benefit to the company, because the benefit to the person, they’re like, “I don’t mind. This is great.” Appealing to that benefit, really laying out the consequences that they’re having for the business as a whole, even though that firefighting dopamine sure does feel…

Andrea: It does. It does in the moment.

Rebecca: I can still remember specific event numbers that were especially exciting.

Andrea: I’m sure you can.

Rebecca: A little bit more about scaleups. You mentioned events, or incidents or whatever you want to call them. That’s a real thing that becomes real. You get more users and systems stop working the way they used to. How are you thinking? I’m sure as a platform team, you are an active part of conversations about incidents. So, how is that changing in front of you as Homebase grows?

Andrea: I would say that I take a very intentional approach to incident management. I want the practice of incident management to be well understood. I want the reasons for an incident to be well described. I want the severities and the priorities or whichever lens you use to be very clear. And I want to drive a lot of insights from understanding the data that come out of incidents. And I want to do really, really good retrospectives to pull those learnings out and make sure that we can add longer-term remediations to roadmaps.

So, for me, again, in that transition from startup to scaleup, often incident management is just a way we do things. And again, it starts falling over because you can’t have the same three people doing all the incidents, or the same three people who know where that metric is, or the same three people who know where that log data is.

So we’ve intentionally created a role of an incident commander, secondary roles within the structure. I’ve written up basically a checklist, just like pilots have a checklist. It’s stressful! We all need a guide and a helping hand, right? So here are things to think about: When should you think about communicating? When do you need to pull in this type of person? How do you get help with this? What is the clarity on when to declare an incident?

It’s also not surprising that, as companies grow, different people used to call the person they knew. “Hey, so and so, I’m seeing something weird here. What should I do?” And that person knows. Instead, we created a very quick Slack bot that you can just type in ‘slash incident’, give it a name, and it kicks off the things. So, pages somebody, creates a Slack room, starts to get people working on it, posts in a particular place. I always pull in customer support in that, and I pull in different people so the awareness is being shared.

And it goes from a place where we didn’t always know that we were having incidents, because maybe a team was working on a thing. And they were trying to do all the right things, it just wasn’t necessarily made aware to the rest of us, and sometimes to management even, that this thing was going on over here that maybe could bubble up and become a real problem.

And so, to me, that awareness is extremely important. So now we have a, I think it’s like a four-step. “If this is happening, call an incident. If this is happening, call an incident.” And it’s quite clear, and so things that used to go to a dog food channel now might bubble up as an incident. Or things that used to mull around in a particular team and a particular thread, most likely now get bubbled up as incidents. We can start tracking those. The very first thing that happens is, “Oh my God, we have a lot of incidents.” Actually, now we just know about them.

Rebecca: Right, right.

Andrea: So I really need that data to see over time, what is going on. Is the severity more likely to be going down or up? Is the frequency more likely to be happening less often? I need to start to understand the baseline, so we’re probably at the stage where we understand the baseline now. And now it’s probably very soon heading into the, “Okay, what does this mean to us?”

Rebecca: How do you set goals around incidents?

Andrea: Yeah. So, the classic goal is your overall uptime, right? I mean, that obviously is a thing. But it’s A - it’s a pretty long term goal and B - two or three specific things can really spike that metric quite a bit. What I’m really looking for at this stage is just people adopting the practice and people recognizing their role in it, asking for help when they need help, understanding how to do those retros and how to capture the remediations or the learnings, understanding how to share that information. And having a review of the incidents – we’re just starting this now – a sort of a periodic review where we get together, and we go, "Oh, okay, we had this P1. Hey, here’s what happened. Here’s what we learned. Here’s what we’ve done to remediate thus far. Here’s what we’ve added to our roadmap." And to me, that’s when I start seeing, okay, we’re understanding the picture and we’re actively working to make it better over time.

And, to me, it then goes into a continuous learning. And so I found that by doing those things over the course of two years, you can see the number of incidents go down, and/or the severity is going down. They used to all be P1s, and now, often, they’re P3s because we’ve gotten better at detecting them earlier or we’ve gotten better at making some parts of the system more resilient, based on what we’ve learned. So, to me, I guess the metric in the moment is how many people are doing those retros, writing down their learnings and just literally collecting all that very valuable information and making sure that that is seen as a valuable place to put effort and time into.

Rebecca: So you’ve gotten to see, like I said, a lot of things and you’ve gotten to see some things a couple of times, like see a company go through a certain size and a certain type of growth. Is there anything that you notice that you’re doing smarter or sooner or better than the last time around where you’re like, “Ooh, I know this one, I’m going to get ahead of this.”

Andrea: Yeah, yeah. I think, A: I have experienced so many scaling pains in the past that I’m at the risk of feeling overwhelmed by all of the things. “Oh my goodness, we need to do X, Y, Z, A, B, C.” And so there’s been some intentional, "We’re not gonna do this. I know this could get better, or I know this needs work, but, quite frankly, it’s not on the top ten list right now.” So there’s some intentional telling myself to not worry about the perfectionist beast that every once in a while pops up. You know, I am a recovering perfectionist. So I do worry about a lot of things.

And so it’s about being intentional because you can’t change all the things at once. You’re taking an organization through a change and that needs to be done in a thoughtful way. So you need to start changing things, explaining why, getting that buy-in, bringing people together, and bringing them along with you or else you’re at the risk of just throwing a whole bunch of things at people, and they’re confused, they’re upset, they’re not understanding why, they’re not being brought along, and they’re not buying in.

Rebecca: That mindset is very smart and probably very effective and it drives me crazy to be patient. How do you keep that calm as things are absolutely going wrong around you?

Andrea: It is definitely like a self-talk sometimes about “okay, yes, there’s a thing over there that you’re just going to have to ignore for right now because you can only do so many things and the organization can only do so many things.” I think what I really try to look for is levers that unlock more than one thing or that have a disproportionate impact. And so maybe I can get into one example right now.

We were struggling with our flakes. Flaky tests cost a lot, both human time: waiting, builds fail, they try again, you’re just distracted. You can’t really get anything else done while you wait for that to happen. And also they just literally cost a lot of money on our CI bill. I mean, it’s a very clear dollar amount. And so we were struggling with this a little bit. And one thing I started to think about was: well, it’s not just about the flakes. It’s about teams knowing that maintenance is a part of their job and, in the early days of most startups, people bias to features, right? It feels great. A: you don’t have a lot of tech debt, you don’t have a lot of users. So you’re getting those features out, you’re focusing on that. You’re finding product market fit. You have to do that; there’s no other way to do it.

But you do get to a point, and I know you know this well, where the amount of toil and the amount of things that start to add up, associated with that way of working, starts to work against you. And so flakes in my head started to become emblematic of "Hey, this is a case where we have to go and pick the weeds. We have to go and tend the garden." You can’t just plant more seeds and water them. You have to also prune and you have to pick out the weeds and you have to get rid of those invasive species. And you have to do all this other work as well, or else, those weeds, they’ll happily take all the nutrients away from the soil too.

So we started to really talk to teams about flakes and we turned off retries. And that was kind of uncomfortable, and actually, predictably, it swung us in the wrong direction for a little bit because then it became very, very difficult to get a build out. But really, over the course of about six weeks, we’ve gotten it to the point where our main branch is now above 75 percent passing, sometimes up into the 80s for a whole week. We had, I think, 30 green builds in a row, which somebody who had been here for two and a half years said he had never seen that before.

And it also shows the possibility, right? That shows the possibility of this large diffuse problem because this is effectively one code base that many teams contribute to. This large diffuse problem can be made better with some levers, with some changes. And so, it’s been a bit uncomfortable, but with a bunch of repetition of why we’re doing this, why it’s important, why teams need to think about their flakes, and I’m sure that we need to do more. I am sure we have not communicated perfectly. I am sure there’s much more to do. I don’t want to try and say we’ve been perfect, but we’ve also given guidance, like maybe some of those tests we don’t need. Are they valuable? Should you just delete them instead of trying to fix them? Were they created six years ago and you don’t even know what they are?

So, it’s a way of thinking about the utility and the value of these tests. And so that then led to the front-end team taking on a role of setting some better standards, and then that led to us creating some champions. So each team now has a champion to go and understand the best practices for jest in the front end. And so it’s one thing that we started, but it starts to unlock a bunch of other behavior changes, both in teams learning and growing and knowing that, okay, "Hey, features are great, but I also have to tend the garden. I have to do maintenance on my code." And to start to set this notion of practices and "What is a good way of doing things?" So you don’t have to think up all the things. You don’t have to sit there, like, "how should I do this? How should I test this?"

Rebecca: On the flakes, I think the answer is pretty obvious that you have to federate that kind of work, that you can’t centralize that kind of work. But how do you, when you’re trying to drive these sorts of practice changes and clean up a mess, how do you decide how to federate versus centralize the effort?

Andrea: Yeah, I think there’s the, I’m sure you’re familiar with this, the topologies of a platform engineering team. You can do different models depending on what’s going to make sense for either the organization or the team. So sometimes you take one SRE or one subject matter expert, and you drop them into a team that’s having a problem, and then they co-create for a period of time.

Sometimes you develop a practice, and you launch it, or pattern, you launch it with one team, and two teams are working closely together to get that done. And then you go, “Okay, okay, good, we got to V1”, and then you go to the next team, and you get to V1.5, and then all of a sudden, you’re like, “Okay, this can be launched to everybody.” We’ve worked out the kinks, we’ve made the documentation clear, it’s working. So I tend to not see it as one thing fits all, but, literally, what is the problem we’re trying to solve? Who’s encountering that problem? And what’s the best kind of topology for solving that in the moment?

When I first arrived at Homebase, a number of my teams, for a variety of reasons, were on the unhealthy side. Either some people had left, or they had taken on things that they didn’t really know very well, and they were spread pretty thin. So the very first thing to think about there is health, getting the team sustainable. Because they can’t go off and create standards and work with other teams when they themselves are not in a sustainable place. I think that also pertains to the receiving team of any new standard. Are they in a healthy and sustainable place to be able to receive and take on this work? Or do we need to augment them more and give them more hands, if you will, to learn and grow.

Rebecca: I think that’s such an important point because I think that often the technical change is obvious. Like “fix your flakes, right? Come on!” But there’s a reason that people haven’t fixed their flakes yet. There’s a reason they haven’t done these things. And maybe that’s a team health reason, but I think that sometimes, especially senior leadership can be in “fix your tests.” And, at the platform engineering level, you’re like, "This is actually more complicated than we want it to be." I think that getting that trust in place is so important. I think of it as kind of table stakes for any sort of change that you want to make. If you don’t have that trust and transparency, then there’s a ceiling on what you’re going to be able to do.

Andrea: Yeah. Yeah. And when we first took off retries, I think we probably did it a little too fast. We came back and said, "Well, yeah, I know this is hurting some teams. I know this is not great. We’re going to try and keep working through it for another week or two." And, surely enough, we did. Again, that comes down to that patience you mentioned — the patience versus the progress and trying to find that balance. And it’s never a perfect balance.

Rebecca: One last question before we wrap up here: scaleups for life. Is this what you want to do when you grow up, be able to scale up all the time? Where does this lead you?

Andrea: Yeah, that’s a good question. So my whole career methodology or mindset, if you will, has been around: am I still learning and growing? And am I excited about the things I’m working on? And so if those things are satisfied, I’m good. I’ve never had the big "in five years, I’m going to be doing X. I have this big thing, this big goal." So I think, who knows? I could happily keep doing the scaleup thing. I could easily do another startup. Super fun with the right people and on the right problem. I’m pretty picky when it comes to the problem space and I’m pretty picky when it comes to the people. So it could manifest.

Rebecca: Well, thank you again, Andrea, so much for talking to me today. Really, really appreciate it. Thanks for coming on.

Andrea: And thank you. This was so much fun, and really appreciate you making time for me.

Rebecca: Yeah. Always a treat. Thank you so much.