How Senior Software Engineers Balance Speed and Quality (Scale-Up Lessons)

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