Removing QA Column, Driving Change and Nurturing Fun in Teams with Finn Lorbeer

In this episode of Quality Bits, Lina talks to a QA-turned-Director-of-Engineering Finn Lorbeer about his past days of ripping off the QA column as a QA, the differences in driving change when you're a team member versus in a leadership position, and why having fun in the team matters.

Find Finn on:
- Twitter: https://twitter.com/finnlorbeer
- LinkedIn: https://www.linkedin.com/in/lorbeer/

Reading recommendations for some mentioned concepts:

• Double Diamond design process model: https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model) 
• On quality specialists: https://finnlor.beer/2016/07/07/are-we-only-test-manager/
• Finn's website with writings: https://finnlor.beer/author/finnvonfriesland/

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! 

Transcript

Lina Zubyte (00:08):
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'm talking to Finn Lorbeer, who is one of the most inspiring and influential people in my life. And I know that I say it a lot, but it's true and I get inspired by a lot of people. But with Finn, I do feel like he has changed my career a lot. Meeting him has opened new opportunities and doors for me. I worked at ThoughtWorks and learned so much about the modern QA world. So in this conversation we're talking about moving from consultant to becoming a Director of Engineering and how actually it's pretty humbling and it's a little bit different than being a team member to drive change. It involves talks about ripping off QA column, very controversial as well as how to advocate certain change in a nicer way and what makes good teams. So enjoy this conversation.

(01:34):
Welcome Finn to Quality Bits. I am so glad that you're here today with me because you are one of the most inspirational people in my career. I think if I haven't met you, likely I may have different ideas about the QA and very likely I would be in a different country. So I moved to Germany because we spoke at a conference and then I decided to give it a go even though it was not in my wish list, let's be honest. So thank you for all the inspiration you've done. Could you please give a short introduction about who you are?

Finn Lorbeer (02:13):
Yes. So I also remember all the conversations that we had and how we met on a conference back in the days and everything that followed after, and it's really, really nice to talk to you again. So my name is Finn and I'm a Director of Engineering at MOIA. That is my current role. I have a strong background in quality, but went to a position where I look at teams and software delivery a bit more holistic. I would say that my job is to make sure that teams are happy and able to deliver. If I can achieve those two things, then we can accomplish wonderful things in the ride pooling product that we are building here. I spent six years in a consultancy before that in all kinds of roles, I worked as a business analyst, I worked as an HR coach, I worked as a full stack developer.

(03:03):
I did my bits of heavy lifting with the backend integration, but the role that I occupied most of the time, let's put it like this, and the one that I always loved most, where I enjoyed my work most was that of the quality analysts. So looking for quality in the teams for quality in the product, for quality in the relationship of people maybe and when I'm not working. So before we had kids, we have two small kids now that occupy a lot of my time. So there's not too much going on the side. I'm teaching a bit of craft maga, which is a specialized self-defense from the Israeli military and I'm teaching handball to the small kids once per week, which is really fun. In former times I went out sailing, which was really, really cool, but time doesn't allow it maybe in five years or something. Again.

Lina Zubyte (03:57):
Nice. I think you learn a lot teaching kids as well, right?

Finn Lorbeer (04:02):
Yes. I had my fair share of learning in all the disciplines. So I teach kids on Wednesday, I teach adults on Monday and sailing. We went shipwreck in the middle of the harbor of Hamburg between the big boats where our sale didn't work, our motto broke and even our rather broke. So that was also an interesting learning. I guess there are learning experiences everywhere in life

Lina Zubyte (04:29):
And then just find parallels everywhere. As a qa, there's one thing that does follow me as a curse or a blessing, it's finding bugs everywhere. Everything breaks for me. Whatever I'm doing, I do find a fault with, it's some kind of professional illness. Do you have the same

Finn Lorbeer (04:49):
Absolutely a blessing or a curse? That's exactly on point. These things tend to happen to us, right? On the other hand, it it's sometimes led to a weird reflection. We would say maybe I'm not particularly good at my job. Maybe I'm just particularly unlucky in my life, which makes me accomplish my job easier. But there's no special skill that I'd used. Just my bad luck that I've been,

