From Output to Outcomes: A New Era in Tech Growth

Hey, what's going on everyone? Welcome back to Master and 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, five times founder, seasoned CTO and ACEO of Full Scale, a top one offshore development company on Clutch with over 300 engineer engineers. He hosts Product Driven podcast and wrote the best selling book, Product Driven.

Matt, great to have you. Hey, thanks for having me in Thanks for being let me be here today. It's. Going to be awesome.

So I'll kick off with this one. One 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, OK, so yeah, go. One, 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. Oh, I love that, I was saying. That the best of what you do and nobody knows.

Like it literally doesn't matter, right? The best known beats best every time. So best known that's ability to market yourself or ability to market your business, OK. So we're saying marketing is very important.

You mentioned sales as well. I mean, no business can survive. 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 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 I was saying then leads finding is more important than actual 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. OK, So just a couple of things there, Matt. So let me make this more difficult and say, if you, if you would choose one 1st 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 going to pick, OK? Like you got to be able to generate leads some way or another.

Lead generation. So what's your go to on generating leads for full scale? It's LinkedIn, it's social. 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 works pretty good. I love you. I love you mentioning a lot of cold out region LinkedIn, especially coming from 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 betweens.

I'm interested why they're doing this. I mean, you know, we, we sort of going on on a tangent here with the from, from the main topic of the episode. But like, what's your take? Why do you think they send these messages?

Because I would, I, I just, I'm having such a hard time seeing them, them closing anybody with 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. So anything they can do right is just start messaging people.

Just start messaging every person they can find and hoping what one in 1000 respond. Spray and pray, right? Literally. That's right definition.

It works. I mean, one in 1000 times you might get somebody, but yeah, it's. It's it's not what that yeah, we had the multiple episodes on LinkedIn business on on the show and great experts. And we had the full dedicated episode where we talked about the fact that building relationships, if your goal is to close deals and you'll 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 drought? You know, 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 AB testing and on paper, you going to be closing more deals.

If you do what it's called show me that you know me, which which basically has no automation. It has no reach out at scale. It's 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 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? What is? It, 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.

Excellent. I'll take that to your heart. I'll just ignore everything you just 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 a rejection or just pure grind? You 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 having SMAY that can help do some of it. You know, obviously I can still handle like the real conversations, but if there's SMAY that can help do some of those kinds of reminders or follow up messages or stuff would be helpful as well. But yeah, but 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 template of approach.

So I, I, I've been doing a lot of lead generation and with AI it's becoming easier to to craft something which resembles an actual human outreach. DM or an e-mail, right? Because you can effectively, you can do what is called enrichment of data. You know, you can look at people backgrounds, you can look at the websites, you can look what they posted and socials quite recently.

And you can sort of, you know, train AI to, to really talk as you talk and, and you know, write an e-mail like that. It's interesting what that's going to take. But I never seen anybody doing better than than something like 3 to 5% conversions when it comes to cold outreach. Like that's a very high level of the game and when you do that yourself manually, that they usually get like 70%.

Like, you know, you get the answer pretty much all the time because it's just people sense when it's people and people sense when it's called outreach. It's just something we really attune to I guess. Yeah, it's like two or three years ago, none of us had ever received really AI messages. Right now, all of us have an amazing radar for it.

It's just it's just feels so odd, but you have a sense like you look at some out output and you go like, yeah, that shit should be right there. It's like I have no 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.

Bullshit radar, 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 a task doers. And what we're saying is that this is becoming it's, it's coming close.

OK. So how to phrase this, it's not a absolute. I mean, there's still a lot of development to do, but with AI coding assistance and just coming in and, and if it's becoming better and better, the output itself of just writing pure code and getting tasks done that let that idea 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 ACTO or maybe developer realized that look, I should not be just thinking about what ticket like I need to get this done by thinking about what the outcome I'm action and enabling with this work. Well, I, 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, 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 full scale that transcribed our podcast like manually, like we didn't have a. Manually, right? Yeah. Well, now think like that job does not exist anymore.

Like 100% Riverside we're using here today perfectly transcribes it summarizes it right, like totally eliminated those jobs. But the jobs that 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 gonna 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 time stamps, which I had submitted that like that is gone. But that was sort of like really boring, mundane works, 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. OK. So we, Yep, but I think specific to software engineering it and really big companies, what happened is, is software engineering was always the most expensive and difficult part, right?

