Mature Software Delivery with Elias Nogueira

Hi everyone, my name is Patrick Akew and have you ever seen an organization deliver feature after feature after feature in their software with seamlessly no issues. I have and you do that with mature software delivery which is exactly what we covered today. Joining me today is Elias Nogueira and it was a real blast learning from his way of working what quality is in software as well as how to collaborate with product enjoy beyond coding.

I was going to say I just joined recently a new client and the

person there, the product manager and he also did most of the scrum master rituals. His preference was really having a physical board. So then when kind of a Sprint cycle changed then everyone would be in the office and I agree with that. I think that has my preference as well. And there was one problem still, because we had people that would either join remotely and then a

physical board doesn't work. As soon as it hit hybrid, there were pain points because then it's like, what do you want me to put on the physical board? Like it didn't work anymore. Yeah. Yeah. So that I thought that was funny.

Yeah, when I was working the in the previous company before I moved here, we had a lot of teams like initially doing scrum and for them to learn in the process and like visualize it, that was was like really the a bad a best decision Doing this like in a formal way like with stickers, yeah and everything. So they can like OK they they can understand the flow, they

are actually doing something. I don't know if like probably learn a little bit faster like by doing things instead of just like created some abstraction and it was really easy because after a while they like OK, they were master. It's not that difficult but it's good because as well like it's not just like that stand up meeting that you just talk but you talk and do something and you talk about you get a sticker note and talk about the sticker note.

This is the thing. Yeah, this is we are doing and it's it's different. It's just different than you are in online with a board like OK, talking about the tasks, it's completely different, but it's it's the, yeah, it's the nowadays. We have to ish. Yeah. I I almost forgot about that. Like when I when I first learned about Scrum and that way of working, I love the physical board. It made so much sense to me and we could do that because

everyone was in the same room. Now with that history, I can do it digitally and I I we know kind of that routine and that way of working. But yeah, people coming into it and then just staring at a digital board, I think that is kind of the loss of magic. Yeah. Yeah. And it's different like because we are seated all the time. So, OK, let me check the board. It's just a different tab. Yeah. Yeah. So physically you, you stand up, you go there, you think, OK, you, you're thinking more you,

you ask someone to join. And OK, what do you think about this, this and that? So yeah. Yeah, yeah. And you don't have to ask a person to move it. You can actually go and you move the thing yourself. You like. Yeah, yeah, people move there and stuff. Yeah. Yeah, I love that. Are you there to or have you facilitated those sessions as well when it comes to either a planning or retro or? Yes, yeah. Do you like facilitating?

I like facilitating, yeah and the way like for me I I I work at at some point with like with Agile coach but more for technically in this, in this way, not for all the the the framework and formalities but more. OK, let's try to combine that is for me is the real agile. Let's combine what the frameworks do does with the technical part or we can technically now can do those things in a gyre way with some technical practice.

And one of the things I was doing, I was the only one during the planning session was guys, we will have one day planning session, the timing slot will be the whole day and we will just stop when we have everything. If you don't have everything the next day we'll plan again. Why is that? Because for me, time boxed plannings are not that good. We can have refinement sessions, etcetera.

But if you have everyone thinking about all the possibilities together, like without interruptions, it's better and it's faster actually than you breaking down in like different refinements than a planning session then you start. So after a while, in the beginning wasn't like like wasn't good enough because yeah, the whole day was starting and

some we were distracting a lot. But after a while, most of the people understand this, Yeah. And they can like of course, like taking 2-3 hours and it's done. I like that they have everything they talk about, all the problems, possible problems, edge cases and so everything basically, yeah, and it's good. Just to to play devil's advocate, did you see that people would get drained during that kind of one day? Sure, after after 3-4 hours Max. They are Jesus Christ. Yeah.

Let's do any other thing, yeah. Yeah, yeah. But they would stick with it and they would reap the benefits, yeah. Yeah, yeah, few teams did it with me actually. But the teams that they stick with it like they they they really saw the benefits. I like that a lot. I might try that out. What we have now is I'm coming into a role and I'm, I'm taking

up that facilitation mantle. And I like the idea of looking at what's there first and then being like, OK, how can we change this and how can we prove this? And how can we try things out like a dedicated day and we go until we're finished? Because from a focus perspective, I like that. Otherwise you're going to switch and you're going to start working and then you have to get back into refinement mode and what did we discuss again? And that's all going to take extra time.

