From Output to Outcomes: A New Era in Tech Growth

Hey, what's going on everyone? Welcome back to Mastering Tech Growth. Every week we chat with industry leaders to bring you big ideas on how to grow. My name is Mike Sirius, and today we are discussing what happens when teams stop closing tickets and start owning outcomes. Today, in the age of AI, may I say, the output is cheap or becoming a lot more cheaper. So the mission critical becomes customer impact, not the output. Joining me today is Matt Watson, 5 times founder, seasoned CTO, and a CEO of Fullscale, a top 1 offshore development company on Clutch with over 300 engineers. He hosts Product Driven Podcast and wrote the bestselling book, Product Driven. Matt, great to have you.

Hey, thanks for having me, man. Thanks for being, letting me be here today.

It's going to be awesome. So I'll kick off with this one. When I say mastering tech growth, what comes to mind?

Well, tech growth usually is less about the tech and more about sales and marketing.

Tell me about it, right? You think like all your tech background will help you. It's probably not. Well, okay.

So, yep. Go. One of the best things I ever saw once, I think I found it on TikTok, was, you know, it's so much more important to be best known for what you do than actually being best at what you do.

Ooh, I love that. I was saying that—

Being the best at what you do and nobody knows, like it literally doesn't matter. Right? The peop— best known beats best every time.

So best known, that's ability to market yourself or ability to market your business. Okay. So we're saying marketing is very important. You mentioned sales as well. I mean, no business can survive if they're not closing deals, right?

Yeah. But I, you know, not to get us off on a tangent, right? But a lot of people don't understand the difference between sales and marketing and, uh, Sales, I don't want to say sales is easy, but usually if you've got good qualified leads, you can close those leads. But the hard part is always finding leads. How do I find more leads? Right? So that, that's always the hard part.

So are we saying then leads finding is more important than actually ability to close? I mean, it makes perfect sense. You explode the leads, whatever is your closing rate, the business goes up. The more leads. The more sales, even if your sales conversion rate doesn't change, it becomes more input, more output, right? Simple math.

Yeah.

Okay. So there's a couple of things there, Matt. So let me make this more difficult and say, if you would choose one first order impact, right? So you can, you know, you mentioned marketing, you mentioned sales, potentially there's more, potentially there's branding, potentially there's hiring good people, doing a good tech and all these other things. If you would choose just one, which has direct and biggest influence on the growth trajectory for any tech venture, what would be your choice?

I think it's lead generation is the one I'm gonna pick.

Okay.

It's like you gotta be able to generate leads some way or another.

Lead generation. So what's your go-to on generating leads for Fullscale?

It's LinkedIn. It's social.

LinkedIn.

You know, ultimately for our business, it's all about trust and relationships, right? Like, We have thousands of competitors in India and all these other places that spam people every single day, right? You, you may get these same emails and you're like, I don't know these people. Delete, delete, delete, right? Like you have to build a relationship with people. And for what we do specifically, like cold outreach doesn't work. Like you have to build a relationship with people. And so LinkedIn and social is one way to do that, but what works the best is getting out and meeting people in the real world. But second best, like social, social work's pretty good.

I love you. I love you mentioning a lot of cold outreach on LinkedIn, especially coming from Indian, Pakistani area where they just sort of like, hey, I do this and it's like 25 bullet points and it goes just from like mobile development to DevOps and everything in between. I'm interested why they're doing this. I mean, you know, we sort of going on a tangent here with the, from the main topic of episode, but like, what's your take? Why do you think they send these messages? Because I would, I just, I'm having such a hard time seeing them closing anybody with these messages. Like, why would you go ahead and do that?

Well, the key to business is all about relationships, right? And if they don't have any relationships and they don't know any potential customers, it's the only thing they can do, right? Is just start messaging people.

Okay.

Start messaging every person they can find. And hoping what, 1 in 1,000 respond?

Spray and pray, right? Literally.

That's right.

Definition.

It works. I mean, 1 in 1,000 times you might get somebody, but yeah, it's—

It's not what, yeah, we had multiple episodes on LinkedIn business on the show and great experts and we had a full dedicated episode where we talked about the fact that building relationships If your goal is to close deals and you look at one metric, which is how much I sell, like that's your core metric, and then you ignore everything in your pipeline. Is it a cold route? Is it a warm outreach? Like you just ignore everything what happens on the left and you say like, what I care about is closing deals. Then on A/B testing and on paper, you're going to be closing more deals if you do what it's called, show me that you know me. Which basically has no automation, it has no reach out at scale. It's literally like choosing by hand 10 people, going DMing them, building relationships, providing real value, and then building business with them and then closing those deals. And that conversion will be much higher than going after like thousands with automation tools.

Amen, man. Amen. It's all about building those relationships. And it's a grind though. It's really hard work and nobody likes doing it. I don't like doing it either. Nobody likes doing it. And my memory sucks, so I can't remember those 10 people. What is it? It's hard, man. It's hard. But it's the key to success. You're absolutely right. And for a lot of people, if they would just spend like 15 minutes a day, 30 minutes a day doing what you just described, would get a lot of success out of it. But it's a grind.

It's a grind. It's a hustle. So wait, wait, wait, Matt, are you saying you're not enjoying being on a podcast right now?

No, no, this is my favorite part, talking to you.

All right, excellent. I'll take that to heart. I'll just ignore everything you said before that. Right.

I like talking to people. It's like cold messaging people and stuff like that, right? Like it's not fun.

Is it just rejection or just a pure grind? You just don't enjoy that. You just have to do it all. Like you still need to hit numbers, right?

It's like, here's your 30 tasks of the day. Go grind through them. Like nobody enjoys that. Yeah.

Did you ever thought about just getting like virtual assistant to, to, to give you the boost with the start? Or you think that's not? Building an actual relationship.

We're working on doing some of that now internally where it's a mix of, yeah, having somebody that can help do some of it. You know, obviously I can still handle like the real conversations, but if there's somebody that can help do some of those kinds of reminders or follow-up messages or stuff, would be helpful as well. But yeah, but you're right. It's more about the show me, you know me thing part of it, right? It's like, but that takes like deep, authentic, personal messages, not like a templated approach.

So I've been doing a lot of lead generation and with AI it's becoming easier to craft something which resembles an actual human outreach DM or an email, right? Because you can effectively, you can do what is called enrichment of data. You know, you can look at people's backgrounds, you can look at their websites, you can look what they posted on socials quite recently and you can sort of, you know, train AI AI to really talk as you talk and, you know, write an email like that. It's interesting what that's gonna take, but I never seen anybody doing better than something like 3 to 5% conversions when it comes to cold outreach. Like that's a very high level of a game. And when you do that yourself manually, they usually get like 70%. Like, you know, you get answer pretty much all the time because it's just people sense when it's people and people sense when it's cold outreach. It's just something we really attune to, I guess.

Yeah, it's like 2 or 3 years ago, none of us had ever received really AI messages, right? Now all of us have an amazing radar for it.

It just feels so odd, but you have a sense, like you look at some output and you go like, yeah, that's ChatGPT right there. It's like, I have no proof, right? But I know it's not you.

I wish people had the same radar when they read news stories and you know, political crap on the news that they would have the same sense of like, oh, this is just bullshit.

Yeah. Bullshit right there, right?

They can tell when the AI is crap, but they still listen to this like political news, like rage baits all day. It's like, that's all crap too, people.

