Here's the truth. Hiring remote engineers doesn't have to be expensive and time-consuming. Our friends at Revello can help you find and hire top engineers based in Latin America in a matter of days. Just tell them what skills and experience you're looking for. They'll come through their network of over 400,000 pre-vetted engineers and give you a short list of curated candidates that meet your specific hiring requirements. You interview
and hire on your terms and only pay for as long as you keep the engineer. To learn more, visit Revello.com-4thslush-elc today and save $2,500 off your first hire. After surveying hundreds of engineering leaders, we've pinpointed the top 10 challenges that engineering leaders face right now. This is part 3 in a four-part series, sharing some of the best insights from hundreds of ELC events, podcasts and conference sessions.
The first two we tackled individual challenges, so challenges that you can control yourself. The second one was about team. In this episode, we focus on challenges at the org level. We're talking the high level strategy behind how you lead the engineering function. Specifically, we're going to get into challenges like aligning engineering in the business, team topologies and figuring out the best way to deploy your resources and strategic thinking.
So let's dive into our first segment, aligning engineering and business goals. Our first person here hits this one right on the nose. Jessica McHeller joined us on the podcast where she shared with us different strategies that she used as a serial founder and head of engineering to align engineering initiatives with different business outcomes.
I'm going to give you the honestly boring answer, which is if you're on the path towards being a public company, which is the path that pilot is on, eventually all companies are evaluated in the public markets in a standard way. Everything is building up, like from the inception of the company, everything is building up towards eventually being evaluated
in that way. And that's why even now as a private company, it's like you talk about this revenue curve and you talk about margin, talk about your burn, your burn, multiple these high quality things, because it's like you're building the internal discipline to be ready to be evaluated in that way. I think what's different about pilot from the other companies is we're very clear with ourselves that is the game plan. And we just are kind of, where
is a better at running companies now, because we've done it several times. We've just matured as human beings and we've gotten the experience, some of the other companies taking all of that experience and knowing what the end game, the end game, frankly, is very spelled out for us by what the public markets do. And then it's a question of how do you run a company year over year, quarter over quarter on a trajectory to get to that eventual goal?
Do you think about the sequencing of building out the maturity or some of those habits or the internal discipline? I was wondering if there was any ways that you think about what parts of the business building discipline typically need to come first versus others along that long-term journey? I'm not going to be like, this isn't maybe not a direct answer to your question, but I think what I would say in response to it is, the earlier you know what metrics you
care about and you start at least measuring them, the better. Because otherwise you're kind of operating blind on how the business is doing on various axes. Even if you're not prepared to invest in changing the metrics, I think having discipline around tracking
them is important. So you can treat you like track your margin from like day one and it, you know, maybe if you don't like what it is, but at least you know that so that you're not surprised about the number when you need to report on it for a fundraising event or
for whatever reason. And then that's about, you know, on the engineering side again, often when you, you know, be it related to customer satisfaction or revenue or margin or whatever, there's often data infrastructure that needs to be built out to have the disability that you need on this. So like as a leadership team, as a founding team, like making sure that you're allocating the right in mind share and appropriate resources to having that instrumentation and disability.
That's great. I want to cue into what you'd mention a couple times, you know, having like this clarity around the end state of the business is having the end state or the end goal in mind. So as we're going to talk a little bit more about with having started at, you know, a number of different companies, that end state has been different. Were you intentional with having that end state in mind within those different types of companies?
And what was the conversation like to make the decision? This is the end state of like how we want this business to go. What was that like? What market you're in and the size of the market go a long way towards dictating what the cost of luck comes are like case place, for example, super fun, cool technology, reboot with current updates on Linux, super fun to build ultimately for a fairly narrow audience. Like there are only so many companies that have a lot of computers that run Linux that
care about like never going down. And so if you're tackling a very narrow market, that's difficult to build an indefinitely independent company on. And so, you know, often in acquisition is the most likely outcome because it needs a home as part of a broader portfolio of solutions for the audience that you're targeting. And that's exactly what happened case place,
right? And the acquisition might work well. And now I don't know if we could have told you that before we started the company like back in school, but certainly retrospectively that. That's where obviously was the case. Leaders often make the mistake that operational metrics are enough to communicate with the business, but to a line engineering in the business, there's a huge gap between understanding metrics and the outcomes those metrics drive.
Andrew Lau who joined us on the podcast shared many of the common gaps that engineering leaders have when it comes to integrating tech decisions with broader business goals and a few things that you can do about it. In general, like I think a lot of us have all heard about process things. We've learned to speak in, you know, whether it's process like agile processes, whether it's from our kind of bottom of these things or door metrics and something like that too, right around
uptime and those things. But I actually think even all of those things still aren't sufficient for the business. Those themselves, I think, are necessary not sufficient. And so those don't represent strategy. Those are, you know, their metrics, right? Like they help us understand some operational parts, some progress on those things. Mistake one is I think people realizing that the business wants to hear those things as the way to integrate
to the engineering alone. I don't think it's enough. Like yes, we have to make sure our spread is completed. Yes, we have to deploy quickly at those things. Yes. But even if you do those things and you're building the wrong stuff or it's not getting there or it's smeared to many ways, they're the business might still fail, right? Crap is that may sound. And so part of this is probably leading with the wrong engagement is a kind of a mistake.
And you know, how do you solve for that? Well, you should ask, right, ask what are the business needs? But that's just that's a minimum floor and how to engage. But like, how do you actually nail the right thing for the business? Well, like I think efficiency and cash and like spend and burn are things that people care about a lot right now. Why? Because sometimes
for some companies, because it's like, they can't swear around. Or if you're a public company, you're getting squeezed by, you know, the public market's actually asking you to move these needles on this stuff. And so like, as an example, in this climate, right, it's not just enough to say, like, hey, we need this many more people. Like a couple years ago, we'd be like, I
just made people and then they'd be like, well, what do you get for that? The next response is going to be like, well, you know, you're going to get this wing and this engine on the airplane, right? Well, I think in 20, 20, 24, that's still not enough. So what if you have a wing and an engine whoop to do now what? No, but this wing will actually help us fly our, like, channel to sell more. Or at least we have some guests that might do that. And so like,
the business might have, you know, choices to make. They only have so many dollars to push forward, right? And so do we want to fund that extra wing or that extra engine or rebuild, rebuild that control system? We can go further than just saying, this is the thing we're making, right? That's the starting point. But what do we get out of that critically speaking? And how do we make this airplane just run faster? What is faster even mean for your organization? Is it about delivering
more things? Well, delivering more things, does it help you sell our stuff? Or does it help you, you know, customers are happier on this thing? And so I actually think where to the point now is the good part is I think it's industry. I think we're, you know, I think it can be viewed as not fun. Probably isn't fun. But I actually think that we're going to tie the pieces together, be more acuity brought together. Because all these things actually have to come by. And I think
that's an important part of that evolution of things. My other reflection, by the way, Patrick, is we're talking through this is it actually has to do, which a little bit of this, but this, this, this jointness around the concept of timelines, okay? So like we've just spent 15 years talking about the great parts of agile. And I think we actually have all learned many to add to the risks to business, to the risk delivery, to the risks, those things, which is great.
Like I think there's nothing bad about that from a delivery standpoint. But I think the part that I think is still not sufficient about there is that businesses need to plan for a year out or two even. And that's crazy. That's like really far, right? Like we're, we're sprint planning like three sprints and there's a lot of river going on while you can't do it. But the reality is the business world just does, right? They fundraise that under, you know, air quote promises for the next
couple of years. They ratified budgets that sketch out things for the next year. Is it going to be right and perfect? No, but they just do. Right? And any of the obtuse to ignore the fact that the system does that. I think like we have to be relative like they're like all these comments I'm making a real estate dependent. I think some listeners might be out there being like, dude, I got like 10 people on my team and wait, we're just making the things within the cell.
Heard got it. Congratulations to those folks here. You're at a fun point in time. So I'm probably not speaking to that like you probably don't need a year company. I don't know what a year's going to be from now. You're not ratifying a bunch of three year for that company. So like you don't need to hear from me on this. But, but I think it's successful. You will, right? Because at some point money isn't infinite and you can't just make yourself and throw things, get in the wall.
The first unit of the moment, they're right going to do a certain stage of the business. I hate it and you can't plan what's that is going to stick. But as companies mature, you fundamentally are in an ecosystem where you're actually making trade-offs. And for good or bad, the business world starts to make trade-off on an annual basis. And yes, they can reach out to them on budgets. Yes, they can do quarterly realignments in all these things. But business is
a financial generally works on an annual basis. And it might be annual by January off some of the annual mid-year, but they generally plan annually. And this is for this dissonant thing, which is we do this moreover like we're lucky to plan for two weeks. And yet, you know, the business is making choices on behalf of you for like 50 weeks later than that. And so like I think in ob-two sets, we just ignore it because when I change them happening, it's not that you ignore it.
Someone else makes the call for you and that's even worse. Right? And so like there's this whole missing skills set here for all of us. We never talk about it. Like yes, teams are most effective if they can actually like kind of work in a world of two weeks out. And I'm picking one framework, for example. But the business is successful if you actually can plan a year or two out and then boys that brand exploding. But I don't even know which is going to work in which of those things,
right? And you're right. But like as bad as you are about guessing what the years look like, I bet you know, a finance person, I guess you're as worse than you are. So what's your idea? You make the guess on that stuff. And it doesn't mean like I think you'll get religious being like this is set in stone. No, it's a budgeting exercise. And you're putting this together to actually clear, you know, a board's approval or something like that. But then you move on,
you adapt accordingly. I don't think this means like, you know, the world's telling you to waterfall it out. But it does need to believe it does need to have a believable plan for the next year. Because it's an expression of where our best guess is on where things are going to play out. And I think that's part of it. And so do you think the finance person's going to come and do the translation probably not? Right. So it comes back to the leadership part of it to do the translation.
And so this goes to like, yeah, understanding what the last year looked like, understanding, how much you're spending on bug fixing, understanding how much we spend on forms of maintenance or KTLO. What are the different kind of new features we're doing and how is it going to actually impact strategic bets on this thing? And understanding like, hey, all the new things, which ones are actually going to move the needle, which needles? And how much? That's the job. And sometimes you'll be like,
okay, well, that's a product job. And it is true. It's probably, but it's also a engineering part of the technology decisions. We're part of the maintenance factor. You can look at your historicals and understand what those costs were modeled at for. If you spent 15 people and bug fixing every quarter for the last year or two, you know, lie to yourself and assume it's
going to go to zero. No, you shouldn't. As much as we might wish it, let's get realistic. And I think part of this is like that kind of shepherding has got to come from this kind of leadership we're talking about because it's not going to come otherwise. You get to help the company make the hard decisions and that stuff. So I think it's around these times that I think it's really important to contextualize both directions, level up that visibility and help people kind of get across the
finish line. As a US company, hiring remote engineers can be time consuming, expensive, and frustrating. You could hire freelancers, but you don't know how much they'll focus on your business. Out sourcing to dev shops, risks, control over who works on your projects and expensive long-term contracts. Or you could look overseas, but working across lots of time zones can really
slow things down. Enter Revello your gateway to a talent network of over 400,000 pre-bedded engineers in Latin America who are proficient in English, work in your time zone, and are dedicated exclusively to your business. Revello simplifies the hiring process, enables quick payroll in local currencies, and provides expert staffing support. There are no big up front contracts you only pay for each month that you decide to keep your developers employed. With Revello, you're in complete control.
You get to decide who to hire, what to offer, and you get to decide how long to keep them on your team. To learn more, visit Revello.com forward slash ELC today and save $2,500 off your first hire. Let's transition to a new challenge. Team topology, org planning, and org resourcing. How do you adapt and intentionally shape your organization to put you in the best position to achieve your goals? What's the most effective way to organize and deploy your resources?
These are existential questions that engineering leaders wrestle with at all stages of the company, Samir Naik joined us on the podcast to discuss how plads engineering organization had to evolve over the past 10 years, and we broke that journey down into three different phases. Here's an excerpt that puts you right in the middle of that transition between product market fit and the initial scale up and how that might impact how you structure your engineering
organization. When you're going from phase one to phase two, that's a transition where you have reached product market fit. I'd say the first thing is that the phase one is such a great sweet spot. Try to stay in that as long as possible. I think Plad really tried to stay in that as long as possible, where you're really small and lean and communication overhead is low. If you can stay in that sweet spot without customers churning, it's really efficient and it's
just such a great place to be. When you get to product market fit, as an aside, a failure mode is assuming you've gotten to product market fit a little bit too early. Sometimes you think that if you've reached a certain funding milestone or a certain number of customers, that's product market fit. You know you've reached product market fit where there's tons of customer pull and your team really can't keep up with the demand. You start seeing tons of bugs and feature requests
and your backlog is growing and you just can't keep up. To me, that's where you get to product market fit. That's one leading indicator is your feature backlog growing. The second is the way we handle that for a really long time is by extreme focus. Talked about the single backlog, but what the single backlog also means is you're saying no to a lot of high ROI things because they're not the highest ROI. That's fine for a while. It's really great for focus. It keeps your platform
really focused as well, but it does start to eat away at your NPS. Your customers are getting said no to for things that are really legitimate tasks. That doesn't feel great after a while. That's another indicator is customer sentiment in NPS. NPS is very lagging indicator, but you can start to feel that sentiment from customers. Probably the third one is what I talked about with
Dunbar's numbers. Your number of paths it takes to get anything done. One thing we saw is you used to be an account manager or somebody that's customer facing could just reach out to one person and get an answer about how a product worked or why a certain bug was happening. After a while, when the complexity of our teams went up, you would see people just hopping around slacks saying, do you own this? No. Then they get routed to another team. You can see somebody's getting routed
around. Nobody has true ownership of something. That's another sign that you don't have the right interfaces internally. We were seeing all of that. I think that's what led us to say. We need to really spin up teams in order to have stable interfaces and stable investments so we can say, yes, more to customers, but also be more efficient about how we route things internally.
How did your role evolve through these things? I think specifically, I'm looking for, I guess, what was probably asked of you or how you had to rise to meet the different changing leadership challenges with all of these different phase changes. You probably had to learn a lot, grow a lot. What were some of those inflection points for you and how did that opportunity come to be? Yeah, it's a big question. There's probably another one of these things where
you don't realize it's sort of happening in the moment. I think going back a little bit to my history, I started my career as an engineer at Disney Imagineering. I think one of the things that I really learned there was, Imagineering was a place where you'd hire engineers that sort of were very creative, had to think about product and design and engineering at the same time.
And so I got to work with really talented engineers there, but I think it also was a very non-functional place, meaning that there weren't a ton of specific functions to handle things like product and design. So it kind of forced you to think about many sides of the end product all at the same time. And so my nature was to kind of think that way as I sort of grew up in my career, working in video games, and even in B2B products was really the end business impact or the end user
impact is my job and the thing that I had to think about. So even though the plan I started in 2017 as an end manager and started to work on organizational things, started to really focus on recruiting in the first couple years. The eventual path took me to thinking about the business as a whole, just because I think I, by nature, kind of looked for what is the biggest problem we needed to solve, whether it was engineering or not. So a couple of personal and inflection points,
I think one thing that I hadn't really ever done before was start a new office. And second year into plaid, it was very much like we need to scale quickly, can't do it in San Francisco, let's start a new office. And that role was, I'd say like almost 99% recruiting, 1% talking to different cities and understanding which one was going to be the best fit for us, but it's very much not strictly engineering. After that, it was really like, hey, there's a bunch of demand for new products for
customers really on plaid to build new things. And it was spinning up a couple of different new product groups. And that was a ton of organization, a lot of engineering work, but also thinking about the product side a lot and product strategy. And then more recently, it's like as we split into business units, we see a need for our core business to really continue to strengthen our core products, but also meet the needs of an expanding FinTech ecosystem and innovate on things that will
take us to the next sort of phase of growth. And so again, I think having some of the longevity of plaid and being able to balance engineering and product and go to market, I think that's led me to sort of fit into that role really well. And it's a transition I went through over the last year. I'd say one sort of key inflection point or learning, I remember a conversation I had with John D'Ane of sometime last year is kind of sitting back and looking at what I was working on.
And I made the comment is like, I don't think a lot of this is really engineering focused, right? It doesn't seem super relevant to the engineering team. And he kind of just paused and looked at me and was like, that is your job. It doesn't matter if it's engineering and you need to fix these problems. And I think it was a mindset shift for me and it was a really helpful feedback, but I think it
kind of frame that there's a bunch of themes in an organization. Doesn't matter whether they're engineering or not, but I really need to kind of look for those themes and those opportunities and make sure they're addressed, whether that's in my job description or not. But what happens after the initial scale up when your engineering organization is operating at a much larger scale. Serby Gupta joined us to discuss how she approached or design during a hyper growth moment
at Robinhood scaling from 300 to 1000 plus engineers. The highest level actually think of it as two different types of teams. You have platform teams and you have product teams or business teams. And I think it's important to recognize the type of team you are and the way the leaders need to operate. So you have the business teams that are at the frontline of building customer features. But they can do that unless you have your platform teams, right? Which is infrastructure or
fraud or customer care, customer support. And what I often find is that you want what works well is that you keep pushing things down. And so let's say that you have two of your business areas that need some common logic. It's more efficient to have a team that can build some common abstractions that help both teams. And so for us here, it's been a journey of evolving our teams going all
the way from the initial structure to this, the product and the platform teams. And then I've talked about the technical programs organizations, but we have that as well that kind of helps all
of these teams. I have a follow-up question about this is I think one of the questions I've been most excited to get your take on because the growth experience from 300 to 1000, to me it seems like there are a lot of complexities and nuances, especially as you are stratifying different functions underneath that with platform, product, QA, data science and all these other
sort of engineering functions. When you were going through like this evolution over the last two years, how did you think about or approach the org design or the planning process for these different things? Was it a continuous operation where there are sort of distinct summits that you had with other engineering leaders on the team to start to architect what that looked like? And I guess how did you balance those different functions as they were being built out? Yeah, that's, it's a
good question. I think that you want to start by actually looking at is there any glaring gap and because there's a new leader and we haven't talked about this before, but you want to try to bet on internal talent where you can and you need to give yourself enough time and run way to be able to develop talent. And so I think that it's important to start with, hey, is any glaring gap
where you need to actually hire someone from the outside? Right, so for us, one one example is when I started we had we had a debit card product and we had two different teams that were working on it and so teams themselves called out to me that like I think we should merge these into its own organization and so that's what we decided to do and then I hired a leader for that, right? Or there was another area where we didn't have a consolidated infrastructure organization and so
we consolidated that and hired ahead of infrastructure. And so I think that I would say it's a journey, it's important to pace yourself and then sometimes you actually and again, like there's no one single playbook here, but I would say that I guess strategy that I used initially because I wanted to see which teams were able to scale is I had a slightly flatter organization and then I worked on narrowing it. And this just gave me some time to be able to look at different areas and
and organizations are living and breathing, they're going to keep evolving. And so I do think that for me, I think of it as a two-year journey, it's not something that I came in and I said on day one all right, like this is the end state and how do I get this quickly as possible? I think you have to really kind of keep evolving the structure and try to not outpace kind of where the organization is or what it is. A quick follow up on the flat team structure, is that true that early on
keep it flat? Well save this space for a little ongoing narrow and be more hierarchical, once you have no more understanding of what you need because I came imagine the reverse of that from a hierarchy called more deep Augs structure to a more flat one requires more term because almost can be perceived as a reward versus adding more layers of Augs structure as needed because
that reflects the maturity of certain parts of the organization. Yeah, I would say that overall kind of org structure scaling, it's always a point in time, like you can look at it as being 300 to 1000 engineers, but in two years we could be, I don't know, 2000 engineers and then you
could say, okay, are you flat or hierarchical in the 1000 to 2000? And so I really think that it is a journey and what's important is that you feel you have the right leaders in the right to roles and especially in periods of hyper growth, like people's roles are changing every three to six months, like it is changing so quickly that people might not even know their own sort of
interest or they might say that hey, like this role is no longer fun for me. I think that being a little bit flatter, I think gave me the ability to just to work with different leaders
and help grow them and help understand their own interests. I do think that a lot of people say, like ideally you should have six and six to no more than eight kind of direct reports, and I do think it's a good goal to have, but I think Jerry, to your point, like if you are scaling very quickly and you are very hierarchical, it does give you lesser dimensions in which you can make changes and it would feel like a more massive reorg. Reorgs are never easy. However, they are
sometimes necessary for an organization's success. We had a conversation at ELC annual about how to do an effective reorg with Aaron Erickson and Mike Tria. They discussed when you should consider a reorg and then they shared frameworks and strategies to help you implement a successful reorg. McKinsey did this study in 2016 where they went and measured for companies that have done reorgs, what percentage of them actually achieved the results they were meant to do, what percent
actually achieved the results? And the answer is 20%. 20% of reorgs actually achieved the outcome for the business that's intended and 10% of them actually caused material damage to the company. So the vast, so it's not just anecdotes that most folks here have felt like you've experienced a bad reorg. Most of the ones actually out there do not achieve the results that they're meant to do. So let's say you've got a situation where you've heard there's some stat in your business,
some particular piece of information. I don't know, you've got lower use or count than you think you might have or your conversion rate isn't good. Let's say on a product, so because you have a bad conversion rate, we're going to reorg and build a team whose whole job is to solve the conversion rate. But then later on you find out it wasn't actually a conversion rate problem. You did your entire org change based on bad data. You did it based on a rumor. Good luck explaining that one.
Like we say, sometimes they do damage to the company and when you reorg for no good reason, who here wakes up in the morning and say, you know what, I want four bosses in five years. So everybody want that? Is that like what you aspire to do? Let's build a new relationship with our boss every time we hit January? That sounds kind of a terrible way to go through your career. It's hard to build trust with your boss when you get a new one every six months, right? So a lot of these,
you know, sometimes, and again, these are, this isn't a lecture from us. This is Confessions because we've all done them. We've all made these mistakes. And so one of the reasons we talk about bad reorgs first is we would love for people not to make the same mistakes sometimes. So we've covered all the bad ones, at least that we know about here. And I'm sure people in the audience have shared bad ones. Tell us about them. We'd love to hear your stories because it helps this talk.
But Mike, what are some of the virtuous reasons to reorg? Who here is heard of Conway's law? I would say the best reason to do a reorg is what's called a reverse Conway maneuver, right? So ultimately, that, you know, Aaron and I just talked about a whole bunch of purely organizational reasons to do a reorg, right? They're looking inside the business. They have to do with like spans of control or products that aren't working or some weird trend. None of them. None of those reasons have
anything to do with enabling some outcome for the business. You want to enable something in the business. You either have something that isn't performing well and you want to improve it, or you see some opportunity out there that you want to chase. Those are the reasons to do a reorg. But a reorg should still be one of your last resorts. So think about it this way. The virtuous re- the virtuous reorg, the idea, you've got something out there you want to do, like an IKVW
specific example at Atlassian where I am. We wanted to start to serve enterprise better in our cloud, right? Historically, the Atlassian products, if you're familiar with them, enterprise companies like the largest, like, you know, your Fortune 500s, they would run our on-premise products. They would go and download and install the products, they would run them on-premise themselves. Our cloud offering was just not suited. It was just not set up to be able to support
enterprise customers. We couldn't do it. For years, we have tried. But to do that, meant a whole bunch of subteams of a bunch of departments all working together to achieve something. Like this subteam here has to change their build system. This subteam here is to focus on performance. This subteam here is to focus on scale, compliance, etc. Maybe we could have pulled it off, but you're asking for a vertical outcome from a horizontal set of teams to be able to solve the
problem. A reorg is a really good solution to this particular problem. You say you have this outcome you want to achieve for the business, and you want to take all the horizontals and turn it into a vertical. Let's make a team whose job it is to achieve this particular outcome. So essentially, the best outcomes, the best reorgs have some very clear business charter, business mandate that ties into the actual change. So what you're saying, Mike, is the best
reorgs aren't called a reorg. The reorg is a side effect of the business outcome you're trying to achieve. And it just happens that you have to change some reporting structures or build new teams or maybe shut down one thing to make a new thing in order to achieve that outcome. You wouldn't even know it was a reorg if it's one of those virtuous kinds of reorgs. Yeah, I think that's a good way to think about it. Yeah, and note, no, we're in there. Did I say anything about
expansive control, organization, or people, right? So I think a really important thing with reorgs, the ones that the ones that work well follow this formula. They go strategy, lag, people in that order. Often when we think reorgs, we think about it in the reverse. We think about, oh, I've got so and so strong leader. How can I put more stuff under that person? They're not thinking about it in the inverse, right? Which is, how do I achieve this outcome for the business?
Figure that out first. Then go through and think about what's the org shape that makes sense. After that, start putting people's names and boxes. Because what you'll probably find is that you might have some great people. You might be missing great people because you may have a box without a name in it in that situation. So the reorg, you know, very much as Aaron said, it happens to be just the means to the end to achieve the business goal, which also we'll get to
later, which is how you know if the thing worked in the first place. The last challenge shared by the community is strategic thinking, specifically leaders shared with us a desire to improve the ability to think critically about current challenges, analyze complex situations, anticipate future trends and develop long term plans or solutions to achieve specific goals or objectives. I mean, this sounds like the key to the job, right? And many of the features shared so far support this
effort to become better at strategic thinking. So with our last two features, we're sharing more of a story and a scenario or a case study, if you will, to really see strategic thinking in action. Ahmad Elwani joined us on the podcast to talk about the messy in-between phase that startups face when scaling and discussed his approach to organize engineering by strategic themes or
complete units of value. So we do our QBR once a quarter, like the whole organization sitting in one room and reviewing the whole roadmap and understanding kind of like, why are we investing in this specific area? And then before actually that step, there's a pre-processing step which is I say with the engineering dev leads and we come up like with a list of everybody we already have,
what are like their strengths and where can they contribute the most. This includes their actual strengths, like maybe they're a very strong back end coder, maybe they're very good at system design and also what have they historically worked on? Because if we can align somebody who's worked on something in the last year, the three align, then they're going to hit the ground running. So we just kind of like try to analyze the team that way and start putting people into
these units and identifying the gap and this will influence our hiring strategy. So maybe if we're if we have a certain number of headcount in X quarter, we should really try to hire the people that will fill these gaps. We make sure we have consensus, people are also in a good spot, like we don't want to just have people feel that they're just kind of like jumping around randomly. It has to be done in a good and respectful way where they still kind of are working on something
they enjoy. We're balancing also their needs. So different engineers will have different needs, some of them might value growth, some of them might value learning, some of that might value just like learning a new technology. So let's try actually to put this into the mix. And it's kind of like a problem with a lot of constraints. It's not trivial, but if you do it with with enough kind of diligence, you can end up with like a very good solutions and it works when the team is small.
So if you have a team of like 25 engineers, you can kind of like still solve the optimization problem. I'm sure the team grows too much. It's going to become very hard to solve it. And I think we've done a good job at it. And there will always be edge cases. So maybe we've done this and then there's like a few people who they would be really good for this team, but you know what? They have made it clear to their manager that they want to learn this technology. So okay, let's do the right
thing. Let's kind of like do a trade-off and maybe just take this into account. And now we have a bunch of teams. We call them virtual teams, we teams and we decide to say, hey, this team will own this team, this team will own these other two and that's last team will own the fourth. And then we go into the QBR and actually have a after we review the roadmap and make sure everybody's on board. We would tell them, hey, this is, we actually use mountain name, so we have team
raneer, team Olympus, team glacier. These are all Washington state mountains. And then we say, hey, this is the team, these are the people in the team, they're going to own this. And then we have a discussion and make sure everybody's on board with a plan. First off, the naming, the nomenclature of the teams, huge fan as a as a fellow Pacific Northwest resident. I now also think like nothing more symbolic and inspiring for a startup journey than talking about summits and
peaks and long endurance journeys together. I think there's like, there's some good layered symbolism there. Yeah, I can't take credit for that one. It was some somebody on the team came up with it, but I love it. And I just felt right. I love it. We we've talked a little bit about the team structure or like the the structure that's been organized here. We talked a little bit about the other models that folks like sort of get stuck in between. And then we were talking
about the trade-offs in the middle. And so you had mentioned we can kind of dive into, you know, now that we have a sense of what did you land on. And then we can talk about how the trade-off conversation fit within what you land is on. So bring us back to the trade-off discussion and how that fits within the context of the model you shared. Absolutely. So I mentioned a lot of the
things that work well. Let me now talk about the things that we don't think are great. Very big, one of them is the one I already mentioned on just kind of like having people not reported managers. We've discussed this one. So I'm going to move to a new one. As any SaaS company, we have an uncle rotation. There's always a set of engineers who are primary and secondary and responsible to be points of contact to deal with issues as they arise, whether it's an alarm, automated,
or customer complaint, whatever it is. So the problem now is if you have these themes, how do you manage the uncle? The people are moving around. So you don't have somebody who's an expert in part of the code base. And you can say, hey, whenever an incident happens in that area, I just give it to that sub-team. This team really changed all the time. So we had that very serious issue where like how do we even come up with an uncle loop? Who do we put on it? And what happens
if the person on call now gets an incident that they've never interacted with in the past? How do they deal with it? So there's a big point of friction. We ended up solving for it by coming up with a good escalation policy and making sure that we have really good documentation so that the uncle person is not necessarily responsible for solving the issue, but at least for an understanding impact, triaging, and assigning to the right person. So we ended up always kind of like something that
works, but it wasn't easy. The tooling had to be configured a certain way. We had to document a good process. We had to do a lot of training on it and make sure that people don't feel it's already a stressful situation when you get paged. So you want to make sure that that person doesn't only have to worry about the page, but also like what do I do now? Like yeah, I'm getting out of alert about something I've literally never even seen the code for. So that was one big thing
that I think was not easy. Another one was hiring. So typically when you're hiring, you are hiring for a specific team and the people who interview would mostly be from that one team, you would maybe have like a bar razor from outside or something like that, but it's easy. Now that the team are shifting all the time and we're not necessarily hiring for this quarter. Maybe we're hiring for next quarter and next time to ramp up who's on the loop. The people who are kind of like hiring
that person might end up not working with the next quarter. So this meant that we needed to have a good interviewing and hiring process that allows us to more like hire for Lexian, not hire for individual team. And this requires putting some thought up front into what are like the skill sets that we're going to need generically, looking a little bit ahead into future road maps and understanding what mixed skills we need to hire for. And it made it a little harder. We were able again to work
around it, but it wasn't smooth. Surely if we had taken one of like the more traditional approaches, that problem wouldn't have even existed. So you end up with things like that that just require now you kind of created a problem with your solution. And at every point you identify a problem, I think you have to pause and decide, okay, is this really worth it? Are we like doing something that's too unorthodox and maybe we should just backtrack and revisit or do we think we can actually
solve this problem? You should give yourself a budget of an amount of problems to solve. And then if this becomes too much and you feel like you're constantly solving problems because of your approach, you really should be open to revisiting this. And maybe people don't do it this way for a reason. And I should go back to the general wisdom. A different strategic thinking case study that
we wanted to share comes from our podcast conversation with Scott Woody. Scott joined us to talk about the challenges operating engineering at an early stage company immediately at global scale. And he shared how metronome built specialized engineering teams to cater to specific customer personas more effectively. So when we were smaller, we kind of just had one giant engineering team.
Just like 15, 10, 12 people, just like we're all on the same team. And what you work on, you start to specialize a bit like there's some people who are more infrastructure leaning and some people who are more front and leaning. But what we realized about nine months ago, especially as we started working with these more public companies, was that actually like the needs of the specific persona were so specific that like this kind of concept of engineers being able to understand, like fit the
entire product and needs space in their head. It became impossible. For me, it became impossible. Like I know exactly when it was. It was middle of December last year where I was like, I actually cannot, like even if I spent all my time trying to understand all of the needs across our client base, it's actually impossible for me to hold it all in my head. And I'm not even trying to act on
it. I'm just trying to like store it. And when I have that, when we had that realization, what we realized is actually now is the right time to start to take the kind of bigger team and focus it based on kind of two things that are very related, which is like we basically started to fork the team into specific workflows. And the workflows are typically one-to-one map to a specific persona. And so for instance, we have a team that's focused on ingestion and processing of data.
The persona that's mapped to that is engineering. And the workflow is I'm an engineer at OpenAI. I need to be able to rely if we get data into into Metro. And I need to be able to read that data out. And so like it was kind of this coherent thing. And so we just started staffing teams against these specific personas. And we started putting up a little bit of like while it was nice to imagine that people could hold like it's like I could also understand engineering and understand the
finance use case. We started to say, you know, that's nice, but like that isn't an expectation. And we need to start to specialize a bit. And so we actually like literally started creating teams around workflows and then mapped those to personas. That worked reasonably well because we had seeded each team with a couple of really strong product engineers. But then what happened is when we started getting into the details of a larger customer, you're starting to talk to someone who's
like a finance operations person, they've done this job for 10 years at this company. Their workflows are incredibly detailed and incredibly complex. And what we realized was that a good product engineer could intuit their way to like a third of the problems and solutions. But like actually it
was like a full-time job just to sit with the end user and deep deep deep dive. And most product engineers, I think they hit a limit where they didn't have either the bandwidth or the stomach to kind of go actually become a thin-ox person because we were never going to hire an engineer who is a former finance person. It's not possible. And so instead what we decided to do is have PMs
specialized and basically embed with these teams and become experts on the workflow. And then their job is to back translate that to the product engineers at the right level of fidelity. But when you're building like expert use tools, you in some sense have to have experts on your team. And so we had to like create those experts because we couldn't find like a finance person who was also not our PM bar like there's like a really hard search. So we just said, okay, let's like
hire a great generalist PM. And then your job is now to become a finance person. And then back translate that into product requests and then work with the product engineer to give them the right amount of context so they can make good product engineering decisions. And so we started doing that. And then the other thing we started doing is phoning experts. Like we just started retaining consultants who were experts. Like it's like basically like you're a finance person,
you're on speed dial and we will pay whatever to answer the phone at any time. And then the last thing we have this concept of a design partnership with a lot of our larger customers. And in the design partnership we go in and we say, look, we are not experts in this particular workflow yet. We will be and we want you to help us get there in exchange. We need to have like more or less unfettered access
to you continuously for the next nine months. We're going to come and ask really dumb questions. We're going to ask really smart questions eventually. And eventually we're going to teach you because we're going to have like a market understanding and we're going to help bring technology from this other company into you. But it's going to start out. We're going to be kind of novices and you're going to help train us and we literally select a client who were amenable to essentially
like teaching us until we became the teacher. And that's kind of what we've been doing, you know, honestly for the past four years, but this year kind of hit its head. It's like hit that breaking point from like we need to specialize a lot more. And now we have more or less specialized teams that kind of you one-to-one map a team to the persona. And that person's job, the PM's job is to become basically could do that job at a large Fortune 500 company.
That's it. We have one more episode in the top 10 challenges series Farhan Thawar, VP of Engineering at Shopify joins us for a dynamic rapid fire high density conversation where he gives his very best takes on all 10 challenges. You don't want to miss it. It's the perfect capstone to this top 10 challenge series. And I can tell you right now Farhan brings the heat to this conversation. Join the conversation with us on LinkedIn. Let us know what you've learned and
help us share the wisdom across the community. See you next time on the engineering leadership podcast.