Lina Zubyte (05:12):
Oh my goodness, I hope that's not true, right? But we're helping the society, right? So if we're like magnets for all the bad things, then we help society to improve. Alright, so when you were working as a QA and we worked in the same company, I remember that you would have all kinds of experiments that you would do in the teams you joined. So in consultancy we got to work with various teams in different projects, and one of the most drastic things that I would hear you say you did was that you join a team and then you would just rip off the QA column and you as a qa, you join the team and then you just go and you remove the column and then you see how the team reacts. Could you tell a little bit more about this?

Finn Lorbeer (06:06):
Yes. I think in the beginning it was an experiment towards the end of the consultant lifestyle there it was a favorite activity when joining a team. I worked across I think 15 teams in those years. So many teams often that I joined a new team and I also had a couple of times where I joined team after team after team on some projects where I skipped from team to team for just a couple of weeks each to see where they can improve in quality and give them coaching instead of establishing myself there as a role. And there I tried it for the first times and then later I did it more consistently and then also really constructively, purposefully didn't come in and dripped it off and look what the team makes of it before I go in and drip off. I have some motivation, some idea and what is that?

(06:53):
So when you come to a new team as a quality person, so he had Moya, we call them quality specialists for a very specific reason and block post. So just that you don't wonder when I'm referring to quality specialists from time to time, what are you trying to achieve in this role? You either want to test everything that somebody is giving you on some test environment and then you want to find back and you want to find back and want to use your unlucky hand that we just talked about to find all of them. So what are you trying to accomplish in the first place? You do not want to test at the end of long process. You do not just want to find bugs. You also want to prevent bugs because if you prevent bugs, first of all, that makes your life much easier because you're not just sitting there at the end of the process testing everything and finding issues.

(07:44):
You're sitting there with a team and saying, Hey, how can we come to a better quality point where we don't have to test so much, we don't have to send you back all the tickets where we are not ending up. It's so much feedback loops that takes so much time. How can we think about fewer things at a given moment of time and just push them out of the door because there are not so many issues anymore, but we have to rework and rework and rework and then we know it, but we still have to rework this is what we want to avoid. This leads to better quality, this leads to faster delivery, this leads to higher team happiness.

Lina Zubyte (08:19):
I really like that you would just ask the team and you would say, how do we do this in a different way? Which I think is a little bit mind blowing for people because they're so used to having this column or role that does the activity that is for that column. And then when someone asks what could we do to prevent it? They're like Not short.

Finn Lorbeer (08:43):
Exactly. It's also a nice place to park some stuff right in between you. Yeah, I think I'm finished. I just put it there. Let's see. Let's find out if I'm really finished and if it's gone, what do you do? And then you stand there with the entire team and then you take the column off the wall. So I mean that's a bit harder now when you're talking hybrid or remote. It was back in the days before big C hit the world, so it was the physical wall and there was a cart glue to the top. So you could walk into the room on your first day. I mean that was towards the end of bolt statement, right? You go there and you take off this card and then the team says, what? We finally got you wire, we broke this away. Yes. And then you ask one question, that's the key question and everything else follows from there. You just ask back, do you think that quality is something that we should only think about at the end of a long development process? They also start objecting and basically make a mental list of the objections because those will immediately lead you to the points where the team has weak spots in terms of quality, but our test coverage is not high enough, but we have no integration test, but we don't know how to, but usually our acceptance criteria are not fulfilled and then immediately where to start to work with those people.

Lina Zubyte (10:06):
I also recently had a similar case where someone was like, oh yeah, we cannot release because there's no QA in the team. I was like, okay why? Oh, we need to do a smoke test before we release. Okay, why do you need the smoke test? And then you actually dig deeper that they don't trust their automation tests and they're lacking quite a lot of them. So that's why someone telling them that hates a green light. It's relieving in a sense because then are calmer. You're more confident about the release, but it also is actually giving away responsibility and accountability for quality.

Finn Lorbeer (10:44):
Absolutely nothing to add there. Exactly on point. Yeah.

Lina Zubyte (10:48):
So when you joined Moya, did you do the same? Did you also go and rip off the QA column?

Finn Lorbeer (10:54):
Yes, and literally on my first day and the team, so I joined as a consultant still in the consultancy where I worked. It was the last project that I joined. As it happened to consultants, I stayed. So at the time it was a new project, was a new team, something I had experienced a couple of times. I came there specifically because the teams had issues with quality and the clients or Moya was calling us out a bit and said this is not satisfying, this is not how we wanna proceed. So my task was really to go in there and deep dive in this topic and help the team to improve significantly and fast. And what do humans in general do? Including me when they have to do something under high pressure, they do the same, they always do. And so I went in and as I always did, I took off the QA column and then we saw where the conversation went from there and we improved in quality. So clan was happy in the end.

