263. The feature factory trap: when output doesn’t equal progress

Why do so many software teams feel busy — but deliver so little value?

Fractional tech leader Thanos Diacakis shares why shipping more features doesn’t always mean progress.

Drawing on 25+ years in software — from startups to scaling JUMP Bikes at Uber — he explains how to escape the trap of over-planning, feature overload, and technical debt.

Listen to learn:

• Why planning more often leads to less progress

• What non-technical leaders need to ask their tech teams

• How to find your team’s bottleneck (and why that changes over time)

• The 4 stages of becoming a high-velocity software team

If you’re a founder, product leader, or innovation exec frustrated by slow progress, this episode will give you the mindset and tools to course-correct.

Follow Thanos Diacakis on LinkedIn and on his website. 

Chapters

02:01 — Stop planning, start shipping

06:16 — Software isn’t construction: you can’t forecast innovation

09:58 — The 4 stages of high-velocity teams

13:56 — Spot the bottleneck, fix the system

20:11 — How business and tech teams can actually work together

FREE Course: 5 Tech Concepts Every Business Leader Needs To Know https://www.techfornontechies.co/freecourse

Growth Through Innovation

If your organisation wants to drive revenue through innovation, book a call with us here.

Our workshops and innovation strategies have helped Constellation Brands, the Royal Bank of Canada and Oxford University.

Listen to Tech for Non-Techies on:

• Apple

• Spotify

• YouTube

• Amazon Podcasts

• Stitcher

• Pandora

Transcript

Speaker 2 (00:00.046)
If you ask a contractor to make you a bathroom, there is like six ways you can make a bathroom. And as elaborate as that bathroom can be, there's gonna be a toilet, there's gonna be a sink, there's gonna be tiles or a wooden floor or carpet or whatever you can do, but there's only so many ways you can do this. With software, the equivalent would be we're gonna make a room that we don't know what's in there and the laws of physics may also change.

Welcome to the Tech for Now Techies podcast. I'm your host, tech entrepreneur, executive coach and Chicago booth MBA, Sophia Matilda. My aim here is to help you have a great career in the digital age.

In a time when even your coffee shop has an app, you simply have to speak Turkish. On this podcast, I share core technology concepts, help you relate them to business outcomes, and most importantly, share practical advice on what you can do to become a digital leader today. If you want to a great career in the digital age, this podcast is for you. Hello, smart people. How are you today? In this lesson, you're going to learn from a techie.

and his name is Thanos Stiakakis. And he has been in senior engineering positions and he's worked with early stage companies and with tech giants like Uber and Included Health. And I wanted to bring his perspective to you so you can hear what engineers need from the business side to build great things. And you know, I've noticed that on the business side, we sometimes make life difficult for our colleagues on the tech side and we inadvertently delay our own projects.

So I'm hoping that this episode and this show in general is going to help you not do that. This episode is obviously great for non-technical founders and also for business leaders in corporates who want to build apps and sites and algorithms and generally digital products that require working in harmony with your engineering team. And if you enjoy this episode, my dear smart person, please leave the show a rating and a review. It really does make a difference. Thank you so much. And now let's learn from Thanos.

Speaker 1 (02:01.71)
Thanos, when somebody is making a new tech product like an app, when should they start doing and stop planning?

they almost always should stop planning and start doing. There's very few cases when you want to do the first thing that you want to do is be planning. There is a little bit of thinking through ahead. There's nothing that says that you can't think through what you're to do and get a little bit of foresight and figure out what you're going to do. But most of the time you're to learn a lot more by actually doing what you're supposed to be doing than just thinking about it. I used to, go ahead.

No, this is, find that people, especially people who've been through business school or people who've been through corporate or even people who've been through business accelerators, they just tend to get stuck in planning and essentially they're producing sort of McKinsey style reports instead of making anything. And this is why I really want to emphasize your point. So where have you seen this go wrong when people are doing too much planning to their detriment?

