How to Innovate through Software with Carlos Kelkboom

Hi everyone, my name is Patrick Akio and if you're interested in innovation, how to disrupt your organization, and how to trust software engineers to do so, this episode is for you. Joining me today is Carlos Galbo. No fancy titles. He doesn't like that he's a software engineer tech fellow and I'll put his LinkedIn. No other socials in the description below. Check them out. And with that being said, enjoy the episode. And about a month ago I figured

out a setting how I can do every drum. In a separate track, Yeah. And that changed my life. It changed your life. I know it's hilarious. How did you come up on that feature? Like, how did you know it existed all of a sudden? Watch the YouTube video. Yeah, yeah, just stuff. Just some magic content presented me by the algorithm gods and it was amazing. Yeah, I love that. Yeah, I mean it's like YouTube recommends me whatever I get

into. Like I got into bouldering and a few months it was way more than it is now. Yeah, because I kind of get need to get back into it. But back then everything got recommended to me. I got, I watched like bouldering, World Championships. All of a sudden it went from OK, how do you start to more advanced stuff to this is like the World Championship and it was all recommended to me. Yeah, and it works.

Damn it, it works. Yes, it works, but it also limits your exposure to new things, and that's one of the things I don't like about it. So what I used to do was have like 3 or 4 different accounts and I would sometimes swap between accounts and then watch certain things on account A and other things on account B and then you get presented new things. Yeah, in a more direct way and I I like that, but they changed something with the algorithm.

Now it now it knows that I'm using multiple accounts. It's like this is the same person. Yeah, yeah, we got it. Yeah, I mean it's very interesting because there are video content platforms where their USB or like one of their, I would say core Usbs is like a recommendation algorithm is different than YouTube's. It's like a raw thing. It's more new organic content rather than recommendations based on watch history. And to me it's very interesting that that can be a USB.

I haven't seen a platform actually take off, obviously the levels of YouTube, but I'm hopeful that it might be possible. I think it will be possible.

I think different front ends on YouTube might also be verifiable. So people just reusing the same content through the API keys but having a completely different front end in front of it. Maybe do some searches or maybe you have like a different type of history. Or you can share your history with other people and then you can get the videos that they liked or. Just some more direct ways of of building a community around the content that you like instead of just getting the content pushed

towards you. Yeah. So that's my hope that we're going to start seeing different front ends on YouTube. That would be very cool. Yeah. I think I didn't even think of that as an option. But customizability wise, that is amazing, yes. Yeah, if it will be allowed and possible I guess. Yes. And it's also one of those things that. There haven't been a lot of communities built around this

type of content yet. So you can you can share stuff, you can like it, you can, you can, but there's there's no way to have like 5 friends and then have a mutual pool of videos you like, and then have the recommendation algorithm recommend based on that pool of videos instead of only your own. That would be something that's worth exploring, yeah.

I wonder if if Google or like the YouTube team is flexible and dynamic enough to make that work. Because right now I don't really see a lot of innovation on YouTube. Some stuff is pretty slow, like to have stuff like, ohh, you can now upload a thumbnail for the short videos that you create. And I'm like, I can already do that for regular videos and I I can't still cannot do that on my web browser. So what's up with this? Yeah, so I don't know how dynamic they are.

It'll be very awesome. I think it's the same thing as what you said about starting up. New stuff has a lot of backing and a lot of people interested in it. But as soon as you continue with things, people just want the return on investment. They want to say, OK, you're already, you've already started, now let's see the results. And the innovation part gets killed a little bit. And I think that's also what you see with YouTube. But I'm not a Googler. So yeah, it's just it's a

hypothesis. I do think it's a shame because I mean you start something and you have a certain vision for it and when it goes live, some people think that's the end like it's delivered. But from a software perspective and the people that build it, like that's when you start, right? Then you get it to the hands of the customers, then you get feedback, you know what to build on, what to focus on. And then you start delivering value more and more and more towards the people that you're

actually building this for. Yeah, yet a lot of kind of projects kind of fiddle off then or like the continuation budget is a lot smaller than getting it live budget, basically. Yeah, I think it's a shame, but I don't know. Yeah, yeah. If the realization is not there of the value or I don't know where it ends.

One of the things I've noticed is companies don't like competing with themselves, but that should be the mindset you have. How can I disrupt my own organization, my own company, my own product? Yeah. And just have small teams. It doesn't have to cost a lot, but just have small teams trying to disrupt your own market share.

And as soon as you start doing that, you can either incorporate good ideas back into your main product, or you can maybe have a separate track and then have a sunset on your old product and then move to the new product. You see it a lot in games, so. Overwatch is a very good example that's currently heavily on the fire. So they they they killed Overwatch one and they're starting Overwatch two, which has a lot of issues linked to it.

But the idea of continuously trying to outperform your existing products is one that I do not see enough in large organizations. And I think that's where, that's where the money is, that's where the interesting stuff is. That's where you get your engineers happy. I would love to be in an organization where that is kind of the mindset, right. And that is the vision and

that's the goal. But as soon as you try and kind of advocate that right, if you have you're in a project and you have two or three options, the best would be to pick all of them and see which kind of outperforms and what kind of flaws one of the options has compared to the other one. And that's when you have all of the learnings, right. But from an organizational perspective, that's usually what's being said to me. It's like that doesn't scale.

We either don't have the people, the money, the resources, the time we want the best option. So we have to pick and then we go, yeah, but that's not how it works. That's not how it should work ideally. Yet that is the route we go for because of probably monetary reasons. Probably, yeah. Only sometimes it feels penny wise, bound, foolish.