Like products can come up with like we want to build this thing now I got to go to the engineering team to get them to build it. And that was a slow, complicated, expensive thing, right? Like it's always been that way. And ultimately what happened is we built everything around the engineering team to try and get them 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. We don't want them to do anything else except hide in the corner and go write code. 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 downs over there writing a code. And AI is changing all of that. 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 got to you got to be a higher level in the food chain. Just like the example of like editing the podcast some you need to be higher level 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 what are we advocating here, Matt? So I was saying that if you are developer right now or, or expanding to more jobs and and you are, if you, if you remain in that space of writing code, you effectively add danger of getting replaced by AI. Is that, is that what what you're trying to say? Like, you know, people, not people, but like engineers should, should start thinking more of like what outcomes they enable with their work.

That then then just being like, Hey, I'm going to own this code like that. Like that's what I will, I will do. I'm just going to concentrate on code ownership. I'm not like I don't care what outcomes I'm, 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? Do 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, 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 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 got to, they've got to drive more of why are we building this thing and understanding why are we doing this?

And so in my book Product Driven, I talked about how clarity is the few 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 and I want to ask them. I need to check these requirements, whatever could be 1000 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, created 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. Tell them what to do right. 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.

OK. I think you describe pretty much the reality of like 99% right now of engineers because I, I, I think about my teams, I think about myself. That's literally what, what is taking place. It's it's a hand off process where where even in agile environments, there's still a lot of hand off process where you have apex of a product like PMS or product owners or some, 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 that that's given as a tasks 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. A.

100% what does that mean to actual? Then POSI was saying that they, they're going to get just sort of like if that's done well by engineers, if that role is not needed anymore, right? So they, they, they, they're just going to become obsolete then? I think the Product Owner role is going to have to, to change, 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.

You know, in some sense, you might describe myself as a product owner 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, 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.

OK, but then we have a, a product manager role is going to have to continue to change as well. But we still need product managers to reign everything in and figure out a strategy, working with engineering team to figure out, OK, what are we really going to do? We got all these ideas. You know, we 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 math? Because I'm thinking there's a pull and push mechanics, right.

So you're going to have some engineers who may be naturally a lot more product thinking or just incline to ask the why because they have a different level of curiosity. And then you're going to have engineers, which is going to be like, you know what, leave me alone. Give give my headset. I want to just put some good music and give me his task.

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 a a pull 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 going to have some people that on the team, like you said, they're just, hey, I just want to be heads down. Just tell me what to do and I'll go do it. And maybe they are just more of the worker bees on the team. And that's OK.

You need some of those. But you can't have a team of all worker bees. Somebody's got to 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 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? If you want everybody to be kind of involved. And the problem that a lot of companies is you'll have like ACEO 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.

OK. And that starts by effectively by empowering some of the team members, we agreed that potentially not everyone will be like this. Is it healthy to actually hire like this and go like, hey, like I know you're coded, but like, do you care about asking why is behind the product and use sort of like so? So I was saying that having a team full of worker bees and 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, I think ultimately 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, we're going to 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, the other big problem that we have. And, 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 or 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 here. Like I understand you don't like this code that's seven years old and you didn't write it and the other guy left three 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 OK. So, so we're saying, yeah, so that's a leadership element 100%.

Always remind the why. Always remind what impact are 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 of I'm a person who runs like scrum teams, right, like agile scrum teams, I'm writing tickets, I have the ceremonies like stand ups and planning and groomings and, and all this 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 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 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 Did it have?

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 5 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, OK, so I'm, I'm bringing So what I'm doing while plannings as as a any role.

I I want to say like a product owner, but let you know, let's imagine you're engineer, your team leader or whatever. You, you, you having a conversation with your team. So you're constantly asking, you know, OK, who's the customer? OK, what are they saying?

You know, what is the feedback? What, why are we building this for them? You know what? Yeah, what metrics?

So I'm driving that, that, that sort of conversation. So vocabulary takes place. Do I put things like that in the, in the actual work items which is affected like agile, you know, stories like, am I putting in like here's the outcome of the story. You know, acceptance criteria is about enabling an outcome rather than enabling some type of.

Effectively, what I'm asking about 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 stand up meeting or some kind of weekly planning meeting. However you want to do it of giving that additional context. And it could be written to, of course, in the requirements, like whatever makes sense for your team and the situation.

But a lot of times you're 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 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 is this need to be military grade, right? Need to perform, you know, is this for all customers or one customer? Like there's 1000 different things, right? And that context can help guide all of those decisions, right?