So I really like that dedicated focus approach. But do you have this as well as a as a facilitator, Sometimes you see some problems. The guys are not seeing the problem. You're seeing the problem. At some point it needs to tell them guys this is a problem no one is seeing. Is that true or not? So they. Yeah, we we forgot about it. Yeah, forget about it. Sometimes I do this. Not sometimes a lot. I do this a lot.

Yeah. When I do, when I'm facilitating, like I try more doing facilitation than more like mentoring because it's it's different. It's a different approach. Yeah. You get more people involved instead of like kosher mentoring individually and initiatives that I'm running. I'm trying to be the the facilitator all the time instead of like telling the guys, guys this is the direction this is what we need to do etcetera. What is your opinion.

So instead of me seeing what they are opinion first I was given the all the possible cases it's good let's say it, it will depends right. It will depends the seniority of people you have, the team you have. But what I'm learning all this to hear more from them and then I can give them, OK, this is a missing piece you guys are forgetting etcetera. Yeah, so but for me it's still difficult. So I still want to facilitate to to give them the answers you know.

Of course you have to hold yourself back. Yeah, I I one of the reasons I really like facilitating is because I get the best what I think. I get kind of the best experience understanding everything. If I'm not facilitating, I feel like I just do my part of the work and I I explained that and I understand what others are doing but not into the detail of when I'm facilitating that type of stuff.

Doesn't matter whether it's a retrospective, I feel like in a retro, I really get a sense of the team as a whole or it's a planning or it's a stand up even. I get better insights. That's why I like facilitating and because of that I don't want to hoard that just with me. So then I think maybe other people want to do it. If they don't then I'll gladly take it. Yeah, but it does come with maturity. And then Even so, I feel like not everyone likes facilitating.

Like even the most senior engineers, they don't really mind if someone else facilitates. Like it doesn't. It's not a thing that goes hand in hand necessarily. It can, but it doesn't have to. And there's a funny thing I believe like some companies are have this approach to they have the team and any different way of facilitating for everything they are rotating.

And this is one of the worst options ever because you maybe will force someone that doesn't doesn't want to do that or not that good and wants to focus in another thing. So if you got the people that OK I in the team I can see one or two that likes facilitating, let's stick to it instead of like having everyone create these opportunities to everyone. Sometimes they don't want to focus on that and focus on other things. So yeah, it's tricky, right?

It could be the maybe the people that have had that. It's either the fair approach, so everyone does it, so it's fair for everyone, or that no one wants to do it, so then we make it all equal. So then it's equal participation. It's like one of those. But I I I agree with you. If one person really likes doing it, I like doing it, then yeah, let that person do it. People will be happier doing what they. Love. Exactly, Yeah.

Yeah, yeah. I wanted to cover mainly kind of mature software delivery with you. And I think we already sliced open way of working.

I think everyone has kind of their own way of working, things that they've seen in the past and things that they're going to bring with them in the future in ways of working. But especially when you come together as a new team or an existing team, if you don't have a way of working yet, there's going to be opinions conflicting. When you say we want, I want a dedicated day because I've seen that work best and other people like no, that's going to drain me. I want fragmented things and

stuff like that. From your experience, how do you usually consolidate into like a team way of working that is really effective for that team? What I think my context now they have I have 14 teams. So for me like I need to have a bare minimum process set for all the teams. So I need the same way of working for some aspects, let's say in the the in the development process equally like distributed equally and then in the same way so I know like I can predict if they have an issue.

The main benefit that I'm telling them is the. How I can say this is the they can help each one in different things, like 100 people can help each one because when you have a problem everyone is doing the same thing in that way. So they can help each other a little more faster, faster actually than if they are doing a different way. So the guys needs to stop analyse and we spend a little

bit more time. But you you could, you could say to me that OK, this would break like somehow the innovation or bring up like bring to the process new, new process, new approaches, new aspects, but for me bare minimum process established. Then you open up for teams to do this differently. OK And of course you need to give them time to do this differently even though it's that that process is working and one team thinks OK, this process

might be done differently. I would say OK, do this in your team first, do a POC, runs it and then share the experience. Other people, other engineers will evaluate, will ask questions, etc. And if you say that it's beneficial, instead of rolling outs to everyone, let's adopt to one more 234 teams and then yeah, we roll out to to

everyone. But I believe like being open and have this opportunity to have this freedom to change things is is the main is the main is the main aspect, of course, because otherwise we would work like 4 years doing the same boring stuff, let's say in this sense, right? And there, there will be no innovation because you are doing the same thing over and over again. But like the set of bare mining process for me is good, yeah, but open to everyone to try out anything they they want.