So the reason why the product got big is because it was either innovating something that needed to be innovated or it was new or it was better in some way or your marketing was better, But there was a reason why the product got big. And as soon as you're at the top of that mountain, all of the small initiatives will look bigger and brighter to the

people using the product. There's there's always this culture that we want to try something new, and if something new comes along that works well enough and maybe addresses a few of the bigger issues that your original product had, people will go for that new stuff. And if if the power behind that new stuff, if the marketing gets better, if it's smarter, if it's faster, if it does something that adds benefit in a different way, it doesn't even have to be better.

It just has to be different. And people will go on. Come on board and you will have competition, so you might as well just do that yourself. And bigger companies should be in a vastly better position. With the money, with the people, with the skills, with the the ambitions, with the names, with the branding, with everything it should be. They should be in a much better position than they usually seem to be. You you see it in a lot of large

organizations. They they try to branch out with different brands or they they split it into different companies. But it's not the same as having like a small group of two or three friends or colleagues just sitting in the basement being creative, trying to disrupt something that they feel passionate about. Yeah. I I think big companies should

do that continuously. Yeah. Have you been part of an organization or a team where that was kind of the goal? Yes and no. I've done a lot of R&D work and with the company I used to work for a long time ago, we set up sort of a software as a service idea, but then with an R&D theme. So companies could hire the R&D team for a week or for 10 days or for two days. And depending on how long you had and how long the goals were, you would just try to do this.

You would set a good atmosphere, you would brainstorm, you maybe prototype, and then you get an idea and they can either continue delivering it or or or they throw it away. But the idea of trying to bring some sort of imbalance into that status quo, yeah, that's where the creativity lies. That's where the money is. Yeah.

It's fun to be in that phase of a project as well, because I'm speaking from experience, like I've joined a consultancy company and I've been in around a lot of projects. But right now my current project is the first time where I was actually involved from the start. Not even from the start. Start, because I came in like the software component came in a few months after. But then we were like, OK, what do we actually have to build?

Like what are we doing here? And then we can look at, OK, which technologies are a good fit, how we can, how can we deliver as fast as possible. We build a bunch of proof concepts, some, some stuff doesn't scale. We throw that away, we get something else and we try to deliver value as fast as possible. But because I had never done that before, I was like, OK, I thought decisions had to be made and those were kind of more

fixed. And once we decide, we we kind of build upon that for at least a few months, right? No, no. If it doesn't work within a week, scratch that, we do it again. And I see people go so fast, like implementation wise, I try to, I try to catch up or I try to speed up as well.

And I don't feel as fast. But when I see people who've gotten really good at this, that's where I see a lot of value being created in such a short amount of time that I'm like, OK, it's weird because somehow we lose that the projects I've been to have already gone live. And I'm working towards delivering more value, asking the right questions, doing the right analysis, basing things on real facts or data at least, instead of assumptions.

And there you kind of lose this. How do you say that playfulness, this innovation, this trying out things and letting go and not being as mindful of the waste of effort because it is still creating value at the end of the day? Yeah, yeah. But the value is usually less

than the first steps, yeah. So for me it's always important to think about how important is it to build this. I sometimes get the feeling that project just run on. Because they have to and not because they should or because they bring more value. People have set up complete teams. They don't want to let the teams go. So you continuously try to invent new things to add to your system. And my personal experience is if you add something, you must take

away at least two things. So especially if something is larger, if you add a feature, take away 2 old ones. And just the the the act of thinking about two things to remove from your system gives you a completely different outlook on what you're building. And you you, you will get a completely different conversation with the product owners and you will get a different conversation with the stakeholders. Because as soon as you start removing things, people get scared.

And they they are scared about consistency and stability and they're scared about. Okay. But what will happen now, but what people tend to forget, is that the complexity is the only problem when you're building large software systems. And by removing things, it's not only about removing them, it's about having the capability to change things that you no longer want in your system. It's like a skill you're building up in your teams as

well. And all of those things combined are much more important than just keeping that status quo going. Keep delivering those features. It's about finding what the core is of your system and making that as small as possible, but as the best you can build. Yeah, razor sharp. Razor sharp.

That's what it needs to be. And you see that in a lot of things. So if you ask a lot of developers, they need to build a system at least three times to make it and then make it good the first time. It's like you. There are a lot of. Not so good adjectives to use here. You just blurt out all of your code in one go, and you don't even think about things like optimizations or performance, or splitting it into the right classes, or doing all kinds of

things make it work. Make it work and then usually what I do but what I see a lot of good developers do as well is they just throw it away. Now that's in the back of your mind. You remember what you did. You remember the problems that you faced. Now you build it again. And that second time, you really think about what you're doing. You think about the problems, all of the sights, lines that you walked just to get to that first blurt of code, just they all disappear.

You make it clean. You make it work. You sit back. You look at it. You think? Okay, that's beautiful. And now the third phase is about a year later or maybe two years later, when you need to scale. Then you notice that the first thing that you wrote will not scale. Yeah, because you haven't written it for scale. So I find that you rebuild it at least two times, maybe four times, if you go through those magical boundaries of the scale

of your product. Yeah. And then I I've talked to a person and they were like, OK,

we kind of know what the domain is and we wanna already build for kind of the end state, right? That third or fourth iteration that you were talking about. And for me, it's been really hard to kind of advocate for what you're saying because I'm like, there's a lot of unknowns in there. If we already go for an end state, it's already a lock in. It's gonna slow us down, right?

We still need to. This thing is so malleable, especially at the beginning, that we have to try and figure out what the end state is going to be. We can't know we're not there yet. We need at least the history and the knowledge that we still have to gain, basically. And that was a very hard discussion because then we tried to build this end state. Basically we got overruled and we were like, OK, we're going to try this and see where it kind of irks us.