So that now they understand like, OK, I understand why we're doing this. I understand how it fits in 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're right, or you asked me a question, I'm going to 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? OK. How would you drive that clarity?

Explaining things in this daily standups everyday that's how I do it. I show up at stand up and I don't look at stand ups like so much like a status update. It's it's more of a technical requirements conversation and a higher level product conversation of like, why are we doing 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've 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 that's really taking in? Yeah.

So a couple of 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 got to message them, you got to tell them you got to schedule the meeting, like you got to be more purposeful in all of your communication, right?

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 for software engineering and really a lot of things in life, it's about collaboration. And just like you today, like I wouldn't be able to tell you something, stare deep into your eyes and no, are you listening to me?

And did you understand that or do you look confused right now? Hopefully 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. I won't be able to tell somebody something and feel like, do they understand? Are they paying attention? OK, important to me, it's yeah, it's definitely, it's definitely that.

OK, 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 maybe even more, which is a lot, you know, if the meetings like half an hour. So we're taking the majority of the time and you're like, you know, you're shedding good details and you're shedding what you believe are very important details.

And some of these needs to be sort of taken as a note and action, right? Then you're going like, yes, you know, let's action that. And then you go like doesn't want to have any questions. Silence, you know, crickets.

And I'm like, did you guys just, you know, we're 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 with the remote that's has a very common challenge I have in my daily life. So that's, 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, so I've got four members on my team and we have a project and like all four of them just work on the project.

I call bullshit. I don't like that. I want one person. Own this thing.

To be in control and doing it for multiple different reasons. But when you got four 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 1 owner on things. 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.

Second thing I was going to say is a lot of this just requires what we call courage at full scale. 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 going to push back or say, hey, you know, Mike, yeah, I don't really agree with that or it's not going to work because of this or yadda, yadda, yadda, right?

Like not everybody is going to have the courage to say those things. And when you go on your 5 minute monologue, not everybody's going to 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. I don't know what to do with that.

Yep, I'm not jumping in front of that. And everybody's going to have the courage of that, right? 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?

Right? Like you almost got to name somebody and and keep the conversation going. 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 shutting them down and telling them their idea is stupid or anything like that, right? You've got to figure out how to encourage people to speak up and reward them for speaking up, right? And having some psychological safety there, including like risk, like you want them to make decisions quickly and move quickly and, and you're OK with the risk, you know, associated with that.

It's about creating that kind of environment. And from a leadership perspective, you have to kind of model that and, 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 OK, we move fast, we break things.

We we learn from it, we keep going right. Like creating that kind of environment is important too, for people to want to move fast and make decisions. OK, I love that. And yeah, and everything is golden Nuggets while you're shooting there, Matt, pure leadership things.

I just, 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've come back now to to the voice of a customer, right. So taking a step back where we talked about how to actually get that culture set where 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 front end team who will be very close to that whatever reaches the customer as a product, right, because it's a front end layer, it's literally what the product sees, the customer sees the very first. Then you have a back end team, you know, let's say they do, they do APIs, right? So they will be behind that front end team. So they will be one level deeper away from a customer.

And let's say there's some type of like Devopsies database team or something like that. I don't know why it exists, but let's say it does. So they will be buried in a multiple levels away from a customer. So they will be doing their own things.

How do you get that depth of of a level of a team which are multiple levels away from a customer to actually think in those terms of asking the wise and the customer sort of outcome orientated thinking and. From a leadership perspective, I think it's just trying to make everybody understand how their piece applies, right? Like how how does what they're working on impact everything. It is a bigger picture.

And you're right, because sometimes it's like I had a friend of mine actually who is 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 after 20 years, you never thought about the customer. Like, what are you talking about? He's like, but that wasn't his type of work.

Like he was like very deep down into the nether as you kind of describe. 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 because 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 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, 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 of the business. And so from a leadership perspective, we just have to keep fighting that fight, keep being the drum. Why are we doing this? Making sure they're 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 back end, we're going to get this if that feature works very fast and the latency 0 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, is that like OK, RKKPI step of approach or, or you know, how, 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, if you're the guy that's like optimizing the code to save, save a little bit of money on, you know, AWS or something, it's a little different, right? Because it's 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, 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 4 minutes in the product, right? So you know, it 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, OK, that's a good one. So how do you get customer metrics is just by talking with the customers and going like, what do you care about?