Lina Zubyte (11:54):
So now you're no more a consultant in the team, you're the director of engineering. Is it still the same thing that you're advocating for and encouraged? So all the teams at the company do not have a curriculum?

Finn Lorbeer (12:09):
So absolutely on advocating and encouragement, my level of success is much smaller I would say. So as director of engineering simplified, I have two options. Option one is I go into the team, I tell them exactly how the process work, I instruct the quality specialist that works now how exactly they have to fulfill that task. And I make them imitate what I did a couple of years spec without maybe even understanding the full thing behind it because they haven't spent five years thinking about it previously to that. And that is the very definition of a micromanager who comes into the teams and then helps out quotation marks. You can't see my quotation marks help out. And the other option is to show it to the team. So ultimately at Moya the teams own their processes, ultimately the quality specialist negotiate with the teammates how they want to work and how the process looks like.

(13:09):
So we have one or two people who follow that example rather. Most of the people are not. I'm still advocating. So when I do trainings, coachings, when I do workshops for all the developers on how to do delivery and discovery in general, we are looking at waltz and we are also looking at this specific wall of the team that I was in after ripping off the QA column. So we have a big picture there and we just sat on Friday in the workshop and we looked at it and I specifically pointed out, look, there's no QA column. Look, there's work in progress limit. Look, there are people pairing on stories, which is also not given all the teams, even though I want advocated for it. And look, we don't have subtasks, we just focus on delivering real value with the real acceptance criteria. And those are recommendations, guidances and coaching that I can give. But I strongly believe that teams are responsible for the process by themselves and that they should drive it by themselves. And this is a stronger principle than our how to work in quality in specific.

Lina Zubyte (14:18):
That's really interesting. It sounds like it was a little bit of a humbling experience to you because you switched from a member in a team to someone in a leadership position and actually even though an understanding of a leadership position is that you have more power, you could enforce decisions, I hate that word but in this case, if you do want to drive change, there's so many factors to consider and you cannot just drastically say, okay, now we change this team or all the teams. So you have to do it step by step. Was it humbling experience for you? Did you learn more compared to when you were a team member?

Finn Lorbeer (15:02):
Yes, plenty. Mostly around this example really of how it's sometimes important not to interfere too much. So the struggle is basically when you grow into a leadership position, when you're not following this career path from university, having studied economics or something, then directly going lateral into leadership positions in big companies. But when you grow bottom up in smaller tech companies, you are not trained for leadership, you're just trained in your profession. So I'm 10 plus years trained in quality and overall team delivery and all the roles and the interaction. This is my training, this is what I got good at. To the point where people said, Hey, maybe you can help out in a way that scales in this leadership position. So in a position that influences more than one team and exactly in this moment also, I can't use my core competency anymore. Not directly. I cannot go into, currently I'm working with nine teams, so it's impossible to go into nine teams, rip off the QA column, have all of those discussion. Also, it takes a lot of time. This is why you do it when you're one person in the team, you do it together with the team, you talk to all the people. It takes weeks until they understood what you did there and hopefully appreciate that

Lina Zubyte (16:26):
You're actually not as detached and you are, I dunno, having lunch with those people, you're talking to them, you're saying good morning to them every day, right? In leadership position, you're a little bit away from the teams, you're not as trustworthy I guess you need to earn this trust.

Finn Lorbeer (16:45):
I would object. I hope I don't have to earn trust for what I do with the teams. So I give trust to the teams immediately. We are trust-based company and society in the company or culture. So I give trust to teams and I think they give trust to me for the role that I currently have. So they trust me that I go do good decisions in the scope of my director of engineering. I don't think it's a level of trust when going to the teams. It's more a level of inter, you don't want people to interfere that don't really understand what you're doing. So on a team and process level, maybe it is trust, but I wouldn't generalize it. I hope people trust me to do my job good before I try to do their job better.

Lina Zubyte (17:33):
Yeah, it's also looks like you have to show a little bit of whatever your knowledge is. So even if we have the silent trust that whomever is filling in whatever role in the company, that they will do whatever the best job they can still with time, you see what they're promoting, how they're working and you tend to either neglect their ideas or their attention to adopt them. In your case, you mentioned that you have done lots of trainings and coachings. So what's kind of trainings have you done? So could you tell a little bit more, you mentioned some of the guidances or promoting concepts. What are you promoting or training your company on?