Yeah, there's a couple of ways that I've seen this play out. The one common scenario that I've seen and I'm thinking of like a recent team that I was in where we did this all the time is that the team has an annual planning session and it was always there and we take the best and the brightest brains from the company, take them away for like about a week. Maybe we even fly them in if we were all remote and we stopped doing actual work and we start thinking about what we're gonna do for the next year. And they spent the whole week making all these elaborate plans and then we go back

And then nothing from these plans ever materializes. Everyone just go back to doing their work as it was. And some people get demotivated by that, right? It's kind of, we spent all this time and we didn't do all these things. And then when next year comes around, we're going to do the same exercise again. Exactly. And in this particular place that I was at, it was particularly dysfunctional because every year we would do this and what we execute would look completely different. Like we wouldn't even get to like 10 % of what we did.

Speaker 2 (04:00.96)
And you get in this like haggling mode where we'd say, okay, well, could we do this? Could we do that? what if, you know, this task like too long, could we do this in a little bit less time and just construct this thing that you know you cannot execute. So it's usually a lot more interesting and it's going in and doing stuff. Now there's usually like good reason, not good reason, there's usually like an explanation of why this happens, right? Is people are not like dumb and they just want to do work for no reason. But often what I've seen is that you will go in and actually

another project comes to mind where this exact thing sort of happened, where the leadership had an idea of what they wanted to build. So they said, okay, let's build this thing. They handed it off to the tech team and the tech team went away for like a month. And then they come back and it's like, here you go. And the leadership is like, no, no, no, no, this is not what we wanted to happen. this is not what I wanted and that's not what I wanted. So the tech team goes back again and it sort of tries to fix this. And after two or three cycles of this, we may get what we want with a bit more bugs.

and not exactly what happened, what's happening. So the next time that we did this, that the leadership team was like, okay, now we're going to make like a really detailed plan. So we're going to like take this project, like we're breaking it, break down every screen and every button. I'm going to tell you exactly where to put it. and you can see where I'm going with this, right? This never actually works because you don't know, like every software project or 99 % of several projects are new. No one has ever built anything like this before. So when you try to plan it ahead, you don't actually know what you're doing.

So we need to like take a step back and figure out how to set up the team in a way that we can do, learn, do, learn and kind of have these really rapid feedback cycles where we can be able to execute first. And once we get the ability to execute, then we can go ahead and start planning bigger and bigger, bigger chunks. But if you try to plan first, that usually just ends up in tears.

The issue, I think, with convincing people that, we need to do more quickly is when they're making investment decisions. know, either when they are going to the CFO in a corporate and saying, give me money for this, the CFO wants to see a plan, right? Or when they're fundraising or, you know, even with their own money, if they're investing their own money, they do, you know, they ideally want to be thinking, okay.

Speaker 1 (06:16.878)
I have three months and in this three months I'm going to do this. I would assume that unless you actually own an oil well, then you probably need to have some sort of end to your runway. What do you say to that?

That is a tough spot to be in because a lot of the times the answer is, sorry, you cannot have that. And that sounds really tough, right? If you go to someone and say, hey, you're gonna spend this amount of money and I can't tell you what you're gonna get, that's a really, really hard pill to swallow. And I'll give you the alternate version of this that I think usually works better. But I can sympathize, right? Someone wants to know what you're doing and how long it's gonna take you and all that. But with software, typically,

there are a lot more degrees of freedom that we have in many other industries. And I don't think we really got in our head around this, right? If you ask a contractor to make you a bathroom, there is like six ways you can make a bathroom. And as elaborate as that bathroom can be, there's going to be a toilet, there's going to be a sink, there's going to be tiles or a wooden floor or carpet or whatever you can do, but there's only so many ways you can do this. With software, the equivalent would be we're going to make a room that we don't know what's in there and the laws of physics may also change, right? Every project, unless you're building something that's kind of very repetitive, which is not most often the case,

is like a bespoke project that is usually built from scratch. sorry, but it's unlikely that someone can tell you exactly how long this is gonna take. They're probably like lying to you or it's probably not gonna come true. Now there is an alternate universe here, which is let's go create like really small projects that we can, deliver user value and we build them one at a time. So I don't know if you've seen that graphic that makes the...