And that was very fast because we made some decisions and it was kind of a distributed monolith kind of thing. It was very painful, very painful to develop on. But the person that envisioned it was not part of the development team. They were more overarching, more architecture, engineering, management kind of position.

And then it's very hard because you're trying to build this thing you don't really feel as strong for As for one of the other options and you feel the pain and the people making the decisions don't really feel the pain as much. Then finally it came to kind of a make or break decision where we said, OK, this is this doesn't work. Basically, if these are the deadlines, we can't do this with this architecture with the learnings that we have.

We now want to start again and we want to do it faster, basically don't do it in this distributed way. We know what goes together. We'll build everything together and when we really know a part should scale, then we put it separately and we make a scale basically. But we haven't gotten to that point. And now a year down the line, we're still not at that point and we're still really fast because of those decisions.

Basically, had we done that in the opposite direction, built in a distributed way, we would have worked with a lot more complexity, probably introduced even more complexity, and we would have had, I think, more people to accommodate for that complexity. So probably multiple teams as well. Yeah, well, none of that was needed at all in that case. Yeah. Yeah, You're absolutely right. Yeah. But that's what happens so many times. Yeah. Right. Yeah. And.

There are so many layers from what you in what you just said. So throwing more people at a problem, it's usually a sign that something's going bad, right? Throwing more people of different disciplines at a problem, that might be a good thing, but but throwing people at a problem is usually wrong. It's the same as with a process. I always say that you need to add a process when something is going right. Process helps you become even

better at what you're doing. The process is not something you put in place when something is going wrong. It's not a way to dig yourself out of a hole. The only way to get to a good implementation is by having good engineers and giving those engineers the freedom to make mistakes. Because that's the learning process. If I enter a project, I'm going to make mistakes. It doesn't matter that I have 20

years of experience. I will not make some mistakes that maybe somebody with a year or with two years experience would make, but I will definitely make mistakes, yeah. And the whole premise that you're going to build it correct in one goal is built upon. Sort of an acceptance of infallible code or infallible people or infallible engineers.

I I never really understood what what possesses somebody to think that that an effort of multiple people can result into something great if you do not yet exactly know what you're going to do exactly. Yeah, I don't understand that either. Yeah, yeah, I I always equated with writing, so I write a lot. And when I try to write a novel, George Tyler Martin said it nicely, I think. So he talks, and I might be wrong here, but he talks about

architects and gardeners. When you write a novel, you can be an architect, and then you write down everything that's going to happen. And then later you write a story exactly in that framework that you did. And you can also have a gardener who plants a seed here or a seed there and watches it grow and then trims the plants when he sees them and just builds A Knight's garden that way. And there is still this belief that software can be like this architect road, and that's just not true.

The technologies change way too fast for you to know in advance what you're going to in advance, what you're going to be building, and when you're there, you don't know how it's going to change. So I I think that entire field

of software engineering called architecture, especially if they don't touch the code themselves and really build it, is causing more harm than good. And this is this is very controversial of course, because I I really believe that things like Togaff and things like those real architecture frameworks. They do a lot more harm than they do good, and they build up a class of structure of people making decisions that hurt the company and the software.

More than that, they help people and and I firmly believe that if you do not write code in that code base almost on a daily basis, you're not allowed to make decisions on that about that code. You should live it. You should feel it. You should know it. You should. When a feature comes in, you should know where the change is going to hit. Yeah, yeah, I think that's for me, it's very interesting, right? Because architecture is such a like, it's a defined kind of domain, right?

And a lot of architects either say I've never touched any code. Like I I come from a different background. I haven't actually been a developer myself, or they've grown from a developer position. But they don't touch the code anymore. And that also brings along a lot of fallacies, like a lot of history that might not be reality in what they're working on or operating on currently.

And then what you're saying is basically you need a shared mental model, right on how the code base actually functions. Architecture aside, even with software developers, that's already very hard to achieve, right? If I'm working on a code base and I'm not developing this feature, I can code review it. But only when I really look at it, play with it, see what has been kind of built, know the

flows also really well. Then I know where in the code base it is, especially if it's a larger code base.

And then I really feel ownership of it. And I've only had that, only that truly that feeling with a smaller team, because as the team grows bigger, people work on different kind of components of the software. It might even be in different repositories, might be specifically infrastructure based or architecture based. And you lose that touch and feel. It's just too many people working on parts of the same system where you lose that oversight completely, yes.

And specifically in a team with that large and and such an amount of people, that's where I felt like I was actually creating software the least, basically delivering value the least because I was way more working with people and aligning, trying to align this mental model. It was very hard, I must say. Yeah, I've had these architecture roles myself and I can speak from experience there.

It is tremendously frustrating to see a team struggle with problems that you know can be fixed but are just there because of the way the organization is set up. But Chad, you're correct. I really do not believe that there are problems bigger than that three or four engineers can solve. It might be that the entire

landscape is bigger. So if you have a financial system and if you have like an asset management system, and if you have, if you have all of these types of systems, you cannot do that with just three engineers. If you want to build them all yourself, right? But one of those things, you don't need more than three engineers. And that's also where I find

myself struggling with ideas like Scrum. Like every team needs a Product Owner, everything team needs a Scrum Master, every team needs a retro, every team needs A and so forth and so forth. I think that if you have people who are honest and know their stuff and work together, you don't need those things. They know what to do. If you have a team that is not coalescing, not working well together, you might need an intermediator.

You might need somebody who sits with that team and helps them become more mature, or helps them work together, or helps them speak their mind right. And then you need a retro. But if you don't need that, don't introduce it just because your handbook says you need a Scrum master. Exactly. And all of all of the things that I try to achieve within organizations is to just remove all of the hardened processes and hardened ideas that somebody read in a book and now they're mandatory.

