Expert Talk: How to Deal with Hypergrowth

While hypergrowth means that a company is on the right track, this phase comes with challenges at all levels of the organization. Lena Reinhard, coach and consultant, and Blake Walters, senior director of engineering at CircleCI, share best practices based on their own experiences, navigating the ambiguity that comes along with these hypergrowth phases in a company's life cycle. Learn how to get through this phase successfully, what tools and tips can support the company and what hypergrowth means for the software engineering team.

Intro

While hypergrowth means that a company is on the right track, this phase comes with challenges at all levels of the organization. Lena Reinhard, leadership coach & consultant, and Blake Walters, senior director of engineering at CircleCI, share best practices based on their own experiences, navigating the ambiguity that comes along with these hypergrowth phases in a company's life cycle. Learn how to get through this phase successfully, what tools and tips can support the company and what hypergrowth means for the software engineering team.

Lena Reinhard: Hi, Blake. We're here to talk about everything that we've learned about scaling and hypergrowth. I have Blake Walters with me. Would you like to introduce yourself?

Blake Walters: Thanks, everybody for having us. My name's Blake Walters. I'm a director of engineering at CircleCI. It's nice to be here today.

Lena Reinhard: Awesome. Thank you. I'm Lena Reinhard. I'm an executive coach and consultant and trainer for engineering managers. I've been an engineering executive for the last five years, and previously I've spent the last decade or so running and scaling engineering organizations in times of high change. And it's actually when Blake and I also used to work together for quite a while and went through periods of hypergrowth together, and so we want to talk a bit about our experiences today and share that with you. And super excited to speak to some of the things that we've learned along the way.

Blake Walters: Absolutely.

What is hypergrowth?

Lena Reinhard: Awesome. Then let's just dive right in. The first thing that I was curious to establish a little bit is basically principles, values, and sort of higher level things that go into thinking about hypergrowth. But before we do that, let's talk a little bit about what we actually mean when we talk about hypergrowth. That might be useful to establish. From your experience Blake, what's been sort of hypergrowth, high growth? How have you experienced that?

Blake Walters: For me, I don't think that there's any specific number I can give. It's not growing from...it's not a 2X-multiplier or a 5X-multiplier or a 10X-multiplier. When I think of hypergrowth, it's scaling yourself, your org, the number of people, the audience that you're trying to reach through whatever you're building or doing, and changing in a way that can fundamentally shift your organization's culture. Whether you decide to let it go or not, it's a period of rapid scale in any of those vectors such that it really has an impact on how you do things, processes, hiring, onboarding, coaching, and the level of hierarchy you need, all of those sorts of things that really can shake the foundation of an organization itself, if you let it.

Lena Reinhard: Yes. I would agree to that and sort of build on it and say, I've gone through hypergrowth or high growth when going from 5 to 10 employees. That can be one, or you go from 15 to 40 and do that in a very short timeframe. The sort of fundamental shifting I think that you described is a really good way to capture it, because so many of the ways of working like operating models, and governance models won't work anymore and will sort of blow up relatively quickly. But at the same time, the way of...you mentioned culture, and with that, the way of thinking, the way you view your own role and also maybe what's made you successful and what will make you successful in the future is also going to shift quite dramatically. I think we'll probably touch on that a bit more later. With that, the biggest sort of unifying characteristic across all sorts of high-growth, hypergrowth scenarios, just that the amount of change really accelerates, and that's basically, just compared to the baseline and whatever your baseline was, basically, can put you in hypergrowth. And of course, there's sort of in the startup life cycle, there are a couple more specific definitions for it, but in the end, I really think hypergrowth, high growth is about the perception and the experience that everyone there is going through.

Blake Walters: Yes, absolutely. think one of the amazing things is that it's really...it's a thing that can happen to you depending on your position in an organization, or it's a thing that you can take control of and really seize an opportunity to grow yourself. Usually, there's lots of ambiguity that comes along with these sorts of phases in a company's life cycle, and it's really a great opportunity to step up, to level up yourself, your ability, the things you're comfortable with, to step outside that comfort zone and to help a lot of people around you through this change period.

Lena Reinhard: Great. Because one thing that, and I think that's why it's so great that you're calling this out is that the...your job is going to fundamentally change, and most likely you won't actually know in which ways. At the same time, the environment that you're in is going to fundamentally change at the same time. And so, a lot of the markers that you've known or guidelines you've used prior to that, or structures that have made you effective previously won't necessarily work anymore. So, Blake and I have both worked with a lot of engineering teams during high change, during hypergrowth, and what we want to focus on a little bit today is basically sharing what we've seen makes people successful, what we've seen has helped people navigate the ambiguities that we've already mentioned and how to essentially adjust to that sort of change of your role and to the change of the environment at the same time because that's...it's a lot of change to go around.

The amount of change obviously can also just do things to your brain and might also be worth acknowledging that there are some studies that show that ambiguity or uncertainty can be as painful as physical pain in the longer term, because the mental, the neurological receptor that gets triggered can actually sort of....if in a sort of fluid state for a really long time and in if dealing with uncertainty for a really long time, it can basically hurt in our brain. With that it can also have an impact on our mental and physical wellbeing. 

