 All right, I think we'll get started. Go for an on time start here. Good crowd for a sponsor talk. So this is engineering engineering. It's about being more than some of our parts. Engineering is the action of working artfully to bring something about, right? Software engineering, chemical engineering, process engineering, mechanical engineering. It's all about that art and skill of bringing the intended results about. So engineering engineering is using that art and skill of engineering to create the structure and environment for a successful engineering organization. So who am I? I'm just a guy who's been doing computer stuff, getting paid to do computer stuff, since I was doing it instead of my homework in the late 90s. I've been doing startups for about 17 years now. Founded a few of them, worked at a bunch more. So I'm currently a director of engineering at Procore, which is still technically a startup. So I'm still doing the startup thing. So Procore, what is Procore? Procore is a suite of tools for running construction projects, projects like convention centers, not this particular convention center, but exactly like this convention center. Procore has been on rail since 2006. We've got 1,000 plus people, our headquarters in Santa Barbara, California. Well, technically our headquarters in Carpenteria, which is a few minutes south of Santa Barbara, because, well, that. That's where we get to do stand-ups. So what do I do there? I'm a director of engineering at Procore, as I said. That makes me an engineer who engineers engineering. And that's a hard problem. But why is that a hard problem? Engineering management on the face of it seems easy. We all want to be here. We're at this awesome conference together. We're all learning and honing our craft. We're all excited about what we do. This is basically one of the best jobs ever in the history of humankind. We all deeply believe that self-motivation is important. We believe in the power of decentralization. We believe that control is not the answer. We believe that engineers mostly just want to do good work. So engineering management seems like it ought to be easy. And a couple of companies have tried just removing all structure and letting engineers figure it out. And it's mixed results. So what's the catch on this? If it seems, if all the incentives appear to a line, if we all just want to show up and do awesome work every day, what's the catch? One of the catch is that engineering is hard. It has an extreme amount of inherent complexity. We've got scope creep and shifting requirements. We've got unknown unknowns. We've got libraries that we thought were going to work. And then seven hours later, we're 18 issues deep in GitHub and submitting a pull request. We've got to get everything right, like everything down to the punctuation, down to the character. We've got hundreds of thousands of lines of code that has to be correct, not just good enough. And by correct, I don't mean correct, because there is no correct way to write a piece of software. There's lots of incorrect ways. There are very many wrong ways, but there's no right way. There's nothing that is just the way to write a piece of software. So engineering is hard. And people are hard. I can give you a big list. Lots of people have given you lots of big lists about why people are difficult, why we are difficult. But really at heart, it comes down to one key core factor. You have a lot going on right now. Here you are at a conference. You got up this morning. I don't know what you did last night. I don't know where you traveled from. I don't know what happened to you all of the last decades of your life that brought you to here. And I don't know what you're thinking about for tomorrow. I know all of those things for me. And I need to know that you have exactly as much going on as I do, that we all have the same richness of internal monologue. And fundamentally, that makes people very hard. You combine those two things and it gets harder. Engineering plus people are harder than engineering or people. And thinking that people will just deal with it, that people are the easy part because we're flexible because we're resilient, is ignoring our own very real reactions to things. So if we want to engineer an organization, we have to accommodate the complexity of both halves of the organization. So what's the right way to do this? Maybe I've convinced you that this is a hard problem. Maybe it's obvious to you that this is a hard problem because you've been doing it for a while. I mean, here we are five minutes in. I've been telling you, hey, this is hard. So what's the solution? What's the right way to do engineering? Well, what's the right way to do a piece of software? What's the right implementation? What's the correct implementation? There are many correct implementations, but there is not a right implementation. And just like software for an engineering organization, there isn't a right way to do it. There fundamentally isn't a solution to this. Just like you'll never solve debugging, it's a process, it's a set of skills, it's a toolbox that you bring to a problem. So you need to bring your best tools. You need to know that engineering organizations that dealing with people, the managing people that working together is a hard problem. It is the hard problem that we all do together. And you need to approach that problem with the rigor it deserves. Because if you expect shallow problems, you'll find shallow results. So why isn't there a right solution for engineering? Like why can't we just find the best practices, implement the best practices, write the great blog post, go take a victory lap? It comes down to the fact that there's, it's all about the context, right? There's this great confluence of context for what we do. And the right thing for a team and for an organization depends on all that context. Who are the individuals on a team? What are their individual motives and skills? What are they working on? What's the product? What are the things that the organization creates? Who are the customers? What kind of industry are you on? Are you a SaaS platform or a space program? Right, you will have radically different right things depending on all of these contextual factors. So an example, how do you run a sprint? Straightforward question, you can find lots of blog posts about how to run a sprint. Well, what tools should you use? I mean, does it matter? It might, it depends, right? Maybe it matters, people might feel very strongly about them. Should your sprint be weekly? Two weeks, three weeks, monthly? When does it stop being a sprint? What are you working on anyway? What kind of delivery cadence should you be optimizing for? Do you have release schedules you need to align with? If you're doing two-week sprints and I'm doing three-week sprints, do we only line up every other sprint? How does that work? What implication does that have for the organization and for our customers? Are we trying to optimize for predictability, for output, for repeatability, for cadence? Is a sprint even the right thing to do? We start with how do you run a sprint and we end up not even knowing whether we should run a sprint. How you run a sprint is a piece of the organizational structure that we can engineer. It's one of the things that we have direct control over within our organizations. We can choose our processes. As a group, as leaders, as individuals, as members of a team, we can structure our teams and our processes to control some of these factors. And there's a relationship between the structure that we can control and the execution that we're trying to achieve. Structure is all the things. It's the sprints, it's the tickets, it's the processes, it's the protocols, it's requirements and standards, it's do we have architectural review committees, do we have design approval boards? It's all the things we do, the mechanisms and mechanics of our work. Execution, though, is the thing that matters. Execution is getting the right thing done at the right time and the right way without collateral damage. Everything we do on the structure side is to achieve an intended outcome. And there's a trade-off for structure. It provides different things for different teams. If you're a very new team who's never worked together, if you're in junior engineers, if you haven't been doing this for a while, then structure provides scaffolding that you can build on, right? It's support. It gives you something to, you can't go too far off the rails. If you have structure, right, you know you're doing, we're collecting some requirements, we're doing some estimation, I'm working on the tickets for five days, I can't go that wrong in five days. It provides cadence and repeatability and the support that new people need and new teams need to gel. As a team hits its stride, good structure provides a foundation, provides a solid base. It removes things from the list of things you have to think about. But as a team begins to excel, as they accelerate, as they gel, as they've been working together for a long time on a well-known problem, that structure becomes overhead. And so the right amount of structure for a team, regardless of even what that structure is, depends on the context. Example, can you run faster without crutches or with crutches? So yes or no question. Think about it, can you run faster? Well, you know, it depends. Are you wearing a boot? Did you just bring your ankle? Do you have two legs? Are prosthetics an option? You can get some really wicked prosthetics and you go a lot faster than with crutches. Do you even have legs? Maybe your legs are fine, but you don't have arms. And how do you carry the crutches if you don't have arms? Now you're running slower. It depends. It completely depends on your personal context, whether crutches will let you get across this convention all faster or slower. So is the answer always? It depends. Because if it is, that's not very useful. It's not entirely useless. Just knowing that the answer is sometimes it depends is usually it depends. Just knowing that there is that amount of change is useful, but it's not that useful. Like it's kinda obvious. So let's look at something a little more clear. Something that we can all agree on. I hope. What kind of organization do you wanna work in? Given that we're all at RailsConf, I can make some assumptions that you would like to work in an organization that embodies trust and integrity, innovation, passion, fairness. I can assume that perhaps you wouldn't prefer to work in an organization that is characterized by authoritarian control and politics and regimented processes and a general sense of apathy and exploitation. These are things we can generally agree on. It doesn't depend that much. We believe that this list of values are critical to the long-term success of an organization. We believe that they optimize for the best outcomes long-term. Why do we feel if we believe that these are all superior attributes? Why do we feel that they are a struggle sometimes? And these, why do these happen? We all agree this makes us less productive. We're unmotivated. We're annoyed. We're not working our best if we're in an environment with these behaviors in place. So what are the incentives which create these environments and what are the structures and incentives that allow them to persist in good companies? And further, how can we then engineer, we as engineers, how can we engineer our organizations to be resilient to them? And we're pretty sure that the positive ones have an advantage. So why do organizations adopt pact practices in the naked list? Why do you wake up when we're like, yeah, I'm gonna be an authoritarian jerk today at work. It's gonna be great. It's not great. So we wouldn't design that environment. Like we wouldn't intentionally do this to ourselves and to each other. So how do we create our organizations to be resilient to them? And to think about how we'd be resilient to them, we have to really understand why they arise. What causes them? What pressures? So that we can engineer in some safety. So let's consider what is a successful engineering organization? Is it an organization where individuals grow and prosper? Is it an organization where beautiful, robust code is written, where real value is created, where individuals are empowered? Or is it an organization where, well, we produce a product that can be sold? Predictably, with predictable output, predictable timelines, predictable costs, no surprises. Which of these is a successful organization? The answer, of course, is both. An unbalanced organization is an unstable organization. If you don't have both sides of that, a corrective crisis is imminent. If you don't have output, the organization will do something. If you don't have any kind of personal health, people will leave. Either way will cause a dramatic corrective crisis for the organization. So what causes those undesirable behaviors we listed before? It's the immediate results that they create. It's the immediate first order outcomes they cause. They're an allergic reaction by organizations to missing the things that the organization requires to function, to missing the output, to missing the predictability. They all work in some context, so they persist. They're all very local optimizations. And because there's no clear single right way to run an organization, because anything which produces some benefit is plausibly good in some context, is defensible. They arise, they occur. All of those negative traits produce some near-term benefit, every one of them. Authoritarian control ensures that something will get done. Something is better than nothing sometimes. Politics let you obscure and deflect. They buy time. They create space. Regimented processes, well, if everything is a machine, then the cogs can be replaced. If people are leaving, then you want an organization where new people can get up to speed really quick, and the best way to do that is to have no thinking involved. Apathy, what is the possible good of an apathetic organization? Well, nobody's arguing or stirring things up. Predictability's great. Nobody's gonna go off on a two-week crusade to go change your front-end framework. They just don't care. Exploitation, well, I mean, if we're a company, an apathetic, horrible, soulless company, more for less, what could be better? What's the downside? Maybe we need to cut costs. The key is that all of these have some near-term benefit, and that's why they occur as a reaction. So to understand the benefit in order to understand the cause. So for the negative things in your organizations, you need to find those root causes to understand what perceived or actual benefit they are creating so that you can work against them. So let's go through and take that knowledge, that learning that this is a hard problem and that bad things happen to good companies because they cause good near-term effects, and let's debug some organizational pathologies. Apply that toolkit. We're gonna define the problem that a behavior causes, find the positive outcomes that it's attempting to achieve, understand the pressure that's causing it to arise, and what actions can we take to prevent it? These aren't foolproof, it's a start, it's a framework, it's toolkit. So let's first think about destructive outsourcing. I'm sure we have some consultants in the audience, this is not consulting, this is wholesale outsourcing in the majority of sense. This is the iron lung of software. You will breathe. Doesn't matter what else is going on, doesn't matter if you're conscious, doesn't matter what's going on, hit. In-house doesn't matter what's happening outside, something will get done. No expertise is required. Its software development is idealized by those who believe it to be a sanitary, requirements-driven, unambiguous process. That's why it's appealing. It's also why it never works quite right. So the problems with rampant destructive outsourcing are that results are approximate. Requirements are not software. They're never the full picture. The only full specification for software is the software. Accountability is reduced to the requirements. You give the requirements, the output meets the requirements, what's the problem? There's a little opportunity for spontaneous discovery and innovation. There's no aha, there's no hey, hey, hey, what if we do this? Costs are externalized. Internal teams who have to receive the work have to do a lot of work to adopt it. So the costs incurred by the outsourcing are borne by the internal teams. These are the problems of it, some of the problems. All of these lists are necessarily incomplete. But it can be a positive. When can outsourcing be a positive? Well, it can be a positive when there's no internal resources. Maybe you don't have any engineers. When there's some specialized knowledge needed and you don't want to hire for that specialized knowledge. That's a fuzzy line between outsourcing and consultancy and it really depends on whether it's a healthy relationship or not. What if there's no long term at all? Like you don't need to optimize for long term effects when there isn't gonna be a long term. Maybe you're just trying to get something launched. It also isolates from organizational problems. Outsourcing works at companies where the company itself is so dysfunctional that an in-house engineering team can't get anything done. Maybe that's because you've got the CEO who wanders in three times before lunch completely changing the product vision. Maybe it's for some other reason. But outsourcing removes the process from the environment. So what are the pressures that create outsourcing? It's insufficient internal resources or maybe no ability to hire long term. It's an actual perceived lack of internal ability to accomplish a specific task. It's the belief that an external team can do better than the team that you have. It's the perceived cost savings due to discounting those full life cycle costs. Externalizing the cost of the outsourcing to your internal teams. And it's the perceived accountability created due to well documented requirements. So what actions can we take to help prevent that? We can address structural deficits in our team composition so that we have everything we need to do, the job we need to do. We can increase internal documentation and processes to provide more structure, to provide that same perception of accountability. Again, these are context dependent solutions. If you have a problem, you're in a otherwise healthy organization where a pressure is arising to outsource, what actions can you take? You can accurately account for the full life cycle cost of outsource projects. Account in your team's internal sprints for how long it took to adopt and integrate the output results. Factor those costs in. It's not again, not a complete list. It's not a silver bullet for outsourcing. But if we don't begin to understand the benefit or we don't begin to understand the pressure, we can't even start to think about how we can prevent it. We just say, oh, it's bad. And then what? Right, oh, it's bad, we shouldn't do it. Doesn't help, there's no argument there. Let's look at another one, the death march. Death march is about doing more, faster. People do work, work takes time. If people spend more time, they'll do more work. I mean, clearly if everybody just worked 80 hours a week, we'd get either twice as much done or just need half as many people. It's win-win. And since crunch time works, since that one late night that maybe I spent last night touching up this talk worked, well what stops us from doing that every day? The problem with death marches is that there's a productivity problem that we as software engineers are not typists. Our job is not to transcribe requirements into software. The majority of our effort every day is the thinking, not the typing. Additionally, there's a human problem. It's simply unsustainable long term. It's miserable. We have options. This is one of the best industries that we have ever created as a species, right? It's a great thing to do every day, software usually. So if you're completely miserable, we have options to quit. What's the positive though, like why do death marches happen? Well you can to a degree brute force software creation for some classes of problems, for some things which are relatively straightforward or repetitions of earlier work, it is more useful to just work more hours sometimes. There's no creativity required. And while it's unsustainable in the long run, what if there isn't a long run? So what software industry then has very firm release dates and little to no need for long term support? What causes these pressures that would lead to death marches? Video games, right? They have release dates. They have targeted times of the year when they wanna release. You might get a few patches afterwards, but there's rarely a plan for years and years of development as we do with our normal processes, our normal business software. And so where is this problem of death marches completely endemic? Video games. Because the pressures exist, they cause the outcome. The pressures that crunch time works, right? In very small doses, it absolutely works. You have late nights, you work late nights, you get more done. But once you start, you can't stop, right? Because we're not typists, because we're thinking engineers, not just transcribing engineers, that mental deficit of the long hours causes us more work next week than if we didn't do it. So once you get into this cycle, it self-perpetuates. The only way to keep getting the same amount done is to work an increasing number of hours. Also politically, it's an absolute win, always. Right? If everybody is obviously working as hard as they can, you can't critique them very much. Right? If my team is in the office seven days a week working 16 hour days, you can't tell me I'm not gonna get it done fast enough because we're working as hard as we can. It's nonsense, but it's absolutely defensible. So how do we prevent this? We have to have a long-term vision. We all know instinctively that run as fast as you can isn't a winning strategy for a marathon. It's a good strategy for 100 meter race, but not a marathon. And we all, as individuals and team members, we can crunch when crunch is needed. Right? Because if we lack any hustle whatsoever, it creates a doubt within the organization that we are actively thinking and calibrating about the near-term and long-term trade-offs. Like if there's no circumstance in which we ever work more than exactly five o'clock, clock out, go home, right? There's no expectation that we are balancing and controlling our work. Then we are acting like typists. So by crunching when crunching is needed, we establish that organizational trust that we are working to maximize output. Stack ranking. We're starting to see a bit of a pattern here, right? What could be more obvious than getting rid of the worst people? If we just remove the lowest performing person on the team, that'll increase the average, right? It's simple math. It's so trivial it can't possibly be wrong, right? And if everyone is always thinking about performance, well, then performance must improve. Completely optimizes, of course, for first-order effects. The problem is that it misaligns incentives to focus on individual outcomes rather than team outcomes. Everyone knows exactly what they have to do, what they need to focus on. The only useful thing to do are visible things to do. And when somebody has to go, you spend a lot of effort making sure it's not you. You don't spend a lot of effort focusing on the outcomes, on the team outcomes. You make sure you end up at the top of the stack. And this is particularly problematic in roles with gameable metrics. Most of the hard metrics we could put on software development are inherently gameable. If you tell me I get paid by the line of code, I'm gonna make a million dollars next year. Like, I can write code generators. So what are the positives of stack ranking? We have to find a positive to understand why organizations think it's a good idea. The positive is that outcomes are transparent. Everybody knows what's gonna happen at the end of the year. There isn't a mystery. And it's arguably better than nothing. If you have an organization that is just nothing, it's nothing but nepotism and just nothing. You've got no trust, you've got no belief that anyone's doing anything, well, it's something. And if it takes your organization from 5% efficiency to 10% efficiency, well, that's twice as good. So there has to be a positive to understand why these things occur. Now, what's the pressure that causes an organization to go, hey, stack ranking, sounds like a great idea? Well, there's a desire for rigor, for efficiency, for accountability, right? It feels scientific. It feels like it's, oh, you got a bell curve. Everyone loves bell curves. Of course, everything's a bell curve and we just need to cut off the bottom of the bell curve and promote the top. It fights off a fear of being seen as soft or ineffective. If you adopt harsh policies, people can't say that you're just being too nice. It's just like the death march thing. It's a political win because you can say, oh, you can't criticize me for not getting rid of the chaff on this team. We fire 10% of the team every year. Right, it's politically defensible. Additionally, if there's a lack of belief that managers are managing, then you will impose structure to force them to do something. This gets back to that structure versus effect trade-off. If you have great managers, they don't need structure of stack ranking. If you have useless managers who don't do anything ever, if you have a manager that never does a one-on-one, that never talks to their people, that is just a manager in org chart space only, stack ranking might be better because at least once a year, think about who in the team is doing better than who else. Like it's not a great argument, but there's something to it. There's a pressure there. So what can we do to prevent these pressures? We do some sort of performance management at all levels. You have to provide feedback. If you're providing feedback, then you don't have that pressure. You don't have as much of that fear that people are just skating by. You have to align the organization on team or project-level outcomes so that individual glory isn't the primary thing people strive for. And you fundamentally need to remember that there is no such thing as an abstract human. We are all real humans, and we all really have as much going on in our heads as everyone else. So waterfall, moving on. We're getting a pattern here, maybe a little cadence. Waterfall is, if we can do all the research, we can know all the requirements. If we know all the requirements, well, then we know exactly what to build. And if we know exactly what to build, well, we'll just build exactly that. And once we've exactly built the thing to the exact requirements, then all we need to do is verify it. Very straightforward. And since, obviously, downstream costs are higher than upstream costs, a missing requirement is much more expensive to discover once I've got something in validation that before I spent thousands of hours writing it, well, we should just solve as many problems upstream as possible. And indeed, we should try to solve 100% of problems upstream as possible because it's clearly the most effective thing. The insidious thing about waterfalls that happens a little bit at a time to agile companies. When your sprints start growing epics, when your epics span quarters, when everything is released behind feature flags, the epics are done, when you start not thinking about what value we're delivering next week and you start thinking about, well, we gotta get to this end of this quarter, we've gotta release this. When that becomes the only thinking you're doing, your agile has turned into a waterfall. So the problem, and again, you can see we're developing a framework here. The problem is that waterfall magnifies the cost of mistakes. Any mistake made in the front is much bigger by the time you get to the end, and mistakes are inherently more discoverable further downstream. It focuses on the completeness of every step, not the impact. Requirements becomes a game of you gotta catch them all rather than, well, what are the important ones? And it's unresponsive to change in context. So what's the positive? What is the good of waterfall? Well, sometimes there is no going back. Sometimes you have one chance to collect requirements or one chance to launch or one chance to do any particular phase of a project. There's some value there. What's the pressure? What is the pressure that causes an otherwise good organization to start adopting waterfall? Well, it's an intolerance for failure. If every time you have a failure, the outcome becomes, oh, we needed to get the requirements more correct. If every time you have a failure, the outcome becomes, well, QA clearly screwed up. If every time you have a failure, it's software engineers, I mean, you can't trust them, we just need to nail this process down. You have that intolerance for failure, you have an inherent pressure to adopt waterfall. It happens also when you have a separation of concerns between functional roles. If my job is only to generate requirements, if I'm never involved in any other step of the process, then I'm just gonna generate requirements all day. I'm gonna generate these requirements and hand them over to you and you're gonna go work on implementing them and, well, what else am I gonna do? Am I gonna play ping pong all day? No, I'm gonna generate lots of requirements. If you have a separation of roles, if your teams don't operate as teams, there's an inherent pressure for waterfall to arise. Additionally, it's a belief that software engineering is about implementation, not discovery. That it's just about getting the requirements written down so that we can go type them out, right? It is a fundamental belief that there isn't as much value in doing something that will then teach us something, that the feedback loops aren't important. So how do we prevent this? What actions can we take to help prevent this? We can manage the impact of failure rather than trying to fully prevent it. We as engineers can engineer into our workflow, feature flags and manage impacts, blast radius of release things. We can think about how to fail safely. If we can make failure safe, there is less pressure to go waterfall. We can focus on accelerating time to value, not time to completeness, right? Big bang releases cause you to try and get everything right before the release. You can't integrate over the value curve. And you can limit work in progress. If you limit work in progress, then I can't just sit over here writing requirements or I can't just sit over here testing outputs. If I'm out of things in my column, I can't just add more things to my column. I need to help you empty your columns. These are actions we can take to help prevent it. So let's move on to another one here, which is excessive client commitments. Cause not all problems are engineering problems. We've got our full little matrix filled out here. It's a tool kit. This is our tool, find the problem. Well, the problem with excessive client commitments is that we are unable to execute long-term strategies. The problem with client commitments is that it's reduced to drive and output and ownership by our engineers. There's reduced inherent incentives. The positive that we get from client commitments? Well, they directly generate revenue. Somebody said, I will pay you X if you promise to do Y, they paid you X. It reduces the uncertainty in the future work done. If you've got a feature you're working on, you don't necessarily know how much value it's gonna create for the organization. If somebody's already agreed to pay you for it, you definitely know that uncertainty is removed. So what is the pressure? The pressure that generates excessive client commitments is revenue uncertainty, because it locks down that revenue. It's hard revenue targets that you have to hit and you'll do anything to hit this corner, and it's a lack of belief in long-term product vision. It's a lack of belief that next year matters more than this year, because maybe you don't know what you're doing next year because you don't believe in the vision you're creating. Apple doesn't do client commitments so much. So what can we do to prevent client commitments? Not quite as much. Not all problems are engineering problems. We need our organizations to maybe discount committed revenue, discount revenue created by clients who signed on for commitments. How much did it cost us to actually meet that commitment? Discount the revenue generated by that amount. Or maybe we as an organization need to think about re-forecasting revenue based on closes that didn't generate commits. Holy shit, these are really hard things. We can't do that. We just can't do that. As engineers, that's not really in our wheelhouse. But we can talk about it. We can think about it. We can know as an organization and our organization can know that that has that impact. So we can at least start having the conversation. If we don't understand the causes, right, so these things are not easy and all of the solutions that we came up before are not complete. None of those lists were anywhere close to exhaustive. The point isn't to have perfect answers to these questions. The point is to have a toolkit we can apply to start thinking about them so that we can start having the conversations. So how do we bring this all together? What do all of these problems have in common? What are the organizational attributes? What do all of these specific pathologies? What is the common thread throughout them all? Well, they aren't the very worst possible thing that could happen. They're not 100% bad. Few things are 100% bad. And they're all reactions to circumstances. They're all reactions to some situation which arises, to some expectations, to some pressure. And they all have an expected near term benefit. There's only one silver bullet for organizational health and that's trust and that one's really hard. What is trust in an organization? It's the one thing, it's the less tactical thing we can do. It's the big problem we could try to solve, right? Trust is the expectation that observation doesn't influence behavior. That if there's a plate of cookies and I'm watching, you'll eat a cookie, and if I'm not watching, you'll still eat one cookie and not two, right? Trust is the fact that observation doesn't change outcome. And for teams, it's the ability to do the right thing without asking for permission. It's operational latitude. It's that I trust my teams to do the right thing. So in a generally healthy organization, what is the action that we can take as individuals and as teams to generate trust? What is the thing we can do which creates trust? Well, it's successful execution, right? The more we get done, quite literally, the more we can get done because it builds that trust. So what is engineering engineering? Or what do we do? What's the takeaway here? It's that we wanna try and create stable solutions which balance investment and output. That we need to keep in mind the needs of the individuals, of ourselves, of each other and the requirements of the organization. We need to remember that what's right is incredibly highly context-dependent. There is no what's right except for today with these people in this team working on this problem in this industry. And you need to figure out what that is again tomorrow. We need to remember that all bad things have reasonable reasons. That if you don't understand the reasonable reasons behind them, you can't work against them. You can't help fix them. You can't just be like, oh, bad things happened. We shouldn't do them. They don't happen in a vacuum. There are pressures. We need to expect hard problems. We need to bring our full brains to this problem of organizational structure. And we need to, we can individually achieve near-term outcomes that in a healthy organization provide us the credit to successfully achieve long-term outcomes. So how do we help well-intentioned organizations become healthy organizations? And well-intentioned is a key here. We do all the things we talked about. So when we try to do it pro-core, we're a well-intentioned organization. We're not always a healthy organization. We have some of the problems that I talked about to a degree, but we're trying to fix them. And that's what you can bring to your healthy organization. Try to fix the problems. That's what I've got. We're engineers. We can engineer our engineering organizations.