The core is have good engineers just give them something that they themselves say they can do. So I think that that part is really important. They should commit to the work they're going to do and then leave them alone. Yeah, just let them do it. Just let them do it. And if they're a week, over time you start knocking on the door, Hey guys, what up? And then you have the conversation Okay, Why is this taking too long? Did you did you do it? Did you? Is the system working against you?

Do you have other obstacles? Do you have other roadblocks? Is to go to difficult. And usually I found that the reason is because they're either waiting on other teams, in large organizations have other types of dependencies, are not allowed to do something, and in very, very rare cases, they the problem is too difficult. Yeah. And then in those very rare cases that the problem was too difficult, 90% of the time it was just throwing out old stuff

that made it difficult. Well, yeah, I I'm thinking about okay. When has an estimation been that wrong that it was too difficult and I I can't, I can't really come up with a good example, and especially when you dove into

processes. For me it's it's odd, right? Because I I don't come from a traditional software engineering background. I got into an organization and I was new as a software engineer. It was obvious I didn't know anything because I hadn't touched any production related code. And then people taught me the ropes, right? This is how it works. These are the processes that are there. And for me, I always thought this is just how it works. Maybe not in this team, maybe not in this organization.

This is just kind of the standard. That's my mindset and then removing a process. I would be like, can you do that? What happens when you do do that? And I've recently come in to a team where we start with a very small amount of processes and now every process that gets added doesn't get added. We actually have a discussion about it. What does it solve? What value does it bring if we need?

For example, if you have a scrum board and we have an extra review column, why do we need an extra review column? Well, that's a good question. No one actually asked that. Well, why do you want to introduce that was to create insights on where things are at the moment. Do we actually care for that? Then we have a discussion about that, but at least that's the conversation. But I feel that's because I've had both experiences. Now I know that's an option. Have I not had the latter

experience? I probably never would have realized that I can remove processes and things don't kind of fall like a House of Cards. Yeah, yeah, yeah. But it's in every other in every other endeavor. We don't do it that way. So if you are an artist and you need to design the cover for a magazine, people come up to you and they say, can you make a cover for a magazine? And you probably ask okay, what's the topic they give you? The topic, it's electric guitars something.

Then you say okay. I think I can do that. When do you need it? 10 days. Okay. You go home, you work on it. You present two or three options. They pick one, you develop it further. That's the cover of the magazine. In software. We have all these processes that that somebody just came up with that worked for their problem in their project with those people in that circumstance. Now they wrote a book. Now they're famous. Now everybody should do that and it is not helping us and you see

it on so many levels. So for example, one of the other

things that I see that I that I find really disturbing is how quickly we pull out that Lambda or that Azure Function that that stateless model. And especially if you combine that with like a language, JavaScript or TypeScript, right, they are full of memory leaks. They are not safe. The only reason why it works is because you throw away that stateless function when it's done and then you spin it back up again. That is a very wasteful way to

design your systems. I'm not saying it doesn't have a place, but I'm saying it's wasteful. It should not be the first tool you pull out of your bag. The first tool would be okay. Let's look at what works. What do we need? Well, we need to build a small system, maybe financial system, some invoices, some building pipelines, some, some invoices and maybe some settlements, right? How do you do that?

Well, just pick a language, one that's performant, one that you can find people on with that have experience with that language, and just build it. Yeah, you don't know if it's going to be correct. Use a language that's going to be fast, Use a language that's going to be good. Don't go using very difficult prototyping languages. So I would never advise somebody to use Rust to do prototyping. That's just insane. It's. The hard way, Yeah. It's like hard mode.

Yeah prototype something in TypeScript. Perfect. Once it comes to building the actual application, build it in something that's responsible. Build it in something that that respects energy and power and CPU cycles. Build it in something like Go build it in something like Rust. If you really have to, build it in javaor.net. But don't just pick one tool because a web developer told you that TypeScript is good and now you use it on the server. I don't want to become a meme,

but don't. Don't use React server components just because they're there and and and these decisions are all stacking up. So we are overburdened with the process. The decision is never towards simplicity, but always towards what makes somebody happy at that that moment in time. And all of those decisions combined I think are bringing down the level of software in general, making it harder for older companies, especially older companies to to stay competitive, which might be a

good thing, right. And on a macroeconomic level, it might be a good thing that old companies are no longer competitive. But at least from from my perspective, they should have the money, they should have the people, they should have the branding to invigorate themselves. And I'm not seeing that happening. And I think it's very it's it's a it's a shame. I do understand that kind of based on what you laid out, If you're overburdened, right?

If there's too many people to interact with, to communicate with, to make communication lines, too many processes to account for, too many people you need to report to, to give status updates to, then who's going to do the actual work? Who's going to make the changes? Basically, yeah. If everyone oversees the changes, then no one's actually creating the changes, basically, yeah.

And when the balance is off. Or where you're overburdened, even as a developer, as people that create change, then you fall back into okay. What tools do I have?

What is kind of easiest? You use that and you use that continuously, cuz picking up a new language, trying to innovate is probably the last on kind of your bucket list of things you have to do. You wanna get stuff done, and I think that's how you fall into this continuous cycle of doing what has worked in the past or what you've done in the past. Because otherwise, if you were trying to innovate that you're starting with a clean slate and there's too many processes, too

many people, yes. So for example, how many times in your career did you advise to use a different tool? And it had to go through an entire chain of people who had to make a decision whether or not you could use that tool. Yeah. And all of the speed from choosing that just got sucked out. Yeah. Yeah. I do see that changing though, where the developer teams get more kind of ownership and autonomy.