Finn Lorbeer (18:21):
So the biggest workshop or training that we're currently doing is a full day workshop on discovery and delivery in general and thick threat of quality going through. It was appreciated a lot by the quality specialist here, but it's not focused on it. So we start by thinking how the entire discovery delivery model works. And I always love to take the double diamond methodology of design thinking and we walk our way through the entire double diamond. So it starts with discovering a business model. So I ask people to invent a startup, then they have to write a business plan for it. And then we have a look at a user, we write an empathy map. So we try to find our business model in their needs and in their wishes. And then we start to sketch something, we write a feature list based on the sketch, we prioritize it and then we end up with a roadmap and then we pick the very first item from the roadmap and start to write acceptance criteria for this very first.

(19:20):
And that brings us in a very packed dense action, rich three hours to the lunch break. But we are basically ready to start implementation and in the afternoon we look into methodologies of software writing. So we are looking at T D D, why it may be helpful to write a test before you implement something and we're looking at pairing and why it may be helpful to get immediate feedback on what you're doing. And then we're looking at the overall process of the team. And then I'm showing an example, the one I mentioned before. And then I say, look, everything that I mentioned is here, no Q column, no T D D, no pairing was all in the scope of muya. So apparently it works and then I let the people leave into the weekend because that was a lot of information.

Lina Zubyte (20:07):
Nice. And you mentioned also pairing, and I love the quote that best ideas come in pairs. Is pairing embraced at Moya? Is it embraced to the level you would like it to or it's more that you're seeding this idea but it doesn't always happen?

Finn Lorbeer (20:25):
I think it's for me, I'm a bit too much on the, we need to pair all the time side, so it's never enough from my side. But that's also not a fair point of view maybe even, but not enough at all. So we have in quotes the problem that we are on the one hand still a company of WAN that requires a compliance process where two people have to look at one specific line of code that was committed and we have to document and enforce that, which means the only way to do that really is that two people log into GitHub and approve the line of code. That means one person commits, opens the code request, the second one accepts the board request and it leads to teams saying, ah, we have to do poll requests anyhow. Or the opening of the poll request is strong enough a statement that teams feel they have to do code reviews while it's not true.

(21:22):
So we talked a lot with their compliance department and we explain the concept of pairing and we had them visit our teams and they were working with them for a week to really understand what is going on here. And they looked at it and said like, Hey, the way you work with pass, that's really cool. In fact, it's so cool, we would like to work that way as well, but well we can't but you can. So if you just open the port request, put a thumbs up and write, we pair it, everything is fine. And on the other hand, the second point is that we're coming a bit from history of strong individual contributors who were so strong and so individual that they didn't want to pair so much because they were much more effective and productive when they worked alone. I mean maybe they were a single people, but they didn't make the team more productive that didn't spread knowledge, they didn't find the better architecture.

(22:10):
And we're dealing with all of those problems now. So I wish that we would've paired much more in the past. I also know that it's much more difficult now that we are not onsite all the time. So we are following a strong hybrid model here where everybody basically is at home on the office. So it's much more with headphones and so on. So maybe 2, 3, 4 hours is than really enough. On the other hand, if you're strongly paired for four hours, you basically did a full day's job and then it's also fine to end then stop.

Lina Zubyte (22:42):
Yeah, pairing is so intense. It's so much of cognitive load, it's making yourself vulnerable. It's two people who are showing what their skillset, discussing improving on each other and not trying to take it personally as well. When someone mm-hmm pinpoints a problem, that's really, really actually draining activity in a sense mentally because yeah, four hours, that's a lot of

Finn Lorbeer (23:12):
Pairing. Yes. But it, that's exactly the point. It shouldn't prevent you from pairing some people you say like I can't pair eight hours a day, so I'd rather do it. Not at all. And that's a bit too to

Lina Zubyte (23:24):
Binary. Yeah, that's a, that's extremes, right? And usually it's somewhere in the middle.

Finn Lorbeer (23:30):
Exactly.

Lina Zubyte (23:31):
So you mentioned trainings and promoting various ideas. I wonder what about this quote saying that if you don't have a problem, don't solve it. Has it happened to you that you come with a bag of good practices and you try to promote them, but then there's like a bigger fish you fry in the teams and how you tackle this, I guess mindset of yourself where you would want to change so much more but the team is not ready for it at all?

