Latest / The Start, Scale & Succeed Podcast / Is Your Engineering Team Worth Its Payroll with Thanos Diacakis (stage 5) - Ep. 435

Transcript

Is Your Engineering Team Worth Its Payroll with Thanos Diacakis (stage 5) - Ep. 435 · The Start, Scale & Succeed Podcast

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