Today on The Rabbit Hole we are sharing an episode from Scaling Tech with Debbie Madden, who is the Founder and Chairwoman here at Stride. The podcast is well worth checking out and listeners can expect to hear some great conversations between Debbie and top tech leaders and experts on a wide variety of contemporary issues facing the industry. Here we are airing the chat that Debbie had with Josh Seiden, in which they cover the valuable idea of outcomes over output, a subject on which Josh has literally written the book! Besides writing informative books, and presenting his ideas at events, Josh works with teams to help them deliver products with the most possible value, and he is squarely focused on practices, processes, and culture. Tuning in, you will hear Josh give some great definitions around outcomes, how they relate to value, and how to approach working backward towards output from a base of value outcome. We also cover where to commit the majority of a team's efforts, facilitating efficient growth, and much more, so make sure to tune in to catch it all!
[INTRODUCTION]
[0:00:00] MN: Hello. Welcome to The Rabbit Hole, the definitive developers podcast, live in large in New York. I'm your host, Michael Nunez. Today I'm introducing a new podcast, and it's Scaling Tech with Debbie Madden. As some of you may know, Debbie is the Founder and the Chairperson at Stride. I remember many, many moons ago when we got the blessing from Debbie to start The Rabbit Hole Podcast and it was just three little bunnies, me, Dave, and William at the time doing our best to take our experiences and share it with the world. Debbie's now stepping into the ring, which is awesome.
She is an amazing person with a lot of experience and a lot of connections. Part of the reason why she wanted to build the Scaling Tech podcast is because like as of right now, due to the pandemic, there's not a lot of events that can happen or these spaces that exist for networking and collaboration. It's just a lot harder. She has an anecdote about 2019, where it was a time where there were all sorts of different tech events in New York and across the nation. Something that she had mentioned post pandemic. If we can't bring the tech leaders to the network, we will bring that network to the tech leaders, which I thought was pretty dope and a good way to summarize her podcast.
In the Scaling Tech podcast, episode after episode, you'll hear top tech leaders and experts in their fields sharing firsthand successes, failures, and lessons learned about the topics that are a high priority for today's tech teams. I think if you want to hear from high positions such as like the CTO or a VP, I imagine Debbie's going to have them on the podcast.
The episode that I wanted to share is with Josh Seiden, where they talk about outcomes over output. I thought that that would be relevant to us as software developer agilest, because there was a time where we were looking at output for things as opposed to the outcome of something. We always get excited about or actually in the past it was about the amount of lines of code that you wrote. We all know that that is not exactly measurable in a way where we can, whether it's actually successful for the business or useful for the user.
They break it down on like how do you look at outcomes and how to identify whether something is an output or the outcome of something. What I want to challenge folks is when they're given a piece of story or a task that needs to get done, take a second look and see like, what is the outcome of the task that's been given. Is it truly just removing lines of code or is it making, removing deprecated pieces of code or lookups to make the website faster or your application faster? Yeah. I'll now be sharing the episode here. When you're done over here, feel free to subscribe to Debbie's podcast, which will be provided in the show notes. I hope you enjoy it.
[MESSAGE]
Follow us now on twitter @radiofreerabbit, so we can keep the conversation going. Like what you hear, give us a five-star review and help developers just like you find their way into the Rabbit Hole and never miss an episode. Subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire William Jeffries and my amazing co-host Dave Anderson and me your host Michael Nunez. Thanks for listening to The Rabbit Hole.
[END]
[0:04:03] JS: Outcome is a particular kind of result. In my work, I've found that it's really, really helpful to be really specific about what we mean when we say an outcome. An outcome is a change in human behavior, that creates value.
[INTRODUCTION]
[0:04:19] DM: If you're a tech leader looking to learn today's best practices for leading high functioning teams, you're in the right spot. In each episode, we learn from today's top tech leaders as they share their successes, their failures, and their lessons learned along the way. I'm Debbie Madden, and this is the Scaling Tech Podcast, the blueprint for scaling tech teams. Let's dive in.
[INTERVIEW]
[0:04:41] DM: All right. Hey, everybody. Today, we are talking about one of my favorite topics. I don't know, Josh, if you knew, he’s one of my favorite topics, but we're talking about outcomes over outputs. I have the wonderful pleasure of talking with Josh Seiden today. Josh and I go way back, and he is many things, a wonderful human being, and a designer, a product person, an author, a coach. He works with teams to help them design and deliver products that people actually value, actually love, companies of all sizes, right? Not only with things about outcomes and outputs, but general culture practices and processes to help us all be our best.
He is the author of the book, Outcomes Over Output, which we are going to focus on today. Also co-author with Jeff Gothelf with the book, Sense and Respond and Lean UX. Two excellent books that are also near and dear to my heart. We're going to get into the mistakes that we all make when we try to really focus on outcomes versus outputs. First, I know you've been talking about this for a long time, but tell us briefly, what is so important – what is this idea of outcomes over outputs and why it's so important?
[0:06:07] JS: Yeah. Well, the fundamental idea is that you can make stuff, right, like making technology, it's hard. We spend a lot of time making stuff and it's hard to make stuff. That's the stuff that we make for this conversation, we'll call that output. You can make stuff that you think is going to deliver value, but it may not deliver value, right? It may be hard to use. People may not even want it. People may not use it. What's the point of making stuff that nobody uses or nobody values, right? What we want is we want to make stuff that people value. We call that value an outcome. The idea is like, let's really think about what are the things that people value? What are the outcomes that we're trying to get? Then work backwards to get to the output that we need to make.
[0:07:03] DM: Okay. Outputs are still in the equation, but they have to follow the outcome that we want to produce.
[0:07:09] JS: Yeah. I think one of the funny things that I never expected, so like, the book is called Outcomes Over Outputs. People think that somehow, I think that we shouldn't be making outputs, that outputs are evil in some way. It's like, no, the book isn't called outcomes, not outputs. It's outcomes over outputs. Let's just think about the outcomes first, right? You still have to make stuff and you have to be good at making stuff, and you have to make good stuff, but like, all of that is in the service of this higher-order thing, which is the outcome.
[0:07:48] DM: Yeah. I think it's so important, because that — people are very good at latching onto one thing. Oh, I get it, outcomes, outcomes, outcomes. Then they focus on that and minimize the importance of outputs, which are so important. I appreciate you bringing that up. I've seen that in my own work as well.
So where do we get it wrong? Right? When people listen to the Scaling Tech podcast, I'm talking to folks like yourself, and I really want folks to tune in when they're like, “All right, I've tried this methodology. I've tried to focus on outcomes, but I just get stuck.”
I think right now, today, outcomes and the idea of building things that are of value is so important more so than a year ago. The name of the game this year is efficiency, right, and really making sure that you are as high functioning as possible with your technology team. I think this focus on outcomes is a key linchpin in that equation. Where do we get tripped up? What's like, let's start with one. You had mentioned, and I want to drill into this, not actually changing the way that we work. Tell me about that.
[0:09:02] JS: Yeah. I mean, I think, outcomes is a way the technique of declaring the outcomes we're trying to achieve. We should probably start with like, the definition of outcome, that we're going to talk about, because I think one of the mistakes is that people use the word outcome to just mean results.
[0:09:27] DM: Okay.
[0:09:27] JS: Outcomes is a particular kind of result. In my work, I've found that it's really, really helpful to be really specific about what we mean when we say an outcome. An outcome is a change in human behavior that creates value.
[0:09:44] DM: Okay.
[0:09:45] JS: It's something that a user does differently, something that a customer does differently, or something that someone inside my organization does differently, that creates value for the user, the customer, the business.
[0:09:57] DM: When you say does differently, that could be as simple as placing an order?
[0:10:01] JS: Yeah. Right. People place orders today – 5% of everything that people put in the cart actually converts.
[0:10:13] DM: Okay.
[0:10:13] JS: Right? People put things in the shopping cart by making this number up. People put something in a shopping cart on our e-commerce site, but only 5% of those people check out.
[0:10:22] DM: Yeah.
[0:10:23] JS: Could we, over the next quarter, increase the checkout rate to 7%, to 10%, to 25%. That's a change in customer behavior, right, that we're targeting. That is really a very different definition of our work than saying, we're going to change the size and color and position of the checkout button. Right? Changing the size and position and color of the checkout button is output, we're going to make something. It might work like it'll work from a functioning software point of view, but will it work to deliver value? We don't know. Maybe the problem has nothing to do with the button size, shape, and position. Maybe the problem is, I don't know, the shipping prices, or maybe the problem is something else. I don't know.
The first thing that happens is that we want to be really, really precise. You're asking me about mistakes. First thing is, we want to be really precise about what we mean when we say an outcome. Okay, team, your job is to increase checkout rate or reduce abandonment, or whatever that is. The second mistake, though, is actually taking that seriously. That's really changing the way we work. What does it mean, right? Like you see that all the time with OKRs, right? People do – they spend all this time in the beginning of the year, and they write OKRs, and then they're just like, yeah, okay, whatever, business is usual, right? As opposed to saying, well, actually, what do we need to do to increase the checkout rate in the cart? Do we know why people are abandoning at a high rate?
We should go find that out. Before we just go ahead with, oh, we've got all this work in the backlog to change the size and position and color of the checkout button, right? We should actually do some discovery, and that might be a different way of working, right? To actually build product discovery into our process, right?
[0:12:28] DM: Yeah.
[0:12:29] JS: Or to approach the problem cross-functionally and say, “Well, maybe it's not actually a product problem. Maybe it's the way we're marketing our services, or the way we're pricing our products, or the way we're incentivizing, or fulfilling, or whatever.” Right? To really take – to really think about outcomes seriously, is to say, well, actually, to ask that question, what do we need to do to deliver this account? What do we need to change in the way we approach the work?
[0:12:58] DM: Then obviously, you don't know if you're right, right? I mean, it's when you're trying to figure out how to change the way we work, to deliver the outcome, you may be right, or you may be wrong, or you may be less right than you thought you were, right? There's all sorts of change of gray in there. Oh, if we do this thing in the double X, but you might only increase X by 10%, right? I think this is where we loop in the iterative nature of this, right? We define what we want to change to deliver the value.
Then we also have to iterate on it, right? As we're learning more and moving towards the future, okay, well, we thought it was going to double at a 10%. We have to then go back and say, “Well, what else do we want to change or what do we want to change different?” Right? This idea of just, because you think you have a hypothesis, you might not be right.
[0:13:59] JS: That's right. That's such a critical component. That being able to iterate and being willing to iterate, right? A lot of teams are measured, their performance is measured by velocity, right? How many stories do we push through this system? To have to go back, it breeds a culture that hates rework, right? If we already – we already fixed the cart, Josh. Why do we have to fix the cart again?
[0:14:35] DM: Right.
[0:14:40] JS: If the mandate is over the next quarter, we're going to raise the checkout rate from 5% to 25%. In our first sprint, we push something out there and then we measure it for a couple of weeks and it's good, but not great. We want to be able to take another crack at it. Another crack at it, and we want to keep taking those cracks at it through the whole quarter. We want to keep updating and being transparent about our progress and what's working and what's not working. That's a very different conversation than saying, “Oh, here's our velocity for this quarter.” Right? Your velocity is probably, I mean, depending on how you think about it, but the number of features, the number of new features you work on, is not going to be the measure. It's going to be the effectiveness of those features. That may mean that you need to work on them over and over again.
[0:15:35] DM: I think one mistake or one roadblock rather than a mistake. One roadblock that I see teams run into here is you run into, if the second you align yourself with business value, which is an outcome, the second, then you are now in this conversation with stakeholders that sometimes have a different level of agile fluency than the team building the feature, right? Not always, but most of the time, right? The stakeholders haven't did like a lower level of that, not always, but lower level of agile fluency than the team building towards the outcomes.
Then this idea of having that autonomy and that comfort to iterate, while also managing up. I think we get – it's not necessarily a mistake, but we get stuck with this. Oh, we're agile. We're iterating. We know that we're going to look every two weeks and see how we're doing, but there might be these external factors driving us towards a different outputs instead of outcomes like, get it done by this date. The carton must be released by this date. I don't care if it works or not. I just need it.
Again, I'm overgeneralizing for the sake of making a point, but how do we get around like, how do we communicate the value of the outcomes and iterating towards them once we have to come in reality with the other folks at our organization?
[0:17:12] JS: I think we're used to a conversation and we built a conversation with stakeholders that is built around features and milestones, right? We're going to have this feature on this date, right? If it's going slowly, then we've trained our stakeholders with this concept of like, look how fast we're going, look at our velocity.
[0:17:37] DM: Right.
[0:17:38] JS: There's just a lot of work here in the queue, right? We're getting on this feature, we're doing this feature, we're getting it by this date, our velocity is this good. That conversation really has nothing to do with, are we achieving outcomes, right? It's not that that conversation is useless. It's that there's a different conversation that we have to have along with it. The different conversation is, okay, stakeholders, we've agreed that our target for the quarter is this 25% number. Now, we're going to keep you posted on our progress every week. That progress is, oh, look, we put this thing out, we think it's going to bump our numbers. Oh, look. Look at the numbers we've got this week, we've grown by 2%. That's not good enough. We're going to keep going. Oh, look at this. We've grown by 10%. That's great, but that's not what we said we were going to do, so we're going to keep going. Oh, we made this change and we actually regressed, whoops, right?
There’s a kind of – you have to keep this line of communication open to demonstrate the fact that you're actually navigating through this unknown, right, this territory where we don't know the answers, but look at how good our team is at finding the answers.
[0:19:05] DM: Right.
[0:19:07] JS: That's the story that we want to be telling. Look at how good we are at finding the answers. Rather than, look at how good we are at building stuff.
[0:19:12] DM: Right.
[0:19:14] JS: This is important, but –
[0:19:15] DM: This goes to, I think, a thing that trips people up, which is that conversation around how we prioritize and commit to work, right? It's not that the conversation needs to be different, it just needs to be or it ought to be in addition, right? Because there are external factors of the team, of the product, of the organization, right? Things in the marketplace might change, things in the industry might change. All that being said, it is that continuous look into progress towards the value that the team is committing to, right?
I think this goes back to over the last 10 years. There's this ongoing debate of what are agile teams committing to stakeholders? Are we committing estimates? Are we committing throughput? What are we committing? This idea of, we agreed that this goal of 25% from 5% is what we're marching towards. We might get to a point where 10% is good enough or not good enough for the next six months, but might then become second priority to something else, right? It's an evolving, ongoing conversation, but we always have to think about the outcomes that we're driving towards.
[0:20:46] JS: Yeah.
[0:20:47] DM: How do we make sure that we are committing to the right work or as close to possible?
[0:21:00] JS: Yeah. I mean, I think that – well, okay, so I guess one thing I should say here and maybe this is – I'm not exactly answering your question, but I'm going to get to your question I – but one thing I should say is that thinking about outcomes and prioritizing outcomes is really, really valuable. It's a really useful way of working when we don't know the answer, right? Like when we're trying to do something that we don't exactly know how to do it like, check out rates here at 5%, and we need to grow them to 25%. We don't know how to do it, right? But there's other categories of technology that we just have to do.
[0:21:47] DM: Right.
[0:21:47] JS: Right? You've got to – okay, we're going to move from this data center to that data center. Okay, we can talk about some outcomes in that scenario too, but like, or we have to, there's this new regulation, and we have to do this work to comply with the regulation. There's very little uncertainty there and in those kinds of scenarios like, being feature-based can be okay, right? Committing to work and saying like, we're going to turn off the old data center on this date, so we have the new data center fully operational on this date minus X, so we can do whatever we need to do.
There's certain kinds of work that it's fine, but for working, we really don't know the answer, right? That's actually an important piece of the conversation with our stakeholders, so if these stakeholders are saying, “Well, we need you to rebuild the shopping cart.” Okay, why? Why are we rebuilding the shopping cart? We could do that, but why are we doing it? Like, how will we know when we've rebuilt it correctly, right? The answer isn't that we need to rebuild. Actually, most of the time in those scenarios, we don't need to rebuild the shopping cart, right? What we want is, oh, well, we've got a problem with the checkout rates here. We've got high bandwidth rates, low checkout rates, but that's the problem that we want to be working on.
In those situations, being able to have that conversation that transforms the contract that we're making with our stakeholders, whether that's a formal contract in a consulting situation or an informal contract internally, we want to be talking about the uncertainty, we want to be talking about the problem and outcomes give us a way to do that, right? That conversation should start when the initiative is chartered, right? It's all about saying, “Well, what is the uncertainty here? How will we monitor our progress?”
[0:23:51] DM: Right. Really make sure that you – I mean, literally ask the question. What is the uncertainty here? Because even if there is no uncertainty, then you'll draw, oh, there's very little uncertainty here, right? It would be confirming to hear that. If there is uncertainty, even if we can't quantify how big that uncertainty is, the fact that we understand that we're going into uncharted territory is really important to have at the start of like you said, the formal or the informal contract. I think that's key, right?
Then what happens, I've seen this happen, I'm sure you've seen this happen, is the people move fast these days. In their head has connected one to dots and said, “I need you to rebuild the shopping cart.” Then if we're thinking about outcomes, we might start with, “Okay, what's the uncertainty here?” Uncover that it's really percentage of people converting into buyers and to customers. Then you follow up with the question of, “Well, what would you say if I can increase that percentage without redoing the shopping cart? Is that still the outcome that you're looking for.” Right?
It's almost like teasing apart like, “Okay, is this what you think needs to happen? What if we can make your outcome happen without doing the out?” Right? Almost challenging folks to pull apart those two things, I think is really a key way to unblock us from focusing on the work versus the results like you said at the beginning. Is that making – am I on track or am I off?
[0:25:43] JS: Perfectly. Yeah. I mean, Jeff Patton. My friend, Jeff, who is I think, is always really, really clear about this. Jeff Patton says that our goal is always to achieve the maximum outcome with the smallest amount of output possible, right? How do you make sure that the scale you're doing this, the little bit, the plentiest amount of work to achieve the maximum result? I think different stakeholders – listen. I've rarely met a stakeholder who will talk to you about their uncertainty, right? Leaders get to a place of leadership by projecting an image of certainty. If you ask them, “Are you certain?” They're like, “Hell, yeah. I'm certain. What are you talking to me about?” But –
[0:26:34] DM: Yeah, I've been known to say that. Yeah, I’ve been known to say that myself.
[0:26:38] JS: Yeah. Right. Of course, I’m certain. I've figured it all out in the shower this morning. I think talking to like sometimes stakeholders will be really, really interested in talking to you about risk, right? Uncertainty is really like, that you can talk about it that way. What could go wrong? What are the things that we don't know here that could cause this project to fail? That's one way to talk about the uncertainty, but the other way is to, is to talk about it in terms of exactly what you're saying. What if there was a way to do this same thing, get this benefit with less, right? Could we do it with less?
We had a client – I had a client that I worked for eight, oh, my goodness, eight plus years ago now. They were not a big budget client. They were small organization and they were trying to build a new digital marketplace. They had built out a really big list of requirements for this two-sided web-based marketplace. It was like a, whatever, the details of it are not super important for this story, but we came to them and we said, “How will that marketplace is working?” They said, “Well, we've got this many of this side of the market on the marketplace. We've got this many of this side of the marketplace. We've made this many transactions by this gate.” They had a six-month deadline. They had to get this marketplace up and running.
We said, “Well, if we could get all of those transactions happening without a web-based marketplace, would you be okay with that?” They said, “Well, no. We're coming to you, because we need a web-based marketplace.” We're like, “Okay. Okay, good. It has to be a web-based marketplace. Clear. That's a minimal. Now, if we could do it without these features, would that be okay?” They were like, “Oh, yeah. If it works without that, it's fine.” We said, “If we could do it without this, would that be okay?” They're like, “Yeah, we could do it without that. That would be fine.”
In the conversation, we started to say like, “Okay, what's the focus?” The focus was onboarding like a thousand of, I don't remember the number, but onboarding X amount of these people on one side of the marketplace, onboarding a wide amount of these people, and transacting X number of transactions before those six months and that was a super effective way to manage that project. It really, really – it helped us and the client be really scrupulous about their spend, because really, they had a very limited budget.
[0:29:21] DM: Right.
[0:29:22] JS: None of us, none of us wanted to be spending time building features that weren't going to deliver value for that.
[0:29:29] DM: Right. Absolutely. That's a great story and a great way to think about the framework for having the conversation starting about risk, then diving into this idea of how ought we might achieve the outcome through different paths, right? If you will, right? That's what I heard that you helped. That's what I took away from that story. One last question that's on my mind that I want to bring up is 90% of the problems are people problems. Not only when it comes to outcomes, but other things as well. We've talked about changing the way we work. We've talked about how we talk about what we're committing to. We've talked about building up those agile muscles.
The last thing I want to dig into is how do we think about the way we organize our teams? Because this whole concept to me is amorphous now that a lot of people are on teams yet working remotely, not everybody. I know some people are back in the office full time. Some people are part time, but I think the concept of organizing teams is complicated by the fact that many teams aren't in person all the time anymore. How do we make sure that we're organized in the either the optimal way or the good enough way to make sure that once we have all the best laid plans, we can actually – our organization isn't a roadblock. How do we think about that?
[0:31:23] JS: I mean, I think one of the challenges and this is a – one of the challenges with outcomes is that we're changing what teams are responsible for. I think, if you think about it as a, one of the ways that it would be possible to organize a team would be to say, you all are responsible for this part of the website or this part of the product, this feature, this feature, this feature, this feature, right? Like the analogy would be a car assembly line, right? You all are the tire people, and you all are the wheel people, you all are the axle people, and you all put it all together, right? You've got four teams there, right?
Instead with outcomes, we're saying, okay, people are not checking out, just to go back to this example we've been using this whole conversation, right? Check out rate is low, okay? Your team wants that problem, okay? What do you work on? Is it the shopping cart? Is it the landing page where you tell people how great your shipping policies are, right? Is it your product information page where people put things in the cart? Like where's the problem? How do you own that across a large product? That's not an obviously easy problem to solve, because we're giving people a mandate that might cut across lots of parts of our product.
When we talk about organizing the teams, we really need to think about how do you organize a team that is responsible for a customer journey that might have responsibilities that touch lots of different pieces of the product and give them permission to go do that. That's a challenge with the way we organize our teams, but it's also a challenge with the way we architect the product. You'll see teams that – I've seen teams now that are working towards that, that are having these B tier organizational structures, where teams are building, some teams build basic capabilities.
I saw – I don't know if they're still doing this, but I heard a presentation a few years ago from USAA, right, the, the bank. They have a layer of teams that work on capabilities like credit checks or interest rate calculations or things like that. Then they have another layer teams that are working on things like customer journeys, right? You might have a mortgage team or a car loan team or a home refi team. Those are stringing those tables together. It's a non-trivial problem, right? But it's definitely different from the way we organize teams today.
[0:34:35] DM: Right. I I've heard you mentioned organizing teams around customer journeys. I've also heard, I think it's identical or maybe adjacent organizing around value streams.
[0:34:48] JS: Yeah. I think it's a, it's a similar idea, I think.
[0:34:51] DM: Similar idea. I think one of the things I've seen present a real problem is when in bigger organizations, when part of the organization wants to organize in this way and other parts do not and will not. Then you're in the situation where I want to really solve this customer journey or this value stream. I only can see 60% of it. The other 40%, I know it exists and it's thrown over to me when it's ready, but I can't see inside that box. I think we don't have tons of time to dig into that thoroughly, but I'll just zoom out and say, I think it's so critically important to really think about how you organize your teams, either good enough or ideally, so that you are mapping the pods, the scrum teams, the customer journey teams, however we want to call them, so that you are at a minimum, not adding overhead.
There's – like nothing is going to be perfect. Again, the bigger the company, I think the harder this is, right? Like, you and I have both seen, oh, we're reorging into business units, we're reorging across specialty. Then these big companies go through these re-orgs and it's painful, it's messy, and sometimes it's not possible at all, right? Sometimes it's just not feasible, but the takeaway, thinking about it and raising that question and trying to organize the teams around customer journeys. Like, would that get us part of the way there? Like what else –
[0:36:48] JS: Well, I don't think you're really missing anything. I just think that like at that point, you've got like, there are organizational problems that stand in the way of using any method you can name.
[0:37:03] DM: True.
[0:37:03] JS: Right? This is the thing you're talking about now. It's like, well, it doesn't really have anything to do with outcomes, it doesn't really have anything to do with agile, it doesn't really have anything to do with anything, except like, the organization is not aligned in their vision of what they're trying to do. It got pieces of the organization fighting each other.
[0:37:29] DM: Got it. Got it. Yeah, I know, that's a fair point, so let's back up and end where we started, because I do think that organizational company, organizational road let me say that again, the way that companies organize themselves is a factor that could be a real headwind or could be like an asset, right? It really is important and yet also it's off to the side. Circling back, I think my biggest takeaway is outcomes are something that we've been talking about now for many years. They're more important now, I think than ever, when the name of the game at company growth is efficient growth.
The best way to get there is to focusing on outcomes that really starts with identifying what behaviors you want to change in the way you work, making that work visible and iterating towards the outcomes that you seek, whether or not you are certain or uncertain about them. The more uncertain there is, the more important and outcome driven approaches. Then really thinking about how we change the conversation around how we commit to the work that we're putting in and delivering. That's like the sum up for me. What's your final thoughts on this? Like, what takeaways –
[0:39:06] JS: You should write a book about this, Debbie.
[0:39:10] DM: Maybe I will.
[0:39:12] JS: Yeah. I mean, I think you captured it really well. I think for me, one of the great missed opportunities in our industry. We spend a lot of time working on software that doesn't deliver any value. The opportunity cost to that is really high.
[0:39:28] DM: Yeah.
[0:39:29] JS: To me, the question is, how can we learn to get better at building stuff that delivers value? I think that there are a lot of ways you can think about that, but for me, I think having teams that can think about identify and then iterate their way towards these outcomes is a way of trying to capture back some of that opportunity cost.
[0:39:57] DM: Absolutely. Absolutely. Well, Josh, it's been, as always a pleasure. I appreciate your time. Thank you so much.
[0:40:06] JS: Thank you, Debbie. Always great to talk to you.
[0:40:08] DM: All right. Take care.
[OUTRO]
[0:40:10] DM: Hey, everyone. If you've enjoyed today's episode, remember to subscribe. Give it five stars and more importantly, share it with someone that you think will benefit from listening. Remember, as always, think about the one to two key takeaways that you can apply today to help you and your team achieve your goals. Until then, keep iterating.
Scaling Tech with Debbie Madden
Outcomes Over Output with Josh Seiden
