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:

- 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

- What weekly investment in process improvement compounds into dramatically higher velocity

This episode is ideal for for Founders, Owners, and CEOs in stage 5 of The Founder's Evolution. Not sure which stage you're in? Find out for free in less than 10 minutes at https://www.scalearchitects.com/founders/quiz

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/

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?

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?

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.

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.

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?

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.

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?

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.

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?

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.

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?

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.

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?

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.

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