rounds around on social media, but it has like a car and it's like, starts with like two wheels, then an axle, then the frame, then the body, and then you get a car, right? That is the waterfall model. Whereas the iterative way of doing this is, is you have like a scooter and then you have like a bicycle, then a motorcycle, then a car, right? And the idea here is that you can create projects where you have value at every step of the way. And you delete, you build the team's ability to execute. So you can go from idea to production in days, not weeks. So then the team.

Speaker 2 (08:23.914)
Instead of getting certainty and predictability and knowing what I'm going to do in those three months and what my money is going to get, they can get the idea that we can try things and we can try them out really quickly and we can learn from these things really quickly. So if we want to go from A to B, we can make sure that every step of the way we're pointed in the right direction and learning. So we'll get to our destination faster as opposed to starting something, trying to predict it, but find out we're going 30 degrees off and we end up six miles from where we're running to B. And it's usually a very interesting sort of

psychological dynamic there because once you see a team that works and is firing all cylinders, can take something and deliver it to production in days, the relationship with the business and the tech team changes, right? You can see a lot more trust develops and you can say, it's okay if I don't know how long it's going to take because I know you can deliver complex features at a fairly fast pace and I can change on a dime. So that's usually a much better dynamic to be in.

So is the answer to people who are doling out the money, is the answer that, if you are going to be involved in software innovation, you just have to be comfortable with the fact that you are not going to have all the forecasting that you want. If you want to have all the forecasting, then build an oil rig, or go into real estate. That this is just a field that has high rewards, but with that,

there is a certain level of risk that you just have to learn to handle. Is that what you?

And that's true, especially early on. Now that's not to say that eventually you cannot get planning and predictability. But I usually, when I work with clients and when I work with teams, I usually suggest that we do things in four steps. And this is just because people tend to get lost and they're not sure how to approach things. And okay, we're slow, the quality is bad, what do we do? So my suggestion is usually start first with iterations. Can you get your software out the door? Not on a schedule, but like quickly. So you'd have an idea and then you can implement it and get it out the door within a few days.

Speaker 2 (10:20.942)
Once you can do that, now you can build and build some quality in the system or build more quality in the system because you have something to begin with. But you can get the software out of the door with fewer and fewer bugs. Right now, the team is getting pretty good in putting out small things at a decent pace and with decent quality. Now, complexity usually starts getting up. So step number three would be start figuring out your complexities. Is your architecture getting too complicated? How is your feature set? How do your features interact with all your other features? And then when you have those three things down,

Now you can reach your planning and predictability. Now you can go to sort of step four and say, okay, well, we got pretty good over our sprints or whatever periods you're delivering software in. The last few went pretty well and we now have the team pretty honed in and dialed to deliver stuff. Now we can kind of foresee and we can maybe plan the next month. And when we get good at that a few times, we can do the next quarter and maybe we can get as much as six months or a year or something like that. So it goes in like a sequence where you get your ability to execute first. And then over time you build your ability to plan and predict.

but usually not the other way around.

But would it also be a fair assumption that you need to iterate that team? Because the team that you're talking about, the team that knows how to iterate, the team who knows how to move fast and who knows how to plan, they're working in tandem. It's like one of those really famous orchestras where basically everybody really knows each other, they've learned how to play together, and this is why they're performing at the Royal Opera House. Whereas if they just came together for the first time,

Even though they're talented, it would just take some time for them to kind of get in sync. And you know, some very talented people might just want to be stars and don't play well in an orchestra and need to be soloists. And that's probably something that you would discover in the first early phases of the cycle. there's this, what would you say about the team iteration in these four phases?

Speaker 2 (12:12.258)
Yeah, generally, by the way, don't have much tolerance for soloists in software teams. Software is very much a team sport, so you have to play well with others. I usually, I start sort of from the end on this, right? We sort of first focus on what we want to do. And we want to add customer value in production as quickly and as high quality as we can. So to do this, we need to be able to ship. It doesn't matter how many things you start, but we want to be able to ship things and ship as fast as we can. So we need to build a machine.

The software world ship means get stuff out. So maybe it's having a new feature on the app store. does not include seas and actual vessels, but yes, continue.