I really like. That I I had a problem in one of the teams that we are we were doing this one team wasn't doing like this OK, not even the bare minimum. Not even the bare minimum because the main engineer in that team was saying OK, I have better ways to do it. Of course we know in that engineer was really smart and OK, first, why why would you like try? We were saying like try first doing what all the teams are

doing. Then you apply what you're suggesting in your team so you can prove like in this way you can prove that's working. It's there's a lot of benefits but no, no I will do my way. My way is the same, OK? The end goal will be the same. We will. We will deliver software in the same way. But in the end you were doing like in a super over engineered way, OK, that he had the same results, sometimes even faster, but the cost for that was higher in terms of development.

Yeah, so that's that. That's why I'm thinking it's like proving to the other teams. Actually nowadays that's OK. It's not good if you try to do everything alone and if you if you don't follow the the bare minimum process. You need to follow bare minimum process 1st and then you bring bring like to the table net new things. Yeah, yeah. I mean, I I love that approach,

especially from you overseeing those teams and then helping when they're it's necessary. Even teams Co creating and collaborating and helping each other when it's necessary. As long as we have the same bare minimum, then you know the processes that are in place. Yeah. And you can adapt to anything that is new, that's built on top of that. Yeah. Could you give like an overview of the bare minimum you're

talking about? In terms of what we do nowadays in the end to end process in a super short way, we do have like we start developing an API with like the services with unit testing, integration tests. In integration test part we divide in two different areas, the integration between the integration between the service and the mocks and we have the

database part as well. So instead of doing this any database loopy grade migration etcetera, we do have this integration layer because we have all the scripts, everything we know everything that will be changing in advance. So we do this in integration layer as well. So we when we run the full set, before we merge anything, we run integration tests for all the supported database for all the tests we do have in parallel to minimise the the, the, the, the,

the time. And then we run all those database migration, zoopy grades etcetera just make when we have one. Of course just to prove OK everything is fine so we can go to the next step. Next step for us we have somehow the we call the capability testing but it's the end to end API test. So we deploy an environment, an ephemeral environment, and then we run the same, not the same set of tests, but the test

without the mocks. But with the real integration we exclude the mocks, we put a real service there communicating with each other. Then we test that part and basically we are doing all the front end scenarios that the user would do, we are doing through the APIs. Perfect because nowadays like everyone like a front end web or

mobile consumes those APIs. If I guarantee that I'm testing this for the API layer and there's no issue, probably there will be no issue in the front end when the user as a user would use that. And then we have the set of tests in the front end, but in the front end it's the same as the back end unit integration. Then this part without mocks which we have the environment with the front end and we can

test things. But the number of tests we have in this last part, in the end to end is far, way less than the than the API layer because we try to balance those things and we know that we spend a lot of time in the front end because it's flaky. It's it's difficult to spend an environment, not difficult to spend an environment with the front end, but it's more time consuming because you need the front end, you need to interact with the front end. It's not that fast than the API itself.

You need to do the flows, you need to wait for each page or each interaction. So it takes more time. Yeah, built up and yeah. And we need to be really smart on which type of test and kind of test we had there.

Yeah. Yeah. I really like that. Just kind of a great overview of the quality and the baseline that is there and then teams probably built on top of that based on new functionality that comes in. Yeah. And for example like before this part with the database we had after the full end to end APIs and now we were thinking, OK, but we have all the technology to do this beforehand.

Yeah this integration layer yeah so we started something we call it like that we have the shift left testing approach that everything that we can shift left like at the beginning of the process not only technically like writing code word anything, any practice we start earlier instead of start later and we start a technical approach on the shift left testing like seeing OK what everything we can do to shift left and we saw like two things one was this database migration and integrating

everything and another like in this end to end API test we were doing a single calls to the API instead of test integration. So OK, this doesn't belong here. This should be before. Yeah, so we're starting this. And actually we could reduce a lot the whole full cycle of testing because yeah, we are doing tests like faster and all the time.

So we can get the issues first in advance and then we focus on what we use, let's say the customer's focus perspective or customer tests or anything like this like OK, I will think like a customer and I will apply those tests to anyway. Yeah, the actual unit, user journeys. User journeys, yeah, yeah, perfect.

Has, has there ever been a way or not really a way, a scenario where people would cut corners basically in that testing suite? Because as new functionality comes in, and especially with pressure from the business to deliver, people might think that delivering the software without tests or without accommodating for integration or users user journeys is faster. But obviously you and I know that for the long term it's it's