Like how? Well, it's hopefully something your product helps with, right. So if it's a by product of something your, your product helps with. So for example, if you were building something we're talking about LinkedIn earlier that helps people find leads, right?

You're like, well, we track how many leads we help you find with LinkedIn. Yeah. So we know if you got more leads than our product is helping you and yada, yada, yada, right? So just trying to figure out a metric that makes sense.

OK. So we get this North Star metrics and then we go like we do like a big town hole, you know, as a leadership of business. And we go like everybody, we going to be doing this North Star metric. And some guys, you know, doing architecture, they go like so like like, yeah, you know, everything I do has no impact in this.

So, 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 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 and outcomes. I think for sure there's always good on 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, I'm giving up food to everybody else that 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? I, I think it helps just give a measuring stick because especially in a, in a early stage company, we all just want to 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 want to win.

None of us want to 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? OK, it's it's a lot more difficult to actually execute that in practice. But when you talk about it, because when I think about old environments have been in, you know, there's always was a business N metric and overarching North Star and you know, in engineering and and and software development, you would you would like come up with these, you know, secondary word, there are proxy numbers.

You know, you would still sort of find some type of OK Rs 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 towards N are and everybody's pulling the same direction. But it is always is quite challenging. You know, it's always is like it needs it needs some like proper thinking.

And I've been in those 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, that's good. It's 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 chaos and ownership because 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 OK Rs.

Now companies do OK Rs and, and different metrics and things like this, right? Like we, we have OK Rs at, at full scale where it's like every department has different OK Rs. 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 and everybody's kind of working towards as well. So OK. And generally I think it's good to give people some goals. Some people work really well with goals and deadlines and.

Otherwise it's just drifting around, isn't it? It's like why I'm here, you know, what's my, 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 and measure that? And sometimes that makes total sense.

Sometimes it also feels like complete crap. So. OK, that's that's the. Nature of.

It it's the nature of it, right? It's just yeah, 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 code that I've been like a team lead. I've been like a manager, I've been like a manager of managers. Hey, I became ACTO.

Maybe I see you now. So you've held 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 you just, you know, go get things. When you walk into like these old like outcomes, you know, managing people and working with people, it becomes it becomes a lot more difficult.

And then you work into owning businesses and then you suddenly, you know, in your hands, you have this responsibility to provide work and livelihood for, you know, multiple peoples, hundreds of peoples in your case. And it just becomes a total different ball game. So yeah, everything becomes a lot more difficult. I want to ask this that 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 maybe startup, it's a tech startup or maybe join a new business. And then you look at the teams and you go like, you know, everyone's is just a task. Do you 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 2 to 6 to 90 days to sort of come up with the plan which someone could potentially cooperate right now and go and, and what do you think how they do things to, to actually change that and get these teams into these outcome, you know, outcome thinking perspectives? Well, so, 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 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? Some of us 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 assed do them. They don't really care. And maybe that's OK. 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.

So find those. So step number one, find the people. Yeah. And ask them how, how 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 and from a leadership perspective, you're always going to 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, 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 going to do, but I'm trying to get them all to come along and agree like this is what we need to do. So they feel like they had some opinion to it instead of me just telling them this is the way it is. And sometimes that can be really hard as a manager because I just want to make a decision and go, yeah, 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.

And I have an example of this for you. So actually somebody recently was talking to Full Scale 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 them, said, hey, we're going to hire some software developers in this other company instead.

And our advocate who was like the CTO 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 in 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.

Like this guy is not happy that they didn't select full scale and went with another decision he absolutely despised. And now he's going to 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 one, identify your your champions, let's call them like this second step to get them involved into decision making. Probably you won't 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 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? And then how do you unstick them when they get stuck? Right? Like 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 got to 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 the 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. Yep. OK. So that that would be number Step 3 then, right.

Identifying champion involving them being decision making so they can own those decisions and the outcomes and then three, effectively having their back, providing the full necessary support along the journey of them owning these outcomes. And that would be step four, Step 4, right. I love it. Step 4.

Celebrate our wins, baby. Oh, here you go. I love that pizza. Celebrate the wins.

Pizza and be of nights or how do you celebrate on your end? Like how do you do this with the with the full, you know, distributed and remote teams? How do you guys celebrate your wins? I mean, it's it's of course just the little things of telling a team that a good job, yeah, customer feedback, telling them the impact it had.

This is what went well. You know, I think it's basic stuff like that. 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, 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 three or four weeks, you can kind of pop your head up and you look back across the battlefield and you're like, OK, we've we've made some progress.

