In this practical episode episode, Thanos Diacakis, Founder of Cosmic Teacups, shares why engineering teams often feel expensive and slow—and how to fix the real bottlenecks. If you’re questioning whether your development team is worth its payroll or wondering why timelines keep slipping, you won’t want to miss it.
You will discover:
– What weekly investment in process improvement compounds into dramatically higher velocity
– Why ignoring Investments and Risk creates technical debt that slows everything down
– How to replace long specs with short feedback loops so the team stays on course
Episode Transcript
Scott Ritzheimer
Hello, hello, and welcome, welcome once again to the Start, Scale, and Succeed podcast-the only podcast that grows with you through all seven levels of your journey as a founder. I’m your host Scott Ritzheimer. Today, we’re tackling a question plenty of founders, both technical and non-technical, are afraid to ask out loud: Is my engineering team actually worth its payroll? It’s a tough one for any founder with a software product or an internal development team, especially those who are in the chief executive level. And that’s why I’m so excited to have Thanos Diacakis with us here today. Thanos helps startups and growing companies overcome software bottlenecks, scale engineering teams, and deliver high-quality products faster. With over 25 years in software development, his background spans both early-stage ventures and tech giants like Uber, including Health, where he led the technical integration of Jump Bikes acquisition, scaling the platform to 45,000 vehicles and over 2 million monthly trips.
He’s seen elite teams stall when outdated processes leave them two heads down to course correct. With lean, evidence-based practices, he unlocks faster delivery and greater developer satisfaction, so velocity rises while burnout falls. Thanos, welcome to the show. Glad to have you here. the The big question is that I know there’s a lot of founders who are asking, you know, this is it worth it question because they’re looking at the payroll numbers, and especially for those kind of internal development teams where they’re not used to that type of payroll number, they can wonder, is this really it? And I think buried inside of that is this question, like, why aren’t we moving faster? That that’s really what founders want to know, and and so how do you help founders and their teams to answer these seemingly really big, really tough questions?
Thanos Diacakis
Yeah, one of the places, by the way, thanks for having me on. Is I’m very excited about this conversation. I can nerd out and talk for hours about this, but one of the first things that I look at when I go on one of those teams is does the business side and does the technical side have the right words to talk about the same things? And is there a disconnect there? In what is the mental model? Most CEOs don’t have an engineering team; they’ve never run one, so they don’t know what the expectation is of engineers and how to work that. So the first few things that we look at is okay, like do you know what you’re talking about? Do you have the same words to describe the world as it is to you, and can you coordinate to get software out the door?
Scott Ritzheimer
One of the things that’s so hard about that is that a lot of founders are wired very differently from those engineers, and in many ways it couldn’t be more different. What are some of the most common ways that you see founders and their development teams talking at each other instead of to to each other.
Thanos Diacakis
Yeah, one of the most common things that I see is where there is there is not a set expectation on what the engineering team is doing and where those requirements are coming from. I like to use something called the flow framework that defines sort of four categories of work for engineering. And when everyone has these four words down, life becomes much easier to talk about. These are features, defects, investments, and risk. These come from the flow framework. Features are things we want to ship for our customers. Usually, internal or external teams. When you ship a feature, you make money in some way, right? Customers realize value; they pay you for it. So the business usually wants features, but they often want bugs fixed. If we ship something that didn’t work, we will want that to get fixed. And usually, businesses are pretty good about communicating those two things. But one of the things that often gets left out is engineering teams often have to do other things.
They have to do investments. They have to upgrade certain things, clean up their processes, sharpen their tools, so to speak. And they also have to take care of risks. Did we upgrade these libraries? Are we going to get hacked. That sort of stuff. The latter two usually get forgotten. So when the business always says about features and bugs, the engineers kind of focus on that, and now you get to the point where your deployments go slower and slower and slower because you have all this kind of debt that you’ve accumulated over the years. So usually one of the things is I go and teach those teams like, okay, this is a framework you can use. These are words you can use to talk to each other, and that will help you because engineers can advocate for their investments and their risks. The business can advocate for their features and their defects, and we can have this sort of creative conflict where we can agree to what we’re going to build and how we’re going to build it.
It’s always good to allocate some time to the team to sort of introspect and look and see how things are going, because that if they do that then they can deliver things faster and faster for you. Now where this often goes wrong is the business team will want sort of to plan things out, right? So they may have a team that’s not really performing that well, and they they you know they they ask them something. It takes months. It’s always delayed. And instead of like fixing the the machine that ships things, we often try to plan in bigger and bigger blocks, and that usually ends up in tears. And we can talk about why that is.
Scott Ritzheimer
Yeah, I think that’s so helpful because one of the the challenges is when those timelines start to slip. It seems to snowball really fast. It’s like we’re a week late, and then all of a sudden we’re we’re two years late, and and it’s like. What just happened? Why is it that you find, especially at this stage with a relatively small development team, you know, not some massive enterprise? But what are the things that cause the most friction? What is it that causes us to be behind schedule?
Thanos Diacakis
Yeah, this is especially true for what I call accidental software teams, like internal teams, where it’s not a software company, and the experience of how to do this is not there. But the most common pattern that I see kind of roughly goes like this: the boss goes to the team and says, “This is the new thing customer X wants. You know, what do you think? The team looks at it and goes, “Well, that’s probably going to take like a month, so let’s tell him two months. And they tell him two months, and the boss goes away and goes runs his business for two months, and then he comes back two months later and looks at it. No, no, no, no, no. This is not what I asked you. This I wanted it this way and that way and that way. So the team then has to rework it and they come back at month three and it’s sort of what they wanted.
And long story short, around month six maybe something that we wanted was roughly outputted to the customer. So the boss now learned their lessons, saying, well okay that was underspecified. So now I’m going to write like a 30 page spec of everything that I need, and then I’m going to have this big written thing of how I imagine this, and just give that to them. Then they can go work on this and come back to me. And that’s usually is what I said. This ends up in tears. What we want is the opposite approach. You want to have the team where they can build some aspects of this in a day or two. Then you go look at it. You give feedback. Then you build a little more in another day or two. You look at it, give feedback, and there’s there’s ways to do this. There’s ways to organize a team so that capability exists because you can learn from the real world examples.
This is not what I wanted. This is not what a customer would want. And if you can slice your product in ways where you can deliver it in little chunks, the feedback is pointing you in the right direction. So imagine like a team goes off and starts like veering off to the right, and to the right, and to the right, and now they’re somewhere in La La Land. Whereas, if you could course correct them every every few days and have them on track of where we wanted to be, we we learn that way. We also sometimes have ideas that we haven’t thought through fully well, and we wanted this, but that’s not actually what the customer wanted. So we can learn that sooner and aim the team in the right direction. I think that’s the correction that I would make with most teams, and most CEOs are surprised. They’re like, “Wait, so I can’t plan this out, and you can’t tell me how long this is going to take. No, I cannot do that. But instead, I give you a better gift, which is the gift of seeing things every couple days, and being able to get your feedback in there, and trying your ideas out, and showing things to customers every couple days, which usually speeds up sales cycles and so on.
Scott Ritzheimer
Yeah, it’s so tempting for for founders and CEOs to like. I just I have so many other things to do just just go do it but there is actually a joy in those little victories if you can commit to that cycle of feedback one you’re going to get to where you want to go a lot faster but two you get to enjoy the process a lot more I’ve found you know that that it’s incredibly frustrating like you mentioned earlier to disappear for two months and come back and see it’s nothing like what you wanted, and it’s actually exhausting to write the 30-page thesis on what you want. And so, while yes, I understand that founders don’t really like to manage things that closely, I’ve actually found for most of them it’s quite rewarding. Has that been your experience?
Thanos Diacakis
Totally. And I think when when someone says it has an idea, and two days later it’s in production, and they can turn on a feature flag, and a customer can see this selectively, they’re super excited about that. And that not only is exciting for the business side of things, but engineers get excited when their stuff is in the hands of customers. That’s what we all trained for, and that’s what we all came into this industry to be able to like build cool stuff. So yeah, usually also increases happiness in the team, and then people do better work when they’re happy, as opposed to when they’re all like, “Ah, he’s on our case again because this thing is so late. Yeah. So yeah, that’s that’s usually a much better way of working with things.
Scott Ritzheimer
I love that. I love that. Another area. Well, there’s this question that I I think founders should never ask when it comes to development, and I’d be interested to see if you agree with this. But it is, can we do X? I think that’s a really, really bad question. If hey, can we do this? Can we offer this to this customer? Can we build this feature? Because it seems like for most things, the answer is yes. But the real question is, how hard is it to build this, or how much is it going to cost, or how much are we going to have to maintain? Have you found that there are better questions for founders to ask of their engineers?
Thanos Diacakis
So I think when you ask that question, you’re kind of priming maybe a grumpy engineer that is not in the right mood because they haven’t shipped stuff in a while to be like no, no, I can’t. No, this is hard. No, this is difficult. No, I don’t want to do it. So, I think it’s it’s genuinely good to go in it with curiosity of like, is this possible? What it would take? But you can maybe say you know phrase it in a slightly different way of like how yes, how hard would this be? What would this involve? How would you think about doing this? Or maybe even say why you want this because that usually gets people motivated. But I also want to say that I think at this point where we are with the whole AI revolution, yeah, we can probably build mostly everything in a much shorter period of time that we wanted to before.
So you begin to move from the meta level of it’s everything now is really quick to build, and if you have the right. Technologies, the right processes, the right culture-you can go really fast again. If you don’t have these set, then AI just makes bad go faster. Bad, but if you are in a good setup like this, and I’m seeing with some of the teams that are in in the bleeding edge of this, that they’re now able to go even a level further. Which is okay. We could build like these 100 things now. Which one of these would deliver the most value to our customer, and we can do a better job than we did before. Because in the before times, we would say, “Well, we’ll ship all these things, and someone’s going to keep an eye on them and learn from what went well and what didn’t. In reality, we never built the dashboards because we didn’t have time. We never went ask the customer because we didn’t have time. I can just ask the AI to do all this stuff, right? So go build for everything we shipped in last month. Go build dashboards and tell me how it works. And instead of telling me how it works, why don’t you you look at how it works, judge it based on these criteria that I give you, and tell me which of these projects that are currently in our bug tracking system are the coolest things to build. Obviously, look through it, verify, make sure it’s sane. But we can really shortcut this value creation process, confirmed from idea to what would actually work in production. So super exciting times to be alive.
Scott Ritzheimer
That’s cool. It is. It is exciting. There’s so much that can be done. It’s going to change so much of how we do what we do. Thanos, there’s a question that I want to get to. I want to make some time for because it’s a question I ask every guest. I’m interested to see what you’d have to say. But from your perspective in this conversation, the question is this: What would you say is the biggest secret that you wish wasn’t a secret at all? What’s that one thing you wish every founder watching or listening today knew?
Thanos Diacakis
My answer to that, which is not really a secret, is you have to spend some time looking at how you do the work and improve on how you’re doing the work because those are investments that compound over time. So if you spend 5% of your time every week to looking at how you worked last week, fixing some issues, this 5% is 1.05 to the power of however many weeks you do this in, which becomes a really big number. So I see teams because they’re busy to they don’t do that, and their output is linear and it’s flat. And I see teams that invest in themselves and do just small improvements, but every week they’re introspective and they go fix things, and now they output 510, 20 times faster than other teams, and and that is the part of the flywheel that you really want to build to go faster and happier and with better quality.
Scott Ritzheimer
That’s so cool. It’s so cool, and it’s something that can be used outside of the engineering team as well. I think that approach for founders can be quite a challenge, but it’s again deeply rewarding. It’s one thing that when you start seeing that compound, you know, week in week out, it really is really is tremendous. Thanos, there’s some folks that are listening to this, and and it’s like, how does this guy know everything about all of our our internal software challenges, and and and you know, how can we get out of this? Is is really what they’re asking. Where can folks reach out to you? Where can they connect with you? Where can they find more out about the work that you and your team do?
Thanos Diacakis
You can check out my work at my website, which is cosmicteacups.com, named after a Bertrand Russell quote. And you can also connect with me on LinkedIn, where I write about all these issues, and sign up for my mailing list on on my website.
Scott Ritzheimer
Fantastic, fantastic! We’ll get all those in the show notes for you all, so you don’t have to go find them. And well, thought it was very fun having this conversation. Could have gone for a very long time. Probably could have gotten us both in a lot of trouble as well. But I really appreciate your your insight into what is both an exciting and challenging time and an area for founders. Thanks for being here. And for those of you watching and listening, you know your time and attention mean the world to us. I hope you got as much out of this conversation as I know I did, and I cannot wait to see you next time. Take care.
Scott Ritzheimer
Hey everyone, Scott Ritzheimer here. Thank you so much for listening to the Start Scale and Succeed podcast. I hope this episode gave you exactly what you need for the level you’re in right now. If you want to discover what level you’re in, take our 10-question Founders Evolution Quiz for free at foundersquiz.com. That’s foundersquiz.com. It’ll pinpoint exactly where you are and give you tailored tips to move forward and reach that next level in your journey as a founder. If you got something out of today’s episode, don’t forget to subscribe, rate, or review. It helps us reach more founders like you, and let’s be honest, it means a ton to me, my team, and all our incredible guests. So keep starting, scaling, and succeeding, and I’ll see you in the next episode.
Contact Thanos Diacakis
Thanos Diacakis helps startups and growing companies overcome software bottlenecks, scale engineering teams, and deliver high-quality products faster. With over 25 years in software development, his background spans both early-stage ventures and tech giants like Uber and Included Health, where he led the technical integration of the JUMP Bikes acquisition, scaling the platform to 45k vehicles and over 2 million monthly trips. He’s seen elite teams stall when outdated processes leave them too heads-down to course-correct. With lean, evidence-backed practices, he unlocks faster delivery and greater developer satisfaction, so velocity rises while burnout falls.
Want to learn more about Thanos Diacakis’ work at Cosmic Teacups? Check out his website at https://www.cosmicteacups.com/
Connect with Thanos through his LinkedIn at https://www.linkedin.com/in/thanosd/