Interesting. All right. Let me take, let me take us back right on our episode. So we're talking about people concentrated, not people, effectively engineers, developers who do a very important development work. Very often they drift into just being task doers. And what we're saying is that this is becoming, it's coming close. Okay, so how to phrase this? It's not obsolete. I mean, there's still a lot of development to do, but with AI coding assistance and just coming in and if it's becoming better and better, the output itself of just writing pure code and getting tasks done, that either will be cheaper or just just not needed anymore, right? So concentrating on actually having an impact with the work you do on a customer is becoming a lot more important, right? So my first question is, because you have this full-scale business, hundreds of engineers, do you remember when you yourself, you know, as a CTO or maybe developer realized that, look, I should not be just thinking about a ticket, like I need to get this done, but thinking about what outcome I'm actually enabling with this work?

Well, I think we should expand the look at this a little bit because it's not just about software engineering, right? Like AI is having this impact across all types of jobs, right? If, even if you were like some form of virtual assistant or you're the person who edits this podcast or edits video or transcribe this podcast, like, you know, there was somebody once upon a time that we hired at Fullscale that transcribed our podcast, like manually, like we didn't have a tool for that.

Manually.

Right. Yeah. Well, now think like that job does not exist anymore.

Hmm.

Like 100% Riverside we're using here today perfectly transcribes it, summarizes it, right? Like totally eliminated those jobs. But the jobs it didn't eliminate is probably the person who was driving the strategy around what is the story I'm going to tell about this podcast and why you need to listen to this podcast. AI still isn't necessarily the best at that, right? And figuring out like, what is that story? And it's that higher level, like strategy and thinking, creativity, you know, problem solving, all that stuff, which is really the true human value that we're all going to have to bring now. Or if our job before was just to listen to this podcast for an hour and write up some notes and timestamps, which I had somebody that did that, like that is gone. But that was sort of like really boring, mundane work too, right? Like humans should be capable of more than doing that anyways, right? We want them to be more creative and doing more things. And I think that's what AI is forcing across the board, not just in software engineering, but in all forms of careers. Mm-hmm.

Okay. So we, yep.

But I think specific to software engineering, it, in really big companies, what happened is, is software engineering was always the most expensive and difficult part, right? Like product can come up with like, we want to build this thing. Now I gotta go to the engineering team and get them to build it. And that was a slow, complicated, expensive thing, right? Like it, it's always been that way. And ultimately what happened is we built everything around the engineering team to try and get them to do less stuff. Like we want them more heads down in code and less time in planning, less time in QA, less time in deploying stuff, less time talking to customers. Yeah. Like we don't want them to do anything else except hide in the corner and go write code.

Yep.

And then we wonder why that doesn't work because they don't understand what they're doing, why they're doing it. They don't get the feedback. They don't understand the big picture because they're like an ostrich, head down over there writing the code. And AI is changing all of that. Um, it's making it easier and easier to write the code. So you've got to understand more and more about like, why am I writing the code? You know, if, if you can write up these super detailed requirements and give it to AI, like AI might be able to write the code and like What does the developer do? It's like, you've gotta, you gotta be a higher level in the food chain, just like the example of like editing the podcast. You need to be higher level of the food chain of like, how do I promote this podcast? Right? How do I tell a story? Like that's a higher level, harder job.

So what are we advocating here, Matt? So are we saying that if you are a developer right now or expanding to more jobs and you are, if you, if you remain in that space of writing code, you're effectively at danger of getting replaced by AI. Is that what you're trying to say? Like, you know, people, not people, but like engineers should start thinking more of like what outcomes they enable with their work than just being like, hey, I'm going to own this code like that. Like, that's what I will do. I'm just going to concentrate on code ownership. I'm not like, I don't care what outcomes I'm enabling.

Yeah, I think absolutely along those lines, like if, if, if it becomes easier and easier to write the code, the harder part becomes figuring out what code to write. Like, why are we doing this? So the hardest part of our job has always been talking to customers and all the other business stakeholders and figuring out what should we build? What's the priority? Why are we doing it this way? Why aren't we doing it that way? Did we all agree this is what we're going to do? All of that has always been the really hard part, right? But if that used to be like, uh, but, but if writing the code used to be like 80% of the job and all of that planning stuff was 20% of the job, that's shifting, right? If, if writing code is twice as fast all of a sudden, now I've got to do twice as much planning work, right? Like, okay, that becomes more and more and more of the bottleneck. And the only way to solve that, as you said, is the engineers have to think more and more like a product owner. They've gotta, they've gotta drive more of why are we building this thing and understanding why are we doing this? And so, um, in my book, Product Driven, I talk about how clarity is the fuel. For a software engineer, it's really easy to get stuck almost every hour of the day of like, hey, I figured out this thing. Now I'm not sure what to do about this. I need to check with this person. I want to ask them. I need to check these requirements, whatever. It could be a thousand different things you get stuck with. And the only way for them to be super productive is for them to be able to find that information, already have that information, or even better yet, create it themselves. Like they create their own clarity. Like they, they know how to deal with ambiguity. They know how to deal with, you know, solve problems and figure out whatever needs to be done so they can keep going instead of just getting stuck all the time and waiting for somebody else to unstuck them, which when you're in this order taker mode, a lot of them are just like, given directions and told, go do this thing. They're completely dependent on somebody else telling them what to do. Right. Um, so, but if that's the paradigm that is changing is these engineers have to be able to drive more and more of what they're doing and think more like a product owner.

Okay. I think you described pretty much the reality of like 99% right now of engineers. Cause I, I think about my teams. I think about myself. That's literally what is taking place. it's, it's a handoff process where, where even in agile environments, there's still a lot of handoff process where you have, apex of a product like PMs or product owners or some type of delivery managers where they go like, we're going to build X. And then it gets taken down into a lot more tactical execution type of items, you know, done by product owner. And then that's given as a task. Of getting that realized for the teams and team just do the tasks. So we're saying that the developers need to start owning the why behind these tasks.

Yeah.

Uh, 100%. What does that mean to actual then POs? Are we saying that they, they're going to get just sort of like, if that's done well by engineers, that role is not needed anymore, right? So they, they, they, they just going to become obsolete then.

I think the product owner role is going to have to. To change. Um, but it depends on how you describe what a product owner is and what a product owner does versus a product manager and what a product manager does. Mm-hmm. You know, in some sense, you might describe myself as a product owner, um, for a product that we're building internally. Like, I'm the owner from the perspective of I'm the expert at how the product needs to work, and I show up to the meeting, provide my guidance around that expertise. So my goal is actually just to get them to understand what's in my head. Right? Like, I, they're, I don't expect them to necessarily replace me, but I'm always kind of the, the thought leader of what needs to be done. But that, but I'm not a full-time job on the team. I show up, you know, for an hour or two a week and help, help, you know, tell the story of what we need to do. So it's not like they're, that replaces me as like a full-time job. I'm still just like the thought leader of the product.

Okay.

Um, but then we have a, a product manager role is gonna have to continue to change as well, but we still need product managers to rein everything in and figure out a strategy. Working with engineering team to figure out, okay, what are we really going to do? We got all these ideas, you know, want to make sure we pick the right direction, go the right direction, do the right things, do it the right way. Like, you know, we still need leadership to help drive that, but we need the team to be more and more involved in the process.

Right. So how do you go ahead and do that, Matt? Cause I'm thinking there's a pull and push mechanics, right? So you're going to have some engineers who maybe naturally a lot more product thinking or just inclined to ask the why because they have a different level of curiosity. And then you're going to have engineers who's just going to be like, you know what, leave me alone, give my headset. I want to just put some good music and give me tasks. Yeah. That's actually one of my best friends. He's literally like that. He's like, I just want to code, man. Just leave me alone. Right. So, so that's, so you have this like, you know, like, As in pull, give me information from some people, but some will not do this. So leadership needs to sort of go like, like, hey buddy, like, you know, time has come for you to be a little bit more involved here because you don't need to code that much. Like, yeah, yeah, I will code for you. So how as a leader you set up your processes so that can flourish?

