Software Huddle - Building a High-Ownership Engineering Culture with Matt Watson

Episode Date: August 5, 2025

If you’ve ever felt like engineering teams are stuck in execution mode—heads down, building what they’re told—then today’s episode is for you. We're talking about what it really takes to build high ownership engineering cultures where devs aren't simply just shipping code, but they're helping shape the product. And our guest this week is Matt Watson. He's a long time founder, engineer, and now the CEO of Full Scale, a company that helps startups and scale ups, grow their engineering teams with top talent from the Philippines. Matt's also the author of a book called Product Driven that shows how engineers can build with more clarity, purpose, customer focus and we get into some of the details in that book during this podcast. So in this episode, we get into everything from the downsides of specialization to the importance of empathy, to why code shipped isn't the same as value delivered. We hope you enjoy it.

The problem is in a lot of big companies, that's the way most developers are. They get told what to do, and they don't, these big companies don't really want them to push back or ask any questions. They really spoonfeed their teams, and then they don't get very good results either. If you don't feel safe on a team to challenge your teammates or bring up issues or ask questions, then, of course, you're not going to perform well in that environment because it's kind of, you're in a situation where you're fearful and you're not going to be able to do your best work. but yeah it's like people have to have trust safety they got to know that their work matters you know they got to have ownership in their work like these things are all important no matter what kind of work you do what's one of these like high ownership engineering cultures kind of look like in practice you know i had a engineering team lead you could tell him like this is

our goal this is what we're trying to accomplish and he would figure it all out i didn't really have to tell this guy what to do at all he would figure out what needed to be done he could break down the work. He could help lead his team and make sure it all got done. And you could trust him unequivocally that it was going to work and he could deliver. So if you were advising like a startup founder today, how would you tell them to structure some of their product and engineering at or interactions from day one to try to avoid some of these pitfalls that we've talked about? Hey, everyone. It's Sean. Welcome back to Software Huddle. If you've ever felt like engineering teams are stuck in execution mode. Heads down, building what they're told. Then I think today's

episode is for you. We're talking about what it really takes to build high ownership engineering cultures, where devs aren't simply just shipping code, but they help us shape the product. My guest this week is Matt Watson. He's a longtime founder, engineer, and now the CEO of full scale, a company that helps startups in scaleups grow their engineering teams with top talent from the Philippines. That's also the author of a book called Product Driven that shows how engineers can build with more clarity, purpose, customer focus. We get into some of the details in that book during this podcast. So in this episode, we get into everything from the downsize of specialization, to the importance of empathy to why code shift isn't the same as value delivered. So let's get

into it. Here's my conversation with Matt Watson. Matt, welcome to Software Huddle. Hey, Thanks for having me today. Yeah, absolutely. Glad you could, we could make this happen. So I wanted to dig a little bit into your background to kind of just kick things off here. So, you know, you've worked as an engineer. You've also been a founder, CEO. I guess what motivated that shift and how has that shaped your view of engineering?

Well, I would say I'm really just a guy looking to help other people, just looking for something to do, right? I think my, from the very beginnings of my career, it was just people would come to me and have technology problems and say, Matt, can you help me with this? And my answer was just yes, right? Like, I always loved helping other people and solving problems. And, you know, that led me to start my own business, which I never really thought I would be an entrepreneur. I didn't even know what a startup was. I didn't know any of that, you know, back in like 2003 when I started my business. I was just sat down with Applebee's and told the guy I could help them FTP some files. That was it.

And then I guess, can you tell me, walk me through that journey. So you've been, you started a company, but like, what did you set it to do? And sort of how is that vision of what you wanted to do or how you help people sort of evolve since then? Yeah. Well, the way this actually started, I was selling computers at Sears and a car dealer came in and buy a computer. And of course, I asked everybody the same questions. Like, what kind of computer do you need? What are you going to use it for? And told me, well, I own a car dealership and I have this little database that tracks my inventory and my customers. But the guy who wrote the program also

left me and he's not helping him anymore and I'm terrified because I've got this database. And you know, as the like, 19 year old at Sears, I'm like, well, hey, maybe I can help you with that. And so that's how I got into that industry. And, you know, three or four years later, that same car dealer, ironically, somebody from AutoTrader.com went to that dealership and said, hey, I need to build some way to upload photos to the internet and track these cars. Do you know anybody? And so it was that same car dealer that made the connection. And at that time, I was 22 years old. I had no idea what I was doing. But again, I was just opportunistic. It's like, well, I can help you solve this problem. And maybe we can build a business. You've got,

you know, 10 car dealerships that you could use this for today. Maybe we'll make. a few bucks maybe we can sell this to a few people and that that was that was the beginning of it i didn't know anything different and honestly at at that stage of my life i never worked in a big corporation i dropped out of college like i'm i you know i'm that prototypical kind of entrepreneur i guess and i guess like fast forward to today like how how are you sort of helping people uh into in terms of using your engineering capabilities and what your company does today well so along the way i started a company called full scale um which provides talent from the philippines and you know we have a lot of customers in the u.s and some other global global companies that's what