One of the human core needs is predictability or choice and the ability to both know things that are going to happen, but also have a certain degree of control and choice in what happens to us. Blake just mentioned there can be a reactiveness, but there's also a choice involved in sort of how you deal with these changes. And so, let's actually talk a little bit about principles, and values, before we dive into more details on specific areas that are impacted during hypergrowth and ways that we found can be useful to think about them. So, Blake, what are some sort of values or principles that you found useful for senior leaders, and engineers in times of hypergrowth, and high change?

Recommended talk: Scaling During Hypergrowth • Oliver Nicholas • GOTO 2014

Blake Walters: I think, you know, Lena will remember this from our interviews back in the day. I think anybody that's worked with me knows that I deeply believe in the tenets of agile development. And that's lowercase-A agile, not uppercase-A Agile, necessarily. It's the idea of small, but consistent changes in improvements of evaluating the process, of having ritual not for ritual's sake but because it's check-in on how we're doing as people, as teams, as organizations. And really reflecting on not necessarily just the output, not just the delivery, not just what did we accomplish yesterday, last week, last month, last quarter, but how did we accomplish it? What are we doing that's working? What are we doing that's not working? What are the changes that we can make? What are the subtle ways that we can show up differently, that we can bring ourselves to the table differently, that we can optimize our teams differently? And what is the smallest timeline that we can get feedback on that to really see if it's working or not? And being honest with ourselves about throwing away what's not working, being open to, you know, retrying things that maybe didn't work in the past. Really reevaluating sort of things that, you know, processes that didn't work when we were 10 people but might be suited for when we're 100 people or 1,000 people. So, it's really being willing to try.

Lena, how about you?

Lena Reinhard: What I just heard from you was also this idea of well, agile with a small A. So, in the sense of like the spirit of agile, not necessarily agile by the book...

Blake Walters: Exactly.

Lena Reinhard: ...if there's such a thing. So, this idea of sort of keeping changes more, but also doing that as a means to really learn quickly and be able to iterate and improve over time. I think that's a really important one. I also think if you're in a position of hypergrowth in your organization and you're looking for some tenets, another thing to think about can be starting with really what matters to your organization. That's such a basic thing to say, but actually, in times of high change, in particular, it can be really tricky to identify what's important. 

What are we valuing as an organization? What are we optimizing for? Because as the number of change increases, those things can often get really blurry or they also may shift really drastically if your organization is pushing to respond to changes in the market and change strategy, those things also may actually explicitly change. So making sure that you understand what's important and also continuously check in on that over time and make sure you have that context on what is the reason for changes? What are we trying to optimize for? What are the goals that we're trying to achieve? Those are super simple questions, but oftentimes those can be really hard to get clear answers on. Finding those answers and making sure you understand those things can be an essential part of being effective in hypergrowth.

Getting the context right for hypergrowth

Blake Walters: So, Lena, where would you suggest that folks, whether they're engineering managers, staff engineers, leaders, even ICs, where would you suggest folks go to get that context that they need to do better, to really rise to the challenge of hypergrowth?

Lena Reinhard: I think your manager's ideally,, a great starting point, but you may also be dealing with a situation where your manager is also quite overloaded and overworked, especially when hypergrowth is happening, a lot of changes going on, that may very likely be the case. And so another point may be to check with peers, check with other business stakeholders. If you haven't established them yet, establish solid business relationships with people outside of your team. Maybe you have partners in the marketing domain or in an area like product management where you can get some more insight, and again, broaden the context that you're operating under.

Another thing if you're not able to get answers is to try things or put forth what you believe. I found that a quite effective technique with people who are just busy and struggling, like some people, also struggle with communicating concisely. And so it may also be worth just saying, "Okay, hey, here are three things I understand right now. Is this actually the case? Give me a yes, or no to just unblock you and get you going. How have you managed some of the sorts of communication things that come with, high-growth environments?

Blake Walters: I think one of the key things I learned very quickly when growing, numbers of teams, numbers of reports, the varied nature of the folks I was talking to, being very vulnerable and very clear about what I needed is asking for help, asking for resources, asking for information is not a sign of weakness. I tell my folks these days that saying, "I don't know," is a superpower, as long as you follow it up with, "I don't know, and here's how we're gonna find out, and here's when."

And so one of the things that I try to encourage folks, especially when there's lots of ambiguity in the air is to push information. I try to let people know that I am not going be on top of every Slack thread. I will try my absolute hardest to read every line of every email that comes to me, but it's best not to assume that I have all the information or that your peers have all the information, or folks like VPs or execs or the folks that you really look to drive the organization has every bit of nuance that you have.