Yeah. What do think? Yeah. The same way that a factory makes its money when the product goes out the door is then you can set the invoice and you get paid for it. I think the analogy is similar to software that when you deliver value to your customer, then the customer realizes that value. That is usually the point where you can get cash for it. So whether you issued a new version or an upgrade or a new app or a new feature, that is the delivery mechanism for software. yeah. So when I say ship, I mean something valuable of high quality into the customer hands, because now I can probably start seeing the rewards from that.

and stay as a business. So going back to the idea of shipping is usually if you examine sort of your value stream. When I say value stream is a series of activities that we do that start with an idea and somewhere has software delivered and changed and tested and out the door shipped, in that value stream, there's usually something that is slow. I call this a bottleneck, right? So there's something that everything has to squeeze through. And if that thing is not working at the best possible speed, then everything slows down. So teams,

when they start off, will, a lot of places will be really slow, but one place will be the particularly slow one, because the bottleneck is like really in one place. If you, for example, again, back to the factory, if you have a machine that is the slowest, it doesn't really matter what the machines before or after do it. If the machines before are really fast, then a bunch of intermediate work is piling up to the slow machine in the middle. Or if the machines after are fast, they don't have any input work, because it's the one in the middle that is slow. So if you fix that bottleneck, then the bottleneck will move somewhere else and you have to fix it again.

Speaker 2 (14:20.962)
The way that I suggest that teams handle this is they think through and figure out what is their bottleneck. So maybe every iteration, every week or every month, they are doing some experiment to figure out where does my bottleneck lie. Sometimes they'll hit it, sometimes they'll miss it. It's okay. But we find where that bottleneck is, we fix it. And there's techniques that we can chat about how to fix the bottleneck and keep repeating this. And time after time, even if you get small improvements, if you're doing a 2 % improvement week on week on week, after a few months, you're like a lean, mean, executing machine.

As working with my Clyde-

I was going say that this is a good question for business leaders to ask their tech lead because our audience, our business leaders, they might not necessarily actually even know how to spot the bottleneck because they wouldn't know what happens in production between the backend being connected to the frontend. But that's something they can ask the CTO, the tech lead, they can say, okay, so where do you think in our team is the bottleneck?

I guess that if the answer is, well, we think it's here, but we're investigating, that's a good answer. Whereas we haven't thought about it. Well, you might have some leadership issues. Would that be a fair assumption?

That is a fair assumption and there's something fairly insidious that often happens here. I was working with this team where leadership was super invested in getting features out the door and they were so motivated in getting features out the door and they're pushing their team so hard to doing so that the engineering team had been trained to forget about all other kinds of work the engineering team has to do. And just to set sort of the setup here, in addition to features, most teams typically do defect management. So there's going to be bugs and stuff that they have to go back and fix.

Speaker 2 (16:03.41)
Most teams do investments, so they may go back and clean up some piece of the process or the architecture or decide to do things in different way that will speed them up in the future. And oftentimes also teams have to do with managed risk. This is coming off something called the Flow Framework. You can look it up. It's really awesome. But if your leadership team is always talking about features, engineers often get trained to just deal with features and they forget they have to do all these other things. And that is to the detriment of their long-term

velocity. this team that I had in mind, management was always so insistent about features that the engineers just completely forgot they have to do all the other things. And eventually, like quality starts going down because you have so many bugs and because you haven't spent any time refactoring and fixing anything, it just goes worse and worse and worse from there. So it behooves good tech leaders to remind the business side of things that there's other kinds of work that we have to do and make sure that they schedule the right sort of amounts of buckets. So like in a new product,

Maybe do 90 % features and 10 % everything else because everything is so new. Whereas if it's a mature product, you might be spending 30 % of your time in features, 30 % fixing using bugs because now you have tons of customers that are using these things and 30 % doing new investments and making sure the team is continuing to go quickly. Might sound less like, hey, we have like 10 people and only three are going to be working on features. That might be true, but the velocity you're to be getting out of those three is so much higher than if everyone's been working on features for the last two years and no investments have been made.