we do at full scale i have like 300 employees and you know our goal today is just to find the brightest talent we can in the philippines and and train them up and a lot of that is some of that training is based on my background and focus on product and outcomes and stuff and not just on the engineering side of it but yeah that's that's what my company does today. And then I own a couple of SaaS companies as well. In terms of full scale, what are some of the tools and technologies that you guys are using on a everyday basis, too, when you're building these things for customers? It's all over the board. It really depends on what our clients use and do. So it could be

dot net, could be all flavors of JavaScript, could be Ruby on Rails. I mean, we do a little bit of everything. So I guess, you know, given that you spend 20, years sort of in and out of working with various engineering teams and organizations, building your own companies. When it comes to how engineering teams actually operate, what are some of the patterns that you've seen work with teams and what should others be looking to potentially emulate? Well, I think we have to start first with the patterns that don't work. Most big companies get so focused on the technical side of thing and the engineering side of

things, that they lose focus on the product and the customer, right? That's the fundamental problem. And the way we see this manifest at full scale, like I have 250 plus developers that work for me, is the ones that our clients love are the ones that have really strong communication skill and good personality. They show up in meetings. They bring ideas. They ask questions. They challenge assumptions. They care about the work that they do. Like, people love working with those people, right? The ones that always struggle are the ones that they just show up to the meeting. They don't say much. They don't bring a lot of ideas. It's just their answer to everything is yes, right? And they, you know, you really have to poke and prod them to get stuff done. You have to

spoon feed them the work. They, they just, you know, it's a different kind of developer that just doesn't do as well, right? And the problem is in a lot of big companies, that's the way most developers are. They get told what to do and they don't, these big companies don't really want them to push back or ask any questions. They really spoonfeed their teams and then they don't get very good results either. Do you think that in terms of being able to, you know, show up as an engineer in a customer meeting or whatever capacity and be better at sort of the communication side of the job and ask questions and not just be there to kind of be told what to do, do you think that is a personality thing that people have,

or do you think this is a skill that people can learn? I think it's both. I mean, some of us are definitely more introverted, right? Some of us are more introverted. But I think genuinely, we all care about having a purpose. We all care that the work that we do matters. We want to solve problems. We want to solve problems that matter other people, right?

But in a lot of companies, maybe they don't know that. The engineers don't know the impact of the work that they're doing, or they're working on the type of work where maybe that impact is really invisible. Like, it's really difficult to know. Like, for example, maybe I'm using Kafka and I'm making something scale and do all this stuff, but I don't really know who the customer is. I'm not in some product-facing thing. I'm working behind the scenes.

I'm working behind the scenes on really important stuff, but I can't really, I don't, I'm not shipping a UI, and I'm not seeing, the immediate response of the work that I'm doing, right? Like, sometimes engineers are behind the scenes and some back-in stuff where they are a little more lost from the big picture. Some of us do that. Like, I understand that. But as leaders, we have to figure out how to make them understand that.

It's like, well, the work that you're doing did have this impact. It did matter. And this is why that work really matters, right? As leadership, we always have to make sure the team understands why their work matters and the value that it created. Do you think that this is something that's changed over time, or was it always this way? I think over the last 15 to 20 years, when things went more and more to Agile and we got product managers and some of the other things that have been done, I think it caused a lot of this. You know, when I started my career, and I think most people would tell you 20, 25, 30 years ago, software engineers did all of these things.

You would hire a software engineer, tell them what you needed to do. they would understand your business problem, and they would go create it. The challenge is software engineering is slow and it's expensive. So it's like we hired product owners and product managers and QA and DevOps and all these other things to basically make it so the engineers just took the requirements and wrote the work. They were like heads down, go build the thing, go get it done as fast as you can. But the problem is that limited their visibility and the scope of their impact, right? Like everybody else was doing all these other aspects of the work.

to try and protect them. But in sense of protecting them, we made them more blind to the work that they were doing and not understand why they were doing it, not seeing the outcome of it, losing the purpose of it. And the other thing I think that's a fundamental problem is engineers have great ideas.

Engineers understand the code, they understand the product. They should be able to go back to the product team and say, well, this is why this isn't a good idea. We could use Kafka to do this thing, or we could use this to do this thing. And you guys don't even think about that. Like, here are other technical and engineering solutions that we should be thinking about.

But in a lot of companies, the engineers are shut out of that. Like, they don't even have a voice, right? Or the only voice they have is them saying, well, we need to do this technical debt thing or we need to do this. And then they lose sight of how that impacts the customer, right? Like, there's this big disconnect between the two. Right. Yeah. I mean, I would think of that as we've added sort of the scope of software products or projects have gotten so big.

and you have more and more people working on them. There's more and more tools and technology. Ultimately, people have to, your companies are forced to sort of specialize skill sets in order to be able to deliver anything. But I guess the negative consequence of that is people get focused on these kind of like swim lanes of ownership and aren't necessarily looking to the right and the left in terms of, you know, or even questioning, why, you know, why am I doing this assignment and maybe miss the bigger picture?