So I think it starts with identifying those people on the team that want to be more creative, right? They want to understand the why, they want to have more of an impact, like that persona. Like, it starts with empowering that persona to get them to do more, right? Like, you're always gonna have some people on the team, like you said, they're just, hey, I just wanna be heads down, just tell me what to do and I'll go do it. And maybe they're just more of the worker bees on the team, and that's okay. You need some of those, but you can't have a team of all worker bees.

Hmm.

Somebody's gotta also be driving what are we doing and why are we doing it to also keep feeding the worker bees that kind of that kind of stuff as well, right? And in the book, I describe it as the goal is shared ownership. And I, and I, I don't refer to it as ownership. I refer to it as shared ownership because it's always shared in any company, in a tech company, that ownership of the product vision, what we're doing, why we're doing it, is always shared by a lot of people in the company, all the way from the CEO level to the product manager, to engineering leadership, the developers themselves. And honestly, kind of feedback from the customers, the users, everybody, like everybody has input into what are we doing, why are we doing it, right? We want everybody to be kind of involved. And the problem that a lot of companies is you'll have like a CEO or product manager who is that one person that makes every decision and everything runs through them and they're the bottleneck. And then they leave and then you're just screwed, right? Like the only way big, big companies like the Microsofts and Googles and stuff of the world work and scale is they figured this out. They figured out a model of like, hey, we build teams that are, you know, 5 to 8 people and we need that team as a whole to own something. We have to delegate and build a strong enough team that they can go figure out how to do stuff and own that thing. And that's the only way to scale is you've got to be able to build ownership in a team.

Okay. And that starts by effectively by empowering some of the team members. We agree that's potentially not everyone will be like this. Is it healthy to actually hire like this and go like, hey, like, I know you're a coder, but like, do you care about asking why is behind the product and use some of the, like, so, so are we saying that having a team full of worker bees are not, not good idea, but having a team full of individuals asking the why, that's a, that, that's a good idea. Or is it a mix which we're looking for?

I mean, I think ultimately a mix is good, right? And we're always going to have a need for —people to solve heads-down, complicated engineering problems. Like, we're gonna have some of that too. But you need some people on the team that care about the users, they have empathy about the user, they want to make a difference, right? Like, they care more about than just the code. I think that's the other big problem that we have. And this is very much a leadership problem. I feel like our goal number one is to keep reminding the team of like, why are we here? Why are we doing this? Because we are not here to write code. We're here to solve problems for somebody else. Like, a user, a customer, or some— somebody in the business, whoever, who is the user of our product. Yeah, keep the focus on them. Because if you don't keep the focus on why we're doing this and who we're doing it for, it's easy for the engineering team to just look internally. They're like, well, we want to do this project because it makes our life easier or look good on our resume, or we, we just want to rewrite this code because we don't like the code. Like, it's really easy for them to look 100% internal instead of keeping the focus on like Guys, there's a bigger picture of why we're here. Like, I understand you don't like this code that's 7 years old and you didn't write it and the other guy left 3 years ago, but we don't care. The code still works. We need to deliver value to our customers, right? Like, how do you, how do you keep pushing to like, why are we here? Because if not, the teams will all focus internally.

That's just the way they naturally operate. So, so we're saying, yeah, so that's a leadership element, 100%. Always remind the why, always remind what impact to the customers they have. I want to ask about like tactical things, and I'm not sure if you will have opinion about that, Matt. So if I'm, let's say, like a product owner or I'm a person who runs like Scrum teams, right? Like Agile Scrum teams. I'm writing tickets. I have these ceremonies like standups and planning and grooming and all these retrospectives. Like what is my tooling or mindset or vocabulary I'm using to actually start developing this team-level culture of outcome ownership?

So I think it's a couple of things. The first thing is always keeping the customer, like, as part of the conversation and getting the engineers to be more involved in sort of a little bit of the product planning at a high level, hearing the voice of the customer, you know, like, hey, we did a release yesterday. Did it go well? Did it not go well? What was the impact that it had? What feedback did we get from the customer? Right? Like, I think it's constantly getting that customer voice and that feedback. It starts there, right? So if they're constantly getting that feedback and they're, you know, doing a deployment, they're like, hey, I wonder how that went yesterday. Did it make a big, big difference to the customer? Like, that, that amps them up, right? Like, they feel like they have a purpose in life now instead of like, I don't know, I committed the code and now my boss is down my neck to get the next sprint done and I don't even know what happened with the last one. Why did we even do that? Right? Like the more you can bring the customer into it, it's just motivating, right? Like, why are we doing this? And I can see results of what I'm doing and people are coming by and giving me a high five and saying thank you and like, feels good. Like it starts with that, like getting that human voice and element into the work, which I think is totally gone in very many places. I fully agree. It's just work item to work item to work item. Nobody really knows what we're doing here. So.

Okay, so I'm bringing, so when I'm doing my plannings as any role, I want to say like a product owner, but let's imagine you're an engineer, you're a team leader or whatever, you're having a conversation with your team. So you're constantly asking, okay, who's the customer? Okay, what are they saying? What is the feedback? Why are we building this for them? What metrics? So I'm driving that sort of conversation. So vocabulary takes place. Do I put things like that in the actual work items, which is effectively like Agile stories, like Am I putting in like, here's the outcome of a story, you know, acceptance criteria is about enabling an outcome rather than enabling some type of— effectively what I'm asking Matt is like, what is the definition of done for stories when we talk about outcomes?

So I think a lot of times it just takes an extra 5 minutes or so to capture that type of context that you could give either in a standup meeting or some kind of weekly planning meeting, however you want to do it. Of giving that additional context, and it could be written too, of course, in the requirements, like whatever makes sense for your team and the situation. But a lot of times it's just taking that extra 5 minutes to stop for a second and explain why are we doing this and why is it important? Because when they're making technical decisions, they're always thinking about trade-offs, right? Do I make this quick and dirty because the CEO just needs it for some goofy little project, or does this need to be military grade, right? Does it need to perform? You know, is this for all customers or one customer? Like, there's a thousand different things, right? And that context can help guide all of those decisions, right? So that now they understand, like, okay, I understand why we're doing this. I understand how it fits into the big picture. They mentioned don't do this other thing because we don't need that thing. Like, they spent just like the 5 minutes I needed to give me a little more context. So now I can make smarter decisions. And have more clarity, right? It's all about the clarity I mentioned earlier. This is the clarity that helps them, you know, I look at it like if there's, I tell my team like, if you think there's an 80 to 90% chance that, that you are right, or you ask me a question, I'm gonna say yes, then just do it, right? So it's like, how do, how do I give them the information so that, you know, they can drive that sort of clarity and decision making so they're not always having to wait and come back and ask me more questions. Right? How do I drive that clarity?

Okay. How do you drive that clarity?

Explaining things in this daily standups every day. That's how I do it. I show up at standup and I don't look at standups like, uh, so much like a status update. It's dry. It's more of a technical requirements conversation and a higher level product conversation of like, why are we doing this? This is how it needs to work. Don't forget this. Think about that. Like, I, I prefer to be more hands-on and driving those conversations. So that I can constantly remind the team like what we're doing and why and all that kind of stuff. That's my style. Everybody has a little different style, but I prefer that.

So in the remote setting, which I believe you have remote teams, Matt, because just looking at the full scale, you know, you got a lot of in Philippines. So is everyone on camera? And if not, do you feel like sometimes maybe you just talk to the void and people just multitask while you're talking and not really taking in? Yeah, so a couple things there.