Finn Lorbeer (24:05):
Yeah, sure. I mean a couple of times the, so how do I deal with it? I need the mantra of patience, patience, patience. Because as I said, I'm not influencing the teams in their process of what they actually do on a daily basis directly. I try to give them structure, guidance and culture and that just takes longer. So you have to be patient. And one example is, I could go now and I could do a training with a quality specialist and we could do it, I don't know, let's say four hours every other week. That would be quite substantial training throughout a year. And then I send you rip it off and this is why and this is how you think about P prevention and those are the endeavors that you can, and then we go into coaching people bring their problems that they have or the objections that the team have, why they don't know how to deal with that.

(24:58):
So I could build a very, very strong quality culture into the teams. And why didn't I do it until now? Obviously I didn't do it because they're bigger fish to fry in their teams before I can bring one role very, very strong into the teams. I need to strengthen the other roles as well that we have now. And Moya is coming from wild startup times in the beginning, just a symbol of group of people. You ship this feature to solve this group of people, new group of people, the other feature and so on. So you're following a model of feature squads until you find out that nobody feels responsible for the services that were launched at some point of time because all the teams that once owned the services are solved and the members are spread across the organization. So you reform your organization to a more business value aligned model.

(25:50):
So we are following the team topology. So we have a bit more structures for the team and we did not yet work on the specific roles in the team or we only did this year now. So this was the bigger fish to fry what we worked on now in the first place was it defined interaction and role set for a technical lead that we call technical designer, the product owner and the agile coach and the team so that we have distinct control and ownership in the single teams over the business outcome that they want to achieve, the architecture outcome that they want to achieve and the process, how they get there. And once we have established that, and we're just in the progress of it this year, so we talked about the roles and we sharpened role definitions in the beginning of the year. We helped teams to find good people for those roles. A couple of people wanted to become those technical designers. A couple of people said it's not the right thing for me. And once we have that, then I have a strong group of people in each team that the strong quality specialists can interact with in the first place. So that is a very simple, even though long lasting example of a bigger fish that we're frying here, it's in the pan for a long time.

Lina Zubyte (27:09):
I feel like this is something that I also faced myself that as a qa, I loved working with a strong tech lead and business analyst or product manager. So it was like a three amigo that we would work together. And not having a strong deck lead ally that's difficult. You can have all kinds of dreams you want of quality and building an amazing product, but you need help and you are not a one man show. So software development is not a one person show, it's a team effort. And if there are roles in the team that could be strengthened. So I believe everyone could do a great job. It's just that maybe they're lacking training or they don't know how to do it. Providing the support and building the right team with the right roll sets extremely important. It's a base and foundation of building high quality products. I would say. You mentioned lots of advocacy I would say about quality and even team building in Moya. Looking back, how would you measure the change you've gone through and the progress? What are the achievements you're proud of? And looking back you'd say, oh we did this actually we improved, not you get lost in this roadmap of everything else and that we need to fix.

Finn Lorbeer (28:36):
Yeah, that's very simple. I cannot answer that question. How do you measure a culture? I don't know. What I do notice is that when I walk in the office here, when I walk in the hallways, when I occasionally join a team ceremony, which happens rarely, it's more often that I join a team event because they invite me. So that's a good sign. Walking, walking through the hallway, it's just a different spirit. There's a different spirit of communication interactions. People are loving. So a drastic example, a drastic example of one of the teams that I inherited when I became director of engineering was a team that was not in a good spot. They had a person that was their technical lead and that was also personal lead for all the beck and developers at the same time. So that person would come on Monday morning, start the stand up without a personal greeting or anything because time was precious, developers were expensive.

(29:31):
So we had to get right to the point, stand up done in 10 minutes because that technical designer was with product owner just chopping down the scope and then the technical lead would them distribute into a smaller subtask. So individual developers got horizontally slice subtask, but they didn't really know how it contributed to business value and they were measured against how fast they gave it back. And the team spirit was, I don't know, it wasn't good. I wonder why. So the first thing that I did as a cultural transformation was to split the people management from the technical leadership in the teams. So we went through the first transformation that was in my first year where we separated this. So every technical leaders responsible for all the people in their team, but the people leader, we call them chapter leads here, the chapter leaders outside of the team.

