The code you write is technical depth.
By definition, the best code you can write is the code you don't
write. Sometimes delivering a feature
is going to buy time, runaway to the business.
You pay the salaries, which includes yourself, right?
So you really need to find a balance there.
You can go for all the technical excellence you want, but if you
don't deliver the feature that is going to make the business
sell to the users, then yeah, it's pointless saying no.
It's also a sign of seniority. It's more about negotiating it.
What is the benefit of this feature if there is another way
we can tackle? If this cycle of creating goes
faster and faster, then we do need to step back and see what
can we simplify to make something that is scalable for
the future in the end, but also digestible for people until we
get to a point that we don't need to do that anymore.
Joining me today is Alessandro Maltone, Senior Software
Engineer over at Aqua Blue, and we discussed one of my favorite
topics, balancing technical excellence with delivery speed
and business outcomes. And this topic is even more
crucial when we're talking about startup and scale UPS.
So enjoy. You've been in a lot of
organisations in, I feel like early stages and at a smaller
scale than I have experience with.
And I'm curious how you view technical excellence on the one
side, but also delivering results, working towards
business outcomes on the other hand?
Very good question. Yeah, I think this is actually
something every engineer should should 3-4 and should pay a lot
of attention. I think in the past what I've
seen it's people focusing either on one or the other.
Usually as an engineer, software engineer, they focus more in the
craftsmanship of the code, forgetting about the business
context. So that I believe the the the
truth in the balance. But that also changes based on
the company you are in and the business you are in.
Like you said, actually Beckett with transfer was really a
really nice journey because I joined it when it was
essentially entering the scale up, scale up phase.
And I believe Aqua blue is in a similar stage.
That's also one of the reasons I I joined it.
I really enjoyed that, that part.
And so you know, when you are at the beginning, especially in a
start up, maybe you have an idea that is sort of validated, but
you didn't still find, you didn't find yet the product
market fit. And in that case you really want
to focus on delivering something fast, maybe not super polished
to validate first idea. And then once you have the
product that you know users want, then you focus on
craftsmanship and instability. This is still a very subjective
thing then, right? Because I can say this is the
right way architecture wise or code pattern wise, but I feel
like it's still my opinion. So even if we go for technical
excellence, we're going to have a a discussion likely if we
disagree. And then if you take that out of
the mix, OK, where is the balance between delivering and
technical excellence? There's a lot of discussions now
on what is the right What is the right way?
Yeah. And it's very hard.
I, I don't think I have the answer, the absolute answer.
It's a very hard one to, to answer.
But I believe that taking into context, this is something I saw
in the past through my career just and I did that myself by
the way, at the beginning, just ignoring the context, the
business context and just going full all in on the technical
excellence. There is usually a balance
between the two. Sometimes you want to favor
speed instead of that doesn't mean you're going for an audible
solution. It's just a trade off, right?
You want to go for the good enough solution and defining
good enough. It's a hard.
That's very hard. Yeah.
I feel like people also have gotten burned before.
When you go for speed, let's say, and then you're like, OK,
we have product market fit, let me clean up all this technical
debt that we've realised. And then the organization could
be like, no, no, no, we have to strike while the iron is hot.
We have to keep going, right? So then if you compromise on
things that actually matter, you might not ever get the chance to
do it. So then people kind of put that
as early as possible. I'm not compromising on these
things because in the past I've never gotten the chance to
straighten that out. I think that's quite hard when
people have gotten third before. Yeah, yeah.
But again, if you keep in mind the business context, then I
think you're going to have more answers that are going to
facilitate your decision. Think about, for example, I
started with this at the beginning, but again, choosing
speed over the technical excellent excellence part.
Sometimes the living in a feature is going to buy time,
runaway to the business and you know, the business is there
ultimately to generate revenue, which hopefully generates a
profit. Yeah.
And with all that, you pay the salaries which includes
yourself, right. So you really need to find a
balance there. You can go for all the technical
excellence you want, but if you don't deliver the feature that
is going to make the the business sell to the users, then
yeah, it's pointless. So you really need to watch out
for that. If you're an established company
where you know there is an established product and you know
also that for example downtime is going to cost you millions
because the products established and use it by millions of users,
then it's a different story. Then you can focus.
Yeah, then probably you will focus way more on the technical
excellence. Maybe you have a team dedicated
to exploring new experiment and new opportunities etcetera.
But again you have the business context with you.
So based on that, you can see you can make the trade-offs and
you can make informed decisions. You as an engineer, you've gone
from company to company and you have this mindset, right?
I need to balance technical incidents and results.
And I feel like if the team has that mindset, then we're good,
right? Because we know we need to
balance. So we're going to have, I think,
kind of really good outcomes with regards to the work that
we're working on. How do you check in with people
to see if that have that similar mindset, either through applying
to companies or maybe even from a hiring perspective?
Good question. Well, first of all, you can see
it from the product itself. For example, with Aqua Blue,
when I joined it, I saw the product, I saw what the guys
were doing and I was like, OK. And also I talked with people.
It's really hard to tell, but I could sense what was going on.
It's also the type of the company as well.
I've been in more corporate companies where everything, you
know, it's slowed down by bureaucracy and that's
understandable. But again, it's not really my
style. While here you know you can see
the energy of the people as well.
Excitement. Excitement, the love they put
into the product. Yeah.
Also going fast doesn't mean, you know, you necessarily
compromise on technical excellence.
So all those things, it's really hard to get it from a couple of
interviews, but if you put all together, then you can get a
nice idea. Usually.
Also what I try to do is I even ask to meet the people myself,
even if even, you know, after clearing the interviews, just to
get an idea. Because in the end the agreement
is mutual, right? So if you go there and then it's
not a fit, it's going to be bad both for you and for the company
as well. So we both want to be in the
same place there, both want to be aligned.
That's really strong that you say, OK, I've passed the
interview. I just need to make sure that
there's a few things in place that I want to see, right.
I feel like especially early stage companies, I've not had
the opportunity to join them. Like because I've, I work at a
consultancy, so I've only been a consultant.
I really like being part of an organization.
But yeah, the fact that people know I'm external, in the end, I
don't have the same skin in the game.
That also means I can say speed is more important or technical
excellence in this case is more important and I don't face the
consequences as much, which is also interesting, right?
Because my my incentive is completely different.
I come in to do a certain job that someone else decided and I
do that job because I also agree.
Otherwise I wouldn't have joined.
But for people that actually joined this team have skin in
the game, I feel like alignment on that front is really
important and checking out the product and checking the mindset
of the team is a huge part of that.
I totally feel you. I've been there.
Actually, my first experience was in a small agency, so we
were doing products for different clients and like you
say, you don't have the skin in the game and sometimes you don't
even have the well, I was pretty junior at the time, so that also
played the role. But you don't have even a say
in, in that, you know, the company's establishing that we
need to deliver this product fast in order to move to the
next one. So you don't really have an
opportunity there. Maybe you need to choose just a
speed and deliver. You still try to do your best
for the given client. But yeah, I guess I really like
to cultivate products. That's what I love it.
When I joined it, we transferred, we were working.
I say always for ourselves, OK, Which it's in part true because
you have your users, right? You work for them actually.
But what I meant is, you know, we're not creating a project and
giving it to a client and then delivering it and then we start
on a new one. We're actually working on the
same code base. For years we were evolving the
code, the code base. We're planning for that.
And you are just cultivating this product and this is
something I really enjoy. Huge ownership, yeah, yeah.
I could never imagine me joining a start up that I fully believe
in and the product taking off and then ever leaving to be
honest, because of that ownership, feeling that
ownership and responsibility. When did you decide, OK, some of
the organisations that you've moved on from are no longer from
me? Did it have to do with growth?
Did it have to do with a difference in mindset?
Yeah, I can can have different reasons.
I can see growth being one of them often not for me, I would
say. So, for example, Beckett with
transfer, I don't have any problems in this, but the
direction the company was taking was not really the one I was
feeling comfortable with. Yeah, I actually realized,
really heartbroken because I really love it working with the
people there. I think it's one of the best
places I ever worked at so far, if not the best.
You see, I left. Yeah.
Let's see if a couple can do
better. But for now, yeah.
It takes guts to leave then still if you have such a good.
Experience, I really had a hard time.
I think it was a combination of things because, you know, that's
when Kenyon came in and I really love bikes, as I said, and I
really mean, I'm an avid biker. So yeah, that kind of made made
it a bit easier to to do the move.
Yeah. But yeah, as I was saying, the
direction of the company was not, and I was talking, I'm
talking about the company and, you know, the product and what
we were focusing on. I was not really happy about
that. I really saw a shift in the last
six months before leaving. And then I started to think
myself, yeah, this is either going to have, you know, a
certain kind of outcome or another kind of outcome.
Yeah, it's all over the news. What happened at a couple of
years ago when they were sold and 90% of the people was left
home. Yeah.
So yeah, I guess I avoided the. You were.
Before then, yeah. I wouldn't say, you know, I saw
that happening. No one does.
No one does, no one does. But the direction gave me that
feeling so. Some signals.
Yeah, that's that's why I left eventually.
And that could be one of the reasons.
That's why I always say keep in mind the business context, you
know, it's for your work, for your growth, for your career,
for everything. It's really important to keep
your eyes open and see how the business goes since sometimes we
engineers focus too much on the engineering aspect of our job
and that's where that for that. So that's an.
Engineer, Yeah. But at the same time, you really
need to have context about everything that's happening
around you. It's interesting to me that
you've gone from company to company and the essence, the
product of those companies have been completely different, which
means that also you, you build up the main experience in a
certain aspect. I've seen product people, they
say I'm an expert in payments. All right, I can go from payment
company to payment company no problem whatsoever, but I'm
experienced in payments. Yeah, I'm happy you pointed out
because it's not a coincidence. I really believe into the
generalist approach. You know, you have a generalist
and a specialist. Actually, if you look at my
career, then you're like, yeah, but you focus it on Android.
So you are a specialist. But like you said, I move it
through different kind of companies for the agency.
Then the product focus at the one which is Wetransfer, then it
was closer to the hardware which is was Canyon and it was not a
tech company. So it was actually a completely
different experience because in and we transfer tech was the
engine of the company and there has some consequences.
Yeah, some pros and cons. While at Canyon you know, the
tech part is more of an accessory because the bikes are
clearly the engine of the company.
And now I move to Aqua Blue, which is even closer to the
hardware. And I will say tech, it's
equally an engine as it is hardware.
Because without that, yeah, the machine wouldn't run and they
wouldn't invest in in this new project.
So it's pretty cool to to see that happening.
And like you say, they expand my domain.
And that's something I really enjoy because that keeps me
growing from a technical point of view while also giving me
context about how different companies work and how they
behave. When we zoom in on that
experience of yours where you said, OK, this was my fondest
experience, especially keeping in mind balancing technical
excellence and speed of delivery with business outcomes, what are
some of the ingredients that were in there that made it such
a a fond experience? I would say talented people for
sure, people who care about what you are building.
So those are two of the main ingredients.
One I haven't experienced directly, but I believe it's
also part of of that. It's communication, clear
communication. It's unbelievable how often you
can, you know, agree on something with another pencil
person and you believe you agreed on the same thing and
then actually you implement two different things.
This happened to me literally 3 weeks ago.
Yeah. So it's that's also really
important. So I would say those are the
three ingredients. And yeah, just careful what you
do. You know, if you, if you love
what you do, I know it's kind of a cliche because often it's in,
but if you love what you do, then yeah, you you're going to
drive on it. Ownership for me has always been
a big thing. It's just in my upbringing.
I've also seen other people that where work is their whole life
and they really take that high level of ownership and
responsibility and if work doesn't go great, it really
impacts them, impacts them to a certain degree that they might
burn out or they might be very jaded towards a similar
experience. But it is the skill that we want
in the people that we work with in the environment that we have,
which I think is quite interesting, right?
Ownership has very big pros and it can have cons as well that we
need to recognise. That's a good point, yeah.
Maybe ownership also connects to another one, which is trust.
You know, that's also very important.
If you have if you can trust the people you work with, then
that's also going to be set you for success.
Yeah. But in order to trust people,
you really have to you really need to have talented people.
So yeah, among ingredients, I guess, you know, when I say
talented people, you can link it to hiding essentially.
It's really important to hire the right people.
It's very hard as well, but you know, they say it takes one bet
able to pollute the rest of the environment.
Yeah. So really be careful that take
your time if it's needed and just try to hire, you know, the
best people, which doesn't mean only the best technical people,
but also the people that feeds the company, the culture and has
the right mindset to approach the problem that you're trying
to solve. Yeah.
I think it's interesting that if you are in very early stage
companies, those are the things you need to look out for, right?
Are these talented people, but also you take pride in ownership
in the product that you're building.
So it's not just you on this smaller scale with regards to
the software that you're building.
You're building software towards business outcomes and you want
the whole company to succeed. And hopefully you have a good
deal that when the company succeeds, it also it also gives
something back. But that's also part of the
risk, right? It's really fun to go.
Usually that's why they came up with the stock incentives in
tech, right? You then are part of the
organization to really own a stake in it.
And that means that whatever the impact you have on the company
is also going to benefit you directly.
So I think that's, yeah, a good approach.
Then like you said, hopefully you have a good package because
sometimes it can be a small one and then you believe the impact
is going to be also hugely beneficial for you and it's not
the case. Yeah, that also comes with
experience, but it's also hard to to judge.
That's part of the negotiation process process whenever you
join a company. And I believe it's, it's quite
hard, especially in Europe because I believe here equity is
not as big of a part of the package compared to the US.
Yeah, maybe because of culture, maybe because of.
I know for sure also because of legislation, yeah, sometimes
it's less favourable here to go for that.
So yeah, something you you need to educate yourself as well.
Yeah, definitely. How have you seen companies or
maybe you've been involved in that as well, get really good
talent in the door? Because I'm also wondering,
there are different aspects of the hiring process for software
engineers specifically, and I'm curious how they're going to
evolve nowadays with the genetic tooling in the mix.
Yeah, very good one. We are in the middle of it.
So it's actually quite hard to to look at that.
Back in the days, I would say we we transfer.
Well, they'll they're the name helped, I believe, because, you
know, a lot of people wanted to work at Wetransfer.
Yeah. The reason it was not only
technical excellence, but also the product we were building.
We really cared about the community around us.
We were trying to do good on top of doing a good product.
And that also attracted certain type of people.
Yeah, people that care. Yeah, exactly.
So that's one way of of doing it.
Then what else? We have to be honest, the
compensation package as well is going to play a role.
If you don't pay enough, it's really hard to it's.
Not going to happen, Yeah. The third one is the idea or the
product that you're building, you know, if some people is sold
on it, that's also going to convince the people to join.
It can be, you know, for example, with me at at Aqua
Blue. On top of everything, I believe
in the product. I really like it.
It. Yeah, those are the ways I would
say. And also if you have talented
people, which is a vicious cycle in a positive way, but if you
have talented people in place, then you're going to attract the
people who wants to work with those people.
I'm that kind of person as well. When I hide, for example, I
always say try to hire people that is even smarter than you.
Some people see that as a threat.
For me, it's not. I see them as someone who can
enrich both me personally and the company.
What are you going to gain by hiring someone that is less good
than you? Allow me the term, you have to
hire. You have to aim for the
technical excellence also within the people, not only within the
code base or or the technical aspect of the product.
So yeah, that's also a way of trying to feel your work
environment with top talent. How have you kind of approach
the interview process? Because for you Android as a
technical expertise is what you take with you.
Your domains are kind of your generalist expertise.
Do you fall back on the technical skills or what do you
try and highlight of yourself throughout the interview
process? You mean as an interviewer,
right When hiding? Yeah, Yeah, good question.
So first of all, sometimes setting up the interview process
doesn't depend entirely on you. So for example, if you want to
have take home assignment, sometimes it's not up to you to
decide if it's allow it or not. That that also comes with
seniority. I guess usually what I try to do
is have a sort of technical round.
Well, of course behavioural interview that also doesn't
involve only me but other people within the company.
But when it comes to the technical round, I really love
doing what I call a live PR reviews because then you can see
how the person give feedback, receive feedback, what they're
looking for within the PR and so on.
Then it's that's one of the ways I really don't do, you know,
kind of a a lead code and stuff like that.
Yeah, I don't have anything against it.
I know why big companies do it. It's fine.
But I believe again, business context, if you have, you know,
in a nearly start up, you don't really need that.
Or if you're trying to you're in a big company, but you're trying
to tackle problems that are different from the ones that
leak code allows you to tackle, then you focus on on something
else. Yeah, so that's it.
And then I would say potential as well, which is really hard to
to spot, But you know, how open and willing, willing it's the
person to grow and to learn and how open is to to different
technologies. That's also something important
to to keep in mind when when hiding.
And now with the I tooling I haven't had the opportunity.
Yet. But what I will say is I will
observe how they use AI within their workflow and what I will
be interested in it's how they can maximize the efficiency
during their daily job and maybe even learn from it.
For sure. How is it when you then
interview for example? Because that's what I actually
wanted to know. But I'm also interested in the
interviewing process. How do you prepare?
Because you want to highlight your own skill set and
expertise? You already say lead code is not
my thing. Do you shy away from early stage
companies that do that? I think that might be a red flag
to be honest. But yeah, it is a tactic.
It is well you have We have to be honest here as well.
If you have the, if you can do that, you have the ability to,
to choose between different companies and sure you can, you
know, filter the ones you don't like and you filter also based
on, on on the process they have the hiring process.
If you have the privilege of doing that, then why not?
I usually don't shy away from that because I still see it as a
challenge. So it's fine.
But as you pointed out, maybe there is a misalignment cultural
wise. So then I will try to keep that
in mind. And again depends also on the
problem we are trying to solve, right.
If you are in a Fintech, I don't know, I can imagine you are
heavily on algorithmic stuff because you are solving problems
that tackle that. So then yeah, I can totally see
that's happening. If you are in a product start up
where the product is focused on the creative industry and so
it's more about UI design etcetera, then I will focus more
on those skills. If you are on the hardware side,
maybe you are, you know more interested in senior
communication, Bluetooth communication, low level stuff.
So yeah, I will also judge the companies based on how they do
hiding compared to what they're trying to build.
Yeah, yeah, makes sense. With agentic tooling now in the
mix, I feel like things like technical debt can either be
solved on the spot or maybe retroactively once we have
product market fit can be solved way quicker than actually having
to prioritise something, having to have dedicated time, a week
of only technical debt. I don't think it's going to be
there much more in the future anymore, but companies still
need to enable their engineers with tooling, with the right
amount of tokens, with the right amount of flexibility to also
use the tools. And there I feel like startups
and scale UPS really have an edge because there's a lot less
engineers and they have a lot more power over product
direction, especially if it's a technical company.
Is also that how you've experienced it so far?
Let me challenge you there. I, I, I see where you're coming
from and I actually agree. I see it myself during my work.
So I usually try to not compromise on technical depth.
And now sounds like I'm contradicting myself because
initially I said, you know, you're going to have contacts
and make trade off. What I mean there, Usually it's
I try to negotiate on the features we are trying to build.
That's also very important in my opinion, saying no, it's also a
sign of seniority. And by saying no doesn't mean
that, you know, you're going a meeting where you're planning a
new feature. They ask you, let's build this
feature and you're like, no, no, I don't want to build it.
It's more about negotiating it.
So, you know, questioning what is the benefit of this feature,
if there is another way we can tackle that.
Actually, I joined the, I, I mentioned that I joined the blue
and we had a very tough title deadline.
The first thing I did was set up a meeting where we went over,
you know what we wanted to build.
And I was like, OK, this is a no.
This is not like this is a no, but this is not going to happen.
It's not going to work. No, it's not going to work.
And then they were like, yeah, OK, what can we do?
You know, especially with seniority, I guess you gain also
authority. So then easier to, it's easier
to negotiate, but I think you still have to earn this and, and
show this up. So then I was like, yeah, you
know, the what you're trying to build makes sense, but there are
a few things we can do here in order to make sure that we're
more more predictable. And thus I have more chances or
actually I can make the deadline.
No, I have more chances, I can make the deadline.
And so we started to, you know, negotiate on the UI, for
example, some components. I tried to suggest how to
simplify existing ones, and they were also super happy with it
because, you know, people usually have a lot of fear in
saying no or even negotiating, asking questions.
But what I try to think in those cases is the other way around.
Let's say I say yes, and then I don't make the deadline.
No one is going, yeah, not only for me, but no one is going to
be happy. Yeah, not the other
stakeholders, not myself because I will be, you know,
disappointed about myself. The product is not going to
launch. So it's also a problem for the
company. It's a problem for all of us.
So instead you go there and you say, hey, I think this is overly
ambitious, but there is a compromise in the middle.
I can suggest a few tweaks. You can tell me also what is
negotiable and what's not. And then we can take it from
there. And I think that's a very
important skill we can build. And now I drifted a bit about
your original question, but to ask for that, I was saying yes,
I see it happening in my daily work in the sense that usually
what I do, it's also negotiate on those aspects we really
mentioned in order to buy time for myself to not have to
compromise on the technical excellence or not too much.
So that also means, you know, covering everything with test
and making sure that the code is it's properly covered indeed.
And tested with AI2, I am able to deliver faster.
So that's pretty nice. But I believe technical depth is
still there because delivering faster also means I can produce
way more code. Yeah.
And so, you know you're going to end up with technical.
The code you write is technical depth.
By definition, the best code you can write is the code you don't
write. That's a famous quote out there.
It's a bit. You need to, of course, write
code in order to build a product.
Yeah. But what I'm trying to say is,
yes, it's easier to put guide trails, I guess, nowadays.
But first of all, you need to have the skills in order to do
that because you can tell that I write unit test and then I don't
know if I'm doing something wrong, but I'm actually doing
that often nowadays. And the unit test they, they do,
it's often, you know, meh. I even have styles and agents
around my code base. So it's customized for that.
It gets it right, especially if I use a quite definite prompt.
But it happened to me literally this morning when I was writing
some unit tests. And then I was like, OK, I'm
going to speed up this one by asking the I to generate it.
And it literally created 2 unit tests that they made no sense.
No sense. They were literally creating a
class and they were defined. It was not null.
Fair, Yeah. And there was no value in that.
And luckily I also have an agent for reviewing the code.
And that one, well, I first of all, I quote it myself because I
reviewed the code, but then the agent also validated it because
he said, hey, this test doesn't have any value, so delete it.
Yeah. If you do not have that and you
did not review the code like I did, you would be creating
technical depth. Yeah, even having AI.
So then, yeah, I believe nowadays you do have a technical
advantage as a start up, but you still need to have people that
is skilled enough to judge what's going on and to control
this amazing rocket ship sometimes can drift away and do
very bad damages. Yeah, it's it's an accelerator
in a very interesting way because it doesn't just
accelerate you, but it would do something that you would never
do, which is then indeed technical debt.
If it's not relevant, then it's not relevant.
Then we do have to clean it up. I agree with that.
For me, there are some things that you should never compromise
on and especially with AI tooling, genetic tooling now in
the mix, things like the unit tests or integration tests, a
big test suite basically that you can be confident to go live
with, to production with is something we should never
compromise on. You should never compromise on
that part of your technical excellence to go live faster
unless it is something that you just want to test in production
specifically, right? Because then me going through
the whole testing and even then with a genetic tooling is quite
quick. So why compromise on the?
First, I will say, unless also I will add another case, you are
in Code Red like I said, they say and so you know, your
company's in survival mode and you really need to ship
something out there very quickly.
But I fully agree with you, nowadays is even if you want to
put basic cut rates it's yeah it's non trivial with AI so you
should do it. Even in code Red, don't you
think it's more risky to be like we go live with this without
tests or integration tests I. Fully yes, I agree with you, but
again, keep the business contacts.
So I don't know how red is the code.
It is extremely red there's. A shade of red.
Yeah, fair. But I agree with you, it's even,
you know, with the deadline I had, I was actually impressed by
myself or by AI or both. I don't know.
But you're still the orchestrator.
You have to. Own that.
Yeah. Yeah, I still decided to.
Cover all the tests, all the code we test.
But yeah, I was really impressed because eventually I ended up
with a decently covered the code base integration tests where I
would say yeah, more than decent unit tests were totally covered.
So really happy with it. Yeah.
So again, yes, I agree with you, you should be able to.
But for example, here is a catch.
If I went for the original plan saying just yes because I'm
afraid of saying of negotiating or saying no or just because I
didn't I misjudged it. You know the amount of work then
I can tell you probably I would I wouldn't have been able to
write at least all the tests doesn't mean no test, but maybe
some parts of the code base will be uncovered.
It is very. Strong to say no, but it's the
way you say no, right? You say no and you go in an
equal level of dialogue and you say we both want this outcome,
we both want the best. This is just not possible.
So let's figure out how we can still do this, how we can still
make this happen if you will say no.
And that's where it ends. Or then you're gonna bump.
Yeah, yeah, exactly. Like then it's like.
What do you mean? No, and how dare you and why are
you here and there are different.
Exactly. And there are also different
scenarios, right? What I saw in the past, and I
think I was guilty at some point as well, although not much was.
I worked with engineers where they were extremely unflexible
on technical excellence, you know, which meant, yeah, we need
to ship this feature. We really need to do it within
one or two months. And they were like, no, I need
to cover, you know, everything and write it in a certain way.
So it's no more than six. It's no less than six months.
Yeah. And there it's when I say also,
you know, negotiating, it's important because we both want
the same thing in the end. Also, the person coming to you
and asking, you know, we need to develop this in a certain time
frame. There must be a reason behind
it. You can ask.
So it's a simple asset. And then you can also negotiate.
If you understand the business context, you can even question
some choices. This is also something I did
recently and it's also a way of negotiating.
So I told you, we're building this new machine and we really
have machines out there. They're not Android based, but
there is stuff we can reuse from them and we want to reuse from
them because they are successful.
So that makes sense. But then I started, you know, to
go through them to get an idea of what we're going to build in
the new one. And then I saw some things and I
was like, this doesn't really make sense to me.
I'm pretty sure there is a reason behind it, but in the new
system doesn't really make sense to me.
So then again, I wrote everything down.
I made a plan, I mapped all the flows that I needed to map.
And then I set up a meeting and I asked it, OK, why do we have,
I think I ended up with like 10 flows more or less with
different features or settings. And then I went there and 1 by 1
I asked why do we need this or what is the consequence of this?
And at the end of the conversation, I believe we drop
it too. OK, so that's 20%.
Yeah. Yeah.
And you know that that has so many consequences.
First of all, there were two things that probably were never
used. I was like, why they're even
there. Yeah.
And actually it makes sense in the in the previous machine, but
in the new one doesn't make any sense.
And the second one is you have to think also long term, right?
So everything you ride today and you ship today, you're going to
have to maintain in software. It's we have, we're privileged
that as well because we can always update, you know, and
delete or fix stuff with hardware, that's not always the
case because once you ship a machine, you can still probably
update the assembly line and fix whatever it's problematic.
But for machines that are already delivered, you either
need to send a technician or, you know, replace the machine
and that's costly for the business.
So always think also long term, we think, you know, reasonable
terms. So whenever you build something,
you're going to have to maintain it.
And nobody's perfect here. I do mistakes all, all time.
So more features I have more chances are that there are going
to be errors or, you know, bugs. And so if I can scale them down,
which doesn't mean I want to provide less value to the user.
I just mean I examine the the current product and I say, hey,
is this useful? Is this not?
Then you can mitigate those problems.
Interesting. You do need an organization that
understands that, right? Because if I were to hear, if I
have no technical background and someone says more features means
more bugs, I'd be like, why don't you just make better
features? Like it makes no sense.
Yeah, Yeah. That's a valid.
Observation then, then we go into a communication territory
as well. When you especially when you
plan those features or in general when you have a meeting
within the company, I'm pretty sure you know, if you're
tackling a very technical problem, then probably you're
sitting with engineers. But if you're in a product
company and you're developing feature for the product, you
will probably have APM sitting at the table, which may or may
not be technical enough to understand.
You will have maybe finance people because they are part of
the pricing of of the feature. Even when presenting stuff to
the company, sometimes you know you present stuff to the company
to show what you did. Some company companies do that
and you will have a different audience in front of you.
So then it's important to communicate effectively.
If I speak with you and you're engineer, we can talk about back
end servers, etcetera, etcetera. Easy, easy, super easy.
If we have finance people or you know, people with different
backgrounds, then you have to translate that into their
language. Hopefully you know how to do
that or otherwise you use more generic terms.
You know, you talk about the server for example, and you tell
them, hey, if the server is down, our product simply doesn't
work. That's what they care about.
You don't talk about the back end of the API.
If the API returns four O 4, that's too technical for for
them. So this needs to be applied also
when you do those negotiations. And I think it's very important.
I think it's something you you need to keep in mind always
communicating effectively. It's it's very important.
I love that. Yeah, 1.
Of the last thoughts I had in mind was I feel like we as
software engineers are on this ever ongoing battle against
complexity, basically, and very early on, there's no complexity,
right? Because you're starting from
nothing or you're starting from something very small.
If you go in big organisations, complexity is already there.
It's all around you. So then this technical
excellence part it, it is really important, but it's also a
mindset thing, right? Are you going to go, like you
mentioned, if we have hardware as part of something and it's
harder to do a firmware release for specifically that hardware,
how much are we going to develop for the future?
Because if we still deliver things that we might never use,
but we might use in the future, are we then going to incorporate
that? Because if we never use it, then
it will be the complexity that we have to navigate around.
This is the ongoing battle. How have you seen start-ups or
early stage companies, even scale UPS, battle complexity or
manage complexity early on? Yeah, even I.
Would say if the company is going to be there, you need to
ask that yourself right when you build a long term.
So that's it's a tough question. It's of course an an extreme
case, but can happen. So that's also usually what
happens to me in deciding whenever I need to do a trade
off because I know that dropping or doing a simpler feature is
going to deliver these faster to the market and it's going to buy
time and run away to the company.
And that's how it goes sometimes or more most of the time
actually when you're in a start up, you are in survival mode by
definition more most of the time.
So you know, you have maybe investors, you are investing in
the product often you're losing money already, you're not making
money yet. So you really need to figure out
what is, you have an idea that you know it's working because
it's selling, but it's not selling enough.
So then you need to try different things in order to
make sure that the outcome is going to be positive eventually
for the company. So sure, you need to think long
term. You need to avoid.
Usually what I do is if something that will improve an
outcome long term has a very small cost or a relatively small
cost, then I will implement it right, right away.
Yeah. And my small, small cost, I
mean, essentially that doesn't affect my timeline or so on.
If you have a big one, then you need to ask yourself, yeah, what
is the benefit of this? I'm doing this in order to make
sure that the product is going to scale properly within three
years. When we have millions of users,
are we even going to get there? Is it worth the extra time I
need to invest on it now or do I need to focus first on
delivering simple but effective solution and then taking it from
from there? They're essentially buying
yourself time. It's technical depth yet, yes,
but at the same time, it's buying yourself time.
Software is there also to evolve, right?
So, and this is also one of the privileges we have again, if we
do the example with the hardware, you ship something you
cannot waste of course upgrade the machine, etcetera.
But the hardware that is already out there, it's going to be very
costly to update. While with software you can
still release updates without having to go physically there.
Doesn't mean it's not going to be costly because maybe you need
to re architect a service you have, but you have you can buy
yourself time. So that's that's also very
important you have the flexibility to do.
So has there ever been a a decision you made where you're
like, OK, that was the wrong one or I burned myself here, I
shouldn't have implemented that for the long term.
I should have gone more for the short term.
Anything that you'd like to share there?
Yeah, I'm trying to. Think, I think I'm not going to
make a specific example, but you know, keeper jobs.
Also future jobs? No, not for me.
Maybe actually. For others, also for me.
But yeah, there were situations where I actually was the other
way around. I I was advocating for the
simple solution, but people was going for big tech solutions in
places that were not big tech in my opinion.
And that ended up, you know, consuming a lot of time within
the business and not really giving any result that was
justifiable by all the time spent and the the time the
resources spent on it. You went with the big tech
solution in. The end.
We went with the big tech solution in the end.
Yeah, for something that was barely used Yeah.
So then you know it's. And I was not responsible for
that so I'm not saying this to, you know, make myself a better
Yeah, I was actually trying to fight that and I also respect
that yeah, it just happens. I I'm pretty sure the other
person's. Had their reasons to to go this
way. Maybe they believe believe it
more than mean in the future. We were building of course, but
I was like, yeah, let's try fields, you know with the fast
iteration and then we can indeed iterate over it because if we go
fast you ship and then you see no one uses it then you have
written answer and you don't invest money and resources on
it. Assuming you build a comparable
solution, right, Because then you can also build a poor
solution. And then you could say, yeah, no
one used it, but that's because we went with a very poor
solution experience. Yeah, exactly.
Yeah. I'm not.
Of course, I'm taking that for granted.
You go for a comparable solution and then you see if the people
or the users are interested in it, and then you can iterate
over it. Sometimes it's even interesting
because you can build something very simple thinking I'm going
to iterate over it once I see the users use it, but then they
start using it and actually the simple solution, it's good
enough to to let it be. So that's also pretty
interesting to see. I'd really like to be driven by
data. You don't don't always have the
possibility to do that, but if you can, I'd really love to do
that because then you have the answers there.
Then of course, sometimes you need to come up with new
features and you just have to try.
You don't have the data to making that up.
You need to try. But that's exactly the point
when you want to try, you want to explore, then try to come up
with an MVP and then take it from there.
Yeah. These areas where it's not.
Black and white, but there's a lot of grey.
I think they are super interesting and I've really
appreciated you coming on and sharing your insights.
I think this was a lot of fun. Yeah, yeah.
No, definitely it's. Part of the challenge, and I
believe it's really interesting and it's also, it's very
interesting to see it in all aspects.
When we talk about MVP or simple solution, it goes also from the
engineering point of view. That's also pretty interesting.
I remember actually one of your persons you had on the podcast
advocating for simple systems. Yeah, yeah, I'm, I'm fully,
you're on that. Yeah.
I fully agree on that. I agree you need to develop
first simple, the simplest solution possible and then
iterate over it. You also mentioned it earlier, I
wanted to touch up on that. You are in a Greenfield project,
so you know there is no complexity and it's easier
compared to joining an existing product, maybe a monolithic, a
huge code base where there is already complexity.
I agree with you. That's true.
But it's also true that in a Greenfield project, you can
start adding complexity yourself and then very quickly.
Yeah, yeah. So usually what I do when
talking technically, I even did that literally yesterday, I do
it all the time. I came up with a solution.
I write the code, or I use AI to write the code, whatever, and
then I come up with a solution. I write a test and everything
validate is working and I'm like, OK, I'm happy with this.
Now let's take a step back. I take a step back, zoom out,
and then I say, can I simplify the solution even more than than
it is already if it's already simple?
And then I start thinking about it, maybe I think it with AI,
and then I end up refactoring the code more often than not and
ending up with an even simpler solution.
And that's pretty, pretty interesting.
I had something similar literally yesterday.
I was building a feature where we need to allow changing
languages in, in the machines. That's pretty understandable,
pretty straightforward. But then digging into it and,
and talking with stakeholders, I came up to know that I came to
know that we had two ways of changing the language.
One is the system system language and one is the session
like one language. So essentially, if you go into
the system settings, you change the language, and once you
change it, it's reflected in the whole application.
That's usually how your phone works, right?
Then you have the session language, which is you change
the language, you use the machine, and once you go away,
the machine goes back to the default language, which is not
the same of the session language.
It's the system one. Yeah, correct.
You can see that. Because, you know, I, I told
you, we build vendor machines. So there is a session, usually
you interact with the machine and then there is a reset state.
And so I started to build a feature and I was like, OK, it's
a bit more complex than I thought, but still it's just one
switch, right? You have season and session,
that's it. And then I was like, OK, maybe I
need a little util and then maybe I need 2 little utils.
And then yeah, maybe I need something to orchestrate the two
things. And then I ended up with like a
few classes. And then I was like, OK, the
solution is working. It's covered with tests and
everything. Zoom out.
And then I was like, OK, but wait a second, these two classes
actually are doing almost the same thing, so maybe I can
simplify this even more. And then, yeah, Long story
short, I ended up with a couple of class, one class, one
utility. The class had a couple of
dependencies. That's it pretty much.
And I even added trading while doing all this.
Actually I even spotted something interesting that was
involving the main and the background thread.
Not going to go into details, but some operation needed to be
done in the main thread even if I thought they were OK to be
done in the background thread. So eventually and then I ended
up with a single plus doing these two little operations and
covering everything. And again, I hope now people is
not going to jump on me, but you have simple single
responsibility principle, right? So that's how I started
actually. I had a class for the different
functions. So one was the system setting
and one the session setting. But then looking into it, I was
like even single responsibilities debatable
because if you mix them, if you merge them, you're still doing
one thing, which is updating the language of the system.
Yeah, can be session or can be system related, but it's still
just updating the language of the system.
And so yeah, eventually I ended up with, I was pretty happy with
it because the final quote was much simpler than the original
1. And in this case, you know, it's
quite a simple example I would say.
So the gains were probably minimal, but in more complex
solutions, when you take a step back, you can end up with a much
simplified system. And I think that's that's very
beneficial to both you and the company.
And that's also technical excellence in a way, I think the
skill. Of stepping back, looking at
what you've done or what you've generated and then trying to
simplify. It is going to be kind of make
or break moving towards the organization.
Because if this cycle of creating goes faster and faster,
then we do need to step back and see what can we simplify to make
something that is skateable for the future in the end, but also
digestible for people until we get to a point that we don't
need to do that anymore, which is also that's a whole nother
conversation. Don't need.
Yeah. Thank you so much for coming on,
man. This is real fun.
Thanks, Leo. Cool.
We'll. Round it off here.
If you're still with us, let me know in the comments section
what you thought of this episode and we'll see you next one.