So, like, how do you start to fix that? Like, is that the manager's position that has maybe more sort of horizontal visibility across these? Is it a PM issue? Like, who should be owning kind of explaining the impact of this work? Or does it come down that individual should just, you know, step up and be questioning those things? Well, part of the challenges in the bigger company you work out, the smaller your role becomes, right? No matter what, you end up having like a smaller slice of what needs to be done versus, is when I was helping that car dealer, I sat down with the business owner, he told me what

needed to be done, and I had to do everything, everything. There was nobody to help me do anything. I had to figure it all out. Like, I had the entire role, 100%. And in a startup, that's usually the way it is too. You may have a team of one, two, three, four people, and they all have to wear a lot of hats. They all have to do a lot of things. And yeah, in a bigger, bigger company, your role gets smaller and smaller and smaller. And I think our challenge is leadership is to understand and recognize that, right? And make sure that the team understand the work they do and how it impacts everything else. Like, we have to work even harder to make sure that we're working on the right things that really matter and that there's visibility to the work, visibility to the customer

and getting that feedback. We have to work so much harder to do those things versus in a very small company, it just sort of naturally happens because there's just like four people working together and, you know. Yeah, I mean, there's less communication lines. So, you like inevitably hear over here someone's conversation or something like that and in big companies they end up doing a lot of work that doesn't matter or it's somebody's pet project or the developers don't know what to do because they have no visibility of the customer so it's like they're doing a lot of technical debt and maintenance and all these other projects that sound like great idea but don't provide any value to the customer and somehow another that

just ends up being the way that the team runs from then on out like there's a lot of different organizational, you know, problems that can occur. Does remote make this even harder? I think it does. I think you have to be more purposeful in your communication and all of these things. But probably the best companies, the companies that are probably really, really good at remote are probably better than the ones that work in office. What do you mean?

Because they've had to work so hard to ensure that they do these things really, really well. versus when they're in office, they just naturally sort of organically happen. And maybe nobody like plans them out and forces the things that happen. They just sort of happen. Versus if you're really good at it when you're remote, like you have to be much more purposeful

than it organically, if that makes sense. Yeah. You have to probably focus a lot more on asynchronous communication, writing things down. Whereas if you're in an office, you know, you can get overly, lying on the fact that I can go tap somebody on the shoulder if I have a question or something like that.

And it may not be doing it very well, but you just think you're doing it okay because you know you can go tap them on their shoulder. Yeah. What do you think of the, in terms of, you know, giving engineers some exposure to customers, like what's the right level of customer exposure? How do you balance, I guess, like protecting their time and ability to focus while still giving them a chance to provide ownership and context. So in my book, product-driven,

I have a little chapter about how to get customer feedback. And there's a lot of different ways from watching a recorded sales call or, you know, demo to helping deal with support tickets and helping do support to going out into the field and like job shadowing people or even using screen recordings. There's a lot of different ways to do all these things. And the answer, you know, like everything in IT is it depends, right? Like the answer is it depends on the situation, the type of developer, the type of thing they're working on.

I think the key is getting some form of that voice, you know, from a leadership perspective, at least telling the team, like, hey, the work we did last week went really well. It mattered. It didn't matter. We're winning. We're losing. Like, how do I deliver some form of that message back to the team? And then when team members are working on specific projects that they need even more,

feedback, it's just ensuring they get that feedback. Like, how do we get feedback on, you know, the big, you know, the big new feature we launched two weeks ago? How do we figure out some way to measure if it worked or didn't work? Should we delete the feature and get rid of it? Or do we make changes to it? Like, how do we ensure that, that we actually delivered something of value to, you know, not only to the customer, but to the business? Or did we just add more features that nobody uses and we made the product more complicated? Because that happened a lot. In terms of, like, a lot of these kind of typically in organizations,

when you have sort of a product engineering split, a lot of these things around, you know, what KPIs are we tracking for success, what, you know, features do we develop? Why are we developing it are kind of owned by the product, you know, person or product organization? How do you bring, I guess, like engineering into the fold of that to have some strategic agency with some of those decisions? Or is that not the right thing to do?

do. From my perspective, if you're working at a company that builds a product, the engineering team basically is part of the product team. I don't feel like they are two teams. Like, we're building a product. You guys here are here and you exist to build a product. Like, you're part of the product team. I don't feel like it should be an us versus them thing. Now, you're always going to have different team members that have different roles and we're going to figure out how we all collaborate together. But again, I think it's a leadership from, you know, CTO, chief product officer, VP level, understanding, like, we all have to collaborate. You know, we need the product manager to do their job and help bring the viewpoints from the industry and the market and all this kind of stuff to the engineering team. But they also have to listen to the engineering team to know ideas that they have or we have to do this technical maintenance, technical debt, all these other things, architecture, all this other work that has to be done and striking the balance.