In deciding what technologies to use, those are the most fun teams to work in. Yeah, cuz then things change. Faster. Way faster, yes. As long as they don't break it too hard, it's very good. Yeah. Yeah. And I think that is if you look at the spirit of what software

development was, if you look at almost all of the giant technology changes that happened, they all happened in a few days, a few weeks. Somebody built something in the basement in in like a few days and they changed the world. What we try to do is we try to force it into a A. We're trying to take the creativity, we're trying to take that out of it and we're trying to make sort of a formula on how to do it. And that formula will never

work. It's it's it's about disrupting an original idea and coming up with something new. You see it with AI, you see it with cloud, you see it with all of those things. It is a change in mindset which delivers a lot of new creative ideas. And the sooner a company realizes that they will be stronger, if they create a system where that creativity is being nurtured, the faster we get to a situation where we're actually building more things that deliver value.

And it's, I think it's the original idea behind Agile. The first thing I ask a team when I when I join a team, is okay. What can you deliver in a week? I don't care about what you have to do. I don't care about where the project is going to be in two years. I don't care who you need to report to. What can you deliver in one week? And the second question is what do you want to deliver in a week?

Because the teams already always know what they want to deliver, where the pain points are, And in large organizations the answer is always I want to have time for refactoring. And we need to clean up some stuff. Yes, always. And in smaller teams, it's oh, I want to build this feature and that gives me the, the really the confidence to say out loud that larger organizations try to kill as much of the creativity because they want to have predictability and that is not a recipe for success.

No, no. I was thinking of a scenario

especially because of the processes component kind of we talked about. If you were to start, let's say you had this idea of creating a product, can be a software related product or anything and you're going to build it, you're going to build it with X amount of people. How would you build it? Because if I think about it, I wouldn't go and start with a Scrum process and get all the

factors in there. No, you would just probably start, Well, how would you build this thing and how would it grow then? Kind of. Well, I've done it a few times. What I do is I sit together and usually these projects start with only one or two people. Yeah, so if I'm by myself, it's different than if I work together with somebody else. But if I start by myself, what I just do is I try to build a prototype and I give myself a deadline. 10 days or something like that. 14 days.

I don't want a deadline to be very far away. I can mock and stop anything I want. I want to have a proof of concept of the idea done in in a week. Yeah, because that gives me a platform to iterate on. If I work with somebody else, what I do is we both make a list of things that we really find important to have in the system in the prototype, and then we choose what we like best to build exactly, and we do exactly

the same as what I just said. And the fun thing is that all of the things that we don't want to do are usually things that are not worth doing. So they just drop off of that list eventually. Do not make it in a week they did. They just get thrown away. That's how I usually build it. And the fun thing is every week is the same reset. I don't think of it as a of course, it's a continuous ongoing process, but I don't think of it as as one continuous line.

I think of think of it as if you cannot deliver your feature in a week, it's not worth delivering because everything will have changed in two months. When I see companies with scrum rhythms of three weeks, I it's just really cringe. It hurts me. It's hard, yeah. Yeah, especially if you have like 12 teams with the three-week Sprint, how are you going to coordinate that exactly? Please don't do that. For me, it's fascinating because I was trying to think okay what

you described. That's how I would do it as well, right? You would try and figure out and get something out as fast as possible. If you were working with one person, two people, you would try and align and at least have some conventions in there. What do we think is important as a team, right? Try and write that down and uphold that and things will naturally fall off. Yeah, now I'm trying to put

myself in the shoes of a person that has never touched any code and then it becomes harder because then the biggest factor. I mean, this is hard because I'm, I'm not that person. But the biggest factor is trust, right? If you see that process happening, it's such a kind of organic process and people are building things, you have to trust that the outcome will be good, will be valid, will be

kind of what you expected. And if you don't have that trust, then maybe with your own mindset and probably the things that you've read online, you're like, no, no, no, This is how it should work on maybe this is how we can. Do it better. How we can improve it? Maybe we should try that work like this. And I feel like once something has been established, I mean it has now Scrum and kind of Azure way of working.

It's still every organization has their own implementation, but still that is what people fall back on. This is the standard. In most cases, they'll probably not say it this way, but in most cases, we'll have kind of a predictable outcome like this. Yeah, yeah. It's, I think trust is the right word there. So trust is basically based either on control or fear. So do you want to control the outcome or do you fear that it's not going to go as you want it to go?

And those those two emotions steer you into a direction where you're trying to limit freedom and limiting freedom in a creative process, Okay. I don't want to say that software development is a purely creative process. Getting to the idea is a creative process. Working on it is a skill and execution. But if if if somebody who has never written a line of code

thinks that they can control a process where the end result is unclear and they don't know what they are doing, and there are so many factors for that people get promoted to positions for reasons which are unknown. People think they don't want to learn how to write software People, especially if you're like in a in a financial organization, right? Every organization has a focus on something.

So if I'm in a financial organization, there will be a very heavy focus on doing financial control on the software project. It's just in the DNA of the organization. And if I work for a creative organization, for a game design studio or something like that, the creativity will be foremost, the quality of the code will be second. So when you enter an organization, you first need to decide, okay, what is what's in the DNA of this this company, and then you need to discuss the

pitfalls of that DNA. And control is one of those incredibly difficult things to to combat, because people really, really think that by having control over the process, the result will be better, while what it actually does it, it dumbs down your developers. It causes burnout of a lot of developers. It causes bad software to be delivered because they need to deliver it on time. It's no longer about the quality, but it's about

delivering it on time. So it has a lot of negative side effects that are not calculated in that cost benefit analysis, while I have found that good engineers really feel responsible for the project. Absolutely. They feel engaged. They wanted to succeed. They usually feel themselves being held back, so let that