(30:25):
So that for every technical discussion where you bang your hat on the team, you don't have your supervisor or report or up in the hierarchy or what it is in the room so that you can speak freely and openly and by now. So how do I measure? I still don't measure, but I meet the team and the team is sitting together, they're all coming to Hamburg. Even the one external developer from Hungary is coming and they are all sitting in the room, they're smiling, they're laughing, you're wondering which team it is that is in such a good mood when you walk by the glass wall of the room where they're meeting and it's this team, they are going all together to the hubs that we have for and our entire fleet is cause when you sit in front of your computer, you never notice how big the fleet management is and all of that. I can't put a KPI on that, but I know it improved and I also know that their output improved. So looking at the roadmap and what they accomplish, I have a better gut feeling and I will not have more than a gut feeling because I won't measure a team's process and judge them based on that. I want the teams to learn to measure process themselves and judge themselves instead of me.

Lina Zubyte (31:36):
I really love this idea of a happy team. I feel like the most high performing team I have worked at in my life was the team that had so much of fun together. We even had a vocabulary of how to say good morning in each of ours respective native languages and we would joke around so much and our work amount was crazy effective. So we were extremely effective and it was because even though we were different and diverse, we learned how to work with each other. We learned how to have fun with each other as well. And this playfulness helps a lot with overall motivation and mood and just being more effective. Actually I think Etsy also had this little measurement of how your day was or how your mood was a happy meter. I really like that idea. Talking about metrics when it comes to quality, I would say if your team members are happy, then you're on the right way. You're building a high quality team because if someone is negative, that's so draining. Also, that affects the whole team.

Finn Lorbeer (32:46):
It depends on the general company that you work in. If you work in SP startups where people are in general, I mean not just startups, I wasn't too many startups. That's why I always come with this example. But here's what, there's so many passionate individuals that want to accomplish something in their life and something good for the society with the product that we are building, that means you are also just happy if you're productive. It could also be that you're in some organization and you're just happy because you have nothing to do. That is the other thing that is always mentioned by top managers and leaders who say if the team is happy, they are not doing enough work. <laugh> work has to hurt. It's one quote that I once heard. Oh gosh, in this context, if the team has fun, it implies a couple of things.

(33:36):
Also what you just said that the entire team had their morning greetings and all their languages. That is a lot of empathy that people are showing to each other, which is the basis for trust. How do you build trust in a team? Certainly not by walking into the room and telling the people that apparently they're trusting each other now because the manager told them. So trust is something like you give trust in general, first of all to people. You do not distrust them by default. You give them a bit of trust. But this deep trust in a relationship towards the other person, really, really knowing when push comes to show, if they entirely have your back, that has to grow. And if you greet each other in the morning creating empathy for the culture and the background that you have, creating more empathy, then you only start to build trust, which is the base layer for high performing teams. So it's not a small thing or a funny thing or it's not. We deserve to have fun at work because our life is so pressure, it's in my opinion, it's fundamentally required to have fun in the team in order to become high performing and not the haha fun. Right? I had a good day today, I had a fun day today. It's not that we made that we cracked a lot of hilarious jokes. That's not the fun that I mean here.

Lina Zubyte (34:55):
Yeah, it's a lot about belonging. So me as my authentic self, I can bring myself to work. So this vocabulary or saying good morning in my native language, hearing it, it respects me as a person. It respects my authenticity, which makes me happier to work in this team that I can bring myself with all my strengths, with all my quirks, with all my skillsets. So I think it's, yes, it's a great foundation for a high performing team. We're having such an interesting conversation, but I have to ask you about Moya a little bit more. So you are also involving a little bit of hardware when you're testing as far as I understand and it's so unusual to me because I've never tested anything with hardware. So do you have any creative testing examples or stories that you face that you would like to share?

Finn Lorbeer (35:52):
Yeah, so we are looking into a lot of hardware also now when it comes to the autonomous vehicle because there's much more hard and software running in the vehicle obviously and small disclaim upfront. I also never worked in this field previous to Muya. Now we have really specialists in this field and I also see that the methodology of we just grab, tear the testing card off the wall, which works incredibly well for super agile software development doesn't work if you want to have by government regulations, certified software for vehicle mass production because there are some regulations and certifications that require you to have that regardless of whether you like it or not. So there are a lot of interesting compromises that you have to make and we are currently in the process of figuring that out. So there's the entire domain that is working on the software inside the vehicle and they are coming from the site where they have to fulfill requirements to the process.