because it's going to be the equivalent of like the dilapidated factory where nothing is really good in there.

You know, we actually had a really good episode on technical debt, but it was ages ago. So the audience might not have seen it, might not remember, but there was a really good analogy there from the guests. And he said that, okay, imagine if you're cooking in a kitchen and you're cutting vegetables and there's onion peel or potato peel. Like there's going to be stuff everywhere. And what you would ideally do is that you would clean up between lunch and dinner.

Speaker 1 (18:04.704)
And imagine if you didn't, if you just kept on cooking in the same kitchen and you never cleaned anything up. I mean, we don't want to imagine it too well, but especially now that we're in the summer, but basically it would be bad. That's not like people would get sick. And so you said that that's the problem with technical debt. So if you don't know that it exists, and you know, you're only serving these beautiful meals at some point, your metrarchal kitchen is going to get absolutely filthy and then bad things are going to happen.

In my experience, I didn't know what technical debt was or that it even existed until my CTO told me. And when he told me, okay, yes, I listened, but I remember the conversation because he was quite annoyed because I was saying, well, you why aren't we releasing stuff? And he was like, well, we have other work to do. I'm like, well, what other work? That's not a thing you say to the budget holder. We have other work to do and you don't explain it. So I do think that.

Often the technical side doesn't bother explaining because they assume that we know, or they explain it so badly, like we have other work, leave us alone. you know, basically destroys trust. So I would say, both sides need to learn to ask questions and give explanations respectfully, which is why we have this show. And have you noticed a difference between how

between the problems between tech and business in big companies versus small companies, because I know you worked at Uber, you also work with small business owners. So are the problems the same or are they different?

The problems are the same, but I don't think there's a straightforward mapping where it works better over here and worse over there. You mentioned Uber. Uber was really, really good at handling all kinds of work. So they would not be shy if they saw something was not working to go and just rip it out and rewrite it. And while I was there, we had many of these projects, which is usually a pretty risky project, but they had seen it where the scale of Uber is kind of like astronomical, right? So if you had something bad and you left it in there,

Speaker 2 (20:11.63)
when you had those millions or tens of millions of users and they're hitting that bad piece of code and it's not working, it's a really bad time to go rewrite it. So having a little bit of foresight there and cleaning this up is a really good idea. And conversely, I've been to small teams that you'd think they'd be more agile and nimble and the opposite happens, right? They're so focused. We're a startup. We just have to do features, features, features, and they forget everything about technical debt. And then there's, your velocity just goes down, bugs go up the roof. And sometimes like you can collapse under your own weight when that happens.

You mentioned sort of the discussion between business and engineering and yeah, obviously like this should happen in a respectful and collaborative way and all that good stuff over there, usually I've seen this exactly like you mentioned it where the teams don't take time to explain what's happening. Like you don't need to explain, like if I'm on tech side, I don't need to explain every nitty gritty detail about this, but I'm gonna say, hey, we're gonna do some work. We don't know exactly what it's gonna be, but it's gonna be kind of in this area because we have this hypothesis that if we went and fixed this thing over here, then we could deliver features

a little bit faster because we don't, dealing with this thing every day, right? You don't need to explain like, you know, the bits and bytes of how everything works, but it's not like, hey, I want to carte blanche and I'm to go over here for a month and you get nothing. So I think we need to explain this balance and this balance changes, right? It's very reasonable to say, hey, we have this customer, big customer deal we're going to get, and we need to spend the next month doing a bit more features. And then we'll go back and carve out some time to fix like the technical debt and fix some bugs. It's okay to change that ratio up and down. What is not okay,

is to have the kitchen not clean for the whole summer. That is when that gets bad. And I make the joke that we think of technical debt as like credit card. You borrow a little bit, you pay a little bit. You borrow a little bit, you pay a little bit. But what mostly I see is you borrow and you borrow and you borrow and then you have to call the IMF and saying, sorry, like there's no way I'm digging out of this hole. We don't wanna be in that.