actually quite harmful. I'm blessed that in this current company the the product people knows the benefits of doing this. First. Yeah, so they really knows. And actually they ask when when they are running these sprints and everything that the quality engineer does like it's we have quality engineers back end and front Enders. So and they work in, they

distribute the load. So during the plane sessions they talk OK those acceptance criteria, this one will be done in the front end, in the back end integration layer only. There will be no end to end test for that, OK. But this and that we will have end to end tests and they start developing at the same time. So quality engineers start at same time as the development. So even there is no like let's say they start one day behind basically right.

Because like when they start, OK, there is nothing to do in the quality part, but as soon as they have some code, they start together with the back end developers or front end developers doing this. Yeah. And we started in full automation like mode in this way we almost don't do manual test, OK, Only few verifications in the front end and we focus more on the estimation because we

know all the benefits. And actually the product managers, product owners, they during this print, they check OK, are you doing the automation for this feature because they know that's like you do one time and then you have the benefit later. Yeah. Then they don't have to do it. Exactly, Yeah.

And this was a problem as well because everything basically is is automated and they were not doing like the, we call it PO Shack. This is good because they were trusting the team that the team's doing this and testing.

Everyone is testing this but at some point it's good to have the the owner of the product like taking a look at the product before we can deliver instead of after because it was happening after after we we was delivering the process the the the the project itself the product owner few days later. OK guys but this like this should be changed it. That should be changed it, but OK, we just delivered that. Yeah, you are in another iteration. So why you are like it's too late.

It's too late. Yeah. What happened? And we have this of course discussions with the field. So nowadays they can see this benefit. Of course they need to see during the development process how the software is being built and I believe this is a it's my personal opinion, it's kind of a a general problem because some some POS I believe are not that involved during the development cycle. They wants to. They wants to see the final product. Like a stakeholder.

Yeah, yeah. Not during the development. Yeah, it's, it's interesting, right?

Because if you're creating the tests, let's say on an end to end perspective or on a user flow perspective, your assumptions or how you think the world works is going to also be in there. And if the PO trusts that what they think is right, everyone thinks is right, then then you have no issues. But that's like that's really hard to achieve. Like that's almost impossible.

That's why you always need kind of that that second pair of eyes that sanity check to go over it and especially from the PO role, that is just the responsibility that lies there. So then to do it as a stakeholder instead of kind of during that. If you don't do it during, you don't get the ability to steer left or right and then you do it after like any other stakeholder.

And sometimes they are like at least in our process, they are creating this idealization first with the designers and then can. They can see the software, but they cannot touch. They can see all the designs, everything. And they are imagining, OK yeah all the mockups, OK, this might work because it's they they create this idealization of the project, of the feature. Of course they know everything, but it's different when you start using it.

So all the benefits you get when they start using it and they started having a second thoughts. OK, this is not that good as I was imagining using the mock up, you know? Absolutely, yeah. Yeah. The pain points arise when you actually fiddle around with the tool and stuff pops up. They will always pop up in development after like it's I think it's inherent and as long as you take kind of this iterative approach that whatever we have can still adapt in the

future, I think is better. There are two things that I always say is that there are two things that will never change. Bo will change something later and when they are experimenting of course, because they can change their mind as well of course, yeah, this is one and 2nd, we will all the time deliver some issues. It's impossible to deliver no issues. We aim to it what we deliver.

So if we start thinking about it and we starts to OK being fine with that, the whole development process interactions if everyone will be easier. Yeah, it gets easier. I I've never, because I heard you mention that before.

I've never worked with specifically the term quality engineers within my team. Have you. Do you think that's a great way of working when you mentioned front and back end and then separate quality engineers? Yeah, I I've been like working this term, not working this term because that is determined the market. But what I'm truly believe in, at least I'm following my teams and I I influencing my teams that you have a group of software engineers, back end, front end and quality.

So a quality engineer is also software engineer is not like that. We know from the past like a tester that does do more manual testing than the other thing. No, it's a software engineer that knows software engineering, knows a little bit of programming back end and front end and nowadays like knows a little bit of DevOps. But his specialization is quality like a back end back end. But the back end there knows testing, knows DevOps, knows a little bit of something.

The same for quality engineers. The quality engineers for me is like the software engineers with quality specialisation and from company to company it depends. So the the the where is the focus right? So in some companies more towards the front end, in some companies more towards the back end, some companies are more DevOps. In our case it's a mix of everything.

So because like we have this quality here to advise the the the other engineers in the way of quality and where we should like if we need to add more tests, we are missing some edge cases, more techniques we can do it faster but also helping them to create those test automation sometimes not creating itself because sometimes the back end developer needs to create all

