Transcript
Kasia Trapszo: When I was a junior engineer, I got assigned one of those safe tasks that are supposed to teach you responsibility without giving you the opportunity to break anything that's too important. I worked at a startup at the time, our team used this ancient bug tracker. May have been Bugzilla. The point being that tool was not particularly configurable. You either got notifications or you did not get notifications. If you configure for notifications, you got notifications. You touch a bug, you get an email. Somebody touches a bug, they get an email. Somebody else touches a bug, you get 10 emails. Get the idea. The team decided, this is not tenable. We need a concise daily report that shows you the life of our bugs for the day. Perfect task for a junior engineer. I built it. Wrote the cron job because that's what you would have used back then for scheduling. Tested it locally. Everything looked great. Then I pushed it to production. Except, I had a typo. You knew that was coming. There's something wrong with the story. I had a typo in my cron expression. Instead of sending a concise daily report, it sent a concise report every minute to the entire engineering organization, including our CTO. I learned a couple lessons that day. One, test your cron expression. I mean, look at that thing. Two, humility comes free with automation. Also remember how the team handled it. Nobody yelled. Nobody made me feel stupid. My direct manager was messaging me frantically through this whole thing. Like, just make it stop. Whatever. Make it stop. We all just laughed. We fixed it. We moved on. That small moment stuck with me, because I realized how safe I felt learning from that mistake. It was one of the first times that I understood that great teams are not defined just by their technical skills. They're defined by how they communicate and how they help each other get better. That idea has followed me through most of my career.
Background
I'm Kasia Trapszo. I lead engineering in a commerce space at Netflix. I've been doing a version of that for the last 10 years or so. Like a lot of you, I spend most of my career thinking about systems, how to make them more reliable, more scalable. Maybe a little bit less surprising at 2:00 in the morning, especially if you're on call. Over time, I did realize that the hardest problems we face as engineers, they're not about systems. They're about people.
Communication, assumptions, alignment, and how we scale our own judgment, so that good decisions keep happening when we're no longer the ones writing the code. We'll talk about that side of engineering. What it really means to grow your impact when your leverage is not measured in lines of code, but in clarity, in trust, and in influence. I will walk you through a few stories, some successes, some less, about how clarity builds trust. How alignment creates influence. How scaling yourself turns all of that into something lasting. Hopefully by the end of this session, you'll leave with a few ideas that you can implement, because none of this is theoretical. It's the stuff that makes a difference between a great engineer and someone who quietly changes how an entire organization works.
Clarity Builds Trust
We'll start with a story about clarity. You know it's clarity because of the sparkles. Not that long ago, I was helping our payments team on a project to support a new payment method in Brazil. This payment method is not new to the people of Brazil. It's everywhere. However, until now, it was only used for real-time payments. Netflix being the very first big merchant to decide to use it for subscription payments. That's when things got a little bit more interesting. Because subscription billing, it's not the same thing as real-time payments. You've got retries, grace periods, renewals. All that invisible complexity of keeping a relationship alive, not just one simple neat little transaction. Naturally, the project looked pretty complicated. Documentation was long. The requirements were strict. The team was pretty convinced we'd need to rework parts of our invoicing system. Nobody wants to touch invoicing, trust me. We started mapping out new states, retry schedules, conditional logic. It's the kind of project that starts out fairly simple, but before you're done with it, it ends up touching most of the codebase and three adjacent services. As I was looking through the requirements, though, something started to feel familiar. The rules, they were written differently, but the pattern was one that I have seen before. It reminded me of how we handle direct debit payments in Europe. We've been doing direct debit in Europe for more than a decade, so we're pretty familiar with it. This wasn't about being smart or experienced. This was about having seen enough payment methods that I could recognize the underlying patterns, even though we were using different terminology. This is what senior engineering often looks like. It's not knowing all the answers, but having enough scar tissue to recognize which problems you have solved in the past. Sure enough, different names, same logic, a limited retry window, delayed settlement, some specific error conditions. Once you stripped away the terminology, it really was the same behavior. When I walked the team through that comparison, you could feel a collective sigh of relief. We don't need a new invoicing flow. We don't need new states. It's just a few configuration changes. That realization, it saved weeks of engineering effort, and it kept one of our most critical systems from getting more complex than it had to be. More than that, it built trust. That's because the team saw that I wasn't just saying no to more complicated work. I was saying there's a simpler way. This is what clarity really does. It earns influence, not by sounding confident, but by helping other people see clearly. When people realize that your clarity makes their job easier, they start coming to you sooner to think things through with you. This is how senior engineers lead. It's not through authority, but through reasoning that earns trust.
Alignment Creates Influence
Of course, even when your own thinking is clear, that clarity, it doesn't always survive the handoff between multiple teams. I learned that the hard way on another project. It looked perfectly aligned right up until two systems started talking to each other. A while back, I was working on a migration between two systems. One was like an older system that was being migrated to a new version, and the other was a production system that depended on that older system. Both teams had done all the right things. Reviewed the APIs, agreed on a schema, walked through the migration plan. Everything looked solid. Tests were green. The migration plan, perfect. Documentation, pristine. You could frame it. Then we started doing end-to-end testing. You've all been there. You start end-to-end testing, you start seeing problems. We started seeing mismatches. Transactions that should have lined up didn't. Nothing crashed, but the data just wasn't matching. We dug in, we found the culprit. There was a key identifier, something that both systems relied on, and it was formatted just a little bit differently. It wasn't a typo, and it wasn't a missing field. Both teams had implemented it exactly as they thought it was written. They just interpreted the same spec in two very different ways. Same schema, same field name, same documentation, just two very reasonable and very different assumptions. It was a big bug, and I feel like we should have been able to catch it sooner. This wasn't about bad code, and it wasn't about bad process. It was two teams doing solid engineering work, each with total clarity inside their own context. That was the problem. We had clarity. We just didn't have the same clarity. I've seen that pattern a lot since then, across teams, across projects, across systems. Everyone's technically right, but the systems still disagree with each other. How many of you have seen that happen? Everyone's technically right, but the systems still disagree. It's the worst kind of correct. It's your classic distributed systems problem, too many local truths, not enough consistency.
I started paying closer attention to where understanding breaks down. It's rarely in the code. It's usually in the conversations that don't happen, because we all assume that we already agree. That's where alignment really lives. It's not in the documentation. It's in the shared understanding that lives underneath it. Keeping that shared understanding alive, that takes real work. That's not the kind of work that you will see on any roadmap. That project reminded me that it's not enough for each team to be clear on their own. What matters is that those views still line up when they meet. Clarity helps people do good work. Alignment helps that work fit together. Getting that right, especially when it comes to multiple teams, it's where the impact really starts to scale. A while ago, we were explaining use cases for one of our machine learning models. It's a model that routes our payment transactions. It's a solid model. It's been in production for quite some time. Naturally, the project team wanted to expand it to new use cases. From their perspective, natural next step, the model works well. Why shouldn't we be using more? From the engineering side, though, things were a little bit different. Over time, the integration had grown messy. You know how systems just decay over time, like all on their own? Multiple conditionals, old configuration paths, historical quirks that no engineer wanted to get near. Adding more on top of that, to the engineering team, that didn't feel like progress. It felt like we're adding tech debt, and really, we're just tempting fate. The conversation started looping. The project team wanted to move fast. Of course, engineering wanted to stabilize first. Product, well, you know about product, they just want results. Everyone had valid points, of course, and everyone was getting frustrated. What had started as a technical discussion was turning into a debate about priorities. A few rounds of that, and it hit me that we had quietly drifted into an us versus them dynamic, engineering versus the business, caution versus progress. You've all been in that meeting. Everyone's right, but somehow nothing is moving forward. It's usually a pretty good sign that we're not solving the right problem. I tried something different. Instead of asking, should we add these new use cases, I asked, what would it take for everyone to feel confident with this model six months from now? That question changed the tone instantly. It turned a conversation from us versus them into us versus the problem. Suddenly, we were no longer defending our positions, we were designing together. Once we started talking that way, we realized that we all wanted the same thing. A simpler model that was easier to evolve, had clearer boundaries, and maybe fewer surprises down the line. Once that was visible, alignment, it got a lot easier. We agreed to pause the expansion while cleaning up the integration layer. The team defined cleaner input boundaries, and product, they saw that this wasn't just a delay. We were investing in future resilience. This is what alignment really is. It isn't about forcing agreement. It's about helping people see that they're solving the same problem from two different angles. In the end, the model got expanded and the tech debt was cleaned up, probably not completely because it never is. More importantly, the collaboration between the teams was better. People stopped arguing about ownership and started focusing on what it was that the system needed next. Alignment is not about being persuasive, it's about being connective. Once it becomes us versus the problem, things move faster and feel lighter. That experience taught me how to align teams.
There's another kind of alignment that's just as important, and it's actually a lot harder to master. That's the alignment you have to build inside your head, because sometimes the hardest person to convince that you belong in the room is yourself. When I first joined Netflix, I came in as a senior engineer from a startup. At that startup, I was the first engineer. I built that engineering team from the ground up. I knew the codebase like the back of my hand. Going back to Netflix, I was going back to being an individual contributor. I was genuinely excited about doing hands-on work again. It was great. This is what I wanted to do. Then I opened the codebase. That is not a bowl of ramen, that's spaghetti code. At first, I thought, this must be brilliant. It's just that I don't get it. I dug in. I spent days trying to reverse engineer the complexity. I was really convinced that underneath it all, there's some super elegant, beautiful design that I was just not qualified to see. Except the deeper I went, the less sense it made. There was one day when I was sitting at lunch with one of the other engineers on the team, and he was like, nobody actually gets that part of the code. It's a black box. Just like that, the fog lifted. It wasn't me. It really was just over-engineered. That moment changed how I think about impostor syndrome. It's really easy to assume that feeling means that you don't belong. Sometimes, it's a sign that the thing you're looking at really is too complicated. Complexity can masquerade as sophistication. More often than not, it's really just lack of clarity with a good vocabulary, like my spaghetti coat. Once I realized that, I stopped trying to prove that I understood everything. I started asking simpler questions. What problem is this abstraction solving? If it's not solving a problem, do we need it? If it's not needed, doing my favorite thing in code ever, remove it. What would this look like if it was just a very simple design? Those questions, they didn't just make the system better. They made me feel grounded again. I learned something that stuck with me, clarity isn't just something you create for others. It's something you have to keep rebuilding inside of yourself every time you enter a new space. Because impostor syndrome, bad news, it never actually goes away. It just changes shape. The antidote is almost always the same. Curiosity, humility, and the willingness to be that one person in the room that asks the question that you know everybody else is also wondering about.
Scaling Yourself Equals Lasting Impact
That brings me to the next lesson. What happens once you've found that clarity for yourself and you start helping others find it, too? That's where scaling yourself really begins. Because at some point, every senior engineer hits a wall. It's not because the work gets harder. It's because there's just so much more of it. You have more design reviews, more meetings, drowning in memos, more Slack conversations than any human being should reasonably survive. One day, you realize that your impact relies on a meeting that people remember and you don't even remember being in. Who's had that meeting last week? I've had two. That's where I found myself not too long ago. We had thoughtful discussions, good decisions, great conversations, and then a few weeks later, we'd have thoughtful discussions, good decisions, great conversations on that same topic. It's because nobody's written it down. It wasn't anybody's fault. It just wasn't a simple way to capture the why behind the technical choices, that reasoning that doesn't really fit neatly into a Jira ticket or a design doc. I tried an experiment. I started using GenAI to summarize meeting transcripts into short architectural decision records. This is my one token AI-related slide. Just a few paragraphs on what was decided, why, what tradeoffs did we make. Dropped that into a shared repo, no approvals, no ceremony, just a very simple record. I wasn't sure that anybody would read it. Within a few weeks, something interesting happened. Other engineers started adding their own notes, linking diagrams, clarifying tradeoffs, notes from meetings that I wasn't even a part of. The system started to maintain itself. I joined a meeting and somebody would say, we already cut that conversation, here's a link. That's when I realized the process, it had scaled beyond me. This is what scaling yourself really looks like. It's not about doing more. There's only so many hours in a day. It's about creating enough clarity that other people can keep making good decisions without you. It started because I was tired of repeating myself, but sometimes laziness is just efficiency waiting to be formalized. Over time, that habit changed how the team worked. Instead of decisions living in people's heads, they started living in the repository. If they join a team, new engineers always wonder why is this thing working the way it is. Now they can find out pretty easily. Growth at this level, it's not about speed. It's about reproducibility. It's about making your reasoning visible so others can reuse it, challenge it, and build on it. Yes, impostor syndrome will still show up sometimes. Because when you're no longer the one writing the code yourself, it's easy to wonder if you're still adding enough value. I've learned to see that differently as well. That doubt, it just usually means you are stretching into a new kind of contribution. One that multiplies other people's work instead of your own. That's what scaling yourself really means. Creating systems of clarity that keep working even when you're no longer there to explain them again.
There's one more part of scaling yourself that isn't necessarily obvious. At some point, your job stops being, make great technical decision, and starts being, help other people make good technical decisions. About a year ago, one of our senior engineers, let's call her Mary, came to me frustrated. She's been working on a really gnarly data migration project. The technical work was solid. Her approach was golden. The project kept stalling because she couldn't get alignment across different teams because they all had opinions about how things should work. She told me, I feel like I'm spending more time in meetings than doing actual engineering, is this what being a senior engineer is like? I remember asking myself that same question not that long ago. Sometimes that's what it looks like. I asked her, walk me through that meeting, the one that you felt was like a total waste of time. She described your typical design review meeting where the discussion just goes in circles. Everyone's agreeing on the goal, but everyone is just debating implementation details that don't even make any sense at this point in the project. I asked her, did you have an agenda? Sort of. She had the design document. Did everyone in that meeting know what decisions had to be made by the end of the meeting? She hadn't. This isn't a criticism. I've made that mistake a dozen times. You assume that you get a bunch of smart people in a room, you give them great context, and alignment will just magically emerge. This is not how it works. Alignment requires structure. We talked through how to design a meeting for decision making. You start by naming the decision explicitly. People need to know what they're supposed to be deciding. Identify who has input and who is the decision maker or the informed captain in Netflix parlance. Time box the conversation. This one is the most important because engineers love to chat. I'm one of them. Then you end by writing down what was decided and who is doing what. If you're coming out of a meeting with a list of tasks and there's no names assigned to those tasks, guess what? That's not getting done. It's basic stuff, but it's rarely taught. Do you all remember having that class in college, this class on structuring meetings? I sure didn't. The next week, she tried it. That meeting took 30 minutes instead of 60, and she walked away with clear next steps. Probably still took 60 minutes, but there were next steps. A while later, I saw her running a design review for somebody else's project. She was coaching them on how to structure the meeting. Scaling yourself is not just about documentation. It's about recognizing what you've learned through trial and error, and compressing it into patterns that other people can use immediately. When you help one engineer skip past the mistake that you've made three years ago, that's leverage. When that engineer turns around and teaches it to somebody else, that's when it becomes exponential. The work you do stops being about systems you touch directly and starts being about systems you touch through other people. This is not less technical. It's just a different kind of technical problem. How do you transfer judgment? How do you scale pattern recognition? How do you make tacit knowledge, explicit? These are engineering problems. They just don't show up in GitHub.
Summary (Clarity - Trust - Motion - Scale)
When I look back at these stories, simplifying complexity, aligning teams, scaling clarity, and helping others grow, they all point to the same thing. The real work of a senior engineer, it's not about writing more code, it's building clarity that outlives you. Clarity earns trust, alignment turns that trust into forward motion. Scaling yourself, this is what makes that motion sustainable. Your influence does not show up in just how much you personally do, but in how others think, decide, and communicate after you have been part of their process. That's impact that lasts. Early in your career, you start out by wanting to prove what you can do, how strong your technical skills are. Then you move on to shaping how things are done. You build systems, architectures. Eventually you realize that your biggest contribution is in shaping how others think. There's no commit history. Git commit. There's no commit history for that kind of work. It's that part that keeps everything moving forward long after the code has changed. If you take one thing from this talk, let it be it. Your code might scale a system, but your experience and clarity scales organizations. This is the kind of impact that lasts. I have a challenge for you. Pick one decision that you made this week that somebody else might need to know about in about six months. Write three sentences. Why? What else did you consider? What tradeoffs did you make? Put it somewhere where others can find it. This is it. That's all you need to do to start. It's not a great strategy, but just one small little act of clarity. Go scale people, not just systems, because one of those actually listens.
Questions and Answers
Kaye Mason: I'm in a lot of meetings where people are just talking about alignment and they go on forever, and then we need a second or a third meeting. When you're talking about listing the decision that needs to be made, do you have any guidance on framing that? Does it have to be a yes, no decision, or can it be, we need to decide the architecture of the system?
Kasia Trapszo: It could be in any of those things, but usually when you go into one of those design discussions, you have something in mind that you want to decide on. It could very well be which database we're using for the systems, or do we go forward with this migration, yes or no? The key is to ensure that we know what decisions we're making, so we don't just go around in circles talking about implementation details, because that's what engineers really love to do.
Participant 1: I think you talked about scaling yourself. Going back to our keynote, the incentivization model. A lot of time what happens, and this is probably just human psychology, is when you're trying to scale yourself, you're trying to pass the knowledge, you're trying to teach others your best practices. Half of the times the person who's doing that is not rightly incentivized. As you said, it's not your Git commit. How do you model that scaling system so that you're incentivized correctly? This is probably just a leadership question. Sometimes what happens is, you're also afraid if you give your best practices and knowledge to some others, it also like threatens you in the other way, your existential crisis. From that angle, again, I just go back to the original keynote thing, like how do you incentivize people to do this more often?
Kasia Trapszo: It does go back to leadership, as you said. If the leadership doesn't believe that this model of engineering, IC leadership works, then you have to prove it to them. The way to prove that is to find a way to measure it. One way might be through, is your team more efficient at delivering code with somebody who's helping them scale and teaching them how to do things in the right way? It's just basically convincing leadership of that. If the leadership is not buying in that this model works, then either do it quietly because you want to do it, or you find another team.
Participant 2: Over the last couple of days, we've heard a little bit about psychological safety. Can you go into how often that should be approached and how to have that conversation the best way?
Kasia Trapszo: I think psychological safety is something that every team should just have as part of its culture. It's particularly visible when something goes wrong. Like my story of flooding the entire engineer organization with emails, it's really easy to get angry at people when that happens, it's frustrating. That's not how people learn, that doesn't help anybody. When it comes to incident, when it comes to things going wrong, it's a lot better to allow people to learn from that without blaming, without finger pointing, using blameless retros, because everybody can learn, versus having one person be miserable.
Participant 3: How do you handle where your influence is just not enough, where you seem like you're hitting a wall with the folks that you're working with and they just don't listen and aren't taking in the influence?
Kasia Trapszo: I think that would be a sign of lack of trust. That means they don't trust that you're either giving them good advice or that you have the skills to give them advice. I would start by building trust, and that can be in many different ways. I think the way I build trust with the teams that I work with is just through showing my technical skills. It's not because I'm such a superstar engineer, it's because I was willing to pick up tasks that nobody else wanted to do. I would go in and refactor code nobody wanted to touch. I would go and fix bugs that otherwise would get unfixed. People saw that I was doing that and leading by example, and started trusting that when I give them advice, it's good advice because the whole team move forward faster.
Participant 4: In the past few years, we have adopted architecture decision records and it immensely helped to shape the knowledge, but in hindsight, it also resulted in cognitive overload. There are too many decisions floating around, too many documents floating around. How do you solve a problem where an engineer is overloaded with too many things going around, especially when the domain is too big?
Kasia Trapszo: I totally get it because I used to be in the same boat where I'm like, architecture decision records, great idea but if nobody is reading them, then what's the point. There's too many, people are flooded with information. I'm going to go back on the AI thing again, because I feel like that's where things actually are getting better now with that stuff because you can use GenAI to not just create those records but also keep them maintained and make sure that they make sense, that they're consistent within each other. If you're creating a new architectural record, you can always ask your favorite GenAI tool to go and check it against all the other records that we have in there. Does it make sense? Does anything else need to be updated? Are we in alignment with each other? Are we creating nonsense? I feel like we're on the verge of really changing how we think about documentation, thanks to GenAI.
Participant 5: You mentioned the impostor syndrome which I think is very common among software engineers. How can you tell you're suffering from impostor syndrome and not the Dunning-Kruger effect, which would be fatal because then you'd be overestimating your capabilities and therefore limiting your coworkers, which should be not what you should be doing.
Kasia Trapszo: Impostor syndrome, it really doesn't go away. I wasn't lying about that. You might be giving a talk at a conference and thinking, am I the right person to give this talk? Are these people even listening to me? I don't have an answer.
Participant 6: How do you build trust in yourself to start delegating things as an IC?
Kasia Trapszo: How do you trust yourself that you're doing the right things? Feedback from others. Seeing how others react to your work, to your documentation, to what you're telling them. If teams are coming to you with problems, that's a sign. That's a sign that you're doing something right. If your coworkers trust you, if they're willing to review a pull request quickly, I feel like that's a great sign because usually those things just linger. It's just taking that feedback from others, I think.
Participant 7: Do you have any tips on, as a technical lead, teaching the team to fish, like learn and adopt patterns from the leads? I feel like sometimes it's a little hard to imprint that in a way on some of the more junior engineers.
Kasia Trapszo: It's very hard. It's hard to tell people how to do the right things. I'd like to say that leading by example is usually the best way, because if you're not practicing what you're saying, people are not going to listen. I will say that as I grow more senior in my career, I realize that the best way to influence people is by the willingness to do the things nobody else wants to do. Something we were talking about earlier in the conversation, no longer relevant today with GenAI, but being that person who volunteers to take meeting notes. That usually gets given to a junior engineer, but if you join it, then you're building trust with your team. They're seeing that you're willing to do it, they're more willing to do it.
Participant 8: We've talked a lot about quietly being in IC and gaining influence in the organization through good deeds and having a solid engineering skill set. We talked about not convincing people or persuading people, but finding alignment. Do you have any insight on how to compete with someone maybe from the product org or something who is extremely loud and persuasive?
Kasia Trapszo: Even the loudest person in a room, they all come with their own angle. Everybody has a story. There's a reason why they want to do things they want to do. The first key, I think, is to find what is that reason? Like why are they being loud about that particular problem or trying to do things in a particular way, and see if that helps you solve it with them. Turn that into an opportunity to create a better working relationship together so that you build that trust. I think key is always empathy, always try to think of why is that person saying or doing or asking for whatever.
Kaye Mason: You really emphasize the importance of being able to make mistakes and learn from those mistakes. How do you build a culture that allows people to do that, as an engineering leader, especially at someone like your level where by the time something reaches your desk, it probably has billions of dollars of impact and people are freaking out? How do you commit and make sure that people can have the space to learn from their mistakes?
Kasia Trapszo: That kind of culture has to come from leadership. It has to be top-down, just pure leadership message that mistakes is something we learn from. Incidents are an opportunity to learn. If something's already cost us a billion dollars, we already spent that money, might as well learn from it. I feel like ICs have way less leverage when it comes to that culture change, so it really has to come from leadership.
Kaye Mason: On the question of alignment, you talked a lot about solving problems together, and that works well across. What do you do once you've aligned across and up is not aligned?
Kasia Trapszo: When the leadership is not aligned, but then the engineers are? First of all, you need to make sure that engineers are aligned first. Yes, if engineers are aligned and the leadership is not aligned, it's a very difficult problem. You need to get leadership to align. When I've been in that situation in the past, you go up a level. That's what you have to do.
Participant 9: Let's say if I am a pretty senior individual IC, and then at my peer, there's another engineering manager, we both reported to our senior management team. As an IC, how can I prove that I'm at least valuable to the company, same as the other engineering manager, while the engineering manager has the entire team work for him to deliver projects and contribute, while, as an IC, I only have myself, performance-wise. Prove that value of the existence of my position here.
You're saying, how do you prove your worth as an IC, as one single individual IC, when your peer is an engineering manager with an entire team underneath?
Kasia Trapszo: I would assume that as that single individual IC, you're either doing a different level of work than that team of ICs, or it's not a fair comparison, because then you have one person versus many. If you're doing that different kind of work, which is some of that leadership work that we talked about, where you're bringing clarity, creating alignment, bridging gaps, the engineer organization needs to value that work. If they don't value that work, then you need to figure out a way to measure it, to show to the engineering leadership that that work is additive. It brings something that's valuable, and it makes the team work faster, it makes the product better. Whatever it is, there's got to be a way to prove that to them.
Participant 10: Do you think disagree and commit is a valid approach for getting alignment, or is that typically indicative that there's something wrong with that discussion, there's some stone being unturned?
Kasia Trapszo: Disagree and commit is part of our Netflix culture. It's just an indication that people have two different ideas of how to solve the same problem, typically. All things being equal, we've all been in this situation, where you can have multiple solutions to the same problem, it's just, what are you optimizing for, and what are your tradeoffs? Disagree and commit just basically means you think this is the better solution, but because the other person is the informed captain in our parlance, or the decision maker, for that particular project, you're going to do what is right for the company, for the project, for the organization, versus trying to make sure that your way of doing things wins. It's a completely valid way of looking at things, because we will have different ways of solving the same problems. It's just part of being an engineer.
See more presentations with transcripts