You know, actually heard somebody talk about relationship debt. It was a tech geek talking about, you know, dating and romantic relationships, but I thought it was actually, it really made sense in that context that, you know, if you snap at, you know, your partner or your colleagues, basically if you're not a particular, if you're not really nice and considerate, you know, people first kind of just.

Speaker 1 (22:23.738)
well, especially in the UK, kind of smile and tolerate it. But then, you know, you're not going to last long either as a colleague or romantic partner. And so what would you say are the biggest blocks between engineering and business? Like what are the biggest misunderstandings that you've seen?

I think one of the biggest things that I see is this idea of work in process. So this is the idea that we have some ideas, the business has some ideas of what they want done and they hand to engineering sometimes with a negotiation, sometimes without and say, now go do this. And we're often way over optimistic as to what engineering can do. And we usually will fail and we will try this over and over and over again. So basically we're handing engineering way too much work in the hope that this can be completed.

And there's not really good language or not really good mechanisms developed for us to prevent this. And that's why I keep seeing this over and over and over again. I call this like waste, basically too much working process. We're too focused on starting new things rather than finishing things, right? We've established we deliver value when we ship things out the door and we put it in customers' hands, but we end up focusing on starting new things. that's a new shiny thing that we just saw today. Let's get that one done.

Again, in many places, I see this all the time where we just don't have good language. Like, well, could you put it in the next sprint just in case we can get it done? And you'll see this happen, right? Where you have like 10 things to do in a given sprint, like a sprint, a two-week working period where we plan it in advance and try to get all the things in there. And we'll put like five stretch goals. And instead of like focusing on one thing, shipping it and doing the second thing and shipping it and doing the third thing and shipping it, we just pile everything in there and we end up working on the 15th thing.

and because we were blocked on something for the first thing. And then you have this priority conversion where instead of focusing a bit more on the first and getting it out the door, we got interrupted, we worked on the 15th thing, we went back to the first thing, we forgot what we were doing, so we created a bug as we were doing this. So if I had one of my biggest pet peeves of engineering and the business side is negotiate these things better. Look at how you did the last time and pick an appropriate amount of work that you're all happy with and then focus on getting better.

Speaker 2 (24:38.446)
Because if you get better and better at doing this, you'll be able to do more and more and more and everyone's going to be happier. Engineers don't like taking on something and not delivering it. Everyone's like, worst case scenarios. I said I'm going to do it. I didn't do it. No one is happy when that situation happens.

You know, I've noticed that the problems in building tech products, building tech companies are actually usually not technology. They're basically usually the human condition. We want everything, so we can't choose a priority. So we have 15 priorities, which is nonsense, right? We want everything now. We've had an idea and okay, we want to do it now. And that's not to do with, you

some sort of language not working out or it's not to do with bugs, it's just the fact that we can't control ourselves. And so it's just kind of, you know, really simple things that we would also apply to, I don't know, healthy eating and just healthy life in general. know, if you are at an all you can eat buffet, try not to put everything on your plate.

So the thing with how to deal with that people problem is converted from being like a culture or sort of a vague thing by giving names to it, right? So I will say we have too much work in process. Now we have a name. We can visualize work in process. By the way, there's a really good book by Dominica de Grandis about called Visualize, Visualizing the Invisible. It's really awesome. It basically says, if you can't see it, you can't do anything about it. So if we are,

keep getting caught in the trap of trying to deliver the same thing but failing to it because we take on too much work, then establish some controls. Like say this is happening, so what can we do about it, right? So first is visualizing it and making sure that we can see all this work and we can kind of measure it. And then you can put some controls in. So for example, one technique that I like is instead of doing sprints where you take like a period of a week or two weeks and you do like a meeting in the beginning and you plan it and then you kind of work on it and deliver it at the end is let's have a pile.

Speaker 2 (26:36.694)
And they call this Kanban, if everyone's seen the term, where we start with a pile and we can say we can only have up to three things we work on at any point in time. Pick your number. It's not like 10 and it's not one, but it's like two, three, five, depending on the size of your team, not too many. And when you deliver the first one, you can pick another one. And what happens there is you get good at shipping, right? You're working the muscle. What does it take? Cause I picked the thing off the pile. I can't put it back on the pile. I have to finish it. So I get really good at doing the thing that matters, which is shipping.