the integration tests. But we are trying, we not trying, but we are looking at the the tests and say OK guys, this test is the test that we have defined it but it's not covering everything we should cover. So they can double check and they can like pass this do this mentoring part in quality. All the developers. Yeah. And for me like this is the way that all the quality guys should do like nowadays I really I, I, I really think that everyone has an should be an engineer in

position. We are adding to the titles right, DevOps engineer, back end engineer etcetera. Yeah. But we need this engineering part, the basic of engineering and this is something missing a little bit in the quality area because we have still this quality people working more towards to the product as well sometimes and work more in the working more in the front end part, not in the back end or different aspect that are important for the, for the, for the product, yeah.

The ones I've seen more from history and then I'm talking 5 plus years ago would only test indeed like a regression test from a user perspective, so go through. Overflows. Click and click. And drag basically and then after each iteration, after each Sprint delivery, do that again and then again. And then throughout the years I've seen that evolve into automation. And then as you say, yeah, I I do see that component of quality more so being prevalent more and

more within engineering. The only part it was where my where I didn't really understand what the quality engineer does. But now that you explained it, it's still hand in hand, right, with a focus on quality, but engineering as a core, Yeah. And I think with that explanation that makes a lot of sense. Yeah.

And there's a second thing like we still, the market still thinks that the quality engineers are quality people needs to be more in the product side, OK. And I disagree. OK, I also disagree, I think. Yeah. Any engineer should know about the product, absolutely not the quality engineer with the product owner. Everyone needs to understand equally the product so we can better develop that product. If we think like no, let's try to create this separation.

Quality engineers will do the front end testing like manual automated and we'll talk more to the people about the features and see all the edge cases. This is in the end of the process. We should bring to the like, we should push the left the shift left testing or shift left mentality and then we like together with the PO everyone should understand the products and then we can build the product in a better way. Yeah, interesting.

As kind of a thought experiment, have you seen, Let me take a step back for me, when there's more roles and responsibilities, When people get a title like DevOps front and back end, they put themselves more so in this box. Yeah. And then when work pops up, work gets basically grab based on those boxes if it's front end or back end. But then what slips through is the work that's kind of in the middle.

So especially when you have a new role like quality engineering or have you seen people say, oh, that's kind of their job and I don't do that or how do they still kind of cooperate and get stuff done? Because those titles, they

sometimes do make a difference. Yeah and the the most common behaviour or bad behaviour is that when you have a quality, when you have a specialized engineers right back end, front end and quality and if you don't have the good or good mentality or quality mentality across the team, the back end there will see the word test quality in your. Job scooch it. Front end will say, OK, we need to test something in the front end.

We have a college engineer for that and they are just like not doing actually their job that they should do and should be in cooperation. That's why we divide the work there. Those kind of things like integration, it's a core for each engineer like the back end engineer knows how to do integration. The front end knows the quantity in you shouldn't be involved of creating it, But reviewing it and talk to them and say okay, are we covering all the possible cases.

Let's talk together. Let's see because this is the shift left. Yeah. And then Okay what is more ends to ends or has more integration or any kind of test like performance tests or sensibility testing or any kind of like no functional test, we can give it to the quality engineers and they can help the team to deliver this because they have more like they have more knowledge on that so. Exactly. That's their focus. Yeah, it's yeah, what makes sense. Yeah, it makes sense I think.

Have you ever been in a situation because especially you mentioned quality engineers advise, but with the role of an advisor can also people can also say, well we take that advice but we still do this and that can have consequences And then I think your culture is kind of make or break there because if it's a culture of blame and I told you so, that's very harmful. No. Yeah, it's it's not a coaster of blame. Thankfully, all the teams are super cool in this way.

That's good. But this happens sometimes. Yeah, right. But we most of the time we send like reminders. So OK, the team decided that we won't do this, this and that, or we would add one or two edge cases. It's fine. But normally we see the problems later. We see one like later, not in the next iteration but like months later. And we are just setting a reminder guys, we discussed about it and we didn't do. So let's try to next time, let's try to implement.

You do take more 10 minutes, 15 minutes doesn't matter but we can prove that you take less time. Now we are discussing more than 10 minutes just because we didn't do this before. And and there's a second, the second thing for me in the terms terms of teams, it's not fully related to quality, but it's also related to quality. It's given this opportunity to, OK, I don't want to do, I don't see the benefit, OK, let's don't do it.