out. That's what you need to focus on. The great engineering culture that you can build within an organization should, especially if you're an organization that makes their money off of software. Let that creativity flow.

Yeah, yeah, absolutely. When you were talking about a DNA of a company, right, If it's really like at its core a tech company or if it does something else and tech is kind of secondary, I feel like a lot of marketing nowadays to attract. Software engineers and people from a tech background is that every company is a tech company first and foremost, right?

How would you kind of distinguish the companies that are real tech companies and the companies where it's just kind of a marketing talk and it's not really there in the culture and the DNA? I would. So the first thing I ask a company, if they call themselves a tech company is Okay. How many projects do you start in a year? And if that's lower than 10, then you're not a good tech company really.

Yeah, well, yeah, it's even if it's just the basement project, even if it's if it's just somebody building something and they're able to present it or internal tools that are being developed so that the lives of the developers get better. You know, those things need to happen. If they don't happen, you're not a tech company, at least in my perspective. Which basically means if you're not innovating. No, because the new things spin out of innovation. Yeah, yeah, yeah.

And you should innovate on all levels. So what you said like half an hour ago about making the lives of engineers better, that should be your core focus if you want to increase productivity, not put a process in place. How can I make sure that the wasteful time of an engineer, time that they are not in flow time, that they are losing to other things? How can we reduce that? Yeah, How can we increase the flow time of an engineer?

Because when you're writing and you're debugging and you're writing and you're debugging, you get into this flow state. Time goes by very, very fast. You cannot predict what you'll end up with as a result. But time will go really fast and good engineers, or at least trained engineers, can achieve that two, maybe three times a day. But they need like a break of two hours in between because it's very difficult to get back into that flow state.

Once you're out it, it's it takes a while, yeah, yeah. And and so tech companies build around that.

They don't have a playground in their office because it's cool to have a playground in your office. They have a playground in their office. Because when you get out of flow and you get into a completely different state, like you do a workout or you take a sauna or you slide of a slide from the 4th floor down to the basement, that is when you're recharging yourself to go into the next flow state. Yeah, you. Decompress. Yes, you need to really swap out of that mindset. So.

So getting developers into a flow state, keeping them into that flow state as long as they can. That means don't have open workspaces. That means have isolation booths. Let give everybody their own office. It's one of the reasons why working from homework so well for developers, because they can, at least if you if your home is large enough and you're not so it. During Corona it was completely different, right?

But now when you're working from home, I close the door, I have my own coffee, I put my headphones on, put some wise white noise in the background, and I start working right. And every time that Slack message pops up, I go nuts. So I turn off Slack. Turn it off. I turn off all of those things. I turn off my phone and I just work that. If if your company is stimulating that you're working for a tech company. I mean. It might be then that I've never

worked at a tech company. I mean this company is probably one of the, I mean I've not worked at a lot of companies, let me preface that. But companies that know that and have people around that facilitate that. This is the only company that I kind of have that feeling that we're going towards that or that we have that. Basically I am also a consultant.

So I've been in other companies and I've never seen that part of it where it's being facilitated that people are as effective as they can be. Usually that's the thought, but then what they introduce is more processes, more communication lines, more reports or more information, more transparency. And then now I'm thinking that all falls back into trust because predictability and fear of delivery and deadlines and people that manage probably things that are kind of out of

their control. Because if you're managing

developers and you're not a developer yourself, you're not in there in the trenches, then a huge part of your responsibility. Falls onto other people, right? If the project doesn't get delivered, then who's to blame? Is it the developers? Is it the person responsible for the project, the project manager? Project lead? That's a hard one, because then kind of a big slice of what you're delivering as a team, you being responsible for the project is completely out of

your control. And then I fully understand that you want to try and control that process because at the end of the day, that's probably what you get. Kind of accounted for. That's your accountability then and there, Yeah, yeah, yeah. But that is also one of those fallacies because every software thing you start has a larger

chance of failure than success. So what you should do is you should stop something that is not working fast, and you should give freedom to things that are working or are still working because they can fail anytime. That means you need to have a very agile mindset and if you have control in place, you have a fake sense of stability and you're making promises that you probably cannot keep. It's the reason why projects go out of over budget. It's the reason why we put more

people on a failing project. Well, you should reduce the amount of people on a failing project. If a project doesn't work but you really believe in the project, the best thing you can do is have only three engineers work on it. Or two. Yeah, just remove everybody else and just let them go. Let them focus. Yes. Yeah, I always make the joke. Get a room with a door with a big space below the door so that you can just shove a pizza under it and that that's the only thing you.

Should do. Take away the trash and that's it. Yes, let them measure time by the pizza boxes being shoved under the door. And for some reason, I I don't see companies being able to relax and take a step back because just imagine if I have 100 people working on a project that is overdue, that's late, that doesn't work. Well, if I now scale that back to 2.3 people, and if I do that, I I do, of course I will do it

redundantly. So I will put five teams of two people, I will have reduced the the total delivery cost, I will have reduced it by 90%, but the chances of success will have increased enormously. And then you look at the projects that are going well, that's where you put the money in the projects that are going okayish.

You ask them whether or not to join the project that is working or if they want to continue on their own, because sometimes it takes a little bit longer to prove that you're doing the right thing. So they can, they can just have that choice, either join the project that's going well, that we're funding or putting a lot of money in or continue your own thing and the project that are not going well. Yeah, just stop the project. So the stopping is so hard.

I feel like. I mean, especially me. I'm a curious person. I like to do it all, and choosing not to do something is harder than choosing to do something right. I like doing a lot of things, and I feel like organizations have a very hard time making decisions and making priorities. And I've never seen anything being cut. Like you said, if something doesn't work, we still want this. Throw more money at it, more resources, more people, the whole shebang. Yeah, and it might not ever