Another tool you can use there is you can put bug limits. When we have more than five bugs, we can't take any more features. We stop when we have to fix the bugs. Now you can haggle over the number. We could say when we have more than 100 bugs. Now what you'll notice is if you have five bugs or 100 bugs, the rate of going in and the rate of going out has to be the same. So if you get good at being able to have the same rates, then it doesn't matter if you have five or 100, because if the rates are the same, you're putting the same resources into it. So what would you rather have, 100 open bugs or five open bugs?

Now, what usually happens is we don't visualize this. So the rate of bugs being created is usually bigger than the rate of bugs being fixed and the backlog gets bigger and bigger and bigger. And we pretend we're going to fix it. Whereas if you now put this rule in place, now you visualize it and you can haggle what the numbers are. You can haggle what the rates are out. You can haggle what the priority of bugs are or what we consider a bug. But it puts you in a much better position to like deal with reality rather than just hiding reality and saying, just file it in JIRA and we'll see what we can get to it.

So the rules seem to be face the facts, prioritize, and constrain yourself.

Yeah, and the thing that I tell most teams that I work with is like, don't file a P5 bug, right? P1 being the most important in P5. I have never in the last 30 years worked on a P5 bug. But if someone says, hey, I noticed this, and I say, yeah, that's kind of like a P5, it's like, don't even bother writing it down, right? We know we're not going to get to it. So I'm lying to you if I say, just put it in there and maybe we'll look at it at some point in time. Like move the negotiation forward and say, you know what, that does not strike me as important in the grand scheme of things. So let's just agree now, we're not even going to talk about it anymore.

Speaker 2 (28:38.144)
and out the window it goes, as opposed to just having a system everyone has, there was like a thousand p5 bugs and we go groom them every now and then and look at them and say, is this now important?

It's kind of like that drawer, I think, that we all have in our house, you know, that has all these mystery things that we don't even know where we got them. Like, I don't know, there'll be like a random nail and an old pen that you are finally going to get the special cartridge for. And just all this crap that accumulates. And you're like, yeah, I'm not going to throw it away, but I'm also realistically never going to fix it.

We should do Marie Kondo if it doesn't spark, if that bug doesn't spark joy, chuck it.

So as we wrap up, what would be the last thing that you would want non-technical founders and business leaders to know about working with technical teams? What would be your final words of wisdom for them?

I think it is develop those relationships and have these open discussions. You need to be able to have productive conflict with the teams. This is not one where you're fighting about things and it's the unproductive conflict, but you need to establish these healthy tensions in the kinds of work that you do and not only focus on getting the work done, but focus on how you're getting the work done and making sure you're improving the work. If you're only doing the work, your competition is doing the work and improving their work and they're gonna take your lunch. So focus on making yourself one or 2 %

Speaker 2 (29:56.014)
better every week on week and then over the years these changes accumulate and they're to be like a leading mean executing machine shipping features outdoor really really quickly. But for that you need that productive tension to be be happening.

Yeah, this is really good advice. And I found that actually it took me a while to get into this groove with my tech team, just because they work in a very different way to the business team. people, they're kind of like two different species of animal who are kind of sniffing around each other being like, is it going to eat me or is it going be nice to me? I don't know. And it took some time to get to this level of trusting relationship, not because things were bad to begin with, but because we basically came from very f****g

different environment. And so would say to people, if that relationship just isn't, you know, super sparkly and amazing right from the start, don't worry about it. Keep on being polite, you know, keep on asking questions, keep on offering your perspective on things that you actually know about, not coding if you're not a coder, obviously, and that relationship will build. Well, thank you so much, Thanos. And so where could people learn more from you?

They can check me out on LinkedIn where I post a fair amount and also on my website at CosmicTeaCups.com

awesome. Well, thank you very much. We'll link both of those in the show notes. Great having you. Thank you.

Speaker 2 (31:16.162)
Thank you, Sofia, has been a pleasure

FREE Course: 5 Tech Concepts Every Business Leader Needs To Know