In this episode, Lina talks to the feedback fairy, a well-known voice in the testing (and not only) community - Maaret Pyhäjärvi about the different readiness for changes in team and supporting the growth journeys.
Find Maaret on:
- LinkedIn: https://www.linkedin.com/in/maaret/
- Her website: https://maaretp.com
- Mastodon: https://mas.to/@maaretp
Links to books are to Amazon and as an Amazon Associate I earn from qualifying purchases
Follow Quality Bits host Lina Zubyte on:
- Twitter: https://twitter.com/buggylina
- LinkedIn: https://www.linkedin.com/in/linazubyte/
- Website: https://qualitybits.tech/
Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.
Thank you for listening!
Lina Zubytė 0:06
Hi, everyone. Welcome to Quality Bits, a podcast about building high-quality products and teams. I'm your host, Lina Zubyte.
In this episode, I have a really special guest. Maaret Pyhäjärvi is a pretty known name in the testing community. She labels herself as a feedback fairy, which I think really, really matches the work she does. And we get to talk about the fact that juniors very often come with lots of willingness to learn and, how we can guide them better, how we can learn from them as well. Also, how tester role is the one role in the company that is looking at organizational problems as well and supports the team, and what it means to have this whole team quality approach that some teams maybe don't really need a tester. Enjoy this conversation.
Hi Maaret, welcome to Quality Bits. It's so nice to have you here as my guest. I'm honored.
Maaret Pyhäjärvi 1:20
It's great being here. So thanks for asking me.
Lina Zubytė 1:23
Could you please tell a little bit about yourself to people that do not know you?
Maaret Pyhäjärvi 1:30
My name is Maaret Pyhäjärvi. I work from where I live, which is Finland. I've been in testing for 25 years. Currently, I work with a company called Vaisala. We do embedded devices for weather measurements and industrial measurements. And my role kind of after 25 years, it's a bit complicated sometimes to explain on what I do. I have a title called Principal Test Engineer. And in my particular case, it means I have three jobs or three roles and hands-on tester in a single team. I am a test manager across multiple teams in the theme of some product that we're doing. And I have a responsibility over multiple teams on kind of like evolving or helping testing grow. And there's a lot of versatility in those teams.
Lina Zubytė 2:29
And who are you apart from your work?
Maaret Pyhäjärvi 2:32
It's kind of a weird question in the sense that I think I am a person who likes to improve the world around her. So I put a lot of effort around things like fairness, justice and equality, and all those kinds of things. And it appears a lot of that is kind of work as well. In addition to that, I have a family: two lovely kids. And we share all kinds of lovely, you know, things together as a family, but it's more of a kind of like you can do whatever you like. And I don't like kind of creating this very clear separation of my personal me and what I do for my work. I only look at the fact that I don't sell more than 37 and half hours to Vaisala, and I have full control over the rest of my time. And if it resembles work, I don't mind.
Lina Zubytė 3:31
That's a really good point. I feel like we have certain aspirations, every one of us, and we can realize them in a lot of different ways. So the how could be different; we know our why. And you very nicely stated that you want to improve the world around you. And you are improving the world around you in different ways. And it could be that you're doing it also at your work that does sound like it especially working with testing and multiple teams. Right?
Maaret Pyhäjärvi 4:06
Yeah, it does sound like that. And it does feel that there's always this common theme. And it's sometimes hard to say what's working and what's not. But I like to think in terms of work is where someone else has power over me. They can control what I will do. They can prioritize. You know there's some sort of management and some sort of goal of that organization that I served with that particular time that is work. And the industry is much bigger than work. And I spend a lot of time in the industry.
Lina Zubytė 4:37
So talking about your work. Could you tell a little bit more about your daily tasks and do you have a regular day? What does your regular day look like?
Maaret Pyhäjärvi 4:49
I don't know if I have a regular day, but I have a regular week. So very typically, I schedule my weeks only on the previous week. So I very much try to avoid having meetings that are always happening that can fill my schedule so that you can't see any space in my calendar anymore. So I start with an empty slate, and I plan for my next week, and I have these guidelines of how I fill my week. About half of it goes into hands-on testing. So I work with some team, and I am actively making sure that I take time to do some testing with them. It might be pairing with the team members. It might be doing some kind of ensemble testing, even like the whole group coming together, or some groups coming together. But there's a hands-on aspect. So I'm doing the tester work that anyone else in a tester role might be doing. Then the other half, I usually have some kind of an impact in mind that I'm trying to drive forward. So it might be that I'm working with a certain other team, kind of like, you know, some week, it's this team, some other week, it's another team that I work with. And it might be that we're kind of like, you know, figuring out some kind of an improvement that we're trying to make. One of those improvements right now with one of the teams is to figure out how would we like to strategize around testing when it seems like we're unable to hold on to the same people for more than a year. And how does that change testing? That's one of the themes that I've been now working on and configuring out; what are the expectations? How do we recognize if within these premises things are good? And another one is faster releases in another team. So kind of like figuring out how they could get away from this nine months of release scheduling, and then being six months late, into more of a maybe monthly scheduling cycle? And how does testing change it?
Lina Zubytė 6:48
Wow, that's quite a lot to unload. And you mentioned that you cannot hold people for more than a year. Could you elaborate on that? Do people change jobs after a year, usually in your company or in Finland in general?
Maaret Pyhäjärvi 7:04
So this is not a team that is in Finland. This is a contractor team. One of the teams is outsourced. We have a team outside Finland with a contractor who seems to be having an idea that they are heavily rotating their people with about one year cycle, to allow their people to grow. So it's the company policy. But then again, it means that if you're growing as a tester, you're growing with different products each for a year rather than becoming a domain expert and knowing the area that you're testing in. And it requires a bit different way of doing testing, for example. You will need to invest in automation, which leaves your work behind a lot heavier than you would if you could build up architectural knowledge and domain knowledge that helps you very effectively explore. So you just have to look at things a little bit differently.
Lina Zubytė 8:04
In your role, you have five teams, and you're a principal. And as far as I understand, some teams have testers, but some don't, and you help them out.
Maaret Pyhäjärvi 8:17
That is correct. Most of my teams still have a tester or even multiple testers. But there's one team where recently we were trying to recruit a tester, we couldn't find the right kind of a person for that team. It had already had certain experiences of a tester coming in not being able to contribute in a fast-moving team where developers actually test a lot. And you will just need to kind of raise the bar on testing rather than take care of the testing for the team. And the team decided that instead of recruiting a tester into the team, they will have a tester hat that the developers will share and rotate on about a quarterly cycle. So three months, each of the developers will hold on to the tester hat. And we'll get in through the entire team so that they won't be a tester as such, but there's a hat that we rotate.
Lina Zubytė 9:17
That is such a great example: that one formula may not work for all the teams. Every team is in a different state, in a different readiness state for change. And some could also be more advanced when it comes to testing. They may need someone to challenge them, and not everyone will be able to do so. I've seen this as well in the companies I've worked in where some very strong teams, when it comes to quality, they needed a very strong tester to join them, not just anyone, because then both sides would be disappointed. How do you see the differences between the different teams you are working with? Are they in different stages in their change journey?
Maaret Pyhäjärvi 10:05
Definitely. In very different stages. And I wouldn't try applying the same rules or saying exactly the same principles for each one of them. They also build very different software. So this particular team where there is no tester, and there's a really fast-moving team, it's working on new technologies. Whereas the other team, where there's a lot of change kind of a given principle of change, it's on a product that has existed already for some decades and is more on the maintenance side. So you have to actually rely on the fact that if you don't change anything, nothing changes. And when you make changes, you're making those changes from a baseline. So you definitely have to take different approaches with different kinds of teams because of the products, but also because of who the people are. If you have people who are new to this industry, it's a completely different thing to look at what kind of things you would give to someone who's new to, you know, expecting the work from someone like me, who was 25 years in the industry. And I'd be kind of through various kinds of positions, various kinds of roles, and various kinds of tasks. So I've had a chance of collecting a number of tricks into my bag, whereas some others might be kind of, you know, getting started with that trick collection rather than having years of collection behind them.
Lina Zubytė 11:30
That's extremely important that we have to know where everyone is within their journey in order to support them and not expect them to know what we know because they may not, and also allow them to grow and learn. How do you balance this out? Do you have any kind of strategy? How do you get to know a person and where they are in their growth journey?
Maaret Pyhäjärvi 11:55
If you talk to people and you listen, that's definitely kind of the starting point of everything. So instead of explaining the same things to everyone, you probably need to start with listening to what people are talking about, what they're able to do, and what they are kind of having conversations on. But maybe even more relevant... Well, I find that if you don't know that you don't know something, you really can't talk about what you don't know because you just don't know it yet. I find that it's actually even better if we can share some tasks in a paired or ensemble way. And we can kind of see in the context of doing the work. We can see what help the others might benefit from. And we can also, of course, be surprised that they can teach us tricks we didn't know yet. Because again, if I don't know that there is a new tool for me, for example, to learn, how would I go about asking my colleagues to show me that tool unless I've seen that they are using something that I had no idea of?
Lina Zubytė 13:04
Pairing definitely unravels a lot of knowledge and knowledge differences that we have between the team, but they also feel like it builds some kind of psychological safety. Maybe you may just share a little bit more because you work so closely with that person. And you're hands-on or not just having some theoretical conversation about the abilities and the skills, right?
Maaret Pyhäjärvi 13:30
Definitely, psychological safety seems to be kind of a big word that we're using nowadays. And this whole idea of hearing kind of everyone's voices definitely requires more listening than speaking. And feeling like you have things to contribute and the things you're contributing are being valued by others. It's kind of important. But there's also groups of people, again, I work on such various levels of organizations and also outside my work in other organizations that I've really come to think in terms of, there won't always be psychological safety, kinda like as in it feels like you might be actually removed from a particular position or not allowed to continue in some kind of a position of trust, like board level, things that I do as well. And you still can kind of work very nicely if you approach things with respect and wanting to learn what the other ones have to do. So while in software development, when you talk about this, this psychological safety, I think myself that it might be just kind of more focused on the idea that: it's such a wasted resource if we don't listen to the others and we just kind of enforce a single way of working, thinking that someone, even if they had a lot of years already has it all figured out?
Lina Zubytė 15:04
Yeah, I feel like also, juniors tend to listen much more. Even though maybe seniors should listen to juniors more because then we can understand how we can support their growth. And sometimes, some seniors may fall into the trap of just lecturing or telling how to do things rather than finding a way how to tell to this person in the best way for them to learn something.
Maaret Pyhäjärvi 15:36
I've had a lot of different trainees kind of beginners in this industry. And I have always kind of aspired. I've been wishing there could be like, you know, when I meet enough people, I can figure out what to teach to everyone about testing, like, there's a program that you can put everyone through, and then they, you know, become really good testers. And the more people I meet, the more I realize that we are all starting from different combinations of knowledge and different combinations of skill. And it is a waste of talent if we try to kind of normalize it too much. Whereas we probably would like to be more focused on making them effective and efficient, providing results, and rather kind of figure out how we can use what they have right now and stretch from that, rather than assuming that there's this movement that everyone must go through. So there's so much of kind of like the gap: mixtures of what people know and what they don't know that I no longer believe we should move people with kind of like standard materials, but it's much more on the listening and finding the right next steps that stretch us.
Lina Zubytė 16:51
Kim Scott, in her book "Radical Candour" has shared how important it is to uncover the aspirations of people in order to support their growth path. One example, in particular, stuck with me. It was about a manager who started asking their employees what their dream is. And you may wonder why would you ask someone what their dream is? Isn't that a little bit ridiculous in a professional context? But in that example, he sat down with a person and asked her what her dream was, and she answered that she wanted to become a spirulina farmer. This was a tech company. And spirulina farming has nothing to do with tech. But knowing the dream of a person, this manager was able to craft a growth path that would involve skills needed to be a businesswoman spirulina farmer. So instead of just following the traditional path that they thought this person was supposed to follow, the standardized one, they realize that there's a win-win situation there for the business and for this person, that she could instead practice different skills. And she was also extremely grateful to this company for preparing her for this future dream of hers. So after reading this, I started doing the same with my team. I started asking them what their dreams are. Because I feel like there's so much, we can do in our growth as QAs. There are many different paths. It's not just that you start in manual testing and then you move to automation. And then you learn Selenium. Then you learn UI automation. Then you go to API testing, and automation. No, it can be so much more creative and interesting. We can be more creative with our growth paths.
Maaret Pyhäjärvi 18:58
Yeah, that definitely rings a bell. I particularly remember one time when I had a 15-year-old trainee. And I started teaching him from the premise of exploratory testing. But that's not the normal premise for a junior, a 15-year-old. Regularly in companies in testing for a 15-year-old: you give them test cases, and they execute them until they're, you know, bored or learned or well might even give up some of them. But that's more typical. And I said, kind of like, I'm not giving you anything, I'm giving you the application, and I'm giving you the responsibility. This is the feature. This is, you know, the material that we have on the feature. And this is me: I will answer any and all of your questions, and I will come and ask you how you're learning and how you're testing on a regular basis. About a week into that testing, this 15-year-old got some advice from someone more senior who happened to be also in the company and also happened to be his dad. And he was told, this junior, that this exploratory thing that you're now doing, this is not how you're supposed to do it. So there was a developer in the company who kind of forced his son into this scripted testing. And he came up with, you know, very detailed test cases for about a day worth of work before I realized that there was kind of, like, leading from the side. And we had the three of us all together, and we had this conversation of, like, I have a different intent on how I'm teaching. And we're doing this and this and this, and there's these differences. And I did get him back to this exploratory track, and kind of like getting him started from basically where I started. No one ever gave me test cases to obey; already 25 years ago, they gave me the responsibility for the results. And I wanted to do the same for him with more support than they gave me back in that day. We have very strongly these ideas of what a 15-year-old is capable of doing. And if we don't, at least experimental, try other approaches, we won't be able to figure out if the old ways, maybe, were not so effective and maybe actually slowed down the evolvement of those people. So this particular 15-year-old, he is nowadays a very brilliant testing professional, multiple years later. And I do believe that he got started much, much faster with the exploratory idea. But there was a bit of a discussion and even a conflict of some sort to sort out before we got there.
Lina Zubytė 21:35
This is such a brilliant example. I feel like it also relates to upbringing people in general and how we can make mistakes because we feel like a book says something when we should do that. And the more I know, in my career, the less I'm sure of, oh, it's supposed to be that way. I'm not thinking that way anymore. I'm always even cringing and a little bit fighting against certain beliefs, which are like it's only this way and no other way. That's the best practice. I really try to avoid the word best practice: it's a good practice in a certain context. And having a nice growth path, which is more adapted to you, I feel it's also freeing. It's good for the person who's learning as well to know that they are already useful the way they are, they're powerful, they have their own strengths, and they have their own creativity. And they don't have to do this scripted testing just in one way. And tick boxes when they have done all those clicks and verifications that the document asks them to do. Juniors are such an interesting topic because they are so willing to learn, and they really want to grow as well. And I feel like we have a responsibility on how to support them better. But when it comes to this, in general, the bandwidth to growth.... Why do you think that matters? And how can we keep this growth mindset and interest with years of experience?
Maaret Pyhäjärvi 23:16
When people get started in this industry, we can't give them the expectation that they would know everything in the beginning or that they could learn all of the things in one go, you kind of need to start from some angle. And over the years of, you know, doing different kinds of tasks and doing maybe even different kinds of positions, they can grow to this kind of like a full 360 type of, you know, approach of all kinds of tasks and even creating their own style of tasks. The software industry is kind of weird in the sense that it's still growing so fast that there's a saying that the industry size doubles every five years. So that would then mean that half of us in this industry have less than five years of experience. So we should be having ways of working that allow a clearer box, a clearer area of working for someone who is newer to the industry. And there's a lot of flexibility for those who have the longer history in kind of figuring out even the ways that we haven't yet figured out. Personally, I have this principle of never being bored at work. So if I recognize that I'm bored with doing something in testing, it probably means I'm repeating the same things. And that may be triggering me to think in terms of, let's automate this, maybe I should automate it. Maybe I should learn how to automate it. Or maybe I should work with someone on getting it automated. Or maybe I should, before automating it think about: does it even actually need to be done? There have been so many things for me in testing where I've missed out on realizing that the world around me and the architectures around me are changing. And I go and spend time on hunting some of the bugs that no longer are actually very likely to appear. One of these key examples for me was I started with localization testing. And with localization testing, it used to be that every single language was different. And then we changed as an industry. We changed the architecture so that the localizations were no longer built-in, kind of deep nested into the code. But they became like a layer, an architectural layer: very nicely isolated, with very nice APIs on how that gets included in even the operating systems that I was testing at the early stages of my career. And I no longer, for example, needed to go through the trouble of testing on a German operating system. I don't speak German, by the way. The German operating system and me remembering which of the words means reboot and which of the words means shut down, it really slowed me down. And also, I needed to repeat things that I would not have needed to repeat if I had understood the risk profile better. And I think some of that thinking and actively looking for the lessons, or how the world around us is changing, is keeping this thing fresh for people who have been around longer.
Lina Zubytė 26:30
So what did you do instead, then? So how did you tackle the localization testing?
Maaret Pyhäjärvi 26:36
So previously, I had to look at every single feature separately for the Finnish operating systems, for the German operating systems, separately for whatever language I had. And generally, I have this principle of, like, we had these language tiers: we talked about tier one languages and tier two languages, meaning how much time and money we were throwing into different tiers, kind of how big of a business priority each of the tiers had. So we budgeted different amounts of time on each of them based on what tier and how high in priorities those were. And when this architecture change came in, and I realized that happened, I realized I don't need to actually test on the German operating system, separately, all of the things. So I could just not test it on that particular language and that particular operating system. Or maybe I could test it, you know, once a month rather than every single day. Just realizing that some of these things actually don't need to be tested, we do the same thing nowadays with browser automation. And there's a huge conversation going on, on whether this is a smart strategy or not. An increasing amount of organizations are saying that instead of, you know, testing multiple browsers with automation. We should create single browser automation because there are very few problems that the top layer application teams can actually deal with any way in the cross-browser world, or they won't be seeing problems, because that's the user feedback that even if they didn't test on anything other than Chrome, the other ones actually still kind of - they work. There are no problems with the other ones, even if it was not tested on all of them. Because, again, testing doesn't fix it. Testing only makes it visible if it was already working. We're using time. We might also argue that we don't need to. There are other things we could choose to use with that time. So this whole kind of a concept of, maybe we automate so that we only test on, well, some people choose Firefox, some people choose Chrome, some people choose Edge but only run our test automation on a single browser, it might already give us enough information across browsers because of the way the architecture currently is. But this is only true, maybe, I think, for the application teams kind of they're on top of that stack layer. If you're building an operating system, or if you're building that browser, you probably are going to have to test your browser. And that's the process features with all kinds of applications. Or if you're creating a framework, like a user interface framework for browser components, you're probably going to want to test that across different browsers in a lot more detail. So there's a lot of fine-tuning between the types of software that our organization is responsible for building.
Lina Zubytė 29:45
It really depends on the product we have and the context we're in. And as you say, understanding the risk profile and understanding what matters for the product the most can help us to a little bit get away from this, everything, all the things we have to test mindset and choose more of what matters.
Maaret Pyhäjärvi 30:06
You won't be able to test everything anyway. Trying to figure out what are the things that you absolutely have to do, and what are the rules on your particular application, your particular users and their needs and requirements, and their comfort level or ability level around risk. It really drives a lot of this. It's not so black and white whether you would be kind of like you know not ever testing this, but definitely you can bring down the cycle time kind of like how often you're looking at a certain thing. For example, if we do run a single browser test automation (which we do in many of the projects), it doesn't mean that the developers in the team wouldn't have agreed that one of us uses Firefox. One of us uses Safari on a Mac. One of us uses IE on a Windows machine. So you can have many different ways of coming up with the sufficient coverage and figuring out what are the most valuable next steps. It's really an exploratory activity.
Lina Zubytė 31:16
Yeah, I feel in groups as well we can be more creative with testing and cover more cases that are important for us. So you mentioned that you would get bored testing sometimes and then it would make you start automating. I have seen cases, though, where people may feel overwhelmed. They maybe are overwhelmed because of all those many cases. And they are overwhelmed because they feel they are responsible for every single language in the world when it comes to their product, even though maybe it does not actually matter. How do we create some kind of room for people to grow and be creative? Because I have seen cases where people burnt out because they were doing the same manual test every single day. But they didn't really have the energy and bandwidth likely to take on automation and just ease their own life as well?
Maaret Pyhäjärvi 32:18
For me, it started with the idea that I don't need to do automation by myself. Like I have the team around me. And I happen to have early experiences already. In my career, were saying what I wished I had made it feel like it's Christmas, this is how I feel with my current team, by the way. And it's great to kind of make this full circle again, back to your team where they take half of my sentence, and they just tell me kind of like, Oh, you thought there would be this kind of a problem, or we needed this kind of testing? Here's the pull request, can you review it, and I'm like, Oh, I was going to do that myself. But I was too slow. So you got there first. And it's you know, it's a great kind of like, you know, environment sometimes to be able to just say what you'd like to have, and have the other ones join into the let's have it and agree kind of like, hey, I can I have no a moment I can do it. Rather than just expecting it's all of my work. So this whole team approach. And the fact that I am not the tester, well, if I am the tester in that team, it doesn't mean all of the testing belongs to me. It always belongs to my entire team. Some of it, I will do, but some of it, others will do. And we will need to have these conversations on who does who does what and make sure that those who have great ideas but maybe don't have the skills of turning it all into automation can provide those ideas for the rest of the team. And those who are really efficient in turning ideas into automation can actively pick up the work.
Lina Zubytė 34:01
It's such a beautiful environment to be in, where every team member empowers each other and helps out. I feel like also communicating our own needs is a good life lesson in general. We should communicate our needs and tell what we want because people are really willing to help. The one challenge I sometimes see in teams is if they're overwhelmed, they may not have the bandwidth to help out. What would you do in this situation? Would you change teams? What is the sign if you voice your needs, but nobody helps you out, actually?
Maaret Pyhäjärvi 32:18
I often find myself quoting Anna Baik from UK on this idea that tester's job is often the only job or the core job in software development where we are expected as testers as we don't only do our own job which is the testing thing. Or the part of the testing thing. But we need to also fix the organizations in order to do so.
Lina Zubytė 31:16
Oh, that's powerful.
Maaret Pyhäjärvi 32:18
For me, like, that's been so powerful over the years for me. Anna said it so well, and I have been reminding people of that pretty much ever since. But it definitely has led me to this realization that when I see that my developers, my colleagues, my respected colleagues are overwhelmed. And they're starting to treat me as in kind of, like, they're sidelining me because of it, or they're trying to create this kind of like you do that we do this, let's not talk too much, just read the documentation, you know, create your own ideas, let's not work so closely together. It usually comes from feeling pressured that there are many things I can do as a tester to fix the atmosphere to fix the way that people end up feeling. And it does require a little bit of going out of my comfort zone in the sense of going to the managers and maybe helping create a better frame for how we take in work. I often find myself doing a lot of scoping with the product owners, for example, kind of like, Is this in? Is this out? Like instead of thinking on "it's a bug" . Yes, it's a bug, I participate in the conversations on, does it need to be fixed for this release? Or can we move it to the next release, so that we have the sense of the team kind of being able to hold on to their promises, but also that we address the problems as quickly as possible after we have delivered what we originally promised. So doing a lot of scope management work is one of those things. And I also find myself kind of like realizing that.... A lot of times when organizations don't have unit testing, it comes from the fact that we don't make space for developers to do unit testing. And sometimes, instead of hiring a new tester that I was just promised and budgeted for, moving that budget to unit testing has helped many of the cases that I have been in. So starting to look at things not only from I get to do my work, and my you know, my area, and I'm only attending to that area, looking at it more holistically, kind of like, how would we work together in the best possible way in this organization, I think that's been helping me a lot.
Lina Zubytė 37:35
You're also showing the example of being a great team member because you're working as a whole team and for the whole team's good even allocating your own resources or plans for the good of the team, which in the end will benefit you as well. But everyone else. I feel it's such a lovely example. So to wrap up this wonderful conversation we've had, what is the one piece of advice you would give for building high-quality products and teams?
Maaret Pyhäjärvi 38:10
I think for me, it's the idea of only expecting change if you change something. So if you don't change anything, nothing changes. So you need to have this idea of continuously striving for a little bit better. Start from respecting what you have today. Like even if you see a lot of problems in the way you work today, focusing on what's good of that and choosing something to make better. That creates those small flows of improvement that over time become really really big ones. So for me kind of the one piece of advice is never give up and go change something. Not everything but something.
Lina Zubytė 39:00
What a wonderful message on expecting change if you bring change yourself. Wow. Powerful words. Thank you, Maaret, so much for your time.
Maaret Pyhäjärvi 39:11
Thanks, Lina. It was great being here.
Lina Zubytė 39:14
That's it. Thank you so much for listening. You can find merits contact details and other resources in the notes. And until the next time, keep on carrying and building those high-quality products in teams. Bye.