Leading effectively across company archetypes: product, business and design-led leadership w/ Sebastiano Armeli #253

We're doing a special in-episode feature on the future of AI-powered incident management with our friends and sponsor X-Matters. People as a primary integration layer is really fragile. With multiple people and all that coordination, you become slower to find the root cause. The slower you find the root cause, you then don't know what action you need to take to resolve it. Getting to that fast is the goal. Later in the episode, Mike Bennett, who leads the engineering team at X-Matters, shares why human-driven coordination creates outage risk and how AI-powered orchestration can dramatically accelerate your path from event to resolution. Line managers have to be much more in the details, almost at the task level, but on a daily basis, have to be much more in the details of what's going on on the ground than in product or design-life companies. That's where having forums like stand-ups or like campan boards, those are things that are very often happening in business-led companies because they give you visibility on the granular tasks. Versus in product-led companies, things happen to be more fluidly and you might not even have stand-ups or campan boards or an average-eyed board. Hello and welcome to the Engineering Leadership Podcast brought to you by ELC, the Engineering Leadership Community. I'm Jerry Lee, founder of ELC. I'm Patrick Gallagher and we're your host. Our show shares the most critical perspectives habits and examples of great software engineering leaders to help evolve leadership in the tech industry. In this episode, we discuss what effective leadership looks like across three different organizational archetypes, product-led, business-led, and design-led companies with Sabasiano or Melee Engineering Leadership at Meta. We deconstructed the situational leadership frameworks Sabasiano has learned and observed from working at companies across all of these archetypes at places like Spotify, PayPal, Pinterest, Snap, and now Meta. He's also heavily involved in the startup community as an investor, advisor, and mentor of engineering leaders. So he has an incredible breadth and depth of experience of what effective engineering leadership looks like across all of these different company archetypes. We also talk about how AI is moving managers from implementation to architecture. Why the next bottleneck is managing the mental overhead of high-velocity experimentation and future team topology where AI enables one person to manage high-scale teams of 30 to 50 people. Enjoy our conversation with Sabasiano or Melee. Sabasiano, welcome. It's so good to see you. How are you doing today? Hey Patrick, I'm so glad to be here. Excited to chat with you and I'm pretty great. I've been really looking forward to this conversation. So Sabasiano has been involved in the community for a long time. A couple different years now. He's helped support at our conference. So I've known Sabasiano for a handful of years. And so, Sabasiano, this has felt like a conversation a long time coming. When we've been kind of poking around what topics might be really fun, we were kind of reflecting on some of the different parts of your experience. A, we identified this like unique thing where you have led engineering teams at a couple different company archetypes. Some of these companies where they're the focus or the outcomes they're driving towards or the incentives are slightly different and then therefore engineering leadership and successful management sort of look differently or oriented a little bit differently. And so we thought it'd be kind of a fun opportunity to kind of dive into your experience and compare contrast and to start to deconstruct what great engineering leadership looks like in these different contexts. So to, I guess, open up the conversation like, Sabasiano, can you sort of introduce us to these different business archetypes? What's the roadmap that we're going to deconstruct today? Yeah, for sure. I think overall, the way I classify the experiences in companies that have been is in three different archetypes. So first of all, product led companies, product led companies are companies like meta where I currently work, Pinterest, Spotify, decisions that those type of companies are driven by product managers intuition and by measurable metrics. And really those metrics, they really drive the product. For example, when I was a Pinterest, I was leading a few teams in shopping and you know, the top line metric of our group was the number of shoppers. So basically people that express interest is shopping a Pinterest and changes in the product they were doing. We're really rotating about improving this metric, the number of shoppers. So lots of the focus on the engineering inside is around the product itself and making sure to move the metrics. Also the ideas often come from bottom up and from engineering as well. Another example is when I was at Spotify and we built a zero to one product called at Studio, which is like the self service at platform, which I believe is still used as Spotify. That was a decade ago. That came from a couple of engineers during half week coming up with the prototype and then they became like a alpha and beta product. These are high level like product like companies, so like metrics, frustration, experiments, people really passionate about the product. Second archetype is like business led companies, people I worked there a few years ago and also like I feel like upwork partially is between business and product companies. So those companies are really are driven by the business needs. So like more than the product sense is the business driving how you shape the product. Between those type of companies, the operation of rigor for engineers is what really is more important than anything else. Usually those companies they take less risk, they kind of like predictability and the decisions are like more structured where like engineers, maybe they're less on the driver seat in terms of like product decisions, but they're really accountable for execution. And then design led companies are, I feel like a more the third archetype and they're more be more rare. Snapchat is an example in my opinion of like design led company. I work as a snap for a few years. You know, the reason why snap is a design led companies because the CEO is a designer, so that basically carried over. So in a design led company design and user experience, they're really at the core of the business. Designers really run the show because they can express as much as they can creativity and really engineers align with designers and really they try to execute as much as they can. What the designer. So engineers really need to have a good product sense, a very good eye towards user experience. So those are like skills are very different from like a business led company and even more than in a product led company. Also like in a design led company engineers that really need to advocate for feasibility of like those crazy ideas from designers, a bit more than other type of companies and product managers also take slightly back seat in terms of coming up with idea compared with a product led company. So basically in a nutshell, design led companies are companies where there are lots of focus on metrics, experiments, pms, product usually come up with ideas. Engineers really also need to have a product sense business led companies are more focus is more on the business on the engineering side is more on operational rigor execution and design led companies are more focus on the user experience design first and engineers are more focused on the feasibility of those ideas. So great about laying out the distinctions here is I can already start to tell how decisions get made differently in each of these contexts and then therefore like what does good execution look like and then for a manager or a leader like what your role is in helping drive success. Like I can already kind of see this sort of teased out a little bit. So let's start doing a deeper dive into product led. What are what are some of the operational or management behaviors that you think help drive success within like a business archetype kind of oriented around this this context. So for a product led company, there are few key areas that are really important for an engineering leader. First of all, as I mentioned, metrics are the primary decision inputs and an effective engineer manager or leader really need to bring rigor in terms of reading and looking at metrics. For example, you might want to make your engineers accountable for readouts. So not just shipping a feature and delegate to data science to write the readout, but actually engineers, they really own the readout. They present the data. They think deeply about why there is a regression, certain metrics, a progression and they use data science as consultant, but they really they have like really strong opinions on whether we want to launch or not the feature. For example, another important things about data for a good engineer manager is also a continuously monitoring business metric. Very good engineer managers, they really dive deep into cutting data in a certain way. They do analysis on their own. They come up with theories. They come up with ideas on how to shape the product based on those analysis. Another element in like product like companies is that teams are very autonomous. They're very independent in some sense. Each team usually has like, you know, a top line metric or some got real metrics and engineer managers are really expected in those companies to do lots of alignment and lots of collaborations across multiple teams. Because every team like really tried to optimize for a specific metric and they might be like some conflict. in terms of priorities across teams. The focus as the engineering managers on alignment, on dealing with ambiguity, prioritization, it's really key. We're taking a quick break for a special feature on the future of AI-powered incident management with our friends and sponsor X-Matters. Mike Bennett, who leads the engineering team at X-Matters, shares why human-driven coordination creates out-of-drisk, and how AI-powered orchestration can dramatically accelerate your path from event to resolution. We're the ones that are correlating the alerts across the platforms. We're the ones that have to remember that a similar issue happened six months ago, and this is what we did about it. We're the ones that have to figure out this is a symptom in service A, but it has a dependency in service B that we need to know what that dependency is and how that could impact this thing. We decide on who is going to be page based on some informal knowledge. It's not scalable. I mean, all of that works in a very small scale environment, but as systems grow, as teams grow, people as a primary integration layer is really fragile. So the outage risk is with multiple people and all of that coordination, you become slower to find the root cause. The risk there is not knowing immediately what the problem is, so you don't know what the root for that mitigation is. With all of the information that is out there, getting to that fast is the key goal, and is the key problem when you're relying on people to do it. Where signal comes into X matters, the first thing that you can do is based off of that signal, you can then make a call out to the right people. For our incident process internally, a signal comes in that says we've got a system problem, the first thing it does it pages out an instant commander and an ops person, because those are the two people that are most likely to be on, you know, required in any call. From there, the instant commander can then use automations that are set up in the incident, because it automatically creates an incident for us, it's linked to the ticket that generated the incident, and from there we can determine, okay, well, I've seen this before, because my instant suggestions is saying this looks similar to this instant you had last week, we've got built in automations that can do stuff. So within an instant, you might have an automation that says, automatically restart pods or automatically rollback services. My comment before we can also do that as part of a response to the signal that comes out to say, okay, this has happened, do a rollback, and I can just touch my phone and go back to bed without even getting out to bed. All of the automation, the flexibility of the tool and all the things that you can build in along with the data that you've got with the service catalog with your own call with your, who's on duties and gets you to get the right people at the right time on the call if you need to get to a point where you're in a conference. X Matters automates the entire incident life cycle, taking you from initial event to final resolution to see how their purpose-built AI slashes your resolution times and gives your team the context to stop disruptions before they start head to xmatters.com that's xma TT rs.com. Is there maybe a story or example of a project you've worked on or an analysis that you've done that helps shape the product to help kind of illustrate like what this sort of capability and function looks like? I was a Pinterest and we were kind of developing like a zero to one product on your shop. I think one of my engineering managers took the initiative to dive deep into like the current data and categories that they were really looked at from users a Pinterest and you know she was really able to cut data and analyze okay does it like the categories and subcategories that we should start optimized for in this is zero to one product and that really was a one key thing for shaping a product and just focus on on those users. So that was something like it was really helpful just to bring focus on the product. So she's kind of like looking at like here all the different users like we're trying to drive more shoppers to this specific product or I guess this was like you were developing sort of the initial how do we measure success for this is zero to one product and then so she was kind of cutting data to help like really break down and identify like some of the different pathways for success like was that kind of the goal with the measurement? Yeah exactly. So like just to bring in the focus more on this is the type of user we want to focus on that was very helpful because then we kind of narrow the focus of this zero to one product into okay let's just focus on the subset of users because really what people are leaning towards in terms of shopping is more a women clothing that was like the L2 as one categories that we're looking at. And one of the other things you kind of mentioned when you're setting the context for like the product companies was sort of the story behind ad studio at Spotify and so I was wondering if you can talk more about like some of the dynamics at play there because I think you were kind of talking about some of the people driving driving the initiative forward and what the relationship between product and engineering may look like in something like that so I'm going to tell some of the story of the ad studio build and some of the relationships that play there and what like good leadership can kind of look like in a context like that of launching maybe like a zero to one new feature. Yeah absolutely. As studio was a very interesting product because as I mentioned I started from two engineers prototyping something and then I think the next phase was okay let's convince leadership that that was an idea that was worth moving forward with. I mean just to give you some quick context at the time Spotify was really focused on direct sales and for advertisements so there wasn't much of a sales service but we knew that other companies were really focused on sales service so that project had some business correlation and compared it to other companies that were already trying this so we had some convincing point there. So the idea was really something that really resonate with the director of product in general you need to find alliances you know when you try to convince leadership about moving you know act project into like a real production product and also like really having a strong business visa. So in this case there was a solid business reason at that point we decided okay let's start and focus on an initial alpha release. As you do with all the zero to one product the first thing you want to do is like an MVP and you try to build things in a very incremental way you don't focus at the beginning too much on the user experience but you want to focus more on the end to end flows and get into the most important end to end flow as soon as possible to internal dog fooding so internal users first and then to some experimental alpha beta users. So initially what we did let's just create the flow where we were creating we were allowing small mini advertisers to create ads using at the platform and you know the first MVP was just like purely creation upload of a creative and then payments to through PayPal since it was easy to integrate and that was like the just initial alpha so really basic but really gets you to the first end to end flow people were using internal we were able to experiment and then the second phase was okay what about we instead of uploading it created we generate the creative so incrementally we built on top of the MVP and we added that so you had the end flow and it was like the third line the third milestone and then fourth one about payments PayPal works okay but then you like once we released that to alpha to first user no one was really using PayPal we had to change the way we did payments and we started integrated with credit cards initially and then eventually we integrated with the Spotify ecosystem in terms of payments I think what's kind of cause you can take these two examples and like you know going off like the thesis of here's how this kind of company archetype is sort of structured with like engineering you should focus on building good product and like product sense and moving metrics so we've got like the one side of like the example of sort of taking insights from data science or consulting with data science to really understand like what are the metrics that are available and then how do you use those to inform product decisions or understanding success so we got like that one side example which I think is really cool and then this other of like this bottoms up driven that new feature launch and then some of the patterns to get this live and as you're describing like this is a hackathon project and like then like the process to create this like tell me what you think about you know but I feel like the pattern of that right now is becoming more and more likely that this sort of like bottoms up net new product hackathon approach with AI tools and everything like that maybe is more normal now or like is going to become more of like the common path for everything absolutely I think that that's exactly the direction I think we're moving AI would just expedite that because each person on the team will like small teams could really start building road types and small products and building them very fast adding incremental features and I feel like this fast iteration is going to be lots of zero to one but not only product is going to they're going to move towards because now with AI you can really expedite the building parts so like getting to what I was saying before like phase one of at studio instead of taking three weeks maybe every week would be like any duration of the product all this fast prototyping I think that that's really what we're going to really see in the near future one of the sentiments from Laura talk of shoes talking about like AI is going to amplify whatever system you already have in place so if it's a good system or bad system it's going to amplify it so when you're kind of talking about the dynamics of a product led company this is probably amplifying the patterns of how a product led company is building already and in like this case it's like if you already are a company that is regularly doing hackathons or doing bottoms up sort of product prototyping you're probably going to have a much easier time amplifying that. system through like an AI-powered approach. And it maybe unlocks that capability for something else and maybe he's like a more business led or a design led product or maybe they don't look differently. But I guess I'm wondering like, do you think like a product led company is going to find it easier to like amplify and operate that way? And do you think, am I, I guess is that a right assumption that I'm like, oh, probably like company is like, because it's baked into how they operate. Like are gonna probably have an easier time doing that and we'll see interesting things from there first. I guess I know, what do you think about that? - I honestly think so just because if I look at all the product led companies I've been, the road maps are always huge and it's always matter of like cutting items from the road map and feeding it in a planning. And usually it's actually probably, we have two X, three X, the road map actually gets shipped. With AI, I would see we can actually sheep the old ideas that we have, the old backlog of ideas. So it really unleashed a level of experimentation that is gonna be much bigger than now. Now I think as you said, like that's gonna amplify also the challenges because with tons of experiments that we run, there's a button around, okay, aligning all those experiments in the readouts. Also that is gonna be amplified in some sense if you ship a set of 30 experiments a month 100 experiments a month. So there is definitely that element. I think another thing I'm very interested is the fact that lots of engineering migration that will also be enabled and be facilitated by AI. So actually I also believe that the quality of the products will actually improve. AI agent might independently do migration and some engineering excellence tasks that now engineers spend time on. - I think it's, it's really so that, I was talking to somebody yesterday and they were mentioning like an experiment they ran in their company was like, how much could they have agents like drive a major like migration? And like they took literally a month to test it and like week one of the result was this sucks. Like it's impossible. And then by week two and three, they were like, wait a second, like we've kind of figured out how to use some of these tools differently. Like we kind of now have a flow and we may think it'll work. And then now like the cycle is a lot faster. And so they're, because I think it's to your point, like they were trying to push like how far could you take agentic coding to do something. Maybe that's like a little more tedious and this was like a pretty big, pretty hairy complex problem. And then you kind of have to do it probably not frequently, but like it's like something that may happen again. So like if you build a system like it may work. But it's something interesting to talk about like if that gets nailed, how that then impacts overall quality. - Right, right. And also I feel like with AI, engineers will spend lots of time in building more about systems and architecture more than the implementation with migration but the other things. So I guess the engineers will be more in charge of making those tradeoff and decisions, but then more architecturally and less of the purely execution and figuring out all those details with the migration. - I love it. Okay, so so far we've got product led company kind of what success looks like around the need for metrics and then what that means for prototyping, product development, bottoms up product development. And then we have sort of this forward looking element of like quality will improve as like you know, the patterns of worker change. And then you need as a leader to be effective in your role to better understand systems and architecture and that's going to be more of what your role will be. Let's dive into a business driven company. So bring us into that like and what are some of the patterns that you've observed around what a great leadership looks like or effective operational practices. - Yeah, so business led company, as I mentioned, PayPal was an example and you know, like all the Fintech companies that is lots of collaboration with the risk, compliance, departments. In this type of companies, EB testing is actually much, much less than in product like companies or design led companies, because people want to minimize risks. What's more frequent is large programs that usually they're run by program manager, TPM. So EM's good engineering managers, they really are involved in lots of status reporting, being able to call out risks and delay in a very accurate way. So you really need to stay on top very much about the execution and where the engineers and the teams are at, more than in other companies. Like in product like companies or design, you let teams vary autonomous. Like sometimes you don't even have standups and you have tech leads or engineers like driving, cutting tasks. But in business like companies, as an engineer manager, I see it's more successful to be much more involved in the details. And really master execution and project management. Really a skill that I even personally developed working in business like companies was being more a better project manager in some sense. So making sure that I was creating spreadsheet where I had a clear vision of what all the people in different teams were doing across a span of a quarter of like two quarters, making sure there were some systems in terms of where each project is at very clearly, like having like boards where I could pull all the information on my own. And there was more certainty, I would say on the stages of the projects. Versus in product led, sign leds, companies, sometimes you have less of that transparent sense of like where you're at because you trade more in terms of like empowering people and having people be more autonomous. Ultimately in today, like engineering is accountable for execution. And the skills that sounds like what that optimizes for is around operational rigor. Can you predict the risks or the delays of things? And then from there is then like structuring the right decisions to make sure that like the, then at the end of the day, like execution is accurate and on time. And so when you were thinking about like people that are successful in that context, like what recommendations would you have for somebody to, I think essentially become better at that role, kind of optimize around those skill sets? Line managers have to be much more in the details, almost at the task level, but on a daily basis, have to be much more in the details of what's going on on the ground than in product of design led companies. And that's where like, you know, having forums like standups or like, campan boards, those are like things that vary. I see very often happening in business led companies because they give you like visibility on the granular tasks. Versus in product led companies, things happen to be more fluidly and you might not even have standups or campan board or, I think that would be a giant board. We kind of captured business driven. And at some point, I want to kind of dive in a little bit deeper into like speculating on the future and how it may impact some of these different things. But I want to dive first, I think a little bit more into the design driven company archetype because then I think we have a few trends and ideas that we want to dive into around how things may, how the dynamics of the, like what good might look like, you know, given AI emerging capabilities. I want to kind of level set and dive deeper into design driven first. So can you talk a little bit more about the design driven archetype and what success for an engineering leader may look like in that context and like a dive in a little bit deeper there? And engineering leaders in design led companies, they definitely need to embrace lots of them be with you and really push them fast iterations because as I said, design kind of run the show. So design really wants to see, you know, their design in an iterative way and also play around with their design, check if their design are correct. And so it's very recurrent that you just, you build things and you might ship on a prototype app. You have a very close collaboration with design. Engineering leaders in those companies that really need to push towards creativity and having engineers really have a knife on the user experience. So it's kind of expected that, you know, you don't just build something for the sake of building something that someone told you, but like you're also expected to, if something doesn't look intuitive for the user, you as an engineer, you need to raise a flag and say, "Oh, this doesn't look right, doesn't look appealing." It's also there is some expectation in terms of like innovation. So like breaking rules, so like trying new patterns is seen as a positive. Taking risks is actually a positive thing. That means that engineering leaders, they also need to train and coach the engineers but also themselves to deal with failures. Because when you take risks, they can be lots of failures. They can be things that you might try on the design side. They're very creative, but then when you end up rolling out, that doesn't work out. So failures roll out, rollbacks, they are much more often. So really developing that culture of learning from failures and having failures, resilience, that's definitely key. The other thing is like, I mean, engineering quality is a common thing across the board, but definitely in a design-led company, where there is extreme design innovation as an engineer, as an engineering leader, you really need to balance that, making sure you always bring the engineering perspective and the engineering excellence in the picture. So for example, I can tell you, as a map, there was a forum where every week all the EMs were getting together and they were talking about engineering excellence, progression and metrics, and regressions for each surface on the app. So I was leading the chat and messaging teams there. So every week I was reporting on the send message metrics. That was really to keep the balance between. that the extreme innovation, but also the engineering excellence boss. I can see how, as you're kind of illustrating into the dynamics here, in an environment where maybe there are major UX shifts going on across a bunch of different features, that can be extremely disruptive to maybe somebody who is using your app regularly. And so then, if that shift is done in such a way where then it disrupts the quality or consistency of that experience, or maybe you're running into reliability issues or things like that, I can see how that has a huge downstream impact, especially if you're optimized around a UX, like a very UX design driven experience. I think one of my questions is how to be a good design partner is probably the broad question. And so when you're talking about this and the types of conversations that happen between engineering and design and trying to balance the UX experiment and extreme innovation with engineering excellence, can you share a little bit about how to be a good design partner in that context when you're in that tension? One key there is that designers have really part of-- fully part of the team. The communication between design and engineer is really continuous. More than other type of companies where sometimes designers are almost like consultants that they come in, they do the design, and then they might go off and do other things. Versus in design led, they're really part of the almost development workflow with engineers. So there is a continuous chat even during the building phase. So I think that's really the key there. Like during the building phase, you have fast iterations where even every week, engineers and design, they have topics to discuss, because there is something to check on. A, we build like a screen and checking with them on is this what we're supposed to build? Why don't we build something else? Is this appealing enough? And there are that type of conversations versus in other type of companies is more like the building phase, usually it's only engineering only. And then once the building phase is done, you involve designers and say, hey, this is what we were supposed to build. One area I'm curious about is the role of metrics when it comes to some of these more design driven companies. And so with engineering, one thing you're talking about was you still in this context, you own metrics in a similar level to a product-like company where your fluency and metrics need to be at that same sort of caliber. Can you maybe talk about the role that those metrics play in some of those design conversations, either in the ideation phase or then in determining success of some of the different changes? Yeah, good question. Design-led companies have a high-regard in terms of looking at metrics and details around each God rails and all the analysis about the different facets. But there is much more, I guess, intuition at the beginning of the duration. So like product-like companies spend much more time in analyzing data and coming up with hypotheses that product drives. In design-led companies, design come up with ideas. They might not support necessarily by data. So like all those set of ideas, they're just more based on intuition. Now, when things launch, I would say there is the same level of analysis in terms of data. And now you do the readouts. But also the decision part might be different where in product-like companies, people are more strict in terms of the metrics. So if there is regressions in specific metrics, it's really hard to launch a feature. In design-led companies, I think there is more wiggle room. There is a strong conviction in terms of design pattern that might even override some of the metrics. I love it. It's been so much fun to dive into the distinctions here. I think especially when you're talking about design-led and product-led, you can see there is this overlap of some of the skills, sort of the skills or some of the things that you optimize for can be similar. But then right here when you're talking about this is a major distinction. But in terms of the role that metrics play at what point of decisions, and then what does that mean for the conversation that you're having around the product. And so I think it's interesting to think about the whole decision making cycle and how some of these skills manifest differently. Yeah, it's something sometimes a clear cut. There are some, as I mentioned, some overlapping things between all those types of archetypes, even between business-led and design-led, there are some overlapping terms like the way that you might care about engineering and excellence things. For me, I've experienced all these different type of companies, the beauty of adapting, being resilient, and noticing those differences is being very interesting. One of the questions we were sort of reflecting on was how kind of the evolving capabilities of AI are shifting what maybe operating as an effective leader might look like in the distinction of these company archetypes. And so we're kind of talking about a few different dynamics of what some of these shifts may be and is kind of purely a little bit more operationally speculative. But I want to kind of dive into some of these things of how you see some of the shifting capabilities of AI maybe changing what effective leadership, like some of the patterns of effective leadership might look like. And so we talked about a few different things already, but in terms of what teams look like and what good leadership looks like in the context of those teams, what are some of the ideas that you've been reflecting on? - Yeah, I think more in terms of organizational structure and how team will parade, I've been reflecting quite a bit on how AI can really change this structure of teams. And I feel like there are kind of two different trends where ideas, one is about having engineering managers actually managing large teams. Because the hypothesis here is that AI really helps you with doing some of the operational things that people do such as performance write ups or like getting signals, like even staying on top of all different projects. So like really your main role as a human is being human, which is providing feedback, being a sounding board, and you kind of play more a strategic role, like with a wider scope, that's one idea. I think the second one is said is almost the opposite, is like engineering managers, like managers managing smaller teams, but have more depth. So instead of having a classic team with EM, PM designer, having a cross-functional leader, the covers multiple roles, and you're kind of a bit of everything in some sense, or at least like lead a bit of everything. And that means that you basically acquire more skills in terms of like product design, business, and that kind of correlates a bit more with the idea of solo entrepreneur, that I feel like that can be something that we really can see that is exploding and now with AI. In my head right now, I'm trying to wrestle with, because you're kind of talking about two kind of extreme polls of like, and I'm sure what we'll see is like businesses of all types experimenting across either of those ends of the spectrum, you know, like we'll have the iterations of this for like a product, business, focus, and design like company for the small teams, like with the greater depth and solo entrepreneur model. And we'll also have all three of those archetypes, do something where it's like managers overseeing larger teams. And so I, but I'm trying to wrestle with like, what might be, what are the implications of running those models across like those different polls? We were talking about larger teams, let's say 30 to 50 people, and it's a product lead company, and the dynamics there are rapid prototyping, bottoms up feature developments, the order one. What's kind of interesting is like that manager is sort of then like, like I'm trying to think of like, if there's strategic role, if there's the strategic role, they're probably trying to orient around like creating alignment, sharing a ton of context around where the business is going, and then helping facilitate a bunch of different groups, essentially rapid iterate new features products, like that are aligned with sort of the business direction. I don't know, like, does that dynamic match? Like, or do you see maybe something different play out? Yeah, honestly, where does he those two models apply? Is actually into different context. One is in zero to one products, I actually do see small teams with one cross-functional leader work very well because you need to move very fast. And I think having small teams and that kind of iteration with one decision maker is actually very efficient, versus in products where there is less innovation, there is lots of fine tuning, a model where an engineering manager, line manager manage larger teams, I think that could work really well, because I mean, there is speed, but like, in those situations, I feel like it's more important to have one person which coordinates the different work streams and be more strategic goal, and then each engineer or engineering, like that lead can run the specific details. I guess even in the first idea, even if an engineering manager leads 30, 40 people, that doesn't mean that there is some type of structure in terms of engineering leadership. So I do see that there would be some tech leads that operate in some ways, like owning some areas, but more in terms of pure management in that type of environment, which is more stable, I think that can be successful. I think there's another trend that you were talking about that I thought was interesting. And you were kind of, we're talking about where the responsibility for ethics and AI responsibility, ownership lives. So I don't know if you could maybe unpack that trend a little bit of where you see maybe that kind of emerge within different teams. - Yeah, I do feel like that's gonna be a key responsibility for all engineering, all engineers, all engineers leaders, 'cause providing the context data sets, it's gonna be like the thing that we last to do very careful, and I think that there would be like most of the, very. human responsibility that we have compared with, you know, the pure computing and solving a problem that that would be, I feel like more delegated to AI, providing safe and ethical context to me that that's going to be one of the main things that we all do. Yeah. It lives at the layer of engineering management. I think that's, I think that's cool. Like the, the ownership of that can be easily blurred. Like some people say maybe it's a CEO of the company or, you know, a separate department, but so I think it's interesting to say like at all levels of engineering, like that's where the responsibility lays and like that's a thing that you're accountable for as a part of the overall thing. I think it's like an essential piece of the function. It's almost like the call to the company would become what's that? Like the context that you provide to the AI. Yeah. It's about saying, we're, we're a couple minutes over. I've got some rapid-fire questions, but I want to check with you first if you've got a little bit of time. Yeah, yeah, of course. Okay, perfect. What are you reading or listening to right now? I'm reading a couple of books. One is The Crocs from the same author with strategy, best strategy, great book on strategy. How not to age and finishing it up from Dr. Gregor book on, you know, how plan-based who helps with aging. Question number two, what is a tool or methodology that's had a big impact on you? I would say a couple. Okay, ours task relevance maturity also like for to determine how to delegate to people. What is a trend that you're seeing or following that's been interesting or hasn't hit the mainstream yet? I feel fascinating about the air taxi idea. You know, I'm not the next person. I was just following a couple of companies that they're exploring in that territory and I find it fascinating. Last question is about Seattle. Is there a quote or a mantra that you live by or a quote that's been resonating with you right now? I guess a couple. The first one is let food be the medicine, medicine be the food. So, you know, for my passion about food and how food can drive health. I think the second one is like from another philosopher, so-or-and-cute. Life can only be understood backwards but it must be late forward. A great way to conclude a conversation about wide and story journey across different companies, I think that's a really powerful way to kind of capture your journey here with us. So, boss, you know, this has been a long time coming. So, I just want to say thank you. It's been so much fun to be able to just like dive into your experience and hear your stories and it's meant a lot that we finally got to catch up on this way. So, thanks for joining us. No, thanks to you Patrick. That was a lot so fun. If you're listening to this and you're wondering, how can I connect with other engineering leaders in my city? Pull up your phone right now and go to elc.community. Click our chapters page. You can see that on the menu on the left. Find your local chapter and click join. We're hosting virtual and in-person events all the time and this is the best way to help you get involved. Expand your network in your city and support your leadership and career growth. So, pull up your phone, head to elc.community. Join your local chapter and get involved. A huge thank you to all of our local leaders who make community happen and thank you for listening to the Engineering Leadership Podcast. [Music]