Hi everyone, my name is Patrick Akio and if you're interested in the role of a QA engineer nowadays, this episode is for you and it might not be what you expect. It has a lot to do with developer way of working and how to deliver value for the business faster with quality in mind. Joining me today is Augustine Zocway, QA Lead, and I love his stories, He's an amazing communicator. So enjoy this episode. What does quality mean for you when we're talking about
software engineering? So quality, that's a buzzword, right? And it's quite a broad word. So quality means different thing for different people. Yeah, if, if I'm an auto engineer in a building cars, quality is a whole different thing, right? The tyre don't need to fall off when a car's driving, you see. So quality is a different thing in the medical section. Quality is a different thing. Well, so quality depends on what
we're working on, right? We need to have a defined set of qualities, attributes that we need to track based on the application, the users. So yeah, quality means different things for different people. So I can, I cannot have a single definition of quality right now unless I'm looking at what we're talking about, what is the application or the, the subject we're talking about. Then we can define that quality based on the risks, the the usage, the uses, the impact.
So you can come together and then define what quality level are we talking about. Yeah. Is that also nowadays the role of AQA engineer within a team? Because I've never worked with a person that had that role, let's say within my team, quality was always kind of how do you say that conventionally understood by developers were at least spoken out and we tried to uphold it, but there was no QA engineers. I don't know what their role is
nowadays within a team. I know from history kind of what the role was, but I think it's evolving. Yeah, QA has evolved. I, I hope that he has evolved, at least definitely for me, he has evolved, you know, moving to the right direction as well. So yeah, to your question, yes, I think that could be part of QA role also depending on the level. So let's say in QA world, you have different levels of QA, right? You have people focusing on different things, right?
Automation, general QA practices. You have some that are coach in AQA, you have QA lead just like I am. And then you have people doing different things. It's quite the broad world, right? So in terms of defining quality, I think is where we can take a lead. Yeah. For whatever team or teams that we're working on, I think it's something we can take a lead, get the awareness out there, help engineers understand that quality is not just testing or writing test automation.
It has more, more broad practices in order to achieve specific level of quality that is defined, that is needed. Yeah. So I think QS can take a lead on that. It should be. It should be part of QA role. What are some of the practices that you've seen kind of work out in practice or are some of your favourites to kind of implement within teams to up the quality there? Pragmatic practices, more flexible practices. So when we talk about QA activities, OK, which practice is one of them?
It's many. So the one that I, I think that worked very well, I wouldn't say the one that worked very well. It what works for a team a might not work for a team BI like that. So the, the, the, the role of AQA should be to assess those, look at the problem itself. Don't be flexible, open minded while you're looking at the problems. So you can actually draft what can help, which practice, flexible practice, pragmatic practice that will help that team move forward.
So one of them is, I think one of the experience I had in mirror is, you know, I started in mirror, you know, things are, you know, working, finding out things, defining things. But then my manager came one day and said, you know what, the experiment we're doing, it's taking too long, right? And why is it taking too long? Well, then I was like, OK, we need to write automated test. We need to do some manual testing. And engineers will continue, of course. And bless them, they were
listening to me, right? They start writing automated test. But at some point AB test is about getting it quick out there to get a feedback back, right? And then you can see the winner and then you can, you know, implement the winner, right? And that stays right. So at that point, my manager said it's taking too long. So when I went back to the team, you know, they're writing automated test for the things that we might throw away.
So at that moment, even though I said like we need to write automated tests for the features we're giving to customers, it's just for me to take a step back and look back and said, OK, let's discuss this, right? Let's talk about how we're going to remove the waste. Let's be practical, kind of pragmatic, right? Let's do quick manual test during the AB test and write specific unit test that we know that that component stays, but the UI will change.
Let's just not write end to end test so we can move quicker, right? And during the clean up, we can have that task defined so we can write an end to end test. That's just small example, right? And then we win the time, we win the lead time, you know, you know, So for me, I looked at it in a different perspective. OK, now we need to stop doing this, right? So we can clean up that. Another thing again is when we're even with automated test, when you have monolith, things
can go wrong, right? So defining, finding out that we ship something, it comes back with the issues. I just decided to find a better way. That means, OK, let's do test session every time before we deliver. Let's just come together, take an hour, 30 minutes, whatever the engineer needs and go through the application and give the quick feedback to engineer so we can actually move forward and deploy what we have, even
with automated tests. So these are little things you can actually be flexible in fixing and and yeah, so this is how I look at practices that are beneficial. Yeah. And not go into the mainstream process and those are good. You need to have it in place, but you need to be smart based on the situation of what you what you're building. I really like that flexibility in the example of AB testing because in the end, you're
right. If we develop a feature that is going to be AB tested and it doesn't deliver the value that we think it needs or it's actually more harmful than helpful, then yeah, we can throw it away, right? And I think less is more. And I think more and more that mindset is there as well, that if you keep on building features, then at some point you just have a bigger application. And a bigger is not always better. It needs to be effective in what it's doing.
And at some point, people don't want a toolbox. They just want one tool to solve the problem they have. And if your toolbox doesn't solve the problem, then it's a waste basically. And the same is for then the quality that you put in that feature to make it future proof. But if it doesn't have a future, then it's a waste of time.
Basically. That flexibility in how you then align with the people that say, OK, things are not going as fast as well as with the development team to still build in that baseline of quality that it needs because it still is going to go to production. It still is going to be AB
tested. I think that's very helpful in the situation because I've also had people, and that wasn't necessarily in QA, but engineers can be dogmatic or people within tech can be dogmatic when it comes to their practice, right?
I've had people from architecture starting from scratch where we already have a journey and we're just trying to involve them for their opinion, but they want to have everything, according to the book, basically without any of the context or without any of the kind of fast pace that we want it to be. Same for security. And I think in QA there's probably similar people also in engineering. So that flexibility and open mindedness, I think that's very helpful there.
It's definitely helpful. I I understand that as AQA probably talking against myself, not to follow process. Yeah, we need to process, but we need a smart process, right? I think today in the world of software, it's about how quick can you get the feature out there, you know, how fast because everything is online, right? So we can have a process we follow, but we can also have that process but adapt the process. For me, it's all experiment, right?
It works when things change, application matures, team matures, engineers matures. So at the beginning, you might define as best set of process, but as they mature, some might be taken out because it's a waste, because they already know what to do. Things have moved on. If you used to find 20 bucks in application and all of a sudden you start finding 5 bucks, you can adapt the strategy, you can adapt the approach and even be more quicker.
So you remove those waste. So I think focusing on removing the wastes, by the way, that's the whole point of Agile. Finding that way you can remove the the the the waste and improve as you go is very important. Yeah, I think it comes with team maturity as well. And it's it's very interesting for me that you can have many senior engineers with the years of experience and when you bunch them up together, it doesn't make a team yet, right?
Those people have still have to figure out their own way of working within this new team, regardless of what past experience they have. That might even be an anchor to some people 'cause it kind of closes their mind rather than being flexible and open new suggestions and new ways of working. You said the word ways of working. Yeah, yeah.
So in my experience, I've seen really senior developers, but when I sit down with them, my previous, previous companies, they have not actually sat down with a QA or anybody to do like pet testing. OK, so and that doesn't take anything from the experience of what they do, but it's just like they haven't done it. They usually have someone that would test what they do right and then give them a feedback
and they continue. So, so when I sit down with them, it's more like, OK, this is new, you know, then that's where why I have to explain why am I doing that? What's the benefit? What is in it for him, right? This is not just me trying to do something, but what are we doing? So some some engineers coming together doesn't necessarily mean delivery will be fast, but we need a process in place. We need an approach, we need
strategy. You know, when 234 people speak one language, it's quicker, you know, to have a communication and work together, right? Because they, you know, they have and aim and role the goal, you know, to deliver this quicker. But if front end is developing that side and back end is developing that side and all of a sudden front end is waiting for back end, there's no communication, there is no process. We're both can actually walk together in one.
So you see, you could lose one hour, half a day, a day. Winning those things back will actually speed up delivery. So I like focusing on how can we deliver quality of speed and yeah, keep working on that in a different ways, right. You meet different situations, step back, open minded. Listen, I learn a lot from engineers and those people, even though they have not worked together with QS sitting down one place, yeah, there's a lot of knowledge you can pick from
them as well. Why you give them that little piece they don't have. You can learn a lot from them. And yeah. That's awesome. Yeah. But that, that role, how I had it in my head, that's an involvement from how it used to be, right. You already mentioned that some engineers are used to, some have not even written their own tests. And then that would be the role of QA right next to actually writing the tests. Also then functionally going through the application.
And then from the engineering side, my assumption is that they wouldn't really know what actually goes to production or what a user experiences with regards to what they produce. Now you're saying this role has evolved, and I agree it has evolved because from my side, I haven't worked with QA, which means QA is kind of integrated in engineering, which I think is
a good thing. But then you still have to have someone, whether that's an engineer or someone that fulfills the role of QA, figure out that base level of quality. And indeed having the conversation and being flexible and making sure that delivery also has quality there. Yeah, I mean, definitely evolvement is part of AQA and there's a lot of story in that. But I just like the way it's
evolving, right? And the mindset is more the difficult part because engineers, which are good people, we, some of us still have that idea that someone have to test my work, right? And give me a feedback that I did well. I want to believe at least my version of QA is, I want you to be able to confirm your good work and sell your good work and be happy about it rather than waiting for someone else to confirm it for you, right?
So it definitely have evolved. And I think every QA tester, while we do what we do, we do test, we still find bugs. It's still on our responsibility to help engineers to understand the craft there, right, the craft there. Because those days it used to be that testers will go all land to find issues and bugs. I think the engineer himself that's writing that code will know the place to press a button
and that breaks. What if he gives us that experience and finds a way like, OK, I know how to test this and I know where it's going to break. I wrote this code and I know the soft part and the weak part. You know, senior engineers knows that and with the craft of knowing what to test, how to write, automated test, they would just do that immediately. Even it doesn't matter which lower level test he's going to write or higher level test and QA is right there with him to go through that.
So you all I'm saying right now comes to collaboration. So this strength, the strongest strength in software development right now for me is collaboration. If you collaborate with these different disciplines in a team and you push the software, you are more happy and you are more confidence in what you're doing, right? So yeah, they all have evolved. And I, I just cycling back to the question of Q as I think we should be more participating with engineers, you know, and take lead.
It doesn't matter whether you're a lead or tester or just take a lead on project you're working on, on the story you're working on, and bring that information to your team. Possibly teach them how to do that, because then they can already clean up some of those things before it gets to you.
Or maybe it doesn't even get to you, it just goes straight to where it's supposed to be. So and yeah, I think we should, it's a very good thing that we should evolve and take lead on that QA. When we're talking about this QA career path, you mentioned tester, you mentioned QA within the team and also QA leads that are more so overarching within the team. Is that like the typical path that you might grow into this field of QA? No, not really. It's it's, it comes from, it's a
personal thing, right. So I've seen I used to be chapter lead in previous company and I have one of my direct report changed from QA to dev op. He was just too good to be just QA. He was really good at scripting and all that. You know, move on to dev op, that's where you need it. So I think it's, it's a personal thing where your passion lays and some, yeah, it's a personal thing. It, it can go many ways. So Qas can be, I've seen a QAB product owner for QAB engineering manager.
So QA is more like crossroad from there. Experienced QA can actually be anything. Some can talk to developer, you know, developer and test. There's a lot of stuff you can do when you're a good QA. So I think sky is, is your limit what you want because you touch all those things you get experience from engineers from if you look at the whole entire QA practices, it involves all these things, right? You know, I'll say project manager, even developer, engineering manager, team lead.
So there's a lot of stuff you have in active building a software that Q is involved in. So you can be any of those. Interesting. Yeah. Do you think from a career perspective, cuz that's some of the questions I get from the viewing audience, is OK. I'm trying to, I get my first job in tech and I want to be developer. I want to be XY and Z or I'm trying to transition into a role and that could be anything, but I'm trying to figure out what a good start would be.
Would you say a good start in this field of tech could also be QA? Because from the Contra side, I do think you need kind of a base understanding of a lot of practices and indeed how you would collaborate effectively. I don't know if you could have that when starting out. As an engineer, to transition to QA is possible. I've seen that. It's not common, but it's
possible. Yeah, it's definitely possible because I've seen there are some engineers that I've met along the way in all the companies I've worked with here really, really good. So QA has have this instinct or intuition, call it intuition. If you have 6 developers that are, once they focus on more and there are ones they just said, OK, I, I, I know he's, he got it.
OK. You know, so those engineers that you know that they know all the things they need to do in testing, literally might not even find issues on, on whatever they create or they've gone through the steps. Once they have the process and strategy and approach defined, they just go through it as fast. You can just leave those ones a little bit. Don't bother them too much, just leave them because they know what they're doing.
So I think those ones, some of them might develop even more passion into going into QA, maybe more like develop developer in test to develop more frameworks, writing test automations, coaching about that. So yeah, it's possible, but it's not common. Yeah. And also for people then starting out, would you advise kind of QA as a starting point or would you advise kind of gaining experience elsewhere first? That's a good one. So starting up as a QA it's possible.
There's a lot to QA, but starting up, I say a tester like you learn things about QA these days. The word QA is actually, yeah, it's it's used a lot. Yeah. I would say you can start up as AQA, but there are basic things you need to do. You need to understand how software has been built. You need to understand how project is works. You know, you need to understand a lot of technical stuff. Then you start with testing. You have to touch, you have to
use your hands and test stuff. You know, I short story, I just started as a normal tester. You know, I just have to test the application, go through it, run through it, check all the type of things before I even move to automation, right? Because things have to work before you automate. So as this starting out, I think the person can call himself AQA, but I think the content of what he needs to do is to understand the basics, which is how to test the software, right?
How the software works, how is it being built? Understanding the simple methodologies, The functional part of it, yeah. Yeah, I think that makes sense. And the only way to go through that, I would say, or a more standard way to go through it is indeed more functionally first from a user perspective than trying to figure out how to automate more and more and indeed work more collaboratively with developers, right? That's how you gain that experience in, OK, how do we work together?
What is this way of working and how can I influence that to indeed improve the quality there? That's a mindset to you these days. I think you can even start quicker because if you look at the tools that is coming out these days, right, a lot of people can just start by automating, right? Yes. You need to know how to use the software, use application, know what it is.
Of course, you probably have that computer, probably I'm too old in there right now, but I think people can start quicker. Actually, people can start quicker just by writing automated tests. Just do a little bit. Not even functional test, like every other experience QA started. Yeah. I think young people these days can really just jump into it and learn how to code. Now tools are making it even easier these days to write automated test.
Yeah, yeah. And the little knowledge they get, they can get it by just building the pro, you know, that's online project everywhere that you can just keep automating and learn how to do those things. Yeah, I think to start up, it can be quick, you know, So I'm not too sure of my old way of doing stuff. I think things are much, much easier to start up right now.
Yeah. I'm curious to hear your take on kind of the future of this QA role, because if I take my experience with operations, it's now no longer in most organizations a separate role. I think more bigger organizations still have an operations department. But indeed we're moving from developers and operations to more DevOps and engineering where the operations part is also done by partially developers in the end.
And I've been on the operation side and I would say, OK, ideally you don't have operations, right? In an ideal world, you go to production and there's no issues. You don't have to investigate anything operationally, but in practice that's still the need for it. I think for QA it's kind of similar, but I'm very curious to hear your take on how this is going to evolve in the future. So it's definitely evolving now how it's going to evolve in the future, I don't know, but here's
my take. So my take is the teams structure and the way software has been built is changing. It's becoming faster that automatically will force Q as to evolve. You don't have, you don't have option to stay back. You go with it. That's that's the whole point. That's the passion I have about QA. You just go with it.
It's changing. You build teams that are changing, you just go with it. And so the evolving part is to take lead of what is happening on the testing world and evolve with it. My personal view it's I see teams are teams are needing more a way to build software quicker. Now we used to say, oh, you build too quick, you can compromise the quality and you build too slow, you can compromise the speed because we need to deliver. My view is how can we balance those?
So I think every QA will learn how to evolve on their own path. But what I can say is evolvement is definitely in the package that we don't have option to stay back. We need to evolve. To your question, I think in the future there will be. It's already happening that you get about 5 teams. You don't get 5Q as now you might get tester, functional tester, but it will be overloaded to work for five teams. Yeah. So when we say QA, it has a
different meaning. So that means that this QA have to find a way to operate in these five teams and that means that the QA have to zoom out, how can I help the teams. That's a whole different story on it's own. But yeah, evolvement is based on that. We are becoming more broad than more specific, so I don't even know if it's tea kind of. It's like queues are becoming more of. You have to be a good communicator in the 1st place. You have to know how to design
processes and approach. You should be able to solve testing problem on the fly as they come because they're different issues that is happening. So there's a lot of just to name few of this, there's a lot of stuff that QA need to do in order to get those X teams working and have that quality mindset and tell them, you know, help them build that software moving forward. So yeah, to cut it short, I think evolve evolvement in the future will be more like taking a lead.
Now I'm not talking about QA lead, I'm talking about every QA person, every tester have to take a lead. And that lead, well, if you take a lead means things have to change. You adapt with what is happening and you help find a solution, testing solution, of course. Yeah. So I don't know the package of what tomorrow evolvement will be. But right now we are on what I call a different level of evolvement in terms of QA. We are expanding.
Yeah. And it's basically because of that trend that you mentioned, right? The competition is now so high, I would say everyone can pick up a programming language and start executing. But then the way you execute as well as the speed of your delivery, how fast you deliver value in comparison to your competitors is starting to matter more and more.
What have you seen in kind of either way of working or indeed in executing that helps engineers or companies deliver software faster while not compromising on that quality? So what I see is a QA plays a a good part in that anyways. So what I see is for a team to do that, there has to be some level of collaboration. So I remember I that's it's a framework I designed. So this framework I designed. So that means that to deliver anything you need people.
Yeah, right. You have the product you want to deliver, you need is process for that. So in those three things team need to figure out a ways of working, right. And when I say a ways of working could be a lot of stuff, but it's just a team to agree on a specific set of quality activities you focus on the quality of what you want to deliver, you focus on. And how are we going to not even how to code it because we're building a solution first. We need a solution which is a
product. How are we going to build that? How are we going to test it? How are we going to automate the entire pipeline, right? Because to deliver fast, you need to have some set of automation in place. That's the only way you can speed up the, you know, delivering fast after building it might take you a day or two before you even get it to your customers.
Now how can you get it shot? So I think for team to do that, there has to be a level of defined ways of working that everyone is on board, on board with. And there has to be a certain level of collaboration between the team. You know, don't wait too long, don't go online searching for something you don't know for 3-4 hours. Why don't you just ask the guy next to you, for example, Hey, I'm going through this, do you know, can I get a, get a help solved next?
You know, so these are the level of things the team needs to have. So all this will be in the ways of working. Yeah. Remove waste, be pragmatic, be flexible. Meetings, know the real ones, how to test the application. Most importantly, automate the entire process if you have to. If you can't, then automate what you can exactly in terms of the process. So these are the things team need to have if I'm forgetting something.
But at least I believe in collaboration in team and ways of working will bring team further, of course with a quality mindset, of course, yeah. And this standardized way of working, I'm assuming it really helps for the person that has what you've had in the past where you are the QA lead, let's say across multiple teams,
right? Because if you have to adopt in ways of working across teams and then also get the context, it's way harder for you to go in, help A-Team and then move on to the next team with a different problem if you have to adopt every single time. Yeah. So walking in multiple teams was really fun, I would say. Oh, that's good, it sounds fun. That doesn't mean it's easy, but it was fun. It was it was challenging.
So I think the path to that is focus on one thing at a time and you focus on one team and if you see all the practices working, you pocket that and then look at another team and see where you can help them with what you have and add the new stuff because everything is different. I have these teams, but they're all different people. Yeah, different characteristics in a team. They're all working in different
domain of the product. So it's not necessarily that solution for A will work for solution for B. So that's where the fun part comes in. So it works for this guy, this team, beautiful. And you go to this team, they have a whole different kind of thing. But some of the things you've done there are basics that can adapt and then you flexibility, you step back, look at the real problem and find a testing
solution for that. So this is just how you get to trickle those to the around the teams. And, and as I do that, you'll, I learn a lot and learning that a lot based on the experience of practical working solution is not a theory. I actually don't like the I, I come up with the theory theory, but I need to see that it's working. So learning that will help me help other teams quicker. It's not the same, but it's quicker because I already have some set of things that works
here or they didn't work. I can advise them this doesn't work. Look at that. It doesn't work over there because at the end it's one product. So, so that's how you can actually in a nutshell, work across the teams. Now there is all the problems as well that comes with it. Because while you're you started from team one and you're about team four, the team one will be having problems, right? You need to go back and say, OK, guys, you know, what are we
doing? So this is how it works, but also fixing the issues and going back. And then the only key you have is collaboration. You know, you collaborate very well with the team. The team knows you, you you lead by example. That's the point. I say that Q as also need to lead. You need to show the team this works. You know why this should be that why we should do this feel that pain with them.
The problem some of the QA's have is we get stuck in a process and we don't feel the pain of developers, engineers, you know, you need to feel that with them, have that conversation with them and they will know what is in it for them, what you're trying to tell them to practice. So that's very important. And and that's how you just sell it to the teams, trickle down to the teams. And and of course, there is cost of maintenance that things, you
know, things evolve. Yeah, some sudden things might not be necessary for this team and just remove it. Allow them to evolve. You know, I won't stuck on, oh, you're not doing this process and we need to go back. No, you're wasting the time. You know, you see them doing it and they're moving forward. Push them, you know, to move forward. Yeah, but how much do you push
them? Because when you get into a team, let's say you have in your toolbox some ways of working or some suggestions with regards to improvements, what you're going to try out and you're going to experiment. And at some point you might be anchored and you want to say, OK, we have to try this further and actually see if it bears fruit or the engineers have to say it doesn't really work for us. At some point you're going to
say it doesn't work. But there's this balance of being flexible or not being too flexible, let's say. And at some point, proof is in the pudding. I wonder how you judge, let's say, what works or what doesn't work and what to incorporate or what to drop. That's a very good question, by the way. So being too flexibly, it's easy to become complicit with what you've done, right? Yeah. So I just try to avoid that. So I do look ahead.
It's not always like thinking of something and I'll come and give it to team to try. No, it it doesn't work like that. But I do look at the I do look ahead. Sometimes I identify gaps in a team and I'll approach the team and said, have you noticed this, right? I think this might be that or this right now, these are professional engineers. They know, you know when they understand when you explain it
to them very well, right? So that allows me to to not be over flexible, you know, because I know if they say, well, we know, but we don't need it now because of that. I listen to them as well. So that's the only way it works. I listen to them, they listen to me, right. So we need to understand each other. So I try as much as I can not to be too flexible because there are still some necessary process that we need to follow. Yeah, we need to make sure that requirements are there before we
start developing. There's no other playroom for that. If you don't do that, the the cost of that is having issue of building something wrong or going back and forth and don't waste time, right. So we need to agree on that, you know, so everyone knows that. So with that we have set of rules. So it's not even being flexible. The flexible part is, for example, hey, we have definition of done check box for example, right, If you finish check box, I've done this, I've done that,
I've done that. It's good at the beginning. But these are professional engineers when they do it often checking a check box becomes a big problem. It's second that is wasted. Yeah, Why force them? Leave them. Just leave it. I remember asking one of my teams, I want to know why you guys are not checking the check box. And I give them a set of question. Is it because you don't see, you don't know it exists? Is it because you already know what you're doing?
Is it because it's just too much work? All the questions, you know, I'm paraphrasing now, but they just agreed that we already know what we're doing. That's a that's good. That's great. Yeah. So, so I don't push them on that. I just leave it. But the good thing about that is if something is happening, they have retro, they will remember we used to have this, can we bring it back now? I think it's the role of AQ way to make sure that those things exist.
That thing can always cycle back to that. Yeah. OK. So there I'm not flexible and there I'm flexible right on the other one like requirements and that you know, refinement the outcome of those scrum ceremonies, if it exists or Kanban need to be clear. Now you still cannot force the team to do that. They have to see the value in it. So it there is flexibility which you present things to the team, I think is on a queue a person
to be able to convince the team. You know how it how hard it is going to convince 1 developers. I know, yeah, yeah. And I think in my sub stream I think we have about 30 developers. OK, gotcha. A different story, yeah. So I, I just, it's not credit to me, but credit to the team, the professionalism they have to understand what this guy is saying is good to try, right. So we get that done, put that in place so everyone can at least
follow all the stuff. Yeah. So I'm probably too flexible in some things that I don't know, but yeah. And you're very conscious about it, at least how you're explaining it, which means you're well aware of what to be flexible on and what is, let's say, what you cannot. Compromise on, yes, I think. That's important. Yeah. And collaborating with the team talking helps to understand what they need and what they don't need.
And if, if, if Qas do that, it's hard to be of a flexible because you need to understand what the team needs. And we work for the team, not for us. We are part of that moving one thing from A-Z, getting something built a solution and deliver it to customers and make sure customers have usable product. So we're part of it. So we need to talk and communicate with them and reason with them as well how we can do that. So with that it's it's hard to be of a flexible. Yeah, it makes sense.
One of the things you mentioned kind of triggered my thought process in something we do as consultants, right? CB As a consultancy organization and as you come in an assignment, one of my goals is to make sure I find a replacement and at the end of the day, make myself obsolete because a corporation is better without consultants. Basically, you don't need help if you don't need it. At the end of the day, the role is either to make myself obsolete or to make the role obsolete.
And one of the things you mentioned in QA, in educating people, helping with ways of working, when things are a smooth operation, you are kind of making your own work obsolete in a way, shape or form. What are your thoughts there? Is that something you take pride in fulfilment in or is that more of a scare? So the first part indeed, you make your work, well, not the work obsolete. You make yourself obsolete. Yeah, exactly. Yeah, yeah. And I, I take a huge pride in that. That's weird.
You know, you, you, you're happy when you're obsolete. That's weird. I recognize that, though I I also take pride in that. But I, I, I, I really feel fulfilled when I see the team try when when I'm needed less with the deliver quality stuff out there and customers are happy and I'm part of that team. That's beautiful. I like that. So that drives me like, you know, at some point, yes, the team doesn't need you, but that's good. Yeah, for the team you might not
be good for. Me, but it is a mission accomplished. But I feel good about it, so I have to find something else to keep myself busy while I wait to see how we can maintain what already exists. You know, things like that. And so yes, we do feel obsolete at some point, but there are so many other stuff that we can do as well. So we can help the team identify Q as can see, you know, gaps and see, you know, if we continue doing these things can change and communicate that.
So as much as it looks like we obsolete, there are other ground works we can do. We can also prepare something new. You know, I remember I worked with, I have to mention his name and Danielle, also consultant from Sabia. So he was on mirror. So that was when he came as an agile coach and I was working, you know, we had a conversation like, oh, OK, how's the team doing? You need to do that. Don, have you done this? Your team done. And he looked at me and said OK. Good stuff, yeah.
My question was, what can we do next? You know, I'm always looking for the next. I'm always looking up to where else can I improve the team? Where else can I help the team improve? Where else can I even help software development improve? Wherever I am, if I'm in any team at all, can I help them improve what they currently have? And that is always my outlook. And I, I remember we came up with this framework, you know, you know how we can evolve.
When you meet a team that's already evolved, they do things themselves. Like you said, I'm obsolete in some sudden things, a lot of stuff because they're doing it themselves, which is good. How do you evolve them further? How do you ident help them identify things they've not because team can be delivering fast, but there are other things that can actually improve to be better. Yeah, as opportunities, so. Yes, opportunities, that's what.
How do you figure that out? So yeah, we sat down and developed this framework and we start working teams through it like, hey, you can identify your level of performance here and see where you have some. Maybe you're missing some observability, you know, maybe you're getting the data but you're not using it. Things like that. I don't want to go into too much details about that, but there is always next. So we're not completely obsolete. If the QA himself wants, we're
not obsolete. Exactly. There's always problems to solve. Yeah. I love that, man. I think I've really enjoyed this conversation. I love the way you communicate and it really shows that you also take pride in communicating well because otherwise I don't think you would have done as well on this podcast. I've really enjoyed it. Before you round off, is there anything you still want to share?
Yeah, what can I share? I just so I'm moving on to a different life that that that I never thought of OK, being outside employment, just being contracting like so I have this few period. I think every QA, just what I'm going to say, every QA or tester or whatever, I take a lead of what you do. You will evolve from there. You know, sometimes we don't know that we can actually take that lead. The title doesn't matter. Just go for it. Take a lead, you know. Beautiful. Yeah.
All right then. Thank you so much for listening. Let us know in the comments section what you thought about this episode and we'll see you on the next one.