I mean, we know that remote work works, but you do have to have a little more sense of urgency and a little more purpose in your communication, right? Because it's not as easy to be like, oh, when I see him later in the office, I'll remember to tell him that. Like, when you have that idea, like, you gotta message them, you gotta tell them, you gotta schedule the meeting. Like, you gotta be more purposeful in all of your communication, right? Okay. But You know, in, in regards to the camera thing, I greatly prefer that people have cameras on and, you know, some people like it, some people don't, but here's the reason why I think it's important. Um, for software engineering and really a lot of things in life, it's about collaboration. And just like you today, like I want to be able to tell you something, stare deep into your eyes and know, are you listening to me? And did you understand that? Or do you look confused right now? Hopefully not. I can't do that if you got the camera off, right? Like body, so much about communication is body language. And I know some people hate being on camera, but body language is important. Like I want to be able to tell somebody something and feel like, do they understand? Are they paying attention?

Hmm. Okay. It's important to me. It's, it's, yeah, it's definitely, it's definitely that. Okay. So stand up. Better than talking to the void. Yeah. And that's, you know, that's like some, sometimes I get, you know, like you go in this monologue for like. 5 minutes and maybe even more, which is a lot. You know, if the meeting is like half an hour, so you're taking majority of the time and you're like, you know, you're sharing good details and you're sharing what you believe are very important details. And some of these needs to be sort of taken as a note and action, right? And you're going like, yes, you know, let's action that. And then you go like, does anyone have any questions? Silence, you know, crickets. Yeah. And I'm like, did you guys just, you know, were writing emails while I was talking? Which is, you know, defeats the purpose, right? I feel like it's a battle we all do, like having right now with the remote. That's a very common challenge I have in my daily life. So that's, um, yeah, I just wanted to see you share that.

I have a couple tips there. I think I'm the kind of person that believes everything needs an owner. I, I know some people don't agree with me when they do this. We're like, oh, I've got 4 members on my team and we have a project and like all 4 of them just work on the project. I call bullshit. I don't like that. I want one person. Yeah. Single point of contact to be in control and doing it for multiple different reasons. But when you got 4 people working on one thing, it's so, it's so much easier for all of them to just think the other person's doing it or waiting on that other person and whatever. Like, I want an owner who is in charge of this thing and, you know, removing any like, you know, blockers between each other and waiting time like that. That's what destroys productivity, like I want one owner on things. Mm-hmm. Um, I think it's really important. And so I can hold them accountable and, and help them and they're not waiting on everybody else. I think that, that is really, that's one of the first things. Um, second thing I was gonna say is a lot of this just requires, um, what we call courage at Fullscale. And so this was one of the aha moments we had a couple years ago. One of our other engineering leaders came up with this of not everybody has the courage to speak up, right? Not everybody has, never, not everybody's gonna push back or say, hey, you know, Mike, yeah, I don't really agree with that, or it's not gonna work because of this, or yada, yada, yada, right? Like not everybody is gonna have the courage to say those things. And when you go on your 5-minute monologue, not everybody's gonna have the courage to be the first one to speak up. They're like, man, he just dumped on us for 5 minutes with this thing. Yep. I don't know what to do with that. Yep. I'm not jumping in front of that. Yeah. And everybody's gonna have the courage of that, right? Yep. So I think part of it is when you have those conversations, you almost have to name somebody. Like you go, you go on for 5 minutes or whatever, and then you're like, hey, Ishmael, what do you think of this? Mm-hmm. Right? Like you almost gotta name somebody and, and keep the conversation going. Yeah. But I think in, in the, in my book and Product Driven, in, in the model, courage is one of the key things. And it's important to create an environment where people can have that courage, people can speak up, and when they do speak up, you're not always like shutting them down and, you know, telling them their idea is stupid or anything like that. Mm-hmm. Right. You gotta figure out how to encourage people to speak up and reward them for speaking up. Right. And, and having some psychological safety there, including like risk, like you want them to make decisions quickly and move quickly and, and you're okay with the risk. Associated with that. It's about creating that kind of environment. And from a leadership perspective, you have to kind of model that and make everybody aware of that, right? And everybody knows like, hey, they made a, they crashed production yesterday, but nobody got, nobody got, you know, fired for it or whatever. Like, it's okay. We move fast, we break things, we learn from it, we keep going, right? Like having, creating that kind of environment is important too for people to want to move fast and make decisions.

Okay. I love that. And yeah, everything is golden nuggets. What are you sharing there, Matt? Pure leadership things. I just came up with another use case, which I'm very keen to get your perspective on, right? So you have layers of teams and I'm coming back now to the voice of a customer, right? So taking a step back where we talked about How to actually get that culture set where engineers start asking, you know, more wise and more product questions. So let's imagine we have the setup, right? So we have a frontend team who will be very close to that, whatever reaches the customer as a product, right? Because it's a frontend layer, it's literally what the product sees, the customer sees the very first. Then you have a backend team, you know, let's say they do APIs, right? So they will be behind that frontend team. So they will be one level level deeper away from a customer. And let's say there's some type of like DevOps database team or something like that. I don't know why it exists, but let's say it does. So they will be buried, you know, multiple levels away from a customer. So they will be doing their own things. How do you get that depth of a level of a team, which are multiple levels away from a customer to actually think in those terms of asking the whys and in a customer sort of outcome-oriented thinking?

You know, from a leadership perspective, I think it's just trying to make everybody understand how their piece applies, right? Like, how does what they're working on impact everything that is a bigger picture? And you're right, because sometimes it's like, uh, I had a friend of mine actually who has been a software architect for like 20 years, and he always worked at really, really large companies way behind the scenes, working on like little performance optimization things, little scalability things, like so divorced away from like the whole world. And he read my book and it was really funny because he messaged me and he's like, he's like, Matt, I've been doing this for 20 years and I really never thought to think about the customer and how what we did impacted the customer very much. And I just kind of laughed. I'm like, yeah, after 20 years you never thought about the customer? Like, what are you talking about? He's like, but that was his type of work. Like he was like very deep down into the nether, you know, as you kind of described. And, and I think our job as leaders is always just trying to shine that light, like, you know, beating the drum of the customer. Why are we doing this thing? And making sure that everybody just understands and they understand how their piece applies to it. Right. And, you know, for my friend, it could have been like, hey, we're trying to optimize for performance cuz we're trying to improve availability and save money by reducing the number of servers or whatever. And Yeah, none of that sounds super exciting, right? And so sometimes it is harder to relate that kind of stuff, but it's work that still has to be done, right? But I think the other challenge is making sure that we just stay focused on how it delivers customer value or business value, right? Because for like my example of my friend, it's very easy for him to like spend forever writing code and optimizing things and working on technical debt or maintenance or whatever, and just losing sight of the big picture. Losing the, you know, the sight of like how to deliver higher level value, you know, for the customer or the business. And so from a leadership perspective, we just have to keep fighting that fight, keep beating the drum. Why are we doing this? Making sure by reminding everybody.

So do we utilize something like KPIs or OKRs to, you know, to connect the dots and go like at the very top is, you know, customer adoption or something like that, or you know, less churn or whatever. And then, you know, we go deeper, we're going to get this if we get that feature out. And then we go to backend, we're going to get this if that feature works very fast and the latency is zero or whatever. We're going to get this if, you know, cloud is cheaper. So that's going to give us some more runway or whatever. Like, you know, all connecting these dots across all the teams, across all the levels. And so everybody pulls the same direction. Is that like OKR, KPIs type of approach or, you know, how do you actually How you do that at your end? How do you make sure that everybody's thinking of the customer and pulling towards these outcomes?