Like we moved a couple trenches. Yeah. But it is never feels that way, right? And I think it's important as leaders to stop and celebrate.

Like let we need to celebrate and acknowledge what we have accomplished because we are grinding, grinding away sometimes at a thankless job everyday, right? And we need to celebrate those wins and and with the team. I think it's important that people don't spend enough time on. It's I, I fully agree recognition in in general is, is real, essential, you know, piece of leadership.

And when we talk about rewarding our behavior, we want to see you, you know, growing in and sort of the flourishing within the businesses is how that's the easiest thing you can do. It's like someone, someone is asking questions about the outcomes. Great to recognize, great job, high vibes, you know, whatever is the easiest form. Someone who goes back on the tickets, maybe you don't do that.

Someone, you know, again asks question 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. 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 and not just doing tickets, not just being doers. I like that you mention 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 five years ago I was going to write a book about engineering, leadership and culture, I'd have told you that was crazy.

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 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?

I mean, you know, I, I think that's something that we should always be thinking about as 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.

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 you. 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 that's a very good feedback seeking question. Yeah, go to your team and in your one to one, just just ask that question. What is it like to be part of my team? That's a great question and they only give you an honest answer.

Yeah, hopefully you have that trust build already so you can 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-one to people. I felt like they were a waste of time. I never wanted to do them.

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 like, Hey, this isn't going to work. And This is why exactly maybe we should do this versus like you don't have that relationship with 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 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 is a better way. Let's go, let's figure it out, you know? But people have got to be open and honest. Yeah, I've never seen any big question or any, you know, conflict seeking question or anything that's very important, like elephant in a room in a room type of question would be answered when there's a group around like, right.

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 then it's probably it's just like talking with your mates, right. Likes like four of us, everybody will will be very candid and, and and share things. But if you would like a professional environment, it's just one to one where you can get those answers. Otherwise you're not knowing probably how you have blinders.

And yeah. I have a couple 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? Yeah. And I, I write about this in my book and one, one example I give is like, not everybody's ready to like jump on the stage and do karaoke in front of everybody.

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. And another example of this I see with my own teams at full scale, you know, if you, if you're using Slack or, or teams, whatever you use, you have like different groups, you've got to 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.

Then all of a sudden if you join that Channel, they aren't going to say much 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 your rapid question, I'm very keen to understand how you guys use AI, right. So you have 300 engineers and full scale, like what ways are 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 the 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 three of our own SAS businesses as well. And we survey all of our employees about every three to six 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, partly because 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.

But I think. Most of that is gone. Like now it's like over 90% of our employees are are using AI. Like there's just a couple holdovers that are still scared about the security part of it.

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.

There are ability to do this job and this craft. So I, I think there's a lot of people that are still on the fence about 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 been done before. We're, we're 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. Now most of our teams are small. It's not like we have 1000 people and you're like, OK, we were able to get rid of 50 of them and get the same productivity. You know what 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. I had the CTO of DX, the company DX, who is a developer experience company on my podcast and she told me on average it saved software developers about four 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, I think what people have also learned, there's a big difference between like vibe coding and vibe engineering and you know, vibe engineering is what normal software engineers would use, 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 yeah, they're they're hoping they get something out of it that's going to work.

Yeah, so you can definitely, we had the great episodes with the with I want to say like an influencer type of persona who, who effectively builds ideas over the weekends, right. So he streams all of that process, which is just basically wipe coding multiple tools in the pipeline. It's around like 6 tools, you know, goes from research to AI. Everything's AI, basically research, you know, UX, UI prototyping and then you know, all of that getting translated to like React code and then you know, APIs and stuff like that.

And then you put out right and he concentrates on this like micro SAS's 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 and enterprise software, and I work for a huge enterprise, we don't even use AI right now.

Like it's just the POC, right? It's like a proof of concept to see if we can get some boosting like testing and stuff like that. Because the the complexity around some of the solutions is just AI is just nowhere close to the tackle. It's great for little things though.

Yeah, it's great for little things. I do agree. Yeah, it's it. You know, if you've got a project like hey, I need a 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 have spent like 2 to 4 hours figuring out yeah. Or, or here's a here's a three hours, you know, brainstorm between 9 individuals. Can you write me a period out of this?

Yeah, 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 left 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.