So, when you feel like something needs to be pushed, push it. Make stuff self-serve if you can, if your team has dashboards and processes. Make sure you're fulfilling the contracts of what's expected of you and your teams. But if something feels off, if something feels really great, whatever the case may be, if it feels exceptional or out of the norm, push it. Push it up to your manager, push it up to your technical leaders, highlight it, get some eyeballs on it, get a conversation going, because that's really how we absorb this information at an organizational level and at a team level is really just by pushing information. We talked a lot in CircleCI about overcommunicating, especially in this day and age in a remote environment. We don't have a water cooler talk, we don't have body language, and we don't really have time where teams are sitting physically in a conference room together ideating and brainstorming. So, really pushing out information and making space for that information to be absorbed is deeply helpful.

Recommended talk: How to Take Great Engineers & Make Them Great Technical Leaders • Courtney Hemphill • GOTO 2017

Lena Reinhard: Yes, I would 100% agree on that. And there's this rule of thumb of, having to communicate everything at certain times, and I have tried this for a while. I think it's actually quite true. Especially, if you're able to communicate things across different channels, it can really make a difference. I think that point about over-communicating is really good as well. I would kind of add as a caveat, over-communicate with a purpose. So, it shouldn't just be for the sake of over-communicating, because then you're just also going to add to the noise, and in a high-change environment, there's probably already a lot of that anyway. Making sure that that communication also has a clear purpose.

I think the whole point you made about pushing information out is so crucial. One thing I've seen a lot with more senior people or people who are pushing to be at a more senior level is exactly that point. So, for example, starting you could provide weekly status updates. It doesn't have to be a big thing. Like there are formats like the 5-15 rule. Or 15-5, sorry, this way around. You spend 15 minutes writing it and it takes 5 minutes to read. So, it can be a really short thing, but it may actually help you, one, reflect on your own work, which is always a good thing, again, especially in high-change environments, but then also it can be super efficient or effective in helping you get your message across and helping others understand where you're at. With that, build a bit of a perception of your work and of what you're doing and how you're sort of stepping up as a leader.

So, that's awesome. Now that we've covered a bunch of principles, around understanding what matters in your organization, getting this context, maintaining a really high sense of communication, pushing information as much as possible, and then setting a culture of learning and making these small improvements that Blake talked about earlier are some of the, like, yeah, really crucial traits that we've I think both experienced in our time. Now that we've covered that, I would love to just dive into a couple of areas more deeply. Blake and I talked before this call and sort of settled on a few. I think the ones that we wanted to talk about in particular are tech, quickly. Then, we also wanted to talk about scaling yourself, which Blake's already touched on a bit. I think it's one of the most crucial aspects of this whole thing. And then talk about delivery and people and teams, and then potentially also a bit more on communication. So, we just wanted to dive into that a bit and touch on different experiences that we've made, things that we found successful or effective in all of that. So, let's start with tech because when we did our pre-call, Blake Walters said, "We don't wanna talk about tech." So, tell me a bit about that.

Blake Walters: Perfect.

Technical decision-making during hypergrowth

Lena Reinhard: I actually agree, so let's talk about that.

Blake Walters: So, when we're talking about tech, especially in engineering management, there is no...and we even have it here, there's no management stack for success. That applies to the engineering teams themselves. We are people leaders, I think first and foremost, strategic thinkers, org builders. No one should trust me to go in into an IDE and write code today. My job as an engineering leader is fundamentally to put the right people in the room together and then get out of their way, empower them and help them to make decisions that are good for our customers, for our business, for the success of all of our teams. And so, we're not going to sit here and layout this backend language and this data storage layer. We're not qualified to do that necessarily, but what we can't talk about is the tools and approaches that we use for solving problems. So, Lena, for you, how do you approach technical decision-making? How does tech factor into the work that you do as an engineering trainer?

Lena Reinhard: I think it's an interesting point in that you've just said we're not qualified to talk about this. I would even go one step further and say, maybe we're, like...this session is specifically also for people who are like senior and upwards. And even if you're a developer or a manager, the biggest point that I would take from this, and also from what you just said, is essentially that tech ultimately is a tool to solve the problem. And the problems are usually much bigger. I think it's very tempting to lean into this idea that knowing sort of the "right stack," or the right tools are going to help you solve problems. And to a certain degree, that's of course the case. Like, good or decent tooling is going to make a lot of things at least not harder than they need to be. But at the same time, as you just, I think very aptly, said, there's no one size fits all, and there is no sort of management stack for success. I love that, the way of putting that.

To sort of loop back to your question, is that ultimately there are a couple of things that you can consider when it comes to tech and hypergrowth that are beyond, "Hey, how much load can this specific technology handle?" One of those things is essentially looking to see if your stack is manageable? If you're an early-stage startup and you've already got several programming languages that you're using because that's just the way the founding team worked, you may wanna look at reducing that at some point, or you may look at, "Well, are we using very, let's say, exotic programming languages or very specific tools that only very few people use?" Because especially if you're going into hypergrowth, that's likely going to create a hiring problem. Or if you're planning to move into hypergrowth soon, looking at, "What of our stack is, approachable? Are the languages that we're using, the tools that we have, are those relatively standard in the industry, or are there a lot of things that are going to create a huge onboarding hurdle?" Because if you're trying to bring in a lot of people at once, you're probably going to want to be able to have them ready to work and moving relatively quickly and not spend a lot of time hiring people and then spend another six months until they're able to actually do effective work in your system.