And if we fail, we fail. We learn with that failure, we see what we can improve and then we improve later. So this culture of like more cultural failure, for me, it's really good. Not because you won't deliver anything, but like allow them to fail in interactions and try to see the problems. You know, we try to find a solution. It's the best so they can learn really, really fast. Yeah, I feel, I feel like I've I've heard that more and more and I feel like sometimes it's

hard to put in practice. But I think the more people have that mindset of failing is OK and it's a it's a way to learn and progress. I think it's like at the heart of engineering culture because what we do does not come without fail. Fail is always there. It's always going to be there. You also mentioned we're going to deliver software and it will have issues. So if we accept that it has issues, we can accommodate for that and we're not surprised when it actually does have

issues because it will happen. I feel like that's very important for a team to kind of mature and also in their delivery. Yeah, and even for people that never did something, we are saying OK, do this and they say OK, maybe I will fail, maybe this will be a problem for other teams do. If it's a problem, first acknowledge the problem. Second ask for help. Then a lot of different engineers will jump in to help

you and this is what happens. Actually, that's great because we have this kind of fear that OK, we did a mistake, we need to hide ourselves first, right? Yeah, yeah, we need to talk to the team. OK, I have this problem, like please help me to fix. But actually, if we allow ourselves to say, OK guys, hey, I did this mistake, it was me. I'm sorry, but I need and I need help to fix because I don't know how to fix. A lot of engineers will say, OK,

yeah, it's a normal thing. No problem, no problem. Let's jump in and let's fix it. And as soon as you allow this as well and it's a, it's a it changed your mind a little bit. Right. Because most most of the people don't want to show up show and say, OK, it was me. Yeah, scary. And when we allow this and people say, OK, I I was sharing that, it was me. No one blaming me. Nothing happened.

And they they are more comfortable doing these mistakes and actually they will next time when they are doing they have like a different opinion and maybe this will fail. They are doing the same thing before. So they are going to the channels and guys I will deliver this. I don't know if there's probably there's a problem and not seeing it. Please help me. The engineers will jump in the same way if if they had the problem. Yeah, Yeah, absolutely. I like that we covered and

started with kind of way of working and then we delve more into the quality aspects of software. I think when we're talking about really mature software delivery, a big aspect is the collaboration between engineering and product and making sure that that is a smooth operation that there's trust on both sides and that you can also deliver based on that with realistic expectations.

I don't know where it sometimes goes wrong if the if the product side is kind of lacking that engineering mindset or if the engineering side is going to lacking that let's say functional requirement in the business mindset and the value that they need to deliver. I feel like it's always going to

be somewhere in between. But I think I shared with you before from my side now I'm I'm moving from engineering to product just to kind of experience that and it is fun having seen kind of both sides in the pain points there. What are the some of the pain points you've seen in the past? Yeah and and it's both ways right.

Yeah because we don't actually the the the the main thing for me it's the we don't know how to communicate between between each other yeah because the yeah because the the the the all the jargons and everything is different. So we need to learn this like a new language to communicate 1st and then we can not the not only the the way we they talk about the product or we talk about tech, but also understanding the

keywords of the benefits. So for me if you tell product people, OK I have this I cannot deliver this on time because this will impact X days in the process and or this if I just take one more day to finalize all the things, yeah this won't have this issue in the customer which will stop the customer you preventing the customer using it and maybe this will give them a loss of X millions or anything like this. They will get your they will get your attention.

They will you have their attention. It's their language. If you yeah, when you start like understanding their language OK customer money things like that that actually product right. So OK they will stop and they listen to you and they will help you actually. And for me the the when I talk to product people most of the time I talk about the problem. Of course we have a problem. This is the problem. This is the context. I I love like when I write a message to everyone like it's

like a chapter. Like I give the context, I give the what is happening, why that's happening, what are the possible solutions, what is the impact of that And most most important for other people, the impact and I say guys, this is the impact, the risks and I cannot take this, this is risk alone. So it needs to help me to understand. And for me in the end product people have the decisions of course because it's product and that's why it's there's a steering wheel for the company.

So they know the direction, they know what the customer wants etcetera. And the the main, the the other problems we do have it's this kind of fighting between each other because we don't understand each other, right. So we are fighting why they are needs to change this one one classic thing product people in the middle of the interation is printed etcetera. They wants to change something or they wants to add something in the middle. Something urgent all of a sudden.

Yeah. But what we do, we complain instead of, OK, sit with me, explain why this is good. No, no, OK, I understood, understood. But explain me a little bit more. Yeah. Because maybe that requirement that the customer is selling to the product is not fully, fully ready as well. So we need to understand as engineers first why that's happening and then OK, it's makes sense. So let's stop what we are doing. Let's do this new thing to collaborate with product in the