ultimately everybody's got to work together and strike that balance and ultimately you're going to have like a VP or a CTO or somebody like that that's going to have to make the final call on some of these things not everybody's always going to agree on what the priorities are but ultimately it's it's making sure that we're delivering customer value first is being the like first like the North Star the North Star is we're not going to do this technical debt or this maintenance or whatever it is unless it provides customer value or it enables us some other really critical thing that needs to be done so we can provide customer value or there's a major risk to it or whatever. But making sure everything aligns back to customer value, I think is the first thing that I would be focused on. In terms of engineers that maybe are, you know, they really want to kind of just be hands-on keyboard, execute sort of the technical side of the product, and for whatever reason don't necessarily want to think too much about that or be too involved in it. Like, how do you think that impacts their career? Is it basically they're going to sealing out at some point? Or is there some other impact? I think there's a lot of things that we could talk

about there. I mean, first of all, is like, how is AI disrupting that? Do those people have a job in the future if AI writes all the code? Not saying we're not going to need engineers to do these things, but how does AI impact that? I think is a legit conversation that we could talk about. But I think we're always going to have the need for software architects. We're going to have the need for people that can solve hard engineering problems, even when we have AI, right? We're going to need that. But even when they are, they still have to take in mind who they're solving the problem for, which is always a customer of some form, right? Like, at a minimum, they've got to have some understanding of the why and the big picture. I think it's important. That doesn't mean

that they need to think like a product owner or a product manager, but they need to at least understand the why behind their work, right? And not just nerd out like they're building legos all day. Like, they still got to have some bigger picture of like, why am I doing this work? And as a leader, I think it's important for us to understand the team members that are that way. Like, I've had team members this way in the past. Like, if you gave them guardrails and said, build something between here and here and do this thing, they were really, really smart and they could build brilliant things. But if they didn't have those card rails, they would build some really bizarre weird things and they struggled with, you know, how to architect

things or how to build something that provided value. So as leaders, we're always kind of struggling with the different team members that we have and what their strengths and weaknesses are, right? But I think the other part of your point is, like, we need some people on the team that are really thinking about the product side of this of how we build a product, not just write code, but build a product that really creates a good experience, right? We need both. We need people that can architect hard things and engineer hard things, and we need people that are more, like, even more customer and product focus.

It takes a balance of all these things. Yeah. I've certainly seen in larger organizations I've worked for, sometimes the tendency on the engineering side, when certain technical decisions have to be made, optimizing for sort of what's easy internally, but what not necessarily leads to as good a customer experience versus optimizing what's good for the customer

and then maybe requires sort of more work for us. And I think part of that has to do with sort of disconnect because they're not necessarily thinking about, you know, at the end of the day, a real person actually has to use this thing that's not, you know, me. It's someone like outside of the company that has to use this. And they're just not sort of connecting the dots sometimes between what that user experience might be and how we should be optimizing because they're kind of optimizing for their own workflow versus the workflow of the customer. I think part of that is having empathy for the user.

It's understanding the customer and having empathy for the customer and the user that has to use your product. And an understanding that the vast majority of people don't want to use your software, they don't want to use your product. Your product is their headache of them trying to do. their job today. Whatever their job is, they don't really want to probably be using your product to begin with, right? They'd rather be doing something else in life. But most of us don't think about it that way. And most of us built the product. We understand the product. And if somebody has a problem with it, it's, you know, some developers have this RTFM mentality of like, why are they so stupid? Why don't they know how to use this product? But it's because we don't have enough

empathy for the user. And a lot of software in shares are super smart. They're super brilliant people our average user necessarily isn't either right so and we're not the users i think it's so that's one of the hardest thing as as an engineer to understand is like i'm not the target demographic for this i'm not the user of this product and having empathy for the person that is actually using it how do you build that culture of empathy i think it comes from getting the feedback right it's it's understanding who is the user seeing the user use the product like Um, I was recently yesterday of trying to sell a car on AutoShare.com and I found like three goofy bugs in the in the product from using it in like, you know, a few minutes.

And I'm like, feels like nobody's ever actually used this product before. Like I'm like, how did you not find these things? Like it asked me to create an AI generated description of the car, which is fine. I did it. I wanted to see what it did. And then I didn't like it. So I hit select all and then I hit delete. Well, because I hit delete and cleared it out, it put the AI back in. So it's like, oh, if you're not going to put a description, it's going to put that one back in, I couldn't get rid of it.

So whichever developer, like nobody clearly does, you know, tested this as a user. Someone missed a test case. Yeah, of like, well, what if they don't want to use the AI description, they want to clear it out? You literally couldn't. And, you know, you can't find every edge case. I get it.

But having empathy for the user, seeing how users use the product, there are a whole lot of people I think what's interesting in this topic is people like our age, probably and older, will probably be the most technical users that existed. Like millennials and older are probably going to be the most technical because we grew up with computers,

like when computers were harder to use, like before mobile and all this stuff. There's a whole generation of people now that have only ever used a cell phone or an iPad. Yeah, like a touchscreen. They never built a computer, never used Windows 95, never used command line, never did any of these things, right? I did. I grew up playing on the Commodore 64, and if I wanted to play the game, I had to know how to type in the commands to make the game start, right?