work. Yeah, yeah, we still try. Yeah, yeah. And most games, for example, are

released because a deadline is being pushed on them. So there is not a single living game developer who says my game is done. This is, this is just perfection. We can we can go live now.

They always say no, it's not done yet, but that pressure of of delivering is very important. That's why you kill a project that doesn't work. You tell the developers, okay, you'll have 10 more days. If in 10 days you cannot prove to me that it's working, it is not your decision. If we're going to continue with the project, I do understand that it will negatively affect you because you've put all of your energy, your love, your resources, your happiness into

this project. And if it if it doesn't work, it doesn't work. And I understand that you'll feel very disappointed. Take two or three weeks to recover from the disappointment. But if you cannot prove to me in 10 days that this will work, we will stop it. And then sometimes you'll see in 10 days, hey, they have managed to fix it. I would always advise doing like a review from an external party when that happens or you need to

stop that project. It's a very hard decision, but that's why the decision should not be made by the developers themselves and the example you just gave. I find it really hard to stop a project. Yes, of course. Yeah, yeah, absolutely. That's why you should not decide to stop your own project. Fair enough, fair enough. The thing is, if no one decides

that, I feel like, and some of my colleagues have pointed this out, they have worked on something for a year, maybe two years, and then it's been put on the shelf for maybe half a year, maybe a year, and then it might not ever go live. I'm sure it was a fun project. You innovated, you did new technologies. But the fulfillment of people using it and adding value to the world or to people that is,

that's a big hit. And I feel like that hit is so much bigger because of the one year or even 2 year investment then those ten days to kind of save and have a make or break moment. Yeah, it might sting compared to it, but otherwise it's really rough. Yeah. And. The funny thing is when they are on a project that is delivering value, that's that's being used, all of a sudden that fulfillment is there and they love it doesn't really matter what

they're working. Then if people use it and see the value, that's also how a lot of pet projects start like we have. We do knowledge exchanges here at CBIA and the website is built and maintained by mostly one person, sometimes two or three, but mostly one person. And he said I love it because if shit doesn't work, people find me. They say so and so doesn't work. Or if they have a cool feature. I I discussed it with some people and I implemented overnight.

He's like, I fixed a bunch of things overnight. People were like, wow, that's fast. That's awesome. And he's like, that's what I do it for. That's it. Simple as that. Yeah, that's very cool. Yeah. And and probably and I don't

know if this, this, this, this is true what I'm going to say, but probably he doesn't do a lot during two or three or four days. And then he knows how to solve that one problem that somebody came up with. And then maybe at 11:00 he opens his laptop, he just bangs out the code, then it works. And then probably during the in the next three or four days, he doesn't do a lot because he needs to recover from that burst of energy that it took to

deliver that feature. And then probably he'll refine and tweak things just because that first the blurb of code wasn't good enough. Yeah, always. And that's the way I think every good developer works in the morning. They read, read it, or they drink coffee. And they do not do that because they're procrastinating, because they don't want to work. They do that because they're procrastinating, because in the back of their mind they're still trying to decide how to solve

the problem. I've trained myself to think about new problems and how to solve them by doing other things. So for example, one of my hobbies is building compilers. So I build compilers to think about problems, and that's not it's because it's so far removed from any problem space I usually deal with at work that I can build, that I use different languages to learn. You learn different concepts, but then in the back of your mind you're working on that problem.

And then as soon as something clicks, you don't even think about that compiler project anymore. But you open up the project you're working on and and I cannot be distracted for two or three days. I'm just in a haze and I build out that feature. Yeah, yeah. Beautiful. Yeah. Is that a conscious thought

process that goes on or is it so unconscious you don't even kind of realize it? I've learned to focus it. It took a long time. So a lot of my managers would tell you that, that my personality, I have ups and downs. And what those managers failed to grasp is that the downs are when I haven't solved the problem and the ups are when I've solved the problem. And in the downs, usually people give me more work. You feel better? No, no, no. If I solve the problem, I will feel better.

Exactly. That's that's one of my personality tweaks. And you need to learn about yourself every day. So it's a challenge to confront yourself with the things you're not good at, to decide whether or not to get better at those things. But it's also a challenge to just get to know yourself. When are you running against that brick wall and how are you going to go through that and what is it going to cost you when you finally break, break through that wall and what what

are the benefits going to be? So finding out about yourself, especially in a work environment, and what you're good at and how to evolve that is the part that I distinguish as seniority. I don't think a senior is somebody who really knows how to program better than somebody else okay. I think a senior is somebody who knows okay This feature is really difficult. I'm going to have a lot of trouble with this. I also going to have two or three other developers knocking

at my door for with questions. Can I handle that? Can I distract myself while I'm thinking about that feature? Because I I I'm a good developer and that's not by nothing doing nothing. That's because I work hard at being a good developer. I train, I do daily exercises. It's like a yoga routine, but then we're coding. But do I have the patience to support an entire team or more teams or an entire department while I'm working on my own stuff? And can I handle that?

Yeah. I think if you can answer yes and you can teach yourself how to do that, that is how you become a senior developer. I love that, Yeah. And I like that a lot because I feel like there's a lot of unknowns like on my day-to-day, I'm like, OK, I don't know how to solve this yet. And it's probably because we're

on kind of a newer project than it might be, a domain I've never worked with. But I do have the confidence that we'll figure it out. Not me personally, but in a team setting that we can sit down and we can figure out kind of how to do this. I have the confidence for that. And then on the side for the things I do know what to do. I do my own things and for other people that I know kind of what they need to do or what needs to happen, I know I can support