So I think it's great to have some form of north star metric like that, that everybody can rally behind. Now, in a bigger company, that gets harder. You know, if you're the guy that's like optimizing the code to save a little bit of money on, you know, AWS or something. It's a little different, right? Because like then that's your metric and that's not very fun and exciting, but it does work a lot better if there's some bigger metric that everybody can kind of see as a guiding light. And so one of my first companies, we built software to help car dealerships sell cars. And so that was one of the things we looked at is like, how many, how many car, how many cars are our customers selling? Because if our customers are selling more cars, like we are winning, right? And you have somebody like Spotify that looks at, you know, how many minutes people listen to of music and stuff like that, right? So the goal is like, how can we get more people to listen to more music? That's always the goal. How do we using the product? More minutes in the product, right? So, you know, depends on your business and what you're doing, but it's great if you can align metrics that way in some form. And but the key is they need to be the customer's metrics. Like, it's like if the, the customer success becomes your success is the best way to do that. It's not your own success, it's really trying to figure out how do you measure something that means this, the customer is successful. And that's why for us with the car dealers, it's like if the car dealers are selling more cars, we're successful.

Well, I love that. Customer metrics, not your own metrics. Yeah. Okay. That's a good one. So how do you get customer metrics? Is it just by talking with the customers and going like, what do you care about? Like how, how—

Well, it's hopefully something your product helps with, right? So if there's, if it's a byproduct of something you're, you're your product helps with. So for example, if you were building something, we're talking about LinkedIn earlier, that helps people find lead leads, right? You're like, well, we track how many leads we helped you find with LinkedIn. And so we know if you got more leads, then our product is helping you and yada, yada, yada. Right. So just try and figure out a metric that makes sense.

Okay. So we get this North Star metrics and then we go like, we do like a big town hall, you know, as a leadership of business. And we go like everybody, we're going to be doing this North Star metric. And some guys, you know, doing architecture, they go like, so? Like, you know, everything I do has no impact in this. So is that becomes like a challenge to them? Like, no, no, no. Like you need to find a way how your work actually has impact on that North Star, or are we actually helping them? And if we're helping them, you know, that becomes like this push behind it. Like we're going like, here's some metrics which, you know, makes you think in outcomes.

I mean, for sure, there's always going to be people that are in different roles that aren't necessarily going to contribute to that, right? Like the person who works at the company campus that serves lunch also is not going to drive that metric. Like, I'm giving out food to everybody else that works here, right? Like, they're not going to impact the metric either. Like, so it, you know, The thing is it gives everybody a team goal, right? Like how do we win or lose as a team, even though we all contribute different pieces to, to the whole, right? Mm-hmm. I, I think it helps just give a measuring stick, cuz especially in a, in an early stage company, we all just wanna know if we're winning or losing. You know, as a, as a company, as a team, are things good? Are things bad? How do we help? What do we do? We all wanna win. We, none of us wanna lose our job. Like, how do we win? And, you know, being able to have some form of metric like that is helpful. I mean, it may not align perfectly for everybody and how they can impact that, right? Because they might be, you know, a degree or two removed from direct impact, but how can they help support it?

Okay. Uh, it's, it's a lot more difficult to actually execute that in practice when you talk about it. Because when I think about all the environments I've been in, you know, there's always was a business north metric. An overarching North Star. And, you know, in engineering and software development, you would like come up with these, you know, secondary word or proxy numbers, you know, you would still sort of find some type of OKRs you can give to the team and go like, look, you know, by doing this, you're going to be influencing it like that. And then it's just going to, you know, pull it towards North Star and everybody's pulling the same direction, but it always is quite challenging. You know, it's always like it needs it needs some like proper thinking. And I've been in situations where it's like, hey team, like come up with your own. And it just very rarely goes well. It really depends, you know, who's the team lead, how well matured the team is, that they come up with something which is like, oh, that's good. It's very often where you go like, you know what, I will help you. So here's what I'm suggesting. but then it goes against the notion of OKRs and ownership cuz you just gave something to them and in theory they should come up with something so they can, you know, be owners of what they come up with.

Right. And there's a lot of different frameworks for doing OKRs and how companies do OKRs and, and different metrics and things like this. Right. Like we, we have OKRs at, at Fullscale where it's like every department has different OKRs, you know, one's employee retention, one has to do with recruiting, you know, one has to do with training and they all have their own different goals and different things, right? And they don't necessarily all relate back to a single North Star metric, but they're all, you know, individual team metrics that everybody's kind of working towards as well. So in general, I think it's good to give people some goals. Some people work really well with goals and deadlines and, um, otherwise you're just drifting around, isn't it?

It's like, why I'm here? You know, what's my goal? What I'm trying to achieve today?

Yeah. And that's the hard part about business, especially like a really well-established business is you're always trying to figure out, well, how do we just get a little better at what we're doing? Like, you know, what, what is the biggest problem we need to improve at? How do we measure that? How do we figure out the goals and measure that? And sometimes that makes total sense. Sometimes it also feels like complete crap.

So, okay. That's the nature of it. It's the nature of it, right? It's just, yeah. Um, It's sometimes, not sometimes, when you experience different level of roles, you know, you go from like, hey, you know, I've been like a coder, I've been like a team lead, I've been like a manager, I've been like a manager of managers, hey, I became a CTO, maybe I CEO now. So you felt these roles and different flavors. And then when you reflect back, you know, it's a lot easier just to do tasks, like stress-wise, you know, realization of it. And it's just, you know, go get things. When you walk into like these all like outcomes, you know, managing people and working with people, it becomes a lot more difficult. And then you walk into owning businesses and then you suddenly, you know, in your hands, you have this responsibility to provide work and livelihood from, you know, multiple people, hundreds of people in your case, and it just becomes a total different ballgame. So yeah, everything becomes a lot more difficult. I wanna ask this, Matt, Can you give us like this scenario and how you would execute? So just from tactical perspective, let's imagine, you know, you coming into something like a maybe startup, it's a tech startup, or maybe you join a new business and then you look at the teams and you go like, you know, everyone is just a task doer, right? No one owns any outcomes. You ask closest person, they're like, I don't know. So everyone is just doing tickets. Like, how would you, you know, use your like first like 30, 60, 90 days to sort of come up with the plan, which someone could potentially copy right now and go and rethink how they do things to actually change that and get these teams into these outcome, you know, outcome thinking perspectives.

Well, so we know not everybody has the capability from personality or intellectual perspective or whatever, right, to be some leader or all these things. Some people are just task doers or like, hey, I follow a repeatable process. Tell me what to do, train me how to do it, and I will do it. Right? We have people all over the spectrum of these things. Right? But I think it starts with identifying who you have on your team and asking them the questions. Right? Like, how are things going? How can we make it better? What do you think we should be doing around here? Right? Sometimes just giving them a voice and listening to them. And seeing who speaks up, who has ideas, who seems to care, right? And then try to give those people more and more ownership and more and more responsibility and figure out the people that are, seemed really disengaged. Like they just don't really care. They just like, I give them things to do and they, you know, sort of half-ass do them. Yeah. They don't really care. And maybe that's okay. Maybe, maybe they have a role to play as well, but identify the people that can do more. They want to do more. Like they want to have more creativity. And there's a lot of people that are that way that have worked in larger companies where they just really haven't had that ability. You know, they've sort of been trained to, you know, follow the assembly line process of these big corporations, right? It's like some team somewhere made the big quarterly plan. The product team made the plan. They wrote all the PRDs and all the requirements and put them on your desk. Don't ask questions, go build them. Right? Like, and people get frustrated by that. So find those people that have been doing that for a long time that are frustrated. They want to do more. They want to be creative. They want to have ideas. Find those people.

So step number 1, find the people.