And my point being, like, the younger people today are probably actually less technical. All they know it is to click the icon on an iPad for something to load. They're actually not as technical savvy as probably the previous generation was. So I guess your point being that if we're building software for that generation, then we can't assume that they have all the technical skills of the team that's actually building it in order to understand what's going on. Yeah. They're less technical than we are.

I mean, my wife's a good example of this. She doesn't use a laptop at all. Never. She only uses her phone. Like, she literally has forgotten how to type. But there's a whole lot of people like that. Yeah, absolutely. and they're using your software.

You talked about this as well of kind of like trying to redefine what code shipped or outcome delivered means. How do you sort of, can you explain that a little bit and sort of how do you operationalize that? Well, I think the challenge for a lot of companies is they get very focused on the metrics they can measure because they don't have anything else, right? They're like, how much code did we commit, how fast, Do we approve PRs? How many PRs are there? How many deployments did we do? Like all these

different things. Not a single one of those things matter. It's like asking a roof for how many nails did you use? It doesn't matter. What matters is did we complete the roof? Did we collect money on it? Is the customer happy? It's the same thing with software. It's like, did we ship a feature that actually delivered more value to the customer? Did the business make more money? Is the customer happier? Do the customer use the product more? Did churn go down? Like all these sort of things are what improve the business and, you know, drive us forward. It's not how many lines to code did we commit, right? But it's super hard to measure all those other things. It's really hard to measure those things. And so as business leaders, that's a challenge for us, is trying to

figure out how do we deliver value to customers, how do we know we're delivering value to customers, which there's not a universal answer to, unless you can define some kind of metric that will help you measure that. And so, for example, you have people like Spotify or something like, well, the way we measure that is based on how many users and how many minutes did they listen to, right? Because if we all align to that, we're trying to drive more listeners, right? And in my first company, it was like, how do we help our customers sell more cars? If our customers are selling more cars, then our product works better, right? And so it's great to have those sort of measurements if you can have them.

That doesn't mean you don't have other internal measurement, but that's how you can have a better measurement of are your customers winning? Because if your customers are winning, then you will win. But you've got to figure out how to know if your customers are winning with your product. Yeah, you see, you need a North Star metric that somehow is a proxy for customer success. Yeah. Yeah, and I think that can be particularly difficult in B2B versus consumer products, too, because I feel like the adoption cycles can be much slower in B2B.

Like if you're talking about B2B SaaS, you come up with some new feature, API-based feature or something like that. Or in the world of AI, maybe it's a MCP tool or something like that. Like it could be the time horizon for adoption could be nine months, 18 months or something like that. So then it becomes a lot harder to know when something is successful. I mean, 100%. That's the challenge with all these things, or it's the, every industry is different, every product is different.

And at one of my previous companies, Stackify, we did application monitoring-related stuff. And, you know, our goal was actually that our users didn't use our product at all. That means their applications worked great. They had no performance issues. They had no downtime. Like, them not using our software was actually a positive, right? So some of these things are super difficult to figure out how do you measure? Like, in those days, like, if somebody's using our software, it meant they were having a bad day.

like, you know, they got production problems and whatever. Like, we don't actually want them to have production problems. We want to prevent those. Like, yeah, it's hard to measure these things. Yeah, so you mentioned your book earlier. And in that book, you outlined some five foundations of vision, focus, clarity, shared ownership, and courage. Can you talk a little bit about those? And then also which of those you think is the foundation that companies most oftenness?

Yeah, so I started down the path of writing the book. I really wanted to write a book about product mindset. Like how does software developers have more of a product mindset, more focused on the customer, more focused on the product, less heads down in the code, right? How do we get heads up more focused on the product? And through the process of the writing of the book, I kept talking about the same themes, specifically things like focus and ownership and empathy for the user and trusting your team and different things. And along the way, I decided that I was like, man, I was kind of creating like these specific themes. Like, I could create a model out of this and make the book about the model. So in product driven, I created the product driven model, which is the five things you mentioned.

And to me, it starts with vision, right? And it's, when I say vision, it's not some like BS, like HR vision and mission statement. That's not what I'm talking about. It's the why. It's the vision of like tactically, why are we building this thing today? like as the development team has to know that like your engineering team has to understand why are we building this thing why does this thing matter it's the kind of the the what and the why not necessarily the how right the job of the engineering team is to figure out the how but they have to understand the what and the why and that's where everything starts and then the next part of the model is focus and again it's focusing on those things it's focusing on what matters right we understand why this thing matters it also focusing on the the customer, not just internal. So many companies get so distracted on focusing on all internal engineering things

and not enough focus on the customer, but also focusing on what matters, making the right tradeoffs, learning to say no, focusing on the things that really matter the most. So that's the second one. The third one is clarity. I feel like in software engineering clarity is the fuel. That's the way I describe it in the book because as an engineer on any kind of project that you're working on, all day long, you get to the,