them basically. That they can come to me and we can sit down and we can kind of figure it out in that way or I can guide them and I can get back to whatever I do sometimes. Some days I don't feel like I'm productive at all. But then like you mentioned, there might be a window in there few hours that I do whatever I needed to do. And then all of a sudden all of a lot of things that were on my

plate are done. And it because it's probably because a lot of things were brewing and I know what needed to be done. The only thing that was kind of missing was actually doing it then. Yeah, yeah, yeah, that's the feeling. Yeah, I personally, I've learned that by writing.

So if a story doesn't work, you know that a story doesn't work. Yeah, if you're writing A blog post, or in my case, I write part of my novel. I know when something doesn't work, okay. But I keep writing. Anyway, I know this is going to be SHIT, but I just continue because I know that when I revise that chapter, I will have written more chapters afterwards. And I can revise it and make it better because it is about the skill of writing and the determination to continue.

And then later you need to be able to trust yourself that you can fix the errors that you made. And that's exactly the same thing what happens with the team. So you know that your colleague is running his head against the wall with a very difficult problem. You know, you cannot literally help him. So what do you do? What I what I usually do is during lunchtime, I just call him up because we're all working remotely these days, and I ask if he wants to play a game of chess.

We just talk about the dog barking and we just play a game of chess and we do something completely different. And then at the end of that session, I ask him, what things do you haven't you tried that you would like to try? And then usually in that in that moment you see those eyes light up. Oh, and then at the end of the

day you get a message. I fixed it just by taking somebody out of the the difficulties that they're in because it's really hard to pull yourself out of a mental state and then help people to overcome that. I think the that that is the core responsibility of a management role in a software delivery team. It's the core responsibility of an organization to give the trust to the people. If you don't trust them, then

please fire them. I mean, it's not good for anybody if you have people on your team you don't trust. Just dragging it out, yes. Please, just bite the bullet and fire them. But if you trust them, really trust them. Yeah, it's all the way. Yeah. Yeah, I like. That a lot. Yeah, the hard part I think and especially early on is having the self-awareness to put a

pause on it when you're just feeling it doesn't work. Right now it can either be for a day, it can be for a few hours. But again, that is really hard. Like, I still struggle with that. I'm not, I'm not going to sound perfect. No, I can go a whole day and be stuck and then just have the aha moment when I'm cooking the same day or when I wake up the next morning all of a sudden. And I can be like, man, that was obvious, but I just didn't get to it. It just, it just didn't work.

And the hard part is realizing that, stepping out of it, taking a walk, doing something else. And I'd like that people can facilitate that, right? Yep. How we having the knowledge that someone is stuck and the superpower then to take them out and to give them a different perspective, I think that's cool. I don't think it's a superpower. It's just a form of empathy. Yeah, It's not even a superpower. You're right. It's it's just it's a form of

empathy. And the reason why I say it's a form because it's not true empathy. True empathy is really being able to empathize with how difficult it is for that person to be stuck in in that situation. This is like a sort of a fake empathy where you realize that somebody is stuck and then you try to help. It's like a nudge. It's a nudge. Yeah, it's.

Of course having true empathy will help, because if they don't respond well to your efforts to be pulled out of that situation, you need to know when to let go, or maybe escalate to their manager or to somebody else. And you need empathy for that, because every escalation is difficult for a lot of people, especially when it's an emotional escalation. But I've I've worked with some teams where emotional escalations were really, really difficult to manage.

And to be honest, I have been in situations where I could not be helped, even emotionally. I was so far along the path of not agreeing with the situation I was in that I wasn't able to step back. But that's your. Growing that, that's the path you need to take to grow. Those are difficulties you need to face, but you need to be honest with yourself. You need to look back on them. You need to say okay did something wrong. Maybe tell the people that did you work with that you did

something wrong. That's that's very difficult step to take. But people will appreciate it if it's an important one. Yeah, yeah. And it. Will make everything better. But that that said, that's only looking from yourself, right? The organization should build a culture where those things are possible. Absolutely. You know that's a. That's rounded off there, man.

This was a blast actually. Normally what I do is I sit down, I let people know we do kind of a pre show and then we we flow into topics. I don't think we did that. We just started talking. Yeah, yeah, yeah. And we of course, we focused a lot on, on almost a single topic that's how to how to improve organizations or what organizations could do to improve. But I think the the topics that we touched are much larger than that. I think these these conversations are really good to have.

Yeah, I love having them. Yeah. Are you? Are you? Thinking about starting your own podcast? Since you said that before the show? It's just too much work now, too much work. I I would love to do that. I have two types of top of podcasts that I would really like to do. So I would look like to do a contrarian podcast. That is have two two people from completely different lines of work that are more or less opposed to.

So have like a nurse together with an IT engineer and then have a conversation about the problems that they're facing in their work or the things that go well or the changes that they need to do Or you know, show some sort of empathy over different the lines. As I think the conversations we're having these days are not broad enough. And so this is just an idea to get to a more broader conversation. But I don't. That'd be an interesting one though, cuz I feel like.

A lot of times I try to be kind of devil's advocate here and there, but it's hard because I do agree with a lot that's being said on this show. There are some stuff that I'm like HM, I might need to re listen and see what I truly think because it's also hard to do that in the moment. But if you're with people that are just from a completely different domain, then probably their perspective on each other's line of work and their insights are just going to be

interesting. Yeah, and I mediate that conversation exactly. Yeah. I don't think anyone's doing that. I know that is hard to set up, by the way. Yeah, continuously. Yeah, that's really hard to set up, but thank you very much. I really had a great conversation. This was a lot of fun. Cool. We're going to round it off. Here, I'm going to put all Carlos's socials in the

description below. Reach out to him, let him know you came from our show. And with that being said, thank you for listening. We'll see you on the next one.