Then, another point that I've realized is really important in hypergrowth is sort of maintaining a bit of a systems view, so a bigger picture of the architecture of the system overall. Because what tends to happen quite often is that you bring in a lot more people and those folks are at mid or senior levels or even staff levels or above. And at the same time, they will typically be quite focused on their teams and on helping their teams succeed, because that's also usually what the delivery goals are about. But then, what tends to happen is that there are not a lot of people anymore who actually know the entirety of the system at a higher level and who maintain that kind of view. And at the same time, having that view can be really crucial for helping people in the teams make the right decisions or make smart decisions that are useful for the company in the long term. How have you dealt with that, Blake?

Recommended talk: What Engineering Managers Should Do (and Why We Don’t) • Lena Reinhard • GOTO 2019

Blake Walters: I like to think of the best metaphor... What I ever come up with for this specific issue is making sure that those engineering leaders feel like they have a bungee cord attached to their belt, that is attached to the other end to all those folks that they're leading. So, there will be cases, whether it's hypergrowth in terms of teams or headcount, or it's hypergrowth in scalability and success. 

Maybe you're an overnight success in the marketplace, and all of a sudden you realize your systems aren't keeping up with the pace and success of your business, which is a great problem to have. But when you think about leading teams, whether it's technical leadership or people leadership, anytime you run forward and progress, you need to make sure that those teams that you're leading are pulling up behind you. It might not be at the same rate, it might not even be at the same pace every time, and it might vary depending on what you're going through, but a big part of leadership is lifting those up around you. I think I've seen some of the smartest people I've worked with in my career fall down the most when they forget that fundamental truth of leadership because it's fundamentally not about hero culture. For me, it's not about solving the most interesting technical problems.

We have thought leaders in our industry. You're probably working with thought leaders in whatever industry you're in if you're listening to this now that really are at the bleeding edge of innovation and really are doing wild things with tech, but the vast majority, certainly anecdotally speaking in my career, what we do as engineers is actually kind of rinse and repeat of the same things we've done before, maybe a little bit better, maybe at higher scale, maybe cleaner. But we can't forget those fundamentals of when you have an associate engineer, when you have somebody fresh out of college or out of a boot camp or a career switcher or intern come in, can they work on your systems confidently? They might not be working on the most critical path. They might not have the most impact that a staff or above engineer is gonna have. But I think the hallmark of success for me technical leaders is can we make sure that everyone can contribute, that everyone can have an impact and that sort of sentence of, you know, a rising tide lifts all boats?

Lena Reinhard: I think there's a lot in what you just described and the lowering the bar, essentially. It's like if you have a high barrier to entry, you're going to set yourself up for failure, because, ultimately, all the work's gonna remain on your plate, and that's really the last thing you want in a situation like that.

Blake Walters: I was just going to say that we talk about the bus factor a lot. And the fewer people, and especially to take this back to the tech choices, if you're making sure you're making technical choices not just to solve the technical problems you have but the organizational problems in the future if you pick really esoteric tech, make sure you have good reasons for that. I'm not saying to never go out and pick something that's exotic or interesting or new if it's solving the technical problems you're having but know that...

Lena Reinhard: That's the key.

Blake Walters: ...the longer things go on, the harder it's gonna be to support, the more difficult that bar is to cross for the folks that hopefully as you're going through hypergrowth, you're seeing success behind it is really planning for years to come with really durable solutions.

Scaling yourself

Lena Reinhard: I agree. And I actually thought the bungee visual you used was great also connecting point to sort of dive into the next area around sort of scaling yourself because I think we both agreed when we were preparing for this that this is actually one of the most interesting and important, and also one of the hardest parts about this whole topic of hypergrowth. The first thing that I've realized in my work, which has dealt with a lot of sort of high-change organizations, and still the case now with the people I'm supporting as a coach and consultant, is that just the context switch is one of the hardest hurdles in all of it. And again, it's one of those things that kind of sounds well at an abstract level, sure, you get it. The context broadens, your company grows, and you have to grow with it, so you're probably working less on, like, say just the task level, but you're leveling up and operating like you're running projects or things at the epic level if you wanted to use Jira terms, which I know everyone loves. But that's something that kind of sounds really straightforward if you say it like this at the abstract level, but the majority of people who I've worked with at some point have really struggled with this, and honestly so have I, because, at this point, you're basically...you're still...you've learned how to be successful. You know how to, for example, run your tasks, get all of this work done, succeed, feel great about your work, and then suddenly there's all this change. You're expected to work at a much higher level, but at the same time you don't have anyone who's telling you what that actually means or how to do it, and the organization's still shifting around you.