Yeah. And ask them how, how, uh, what they think they should do and lean on them and try and get them to do help, include them. And I think one of the things that is important is anytime you have some kind of product vision, uh, from a leadership perspective, you're always gonna be better off if you include everybody else in the decisions and get buy-in from the team. And because if everybody's always told what to do and why to do it, they never have the same sense of ownership or pride in their work. And so even if you know what needs to be done, mm-hmm, sometimes you can just rhetorically help get the team there and get buy-in from the team. Before just telling them what to do. You're like, I already know what we're gonna do, but I'm trying to get them all to come along and agree like this is what we need to do so that they feel like they had some opinion to it. Yep. Instead of me just telling 'em this is the way it is. And sometimes that can be really hard as a manager cuz I just wanna make a decision and go. Yep. But sometimes you're like playing a little bit of a psychology game with a team, right? You want them to come along with the direction. Hmm. And I have an example of this for you. So actually somebody recently, um, was talking to Fullscale about doing business with us. Really, really, really wanted to do business with us, but the owner of the company, or the CEO I should say, overruled him. Said, hey, we're gonna hire some software developers from this other company instead. And our advocate who was like the CTO, mm-hmm, was not happy. He didn't have no buy-in to the decision that the CEO wanted to make. And so now he doesn't want to do it. He's going to slow play it and he might probably sabotage it along the way because he didn't have buy-in to what was going to be done. And now this is like a higher level of politics that's going on at a corporate level. But it's important. The point is, it's like, it's important to also kind of have some buy-in from your team members. And this is like the perfect example where like, this guy is not happy that they didn't select Fullscale.

Yeah.

And went with another decision he absolutely despised, and now he's gonna kind of sabotage the whole thing. That's just the human nature. Like, as leaders, we have to get some buy-in with our team if we want them to, you know, take some ownership and carry the thing forward.

Fully agree with that one. So step 1, identify your champions. Let's call them like this. Yeah. Uh, second step to get them involved into decision-making. Probably you want to involve everybody, but sometimes people just like, leave me alone, I have things to do. So get your champions into that, make sure they have a say, or if they don't have a say, at least make it feel like they, you know, they part of making that decision. So that's step 2. And is there a step 3, or are we saying those are the core steps to start getting that outcome ownership?

So I think the hardest part about software engineering, and probably applies a lot of things, is figuring out how to support the team. How do you, how do you, how do I, how are you able to identify when they get stuck or when they're about to get stuck? Mm-hmm. And then how do you unstick them when they get stuck? Right? Like, yeah, I think that's one of the most important things as a leader is being able to know, like, are we making progress? Do I feel good with the progress? Does everybody feel like they know what they're doing? Or do they feel like they're stuck and they need help? And then I've gotta ensure they get the help that they need and keep them moving forward. And I think there's a lot of people that end up in leadership positions that don't necessarily know how to do that, or maybe they're not technical enough to do that, or they don't have the right relationship with the team to do that. So I think you get some leaders too that are just like glorified project managers and maybe they don't even know how to deal with those issues when they come up. But the, but the best leaders, I think, understand that really, really well. They understand what the teams are doing, what they're, why they're doing it, how they're doing it, all that kind of stuff. And they can sense when there's an issue and they can help them navigate it, keep them on track.

Yeah. Okay. So that, that would be number step 3 then, right? Identifying champion, involving them in decision making so they can own those decisions and the outcomes. And then 3, effectively having their back, providing the full necessary support along their journey of them owning these outcomes.

And that would be step 4.

Yeah. Step 4. There's step 4, right? I love it. Step 4.

Celebrate our wins, baby.

Oh, here you go. I love that.

Pizza and beer nights. Celebrate the wins.

Pizza and beer nights. Well, how do you celebrate on your end? Like, how do you do this with the full, you know, distributed and remote teams? How do you guys celebrate your wins?

I mean, it's of course just the little things of telling the team they did a good job, giving customer feedback, telling them the impact it had. This is what went well. Okay. You know, I think it's basic stuff like that. Yep. But when you can, it's, you know, of course when you can in person stopping to go have a beer or do whatever you want, spend time with the team, celebrate with the team. Like, I think that stuff's important, you know, week to week.

It's very important. Yeah.

Week to week, it feels like you're in the trenches, right? Like your head's down, you're working, you're grinding away. And then, you know, after 3 or 4 weeks, you can kind of pop your head up and you look back across the battlefield and you're like, okay, we, we've made some progress. Like we moved a couple trenches. Yeah, but it just never feels that way. Right. And I think it's important as leaders to stop and celebrate, like what we need to celebrate and acknowledge what we have accomplished. Okay. Because we are grinding, grinding away sometimes at a thankless job every day. Right. And we need to celebrate those wins and with the team. I think it's important that people don't spend enough time on it.

I fully agree. Recognition in general is a really essential piece of leadership. And when we talk about rewarding a behavior we want to see to, you know, growing and sort of flourishing within the businesses is how that's the easiest thing you can do. It's like someone is asking questions about the outcomes, great to recognize, great job, high fives, you know, or whatever is the easiest form. Someone goes back on the tickets, maybe you don't do that. Someone, you know, again, asks questions about outcomes. You do that. There's a retro, there's a night out, you know, maybe you raise a glass or give a toast and you talk about how everyone was thinking about outcomes and how it was different and it was great. That's effectively, as a leader, how can you just push that culture into existence when it comes to owning outcomes and not just doing tickets, not just being doers.

I like that you mentioned the word culture. You know, I feel like my book, Product Driven, is a book about engineering leadership and culture, which is weird to me because I'm not a culture guy. Like, if you would have told me 5 years ago I was going to write a book about engineering leadership and culture, I would have told you I was crazy. Um, that, that, that never is something that would have crossed my mind, but I think nothing is more important than leadership and having the right culture on a team. It, it, it really is important. And the best way to describe culture is really like, what does it feel like to work for you? Not even your company, but just you. What does it feel like to work on your team and work for you? And, and, you know, I, I think that's something that we should always be thinking about is like, what is it like to work for me? And, and what do I need to improve about that? And it is a lot of little things. It's what we reward. It's what we recognize. What we give attention to, how we react to things. Um, and most of us are not very self-aware. Like, we're very good of aware of other people's behaviors, but we're very terrible at being aware of our own behaviors. It's just, you know, blinders. Yeah. Yeah. But it's all the little things we do every day with our team. And the best way to summarize is it's just what it's like to work, what it feels like to work for you. I love that question.

That's a very good feedback-seeking question. Yeah. Go to your team and in your one-to-ones, just ask that question. What is it like to be part of my team? That's a great question.

And they will give you an honest answer.

Yeah. Hopefully you have that trust built already so you can give this beep, blah, blah, blah, beep, blah, blah.

So you bring up another good point. Like I'm also the person that in my career that never liked doing one-on-ones with people. I felt like they were a waste of time. I never wanted to do them. Okay. But I think they're also super important for what you just mentioned. It's about building relationship with the team, right? Like, can you ask them a hard question or a pointed question and they give you a real answer, right? Now, if you've worked with somebody for a while and you've built up a really good relationship with them, they'll probably be really honest with you. They'll be like, hey, this isn't gonna work and this is why. Exactly. Yeah. Maybe we should do this. Yeah. Versus like you don't have that relationship with you, they may not challenge you. They may not say anything. They may just, you know, take the most passive answer they can, they can give. Right. So one-on-ones are important and other things to build a relationship with people because ultimately that breaks down those barriers. So people will be more honest. And at the end of the day, that's what we need. Like, to me, software development has never been personal. It's just business. Like, It's not about calling my baby ugly. Just tell me, is there a better way? Let's go. Let's figure it out. You know, but people have got to be open and honest. Yeah.

I never seen any big question or any, you know, conflict-seeking question or anything that's very important, like elephant in a room type of question would be answered when there's a group around. Like if you have a super great relationship with your team and everybody's almost like friends and you've been together for years, then yeah, then it's probably, it's like talking with your mates, right? Like it's like 4 of us, everybody will be very candid and share things. But if you're in like a professional environment, it's just one-to-one where you can get those answers. Otherwise you're not knowing, probably you have blinders and yeah.