Yeah, exactly that you just, Yeah, you, I mean, yeah, you're just more productive. That means you you're getting things done faster, but it doesn't mean you you have less things to do. I mean, my, you know, workloads are basically the same. I feel like I'm doing more, like 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, right. So let's jump into rapid questions about a minute or so. Better question. So we're just looking for some tactical stuff in a daily stand up.

What should the 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, What's about status should be more about, you know, driving technical and product requirements. OK. So we will 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? OK, you got that done. What's next?

And what do we need to think about that, You know, who needs to do what? OK. 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 is this and that and, and actually, you know what, can you, can you give me more? Because I feel like I get this all the time. Like in stand ups, 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 stand up to you or that's a bad stand up?

I think it's fine, but what I prefer is spending that time going to more nuanced details about like, OK, you did that, but what's 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? OK, OK. What are you working on tomorrow?

Did you talk to so and so about how we're gonna 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.

OK, I get the exactly. How I prefer. Yeah, I get exactly what you're saying Matt. So I got this one.

How do you take a mixed backlog and want to say mixed backlog? I mean there's there's multiple different things going on, not necessarily like one feature, one product line is just a lot of different things. How do you take this into something which is a outcome orientated backlog? Like what's your like?

Do you have a way of of sort of looking at the whole and going like, we're going to be doing this because it's going to be XYZ 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.

I. Didn't delete the backlog? Let's go to the road map. Forget the backlog.

OK, well give me a little bit more math because I'm like, I'm thinking I'm proud of tone or 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 long LinkedIn stuff is I feel like people get so been out of shape about the backlog, but I feel like that's where we've been, not where we're going, You know, like, OK, we need to focus on the road map. 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 seven 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 road map, 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 ticket in the backlog.

It's like it's not on the road map. We don't really care. It's not a priority. So it's in the backlog, OK.

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 OK.

Then I think it's OK 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 Smay asked this thing and I got all these things and blah, blah, blah and all this stuff. It's like, forget all this mess. Yeah, OK.

It should really be like that 246 weeks view and if it's a bunch of mess past that. Yeah, you're 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.

It'll come back, but yeah. Exactly that I, I got the same, someone gave me the same advice 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, I 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, the, the smooth ride instead of having these pigs feels just better.

And he was like, I don't know what you mean. Look what I do, Just select that all 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.

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. 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 e-mail both.

You're like you're tired of getting so many text messages or e-mail. The number one thing you need to do stop sending text messages and emails. Yourself, right? Stop replying to people.

Just go there and then we'll. 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 OK you minimize? It as much as you can. I get what you're saying man.

Right. Yeah, you just minimize it. OK, let's go second one. No, second one, third one.

So you're doing a one page brief or something, you building a feature or something like that. What do you put in then brief? So you start creating the outcome driven language. Is it like success metrics?

Is it some OK artists? Like what's your go to to make sure that people don't just look at it as a task list? So 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 in 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, OK, 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. OK, so basically context.

And the trade, understanding the trade-offs like the decision making behind some of it, is really valuable. All right. So if, if you're doing, let's say you're running like 2 weekly sprints, maybe 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, like how do you fill that gap is 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 accept this. But the fact is, you know, the question is like, do you have any setup of like data capture which can just feedback into people and go like here's how you're helping the customer? Yeah, I think, I think that's definitely the job of leadership all the way from CEO to engineering leadership to the product team.

Like their goal has got to be like, OK, 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 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 full scale, 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, yadda, yadda, yadda. It's like we got to take time and go share that with Jose and share it 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 OK. So I wanted to ask what what's what's in, 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 you need to feedback to the team and go like, here's the outcomes which you just enabled or achieved.

And that that literally needs to come from whoever owned to go to market plans. You know, the leadership, because they're going to be talking about the customers. Maybe it's the sales team, maybe they're selling better, maybe it's marketing team, you know, whatever 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 six 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? Well, 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 is just a ticket and a task is such a 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 we're 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 can. Definitely go to productdriven.com.

Learn more about my newsletter, podcast book, Follow me on LinkedIn. I have 70,000 followers on LinkedIn. I write funny and insightful things on a daily basis there, so give me a follow there as well. Oh, you got like some, some humor in your LinkedIn posts.

Ah, sometimes, sometimes real, real life, real life examples with some with some spins. I love that. So we'll have everything, of course, in the show now. Just Scroll down and and check it.

Make sure to get Matt's book. It's an XNL book. Check his podcast and check all the links. And as always guys, until the next time, stay safe and see you online.