We've talked earlier about obtaining context and speaking with your manager or with peers. And so making sure you actually understand things that are appropriate for the new level that you need to work on is really important. So, making sure you have actually a solid understanding of strategy, you understand roadmaps, you understand at least quarterly goals, like whatever it is you can hold onto that's more durable than the next week, like hold onto it for dear life. And make sure you use that context also to help others like to the point of sort of leveling others up, which I wholeheartedly agree with. Make sure that you're able to also share that context with other people. Blake, what other things have you sort of found useful in sort of elevating your role? What should people think about it?

Blake Walters: It's interesting because, like I said, in sort of the intro is high-growth organizations, and especially periods of high growth, whether it's, again, 5 to 10, 10 to 100, 100 to 1,000, there's no magic number here. For me, it presents an opportunity. It's an opportunity to really look around and see what your organization needs. And this is gonna be different for everybody. There's no, "Oh, go be the..." Just to use the Jira thing, "Go be the Jira process person. Go be the technical person."

Lena Reinhard: Don't be that.

Blake Walters: No, don't be that. There is no one tried and true statement for everybody, but it's really helpful to really evaluate from your vantage point. You can be unbelievably biased in this process because it is your perspective of what the organization needs to get to the next step. So, whether it's more process, whether it's more communication, whether it's enabling and facilitating conversations, really think about what would help you in your position and somebody coming into the position that you just left or you just grew out of, and how we as an organization can think about how to fill that gap to make sure things aren't dropping on the floor. Because when you go through these areas of expansion, senior technical leaders, and senior people leaders are going to be thinking about a whole different level of context. New folks are coming in and there's this expectation that everything is running great, but I think in the startup world that is rarely the case. And in the corporate world, the same is true, but especially when these teams are going through these rapid bursts of change there are opportunities to really notice issues, to notice what's just not being done, and figure out ways that you can pitch in to help, to facilitate, to drive, to not necessarily do the work yourself. If you find yourself doing lots of day-to-day tasks as a senior member of the team, you're probably not leveling up the people that might be at your level or beneath in those opportunities to facilitate and guide.

We'll talk about it in a bit, but really changing how you think of success is kind of the key part, but really noticing what's just not getting done. As importantly, not doing things to get you to the point where you're going through the next burst of change. You know, it's the same for engineering. You don't wanna do 10X unless you know you're goinig to hit 10X scale. Focus on 2X first and get there. How about you, Lena? How do you navigate sort of the ambiguity of a position changing without maybe a title change or just, "Hey, we've gone from 40 people to 80 people this year?" How do you approach just the ambiguity of it all?

Lena Reinhard: I think it can be quite tough. I've certainly even, like, struggled with it for quite a while and it's taken...because it's not necessarily something that was sort of in my natural wheelhouse. I would say an interesting factor here is also what different organizations value. In my experience, like, something that's quite valued in a lot of startups is essential, you know, confidence and what I would always describe as aggression in the sense of like really going for it, just grabbing work. A lot of organizations promote based on essentially people stepping outside of the role that they're assigned and doing a sort of work at the next level and doing so unprompted. Whether that's a good thing or a bad thing is a separate debate that we could probably spend another hour on, but for the sake of this conversation...

There's a lot about sort of putting yourself out there, doing things that you probably haven't done before, doing things that you may not feel comfortable with because you may not have a lot of experience with it, and that can be scary. For other people it's fine because they're, like, naturally more confident and they feel like sort of everything that comes naturally to them. But if you are not that kind of person, I would encourage you to try small things out and see if you can first of all kind of acknowledge the ambiguity that you're dealing with, and also sort of understand what it does to you. Is it something that you feel comfortable with that's fun to you? Or is it something that's a bit scary and that's a bit difficult to figure out? And just working through that already can be I think a huge shift or lead to a shift in just being more cognizant of what's happening to you and also of getting you out of that reactive mode and into a mode that's a bit more sort of proactive and puts you into a position to actually then make use of that opportunity that Blake was probably very comfortable with ambiguity, that opportunity that he keeps talking about.

And then I also think what I mentioned earlier is sort of just developing some clarity where you can. I think a big part of that is also about managing up and essentially finding other ways to know that you're doing well. Like you probably won't have, as Blake just said, you probably won't have a title change. You probably won't have a clear document that lists your role and responsibilities, so there's a lot of having to make it up as you go and as the organization shifts around you. 

The one component that I've just seen be incredibly helpful is managing up effectively. So, understanding what your manager needs, understanding what your boss' boss needs because that can help you figure out how to make your boss look good, which is always a win. And then also understanding what your boss values and what principles or values apply in your organization at large, and how to use those things to get wins for your boss. Can you do this one thing that as Blake just said earlier that sort of fell on the ground, can you just take this and fix it, or at least...or work with someone to help them fix it again, to the spirit of the sort of growing your own role and not doing everything yourself anymore?