(36:56):
And then they asked me to occasionally join a conversation and see how we can give it a bit more of an agile flavor, let's put it like this. And regardless of whether you have this column at the end, you can still be involved in the beginning. And this is what we are learning now also in the hardware world to reduce feedback loops, to have bug found often or to have them not happen in the first place. But still there's some history to muya. So we are operating since a couple of years now and we had our own learnings also when we didn't have autonomous vehicles when it was the vehicles we have right now where we are operating a small screen where you can see until when you are in the vehicle when you're dropped off. And we had to particularly funny thing at some time, I mean wasn't funny at the time we noticed that our vehicle would go offline randomly.

(37:46):
Someone started someone in summer and at some point of time they just came online again. And this got more and more as summer progressed and we wondered what it was and we formed a task group of software developers and of the hardware people of the people who are maintaining the vehicle. So the real engineers that change a wheel, not the engineers that load some files on the server and make them run. So they investigated a lot because it was a really big trouble. And what they found out in the end was that we had a problem with our vehicles themselves and the temperature in them cuz our vehicle have a black roof and in summer when you drive through the city all day long, I think at some point they noticed there was vehicles that were out for longer time. So if you drive through the city all day long, the temperature under the roof rose like the two or three centimeters under the roof that were not served by air conditioning.

(38:45):
So the last few centimeters under the pitch black roof, they were 50 degrees hot Celsius, same carts are cheap plastic and they are not built to sustain those high temperature. I mean at this point of time also some enzymes and so on breakdown and also sim cards. So ultimately we figured that the sim cards were melting and the sim cards were losing the contact to the router they were put in. So ultimately we just lost our entire internet connection in the single vehicles and it manifested in so many software systems that it was incredibly hard to triangulate and debug that it's a bit of plastic melting under the sun. Wow.

Lina Zubyte (39:27):
And what did you do there though? Can you affect the plastic of the sim cord?

Finn Lorbeer (39:33):
Apparently there are fireproof, I don't know how fireproof they are, but they are the temperature resistant sim cards. So we ordered a special batch of sim cards and then we had to replace a lot of sim cards, which was also interesting because there were a couple of software developers who were then helping to switch them. And if you have to switch a tiny, tiny plastic chip in 500 vehicles where you have to get the key for each of those vehicles and you shouldn't mess up with the keys and mix them because nobody finds which one is which anymore. Afterwards. You also learn a lot about processes, especially CanBan,

Lina Zubyte (40:10):
How

Finn Lorbeer (40:11):
Well it, it's a full cue, right? Somebody has to go, you have to grab the key, you go to the vp,

Lina Zubyte (40:17):
I bring

Finn Lorbeer (40:17):
It on the yard, you have to find it, then you open the door, then you put up the sim card, then you close the door, then you bring the key back, five minutes are gone. So you're thinking about optimizing this.

Lina Zubyte (40:27):
Yeah, this example was really interesting and unusual, who could have thought of that? And also thinking about this like cost reductions and things like that. So you could just order the cheapest sim cards and then you actually learn the hard way why you need something better. So I think this is a great place for us also to wrap up our conversation and topics we've touched on here. If you had to give one advice for building high quality products and teams, what would be it?

Finn Lorbeer (41:04):
One advice. Listen to this podcast because there were a lot of advisors in there, but that also doesn't make sense in the end. That's maybe it easier. So the one advice I would give is that you shouldn't waste a good stake but learn from it. And then you can become very, very creative in what that means for your context, what your team, how you can make it safe to create or to make mistakes. How you can create an environment where mistakes are not painful, where people don't look at you, where people don't point of view, where you get the opportunity to learn where mistakes don't have a great impact other than gaining knowledge.

Lina Zubyte (41:44):
Love it. That's a great message to wrap up the conversation. Thank you so much Finn, for this great inspiring conversation as usual. Love talking to you.

Finn Lorbeer (41:56):
It was so nice. Thanks a lot for having me. I enjoyed it. Thoroughly have to say.

Lina Zubyte (42:01):
That's it for this episode. Thank you so much for listening. Feel free to leave your reviews about this podcast, any feedback that you have to me. And until the next time, keep on building and caring about those high quality products and teams. Thank you.