same like in the same way. One of the problem, not problems but learnings we are having together there is that we have this tech versus product all the time and most of the time probably the people they have their their their calendar, they they they backlog for like 3-6 months, one year like planet, right. And but at some point tech has a lot of things in the middle, not the the development process but

we have OP grades. If we have new approach we want to apply to reduce the time of development or to increase the quality etc. And we need to start negotiating, yeah it will impact their backlogs. This is kind of a problem, but a good problem to solve as well. And this solves with communication and actually this proper communication. Just saying that is that important. It's it won't be listening. No, because everything is important.

Everything is important. But as soon as you OK, this is the benefits, this is the impact, this is the risk, they start listening to you again. So OK, they they try to understand. They they will try to understand all the time. The problem is more this communication and OK, how we can understand each other.

Yeah, I think the the more we indeed focus on language, the better we can understand each other. And then it's at the end still about trust, right? If someone says no, you can still work and you can still commit and you don't have to butt heads when people disagree.

Because I think always that's that's within a team of engineers and especially engineering and product people will still disagree and people will have a different vision on how we should move or if we should move left or right, especially when it comes to product decisions. And at the end of the day, it's all assumptions anyway and we

will have to make decisions. And then if it turns out to be wrong, exactly as if as if how you would treat engineering when when a mistake happens, you pivot, you say, OK, we've made a mistake, we've learned from that, you pivot and you go the other way. I feel like the more we realize that that it, that it is iterations, the more flexible you'll be as a team. What I'm struggling with still is people that kind of like that or that don't like that

iteration. I feel like sometimes I've worked with engineering both in teams and from outside of the team, working in people that want to do one thing and then have it be right and then not have it be changed basically, and that's really hard I feel like, to achieve. And I'm reading a little bit more about this this topic, this product minded engineers that normally what I have in the teams technical minded engineers right?

Because we we see the the feature or any change, we instantly start thinking about technically how we can approach that. But we are not thinking OK, how the user we've approached that, how the product we've approached that and then I will create the technical solution. So they are the product minded, they will OK, why we are doing this? Yeah, for which customer, what are the benefits, which way they are using and then they start thinking about the solution. This you can see this more in

the architect. For example, when you talk to an architect, the architect normally will say, OK, what the use case what the user will do, yeah what is the known function requirements because they have this full experience on this. They know how to prevent this kind of problems. Yeah but engineering the teams don't have this and as soon as we have like trying to influence the the the engineering the teams to think about the product first, then they can like deep

dive in the technical solution. Better. Yeah, better. Yeah, I agree. It's funny because I'm I'm now in that product seat and I'm looking back in my experiences and as a personal preference, I I always went for solutions I didn't have to build because I think that would be more valuable, right? The less code we have and the more problems we solve without kind of technical solutions, that's better because that gives us room to improve and to expand in the future without kind of

having this weight of code. Because I feel like more code you have it is kind of a wait and at some point you can do things of standardization and accommodation, but it is still weighing you down in some degrees. So the less functionality and the less features you have. I think the faster you can keep going because it it at the end

of the day it's a marathon. But now that I'm in the product seat, I do see that, OK, Even from design, when we see a problem, everyone loves coming up with solutions. We can do that. We can do that and then that. And the people fixate on that. And I'm like, yeah, but is this, is this really a problem we should be solving? Because not every problem I feel like needs to have a technical solution. No. And that's the realisation, yeah, that I think a lot of

engineers can do well with. And even like I have this, this

kind of discussions as well because we trying to follow indirectly the zero bug policy. When we deliver something, no issue should be delivered. If we find that issue we fix then we deliver. Yeah, but at the end, like for me, I changed my mind in this way because I was thinking all the time that no, we should deliver with zero issues.

But when we start talking to the product people and say, OK, we have this issue and we have this deadline and we need to deliver the software, this feature, what do you think? And they can give an awesome insight. They will say, OK, this issue like 1% of the customers will, will, will hit this, this, this point. So let's deliver because of the time of restrictions and another thing constraints and then we can fix it.

So this kind of prioritization is good as well because as a quality engineer we don't want to see anything being delivered with bugs or failures. But like as soon as we start talking to product people, they have all insights, they can even see like a small issue that is not blocking issue, but OK, this is important, no. And we need to fix that.

So from from my perspective was like looking but this is not like stopping anything but this is an issue but maybe for the product people, no, this is a huge issue this differently because I have this, this and that's inside. So it's it's good also to have this kind of, it's not good that we that we think and we deliver software with issues, but it's good to have the conversation with other people to understand