decision points. You're like, I don't know how I should write this, you know, part of the code or this part of the feature. And so you could get stuck. You're like, well, I have to go ask somebody how to do this. The more clarity you have, you know what to do. And that could be better requirements, better collaboration. You have more of an understanding of the product. You have more visibility to the customer and what needs to be done. There's three different kinds of clarity. There's the why, the scope, what's in scope, and then how? Like, how are we actually going to build this thing. All of those forms of clarity are really important as an engineer to do your job. And the best engineers create all this clarity. They don't wait for anybody else

to tell them what to do. They don't wait for anybody else to give them this clarity. They can create the clarity themselves. And usually this is CTOs and sort of the mythical 10x developers that exist from my perspective. They know how to do all these things. They're not waiting for anybody else. okay the fourth thing is ownership and you know we all know it's important for people to have ownership in their work it doesn't matter what kind of work it is but i don't describe it as ownership i describe it as shared ownership because in any kind of engineering team you know even at your company you don't have full control you don't make every call right you're you're going to have to collaborate with other people ownership is always shared we work together as a team to figure out what needs to

be done. We all have input. And the problem with most companies, especially startups, is you may have an early stage, you've got a founder that has a great product vision, has true ownership of the product and the vision, and then they leave. They're gone. Who has that ownership of the vision and the product going forward? Like, it's just gone. And so you've got to have shared ownership amongst the team. You've got to get everybody to work together and collaborate together on what's going to be done. And the fifth one is courage. And you asked which one I think is the most important. It's that one. And courage to ask the questions, just to push back, to make suggestions, to, you know, want to push for change. You know, we asked earlier, you asked earlier about full scale and what we see

what works and what doesn't work. And the thing that we really train on at full scale training our engineers is this it's courage it's like no matter what we want you to have courage to ask the question to step up to push back to say this is a bad idea to suggest other options like but that takes courage and if you work in a company that has a culture that is more based in fear people are going to be scared people are scared to ask those questions because they know nobody cares or somebody might ridicule them. So as a leader, you know, we have to create that sort of safety and trust in our teams, right? Like we want our employees to bring ideas, bring suggestions, ask the questions, even if they're stupid questions.

Like, thank you for caring. Thank you for bringing up these ideas, right? Even if I don't like your idea, thank you so much for having enough courage and caring enough that you made the idea, right? Like, we have to encourage these sort of things. Otherwise, you end up with a lot of developers that just say yes. They just do what they're told. They don't have the courage to push back and do more. So that is the model that I kind of created that I thought all five are really important

things in a team that I think as engineering leaders, a lot of engineering leaders may not, you know, we're very technical people. Like I described in the book, I didn't go to management school. I didn't go to leadership school. It's all hands-on, but I feel like these are the five important things that the leaders need to do. Yeah, and there's a lot of parallels to some of the things you're talking about there and this study that Google did.

I forget the exact name of the study. You can look it up, but where they looked back, they looked at basically all their various teams within the company. They measured them against like a whole bunch of different factors. And then they came up with a suck, like, I don't know, I think it's been a little while, but it was like top five factors of high performing teams. teams. And the number one feature was psychological safety, which is kind of analogous to what you're talking about with courage. It's like, if you don't feel safe on a team to challenge your teammates or

bring up issues or ask questions, then, of course, you're not going to perform well in that environment because it's kind of you're in a situation where you're fearful and you're not going to be able to do your best work. Are you quoting my book? This is page 47 in my book. Is this study? Project Aristotle. Oh, that's it, yes. Yeah, they studied up. Did you pick that up for my book?

No, I mean. It just happened stands. You mentioned the same thing. Yeah, well, all managers at Google, which I used to be, go through that training. Ah, okay, okay. Yeah. So I literally in the chapter where I talk about the model, the five foundations of the model we just talked about, I mentioned this study.

Literally, I'm like how similar this study was. to the model that I came up. They're very similar things, but put in different ways. And when Google did the study, it wasn't specific to engineering. It was specific to just team success, right? And so you're right. It was about psychological safety, dependability, structure and clarity, meaning of work, and impact of work.

Those were the things that were mentioned in the study. They were very similar to what I kind of came up with the model, just more specific to engineering and stated in a different way. But yeah, it's like people have to have trust, safety, They got to know that their work matters, you know, they got to have ownership in their work. Like, these things are all important, no matter what kind of work you do. Yeah. And I think that it's not only about, you know, performance of the individual or performance

of the team, but it also probably has a high correlation with sort of how good you are at maintaining employees versus losing them. You know, there's all the, especially in big tech, there's a lot of focus on all the, like, sort of bells and whistles around, you know, what sort of amenities you give employees of free food and, I know, massages and, you know, but like, When it comes, that's not what keeps somebody at a company for a decade. You know, there's, there, it's really, you know, what's the meaning behind the work, I think? Do you like the teammates that you're with?

Do you feel safe in this environment? You feel, you know, you're getting the right challenges. And do you have clarity about the job that is to be done, all those types of things? I think you nail it because it's knowing that your, your work matters, right? Do you have a purpose in what you're doing? Or does it feel like I show up every day? I write some code, I commit it, I don't really know, whatever. And there's some people that that's all they want to do, and that's okay.