I have a couple of tips about that I think are really important from From a leadership perspective, you have to understand who's on your team and their different personalities, right? Like some people never shut up and they're always going to speak up in the meeting and you know those people. Yeah. And then you got people that don't say much in the meeting, right? Yep. And I write about this in my book and one example I give is like, not everybody's ready to like jump on stage and do karaoke in front of everybody. Hmm. They're just not, not everybody is built that way. Right. But these same people might have really thoughtful, great feedback in a one-on-one conversation or in a really smaller group setting. Yeah. And another example of this I see with my own teams at Fullscale, you know, if you, if you're using Slack or, or, or Teams or whatever you use, you have like different groups. You've gotta create really, really small groups that people feel comfortable in because you might have like 3 or 4 team members. That feel comfortable really talking to each other, but all of a sudden, if you join that channel, they aren't going to say much. Yep. Because they're scared of working in front of the boss. They're scared of the perception. They're going to say something wrong, whatever it is. And that's just the reality of it. And to me, that's super frustrating because it's like, hey, I'm here to help support you guys. How can I help? Like, I just want to help. Like, how can I help? Right. And but to them, they're like, whoa. I don't want, I don't want my boss to see all this stuff. It makes me nervous. It stresses me out. And so point is like just understanding that's just human nature. That's human nature and creating safe sort of spaces for your team members to work and collaborate potentially without you is also important.

Amen. So I have this before we move into rapid question. Uh, I'm very keen to understand how you guys use AI, right? So you have 300 engineers and full scale. Like, where is AI helping you? How is it helping you? And what are the plans for the future of just embedding more or less?

So we have about 70 to 80 different teams working across different clients. So it's all over the board and what we do in regards to types of tech stacks, the industry, the different tools that we use, if it's, you know, GitHub Copilot or Cursor. Lovable, or all these different things. So we have a wide mixture of it and it's really dependent on our clients and what they want to do. We also have full-scale ventures where we're, we're building 3 of our own, uh, SaaS businesses as well. Um, and we survey all of our employees about every 3 to 6 months to kind of see what they're doing and what they're using. And I was really surprised early on actually how many of them did not use AI, uh, partly because, and this was say 12 to 18 months ago, because the companies didn't want them to. The companies were worried about all the security implications and all that kind of stuff. Yeah. I think most of that is gone. Like now it's like over 90% of our employees are using AI. Like there's just a couple of holdovers that are still scared about the security part of it. Mm-hmm. Um, but also how many of the developers were kind of nervous about it. They're, they're worried about how it's going to affect their skills. They're like, you know, no different than somebody who's a writer or does any other kind of what they consider to be a craft or creative work, right? They're worried about how is it going to impact them long-term, their ability to do this job and this craft. So I think there's a lot of people that are still on the fence of that, how it's going to impact their career. But we, you know, we, as a whole, I would say we have more work to do than we've ever had done. Before. We are, we are still growing every month and AI has created more work for us than it has impacted really the number of developers. I don't think we've really seen much of an impact on teams having a lot fewer developers. Mm-hmm. Now most of our teams are small. It's not like we have 1,000 people and you're like, okay, we were able to get rid of 50 of them and get the same productivity, you know, at a massive scale. Maybe that's true. but in small individual teams, I, I don't think it's made that big of a difference. Um, I had the CTO of DX, the company DX, who is a developer experience company on my podcast. And, uh, she told me on average it saved software developers about 4 hours a week. That was the impact. And, but, but the news and the hype that we see are people rapidly prototyping things over the weekend and vibe coding things over the weekend, right? Like But I think what people have also learned is a big difference between like Vibe Coding and Vibe Engineering. And, you know, Vibe Engineering is what normal software engineers would use to help write stuff and do stuff, which people are doing at all differing levels, right? And then there's the Vibe Coding part of it that's really people that don't know anything about software engineering, but they're hoping they get something out of it that's going to work.

You can definitely, we had a great episode with, I want to say like an influencer type of persona who effectively builds ideas over the weekends, right? So he streams all of that process, which is just basically white coding multiple tools in a pipeline. It's around like 6 tools, you know, goes from research to AI, Everything's there, basically research, UX/UI prototyping, and then all of that getting translated to React code and then APIs and stuff like that. And then you put out, right? And he concentrates on this micro SaaSes, right? So it's like a very precise problem solution type of, and you can do that over the weekend. So that seems to be like where a lot of impact is, but to your point, when it comes to enterprises writing an enterprise software, and I work for a huge enterprise, we don't even use AI right now. Like it's just a POC, right? It's like a proof of concept to see if we can get some boost in like testing and stuff like that. Because the complexity around some of the solutions is just AI is just nowhere close to really tackle that.

It's great for little things though. Yeah, it's great for little things.

I do agree. Yeah.

Yeah. It's, it, you know, if you've got a project like, hey, I need to batch insert this in a database and it would be a pain in the neck to write this crazy merge query that would do this. Well, now I can go to AI and like 3 minutes later, it just gives me this crazy complicated query. Yeah. Before I might've spent like 2 to 4 hours figuring out how to write it.

Or, or here's a, here's a 3 hours, uh, you know, brainstorm between 9 individuals. Can you write me a PRD out of this? Boom. Done. That, that's a, that's something I love. Like that's, I mean, sometimes it misses details, so you need to, you know, sort of backfill, but there's a huge time saving in that. Just that, just writing documentations.

but those are little wins every day. That doesn't replace a whole, whole person's job to me. Yeah, it just makes it more productive.

Yep, exactly that. You just, um, yeah, you, I mean, yeah, you're just more productive. That means you're getting things done faster, but it doesn't mean you get, you have less things to do. I mean, my, you know, workloads are basically the same. I feel like I'm doing more, like I'm, my output is increasing, but it doesn't mean like, you know, I can. you know, go for a walk suddenly, like, you know, that, that space just getting filled with other stuff. Yeah. Yep. All right. So let's jump into rapid questions, Matt, uh, a minute or so per question. Uh, so we're just looking for some tactical stuff. In a daily standup, what should engineers report so the team stays on the outcome, not output?

I think it's more about what do they need help with? Why are, you know, why are we doing this? What do we need help with? How is this going to impact the customer? What to do, what not to do. Okay. Less about status. Should be more about, you know, driving technical and product requirements.

Okay. So we, we always go like, what would the customer say or something like that? Like just keep the customer in mind pretty much. Yeah.

But I mean, each individual work item, it's like just reporting status to me is kind of stupid. I want to know like, what's the next step? Okay. You got that done. What's next? And what do we need to think about that? You know, who needs to do what?

Tactical. All right. So it's not like, hey, I'm doing this one. I'm not blocked. Everything is fine. It's more like, hey, I'm working on this. And once I'm finished, it's this and that. And actually, you know what? Can you give me more? Because I feel like I get this all the time. Like in standups, it's always like, I'm on this ticket. I'm all fine. I'm not blocked. I'm just continue working. Is that like a good standup to you or that's a bad standup?

I think it's fine. But what I prefer is spending that time going to more nuanced details about like, okay, you did that, but what's the next step? How are we going to test it? How are we going to deploy it? Did you think about this? How well did you test it? Would you need to ask so-and-so to help you test it? Okay. Okay. What are you working on tomorrow? Did you talk to so-and-so about how we're going to do that? Do you have any questions? Let's talk through them real quick before you start on that tomorrow. Like, to me, it's more about, you know, shaping the work. Okay.

