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.