There's some people that are just, they're okay with being a cogs in the wheel, and maybe they work in a lot of these big companies, right? But there are a lot of people that they want to know that their work matters. They want to know, like, I worked my butt off, and I want to know that it mattered, and it delivered results. What's one of these, like, high ownership engineering cultures kind of look like in practice? you know at stackify at one of my companies you know i had a engineering team lead was a good example that helped manage like three to seven other engineers while he was there

and he he was a perfect example of me that i almost described as sort of like the 10x engineer or something where you could tell him like this is our goal this is what we're trying to accomplish and he would figure it all out i didn't really have to tell this guy what to do at all He would figure out what needed to be done. He could break down the work. He could help lead his team and make sure it all got done. And you could trust him unequivocally that it was going to work and he could deliver. And that kind of ownership is critical if you're going to scale a team.

Like you've got to have teams, like actual teams that you can give something and say, go figure out how to do this. And you can trust them to go do it. And they can work autonomously. Right? Because otherwise as an engineering leader, like you're always the bottleneck trying to get everything done because you don't have anybody that can like own something and go do it. And for a company to scale, you've got to have somebody that you can continue to trust and take ownership of their work, that you can trust a team to go figure something out and they can go do it. That doesn't mean you don't validate it and provide direction and strategic leadership and all these things.

But you sure say can't like micromanage them. You're never going to scale. Yeah. You're also probably not going to create an environment where you keep anyone good. Because I don't think anybody good. Yeah. You're breathing over the shoulder, you know, not allowing them own anything. Well, the best engineering leaders want that creativity, right?

Like the CTO, I just hired at Full Skill Ventures. The reason that she left and came to work for us is she's like, you know, I just want to have more say in the product. Like, I want to understand more about the product and decide what we're going to build and how we're going to build it. I just want to have more leadership in what we're building and why. Like, I work at this bank and they just tell us what to do, and that's fine. Like, we're engineering cool and hard problems. But, like, I want to drive more of the product. I want more creativity.

Yeah. You know, we talked a lot about the types of things that, you know, engineering teams should look to do or maybe they need to change to kind of create these environments where they can be not just order takers, but have sort of more strategic agency. And we also talked a little bit about how, you know, product and engineering, it shouldn't be, you know, product versus engineering. They should be collaborating and working on these. But in a typical product organization, are there things that they might need to change in order to create an environment where product can end work well together, sort of based around this vision of how engineering teams can be high-performing teams? Yeah, I think that's where it comes down to a couple of things.

things. It's product trying to help make sure we're driving, like, vision and focus and clarity, right? Like, what are we working on? Why are we working on it? What's in scope? What's not in scope? Understanding why this matters to the customer, the big picture. Product needs to help drive all of those things, right? But they have to leave some space for engineering to help co-create it. If you're always telling somebody what to do, they're not going to take as much ownership in the work, right? Versus if you say, hey, this is the problem we're trying to solve. I need you guys to help figure out how to do it. I'm not going to tell you exactly what needs to be done. I want you guys to help figure it out. You leave space for somebody else to

come in and have some ownership of their work and feel like their opinion matters and they care more about the work versus like, I help design this thing. I help create this thing. This was part of my idea. And as a leader, we may already know what we want to do anyways. Like, we know this is what we want to do but we leave space for at least other people to feel like they contributed to it and they may contribute ideas we didn't think of or they may come to the exact same scenario that we thought would play out but at least we gave the team ownership in the work so they felt like they had some opinion and now they care more about the work because they're like I help shape this thing it was my idea and that helps create more ownership instead of just telling

people what to do. Do you have an opinion in terms of what sort of assets the product team should be generating before handing off some of the stuff to the engineering team to be able to go and own some of these problems and be part of the design process? This is actually kind of relates back to what I did a talk like a year ago that kind of set me off down this path at a software development conference. And part of it was there's a huge difference between like product requirements and technical requirements, right? Like product requirements usually should just be like, this is the problem we're trying to solve. This is what the product needs to do. But then technical requirements, there's like to be 50 different things, right? Like security, scale, performance,

we're changing this thing, testing. How do we build automated testing? How do we deploy this thing? It can be like a thousand different things that go into like technical requirements, right? So the engineering team needs to own the technical requirements, right? And they need to be good at thinking through all the technical details that the product team probably wouldn't think about. But the product team needs to leave room for the engineers to figure out how to engineer the solution, right? I don't believe that we need to tell the engineers how to engineer the solution. I want to give my, I want to, as a product manager like myself, basically, I just want to tell the team what I'm trying to accomplish. I'm trying to accomplish this.

This is the goal. You guys figure out how to go solve it. And I think it's part of the skill is understanding as an engineering leader that's trying to maybe referee between the product team and the engineering team of knowing when I'm concerned that the engineering team may not get this right. Maybe they need more clarity around how we're going to architect this thing. Did we think about the security? Did we think about where this could go wrong?