I get exactly what you're saying. That's how I prefer. Yeah. I get exactly what you're saying, Matt. So, uh, I got this one. Um, how do you take a mixed bag a mixed backlog, and when I say mixed backlog, I mean there's multiple different things going on, not necessarily like one feature, one product line, it's just a lot of different things. How do you take this into something which is an outcome-orientated backlog? Like what's your, like, do you have a way of sort of looking at the whole and going like, we're going to be doing this because it's going to be X, Y, Z outcome?

Well, if it's the backlog, I would probably just delete it.

Did the whole backlog just like delete? All right. Well, someone wrote it down.

I just delete the backlog. Let's go to the roadmap.

Forget the backlog. Okay. Well, give me a little bit more, Matt, because I'm like, I'm thinking I'm product owner. I've wrote all the stories. So, you know, I'm like, I'm not loving what you're saying.

So like, I, I write about this in my book and I do, I do write about this a lot on LinkedIn and stuff is I feel like people get so bent out of shape about the backlog, but I feel like that's where we've been, not where we're going. You know, like, okay, we need to focus on the roadmap. Like, where are we going? And the backlog is usually kind of the leftovers or the things we're not going to do, or it's the ideas that somebody had 7 years ago that's still on the list. Like, I'm just not a big fan of the backlog. I'm, I want to focus on the roadmap. Like, what are the most important things we need to do going forward? And the backlog always feels like the thing that weighs people down. They get so worried about, well, there's a ticket in the backlog. It's like, it's not on the roadmap. We don't really care. It's not a priority. All right. So it's in the backlog, whatever. I can't, I think it's so easy for people to get so wrapped around the backlog.

What about if the backlog is fresh? What about is a backlog for the next 4 weeks?

Then I think it's okay. Yeah. Then I think it's okay. As long as it's stuff you're actually going to do. It's when it's this long list of 100 things, you're like, well, we didn't do that and this bug and somebody asked this thing and like all these things and blah, blah, blah, and all this stuff. It's like, forget all this mess. Yeah. Okay. It should really be like that 2, 4, 6 weeks view. And if it's a bunch of mess past that, yeah, you probably, yeah.

If you, if you didn't touch that in like multiple months, you know, you just, you're probably not going to touch it.

And if it's important, it would come back.

It will come back and you would just read it.

It'll come back if it's important.

Exactly that. I got the same, someone gave me the same advice, uh, from leadership when it comes after come back after holiday to like hundreds of emails. And, you know, I was like, oh my God, you know, sometimes I don't want to go on holidays because I come back to hundreds of emails and it takes me pretty much the whole week after holiday to run back up, which feels like it defeats the whole purpose of a holiday. And sometimes it's just, you know, the smooth ride instead of having these peaks feels just better. And he was like, I don't know what you mean. Look what I do. Just select that old emails and delete it. I was like, How do you know if you didn't miss something? He's like, if it's important, they will send it again.

I was like, all right. Like, you know, sometimes it's the most practical advice like that that is like hits the hardest, right? And you're like, but he's right. If it's important, they will contact you.

Yeah, exactly. They will chase. I mean, you're probably going to create some lead time for the, for that person, but they will definitely chase if it's important.

100%. I'll give you another similar piece of advice I saw one day. It had to do with like text message and email both. You're like. If you're tired of getting so many text messages or email, the number one thing you need to do, stop sending text messages and emails yourself, right? Stop replying to people. Just go. Then they won't reply back to you. Stop messaging them. So what do you do?

You just call them? I mean, you still need the information. So like, how?

Okay. Yeah. Just minimize it as much as you can.

I get what you're saying, man.

Right. Yeah. You just minimize it.

Okay, let's go. Second one, not second one, third one. So you're doing a one-page brief or something, you're building a feature or something like that. What do you put in that brief so you start creating the outcome-driven language? Is it like success metrics? Is it some OKRs? Is like, what's your go-to to make sure that people don't just look at it as a task list?

So I, I think it's a little bit of a context, right? Why are we doing this? A little, a little bit of context about the why and the big picture I think is important. I think the other part of it is the trade-offs. It's understanding why are we doing it this way and not that way. Because as a software engineer, that's, that's one of the things you get frustrated about. Like, well, why are, why do they tell us we need to add this new database table when there's this table over here when we could have did this, right? Like you get very frustrated. Like, I don't understand why we did it this way. Doesn't make any sense to me. So if you can give them that, that, those trade-offs, it helps them understand like, okay, now I get it. Now I understand why this decision was made this way. And might, might make them a lot less, a lot less adversarial to the whole thing if they understand the decisions as well.

Okay.

So basically context, um, and the trade, understanding the trade-offs, like the decision-making behind some of it. Okay. Is really valuable. All right.

So if you're doing, let's say you're running like two weekly sprints, maybe, you know, cadence is a little bit different, but you're doing this, you know, retrospective. And let's imagine that the team are not part of like customer calls, you know, they're not really sort of getting that feedback. Like how do you fill that gap? It's like, what do you bring back to the team in a tangible way? Like, you know, data metrics. Maybe it's just the feedback, hey, customer X said this, but effectively, you know, the question is like, do you have any setup of like data capture which can just feed back into people and go like, here's how you're helping the customer?

Yeah, I think that's definitely a job of leadership all the way from CEO to engineering leadership to the product team. Like their goal has got to be like, okay, how do we get You know, not only insights from our customers about what to build, but you know, what are we doing a good job? What are we hearing from the market? Our last release we did a week ago or two weeks ago, how did it go? How do we give that feedback to the team? I think it's important that they take that extra, could be a couple minutes extra, you know, 5 minutes, whatever it is, to give that message to the team. And so for example, at Fullscale, we do that by, we get feedback from our customers every week. They're like, hey, I have, Jose on my team, he's doing a great job, yada, yada, yada. It's like, we gotta take time and go share that with Jose and share with the rest of the team. Like, kudos to the team. And it's just really important to just find those opportunities where you can give that good news and give feedback to the team.

It's really important. Okay. So I wanted to ask what's in your go-to-market type of plans, but now I, when you were talking, I realized that all of this basically goes literally up to the top and needs to come back from that top down to the engineers. It's like, Let's say, you know, you're a team, you build something and that goes to market now, you know, it's getting its release and everyone's excited. It goes to market and then you need to feedback to the team and go like, here's the outcomes which you just enabled or achieved. And that literally needs to come from whoever owned the go-to-market plans, you know, the leadership, because they're going to be talking with the customers. Maybe it's a sales team, maybe they're selling better. Maybe it's marketing team, you know, whatever it is that it needs to literally go up and back to the team.

Somebody's got to know it was important. Otherwise it's like, why do we do it? It's like, hey, we spent 6 weeks, we deployed this. Like, did anybody care? Like, if we don't even know, why did we do this? And if we do know, why don't we take the extra 5 minutes to tell everybody else what we know?

Sounds so simple, Matt. And then I reflect back on my own environment. I'm like, why people are not doing this? It's like— I don't know why it's so often, it's just a ticket and a task. It's such a dilemma, right? Such a dilemma. Well, hopefully we did unpack some details to our listeners today, which helpful. And you can, you know, go back to your teams and least amount what you can do is start asking, you know, why are we doing this? And what is the outcome, you know, with this work, which I'm doing, if people want to know more about you, Matt, how do they find you?

You can definitely go to productdriven.com, um, learn more about my newsletter, podcast, book, um, follow me on LinkedIn. I have 70,000 followers on LinkedIn. I, I write funny and insightful things on a daily basis there, so give me a follow there as well.

Oh, you got like a, some, some humor in your LinkedIn posts? Ah, sometimes. Sometimes. Real life examples with some spins. I love that. So we'll have everything, of course, in the show notes. Just scroll down and check it. Make sure to get Matt's book. It's an excellent book. Check his podcast and check all the links. And as always, guys, until the next time, stay safe and see you online.