Also when working with your boss, one big step can also be to focus on outcomes and results instead of approaches, because a lot of bosses are in hypergrowth, and it's worth keeping in mind, that they may struggle themselves. This may also be a position they actually haven't ever been in. So they are in a similar position, as you're struggling with figuring out what to do, they may do the same thing. If you can put some things forth as described earlier, like say, "Hey, here's what I understand or here's what I've been working on. Here's my weekly status update." This can be super helpful to at least provide some structure. And even if then the things that you're doing aren't all sort of the greatest, you'll at least be very quickly able to learn and iterate on them together. It can also help you understand much better are you doing well? How are you doing in your current role? Are you sort of elevating yourself up as the organization's growing around you?

Recommended talk: Attitude Determines Altitude: Engineering Yourself & Your Teams • Randy Shoup • GOTO 2018

Blake Walters: I think on that point, self-awareness is a remarkably powerful tool for a leader. A lot of us, when you get to a certain point in your career, you have a brand, you have a personal style. Knowing what that style is and leveraging it to great effect can be a really powerful tool, but also knowing what your weaknesses are and being honest about them. You know, I think decently into Lena and I's working relationship I realized...and we've worked on this for months, was that I have basically two levers, and they're very specific to me, but hopefully, this resonates with somebody is I can do really well in situations where I have a lot going on. So, lots of tactical work, lots of things in flight. I can also do really well when there's a really high degree of ambiguity. So, things are not clear. We have rough shapes of goals. We have targets we might wanna hit, but not a clear idea of how to get there. But when those two meters are peaked, I do terrible and it frustrates me and it burns me out. And so figuring out what those levers are for you and how to dial them back.

I think one of the most powerful things that I realized working, Lena, with you was, "Oh, the things that I am doing day-to-day that I am good at, those are really good things to delegate and to teach somebody else how to do because I know how to do them." I know what success looks like. I know how to...or at least I learned on the job how to coach people through how to do things the way that I do them and to know that output is different than the work going in to produce that output. So, to say, "This is what I expect." These are my expectations for whether it's a status report or running a meeting or monthly planning or whatever the case may be, but really taking those things that I'm very comfortable with doing and handing them off so that I can devote more time to the things that make me a little more uncomfortable. So, flourishing in that ambiguity, buying space for the things that I know I need to work on, and just being open and honest.

I think a lot of times, especially in hypergrowth, it can feel like these opportunities are, "Oh, I just have to push this thing through. I have to get it done. If I drop this thing on the ground, it's gonna be that's on me." But in all of these, and I know that we both have a very team-oriented perspective on these things leaning on your team, leaning on your peer managers, your peer technical leaders, leaning on your boss, leaning on your support system of not spinning and not doing things in the dark and hoping for an outcome saying, "This is where I'm at." Doing that self-introspection and saying, "What am I failing at? What do I really need help with?" And going out and finding that help is a lot of times you'll be rewarded for giving somebody the opportunity to mentor you through a thing or to tap into their previous experience. It can be really rewarding on both sides. And if you're honest about it, it doesn't show up as weakness. It shows up as self-awareness, which again is a massively valuable tool.

Lena Reinhard: I would very much agree that many of the best leaders I've worked with have a really high degree of like self-reflection, self-awareness, and great introspective ability, and I think it really goes a long way. And I think that also segues really nicely in what you've alluded to earlier already about sort of your feeling of success, and that's another thing that I've seen just a lot of people struggle with in these kinds of high-growth environments because you often go from being able to deliver or do a lot of work by yourself on your own, or sort of with the help of the team, but in the end, sort of you get that pull request merged, you get that commit in, and you get that dopamine hit. Whereas suddenly you're in this much more sort of higher level role, it's much more ambiguous, much more of the work is longer term, there are political issues involved, there are other people involved, and we all know that hell is other people. And suddenly, there's a lot of like having to basically figure out how to be successful in very different ways. You're not getting things off your to-do list as quickly probably either, and the dopamine's missing. So, adjusting how you feel successful and what makes you feel accomplished and good about your work can be a really important part of that as well.

So going from sort of doing work yourself to helping others succeed, being successful through others by coaching them, by mentoring them, by guiding them, by delegating, maybe even delegating some work that you would've loved to do previously but you know it's a good opportunity for someone else, that can be a really huge jump, but at the same time, it's such a crucial step because it can completely shift honestly what you're capable of and what you're able to reach in your career.

Blake Walters: Yes, and it's a team sport, right? It's no one in this industry who is going out and absolutely killing it by themselves. There are always folks. There are partners in management, there are partners in tech, and there are cross-functional partners that we work with day-in, day-out, whether that's product managers, designers, or user researchers. There are cross-functional folks that we might rarely see but are important relationships to have. And marketing and sales and IT across the organization. No one is doing this by themselves. And so, being able to navigate these conversations and really redefine what success is for yourself can really help unlock how you get there together.

Reassessing impact & delivery

Lena Reinhard: I totally agree. That's actually another great segue because I'd love to talk a little bit about delivery. So, obviously delivery shifts quite a bit as well, like you suddenly...your organization's much larger. You've had all these new people coming in, you probably have some really tough goals to hit at the same time. And so I'd love to talk a bit about sort of what we've seen work. I'll just throw the first thing out there, which I just think is so crucial, which is just keeping work small. Blake talked earlier about this culture of sort of small changes. DevOps culture is obviously really crucial, and that is with the idea of making change easy and making change sort of a habit for teams really. So, keeping work small is another really simple thing, but it's so important and it can also be really hard, because you may also want to sort of run larger technical investments. Maybe even you have this...you even have this refactoring idea that would really unlock new capabilities that you also want to do.