Like, why would we fail? You know, as a leader, that's one of things I'm always. thinking about is like, why would we fail? And how do I ensure the team understands, like, this is what failure would look like if we did these sort of things. But making sure that those are part of the guardrails, it's like, as long as you guys don't do, these things will be okay. Just stay here and get everybody to work together within those bounds. Right. What are some examples of, like, big tech companies that you think of figure some of this stuff out. And what exactly are they doing right that you could actually transfer to a

smaller organization? Well, you said you worked at Google. Did they figure this out? I think they have some stuff figured out. I do think that because it's such a big organization, there is certainly a significant amount of insulation between the engineering team, sometimes and the impact to customers. And I think the good, like, edge managers, the good product leaders are able to bridge that gap and create a culture of empathy, but I don't know that it's part and parcel with every single team that's there. Well, I think some of the big tech companies have definitely figured this out. I think in the book I mentioned Spotify and Microsoft and Google and some others that have proven these models, right? And some of them do it with, you know, they're really

focus on creating autonomous teams like Spotify is like hey we have a squad of six people and this is the kind of different roles that we do and um again every company is totally different and what they do the product the industry all the different things um and so it varies wildly but i think in all of them it comes down to trying to create as much ownership in the teams as possible right where if you're always telling the team every detail about what needs to be done they're never going to be able to work autonomously and take ownership of the work. So in every company, it comes down to understanding that. I did highlight in the book a story about a guy at AWS, I thought was really cool where he was working on Elastic Beanstalk's integration.

And the product manager at AWS basically told him, hey, go figure it out. Go to Stack Overflow, go to the forums, go to Twitter, go talk to all the developers. that use elastic beanstock and go figure it out. And that was really cool. It's like, wow, Amazon is doing this. And the developer, his name was Nick Humrich. I interviewed him on my podcast on the product-driven podcast. He said it was one of his favorite things he's done his career.

It was so freeing. I just got to go talk to the developers. I got to figure out what needed to be done. And I could just go build it. I could ship it. It's like, I didn't have to work through the sort of proxy of the product manager. where most developers, the lens they have is this sort of distorted lens through the product manager.

Like, you're totally at the mercy of what they're telling you, right? Versus if you remove the product manager out of the way, a lot of engineers may get a whole different insight and perspective that just gets lost. And so it was just cool to hear his story, you know, working at Amazon that way. Yeah, that's cool. Yeah, one of the things I always tried to do during my time at Google was,

you know, if we were early in the design phase for something, some sort of new product initiative, I would bring in sort of my NGE counterpart to be part of those early sort of customer exploratory conversations. And so a lot of times they would have questions that I wouldn't even have thought of just because they're kind of approaching it from a different lens. And then it helps set up, you know, that sort of personal relationship with the key stakeholder, which is the customer. And then when we would launch stuff and we would announce it in a lot of times in these office hours that we run, I bring in my NG counterpart for those too

so that they could see what the reaction was when we lost certain things because you're getting... I mean, everybody wants to see a positive reaction to their work. So it's like you're able to kind of bring people full circle and I think they really appreciated that. We all care that our work matters, right? Like we want to see the result of it.

That's the only way you're really going to excite people about the work that they do. Yeah, absolutely. So if you were advising like a startup founder, today, how would you tell them to structure some of their product and engineering at or interactions from day one to try to avoid some of these pitfalls that we've talked about? We could do a whole podcast on that one. I think as a startup founder, the first thing you have to realize is like who is on your team

and kind of what their strengths and weaknesses are. One of the things I wrote about in the book is I feel like there's four different types of engineering leadership. They're strategic, operational, product, and technical. And nobody is all four. Like, that person doesn't exist. And I think as a startup founder is understanding the team members you have, like what they're good at and what they're not good at.

Because a lot of times what happens, you hire a CTO that's really good technical, but maybe they're terrible at operations, right? They're not good at managing people or managing process. And so a lot of startup founders will struggle because things aren't scale, they can't add people to the team or the CTO thinks they need to solve every problem and they're always the hero and all this stuff. And so I think that's one of the most important things as a founder is just understanding your team and what their strengths and weaknesses are across those things and realize, you're like, you know, I want to fire my CTO, but maybe that's not really the solution. I need to hire like a VP of engineering or somebody that's really good at all this operational stuff.

So I can just free my CTO to go focus on these like super hard technical problems. and product stuff and prototyping because he's just terrible at this other stuff. I think as a founder is just understanding the strengths and weaknesses of your team and understanding that it's not everyone, not one person can do all these things. Awesome. Well, Matt, is there anything else you'd like to share? No, I really appreciate having me on the show today. And if anybody's interested, they can check out product driven.

It's on Amazon. and you go to productdriven.com and learn more about a newsletter and podcast and book and all that stuff. You can follow me on LinkedIn. It was pretty cool. We launched product driven. It was a bestselling book on Amazon. It was pretty cool to see. So, congrats. That's amazing. Well, thanks so much for being here. I really enjoyed it. All right. Thank you, sir. Cheers.