what is the impact, right. Of course, of course when you have something blocking that you know that will block the operation and the customer will stop of course will fix right away. But other things just talk to product people and it's hard when we say OK we are delivering things with bugs it's it's really hard. We don't want this because the whole, the whole like the the whole area, the whole IT area, it's telling you all the time we need to deliver without any issues.

Yes, like a professional pride. Yeah. And as soon as we Start learning a little bit more about it's talking more with the product people to understand this, it's it's become easier actually to deliver software, right? Yeah, yeah, absolutely. It's, it's funny because you really made me reflect on kind of the gaming industry.

When I'm thinking back when I had like APS One, I would have this disk and then that would be that and all the bugs that would be on that video game, it would be there forever. Forever basically. And nowadays you download your software, you don't even have like a disk anymore or or ASD card or anything. It comes and as soon as it hits release, it already comes with an update patch. And then probably the next day another update patch.

Because somehow with a certain button combination you can clip through a wall and then you're out of bounds. And then oh, they fix that with another patch and things get released with more bugs. And I especially see it in the gaming industry, sometimes with too many bugs. But then immediately they hit you with upgrade patches where all of a sudden it looks like a really good game again.

Yeah, yeah. And it's tricky because when I play as well, sometimes I'm playing playing something and I'm not, I'm not seeing that issues and some players are. So it's exactly like this like the I try to try to combine with the what I was saying about product. So maybe the product will say, OK, this issue only 10% of the players will will reach this point. So let's deliver and then we patch. Yeah. Because most of the users, most of the players won't won't reach that point.

So it's fine for now. So we need to have this balance as well, right? Of course we don't like it when as soon as we see it right, as the players let's say. But yeah, it's the it's the time to market we. Know everything? Yeah.

I think the the hard part or like the downside would be because people also estimate then their releases on that. Let's say if we're still taking the video game example, oh, we did that in the past, then yeah, we can still make these deadlines because everything looks. Similar. The problem is the reality is not always similar. So then all of a sudden you might have to release or you might have a deadline which is actually not feasible anymore. And then you can do two things.

I think I've seen from engineering position you can really do everything in your power work day and night and try and make it happen and then you still have that kind of make or break moment or you have to push back and say listen, I can't do it. If you want go ahead even though they they cannot do it because they're not technical minded. But you have to have that conversation and those conversations can be quite hard. Yeah.

Yeah, I feel like exactly as you said when you're asking for help, you did your homework, right? You said why? You said this is the urgency. If we don't do this, then these are the consequences. That really helps when driving those conversations. But at the end of the day, I feel like with mature software development with mature engineers, a skill is also putting your foot down and saying no sometimes.

Yeah, that's for sure. And we have a lot of ways to do it like even during the interaction let's say if you do, if you use like sprints for example, if you use scrant, we know the front scrant that OK, you can add as much as features as possible during the the this time frame like can be one week, two weeks, etcetera. But we know that we can prioritize one or two and the PO can say those are the real priorities from this iteration. So let's focus on this first.

If we focus on that first and we see problems, the PO knows that other features are not that important than that one. Yeah, so we can we can have even ways to try to avoid some most of the problems of it, but it's still it's there. So the the communication part, right. So this, this, this must happen with product. And this is also communication problems, right?

Because we have the deadlines, we have issues and sometimes we don't know how to express when we are having issues and we say, OK, this product or the interaction for this feature cannot be delivered or won't be delivered on time. We don't know how to express the problem to the product people and say, OK, those are the implications, those are the risks, those are the problems. So in the end, actually basically almost everything is communication, right?

Yeah, yeah, I think so too. And I think the hard part is, and and maybe this is a cop out, a lot of communication skills, a lot of that kind of business language, that way of working comes with experience, right? You have to have been in a team where there's a mature level of software development and delivery and milestones that get hit time and time after again that you see, oh, there's a dialogue that's happening and

we're not just executing. I feel like if you find yourself in a team that's just executing and that is bumping heads and then that's a symptom of a dialogue that's not happening and it it needs to happen for things to progress. I feel like, yeah, I really enjoyed this, man.

This was a blast. Yeah. Was this kind of what you expected coming into this? Yes, it was. Yes. Because like, this conversation is like going to different directions. It's good because yeah, we can talk about basically everything, right? Awesome, cool. Then I'm going to round it off here. If you're still listening, let us know in the comment section what you thought about this episode. And with that being said, thanks for listening. We'll see you in the next one.