So, figuring out how to get small experiments out, get small wins, and be able to really continue seeing results and see them quickly can be really important in sort of managing high growth, because high growth is usually not the time for big investments and not necessarily the time for big leaps, because you're already leaping big when it comes to building out the organization. And so, keeping delivery focused on small things or big wins that are broken down into small steps along the way can also be an approach that is really, really crucial in that.

Blake Walters: So, a question for you, Lena. One of the things that I've seen, especially in startup culture, and that's most of my background is working with high-growth startups as well, is you have folks that are going through these periods of change that joined early, or certainly earlier, maybe it's a year or two, maybe three years ago or even longer. I don't wanna use the phrase blast radius, but the impact of their changes seems to diminish. You go from being 1 of 5 engineers and knowing what everybody's working on, to being 1 of 250. How do you approach that conversation with folks? How do you coach folks through that because they have to redefine their success as well? They have to redefine what impact really means. How do you help them through that sort of personal transition into this wider world of, "Yeah, you're 1 of 250 now and this is just the new reality."

Lena Reinhard: I think it's a great question. Also, it might be interesting for people who are in that position and who may be struggling with that, and understandably so because suddenly you may be reporting not to the CTO anymore or the CEO, but you're now reporting to an engineering manager who's five levels down from the CTO and who's just new to the job.

I think what you just mentioned around sort of the impact shifting is quite a huge question, and I think it can be really tough. One thing that can be worth thinking about is essentially what are the things that you're bringing to the table that are quite unique to you? So, what skills do you possess or what knowledge? Like, oftentimes people in a position like the one you described are, like, very long-tenured, have a very good understanding of the system, and have probably built a lot of the system themselves. And so, figuring out how you can pass on that knowledge to others, like can you mentor someone? Can you set up an onboarding session? Or can you start working with a group of newer people to help them understand the system, help them understand why certain parts work a certain way? Maybe also the traps that may be buried someplace, because there are always some traps? So, that can be one part. Another part can also be to think about what kind of impact you actually want to have. Because of course, like, you've had a certain impact already previously in the role, but what do you want to do in the future? Like, what are the things that you want to feel good about when you end your workday? And what are the impacts that you want to have?

And another part can also be thinking about how to use essentially the specialization that you now have in a bigger sense. So, for example, typically, you've gone through a transition from being a generalist to being in a highly-specialized role if you've moved from an early-stage startup to a later stage now. 

Thinking about, you know, what's the impact that you can have with this specialization that you have now, or can you shift your role around to being more of a generalist again, for example, by moving into a role that's much more focused on the entirety of the system like an architectural role or a staff or a senior staff level role, whatever leveling system your organization has, where essentially you can use this really special knowledge and understanding that you have to have a much greater impact on a much larger amount of people? So, the impact that you have may shift from the sort of lines of code that you deliver and parts of the system that you've built to essentially enabling other people to build that system and continue developing. And Blake Walters do you have anything to add there?

Recommended talk: Scale, Flow and Microservices • James Lewis • GOTO 2021

Blake Walters: I don't. I mean, that was fantastic. I think that's one of the things that I see engineers struggle with a lot. And when we're talking about delivery and results, you really do have to change... It's a constantly shifting scale of what you're having an impact on, what your role is, how you're stretching yourself outside the role, and how you're empowering those that maybe are not at your level, or maybe they are, or maybe they're above, but really helping guide the organization through however it is you can. I think one of the biggest things that I've seen is giving people autonomy and empowerment, but with guardrails of expectations, outcomes, alignment on goals, having a clear vision for where we are headed, and then stepping back. And I think about it like going on a long trip or a journey or whatever. It's you really wanna have a destination in mind and be open to the possibility that there might be different stops along the way.

But nobody likes a backseat driver. Nobody wants somebody saying, "No, no, no, you need to adjust, you need to realign, you need to go a little faster, go a little slower." You really want to say, "Hey, this is where we're getting. Plot our course. Get us there." And small adjustments along the way, really small tweaks, really, you know, probing questions, in rare cases dive-bombing saves. But most of the time, it's really just having a clear set of expectations, a clear set of goals, and regardless of what level people are at, and I've seen it from VPs and execs all the way down to brand new engineers to the organization, really having clarity on the vision of what we're trying to do together. And not just that. I think that isolation can actually frustrate because people are so removed from the organizational level that they're like, "How is this ticket gonna help that?"

Lena Reinhard: Oh, you're right. 

Blake Walters: But really saying, this is the through line from... Draw a line from the middle of you to that success metric of all of the steps along the way that empowers it. It's really a remarkable thing to step back and watch ideas that you would never personally come up with strike you as, "Wow, that is a thing that this group of people or this individual did completely on their own without me involved, but it was a situation that we can manufacture, that we can set up, that we can empower." And that success can become organic for those folks, and they're deeply intertwined with the success of the team, the organization, and the company as a whole.

Lena Reinhard: I love that. You're really bringing it with the visuals today. And I think the whole point of the through the line I think is so important, like, and that whole point of like going from the vision to what does this actually mean for this ticket that's up next in my backlog? Or what does this mean for my actual daily work? I think that translation or that connection is such a...it can make such a huge difference also in terms of motivating people, but also in terms of helping them understand how to go from this really 10,000-foot high-level view of "Here's the vision," to, "Okay, and here's the day-to-day work." And that can be super helpful.

I think, again, to the question about sort of more senior people or people who have been around the longer term, like you can make that connection. You can shift your role also to incorporate some of that sort of translation or connection work. I think with that also comes an ability to basically shift your role and essentially learn new tools, because, ultimately, a lot of the things that we've talked about so far are just they're leadership tools. They're different ways of communicating, of operating. And with that, they're things that can be learned. They're not things that people are necessarily born with. If you are, good for you.

How to support teams & people during hypergrowth

Lena Reinhard: Actually, I would love to briefly also touch on just the topic of sort of people and teams, because obviously, hypergrowth means teams are most likely growing really fast, lots of new folks, and at the same time, people who've been around for longer-term are dealing with all these radical changes to what they used to be used to. And so, I'd love to talk a bit about sort of how to support people and teams through that. I think we've touched on a few aspects already, but is there anything that you'd wanna add, Blake?

Blake Walters: Yes, I think, when we talk about people and teams, and a lot of what we've been talking about today is leadership through hypergrowth, through growth phases of an organization, is that there's a fundamental difference between management and leadership. Management is a position. It is a role. Leadership is a thing that anyone can do from any position within the organization. And I really think it's important that people realize that anytime you step into a room and facilitate a conversation, anytime you pull a ticket and become the person that is ushering that ticket through from start to finish, whatever the case may be, you have an opportunity to lead. Being a good leader is also being a good follower and knowing how your role plays into the larger whole, but it's more than just being a technical thought leader. Leadership isn't just telling people what to do. It's listening...

..it's collaborating. It's all the soft skills that go into working together with a group of human beings towards a common goal. So anytime we talk about leading, we want to make sure that folks are leading with context. If the context is missing, the same instructions might come across completely differently. And if being as transparent as you possibly can be, that doesn't mean exposing every single person to all of the inner workings and conversations that are happening at every single level. Actually, that can add a lot of ambiguity on a lot of lack of clarity to how people get their jobs done, but making sure that you're communicating when decisions are made, how decisions are made, and how those decisions will impact people. Just to hearken back on something we talked about before, doing that over and over and over again.

One of my bosses at one point said, "About the time that people start complaining about how many times you've said a thing means they've started hearing it." So, really driving those points home when they're happening and being as transparent as you can in your given position.

Lena Reinhard: I totally agree. I think that this whole point about sort of really bringing people up with you and helping them understand context is also...it's also so important because it, again, helps people learn those traits. Like they observe the way that you communicate, and the way that you lead and they will be able to emulate those kinds of behaviors as well, which then also helps them elevate themselves in their roles and do the same for others. So, it's you can really help set a great change in motion just by changing the way that you operate there. One thing I would absolutely recommend is learning to ask questions and learn to ask good questions. There's a whole concept in coaching training where they teach you to ask powerful questions. And the power of the question is not as you might think in asking something that's really well-worded or really well-framed or super thought out. The powerful question is actually in really listening and in turning off your own brain and your own desire to sound clever or sound smart, and really focus on the other person on what they're expressing and then being able to respond to that.

So being tuned into the people around you can actually help you be really effective in these hypergrowth changes because it's also gonna allow you to build relationships with the new people quicker. Understand what they need, understand their motivations, and then be able to respond to that appropriately.

Recommended talk: How to Become a Great Software Architect • Eberhard Wolff • GOTO 2019

Blake Walters: Absolutely. Couldn't have said it better myself.

Lena Reinhard: Thank you. And just looking at the time, is there anything else that you'd really want to say, Blake, on the whole topic of hypergrowth and navigating it successfully?

Blake Walters: Nothing specific. I think the best general advice I can give to our audience is to stretch yourself, and go beyond what you think is personally possible. Reach out for help, be vulnerable to do it, but be open to possibilities that are beyond the kind of what you about day-in, day-out. And a lot of times seizing those opportunities is what's gonna help move you forward in your career and have the most impact on your organization. Lena, how about you?

Lena Reinhard: I would just say, be curious, and there's probably going to be a lot of things that you don't necessarily understand immediately, or that don't seem to make sense. Like ask questions, try to understand, and then like try to find the opportunities, like see where the work isn't happening and figure out where you want to have an impact and then how you can go for having more of that impact. And also have fun along the way. Like it can be exhausting, it can be tiring, but it's also incredibly rewarding and a lot of fun.