From intern to CEO with agile testing expert Alex Schladebeck

About Alex Schladebeck
Alex Schladebeck, is a testing expert and powerful voice in the tech community. Alex is the CEO of Bredex, a dev shop that offers tailor-made IT solutions but also specializes in quality assurance and testing. A decade ago, Alex graduated in linguistic and came into tech by accident.

Read the whole episode "From intern to CEO with agile testing expert Alex Schladebeck" (Transcript)

[This transcript is the result of a community effort. You can help make it better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.
Special thanks to The QA Guy for helping improve this transcript.]

Michaela: [00:00:00] Hello, and welcome to the software engineering unlocked podcast. I'm your host, Dr. McKayla, and today I have the pleasure to talk to Alex Schladebeck.

But before I start, I wanted to give you an update on my experience with Codesubmit. As you might know, I started hiring engineers for a startup I work with at the same time as the founders of Codesubmit - a take-home assignment platform - reached out to sponsor the podcast. Their tool really fascinated me. And so I used it over the last three weeks. What I think really sets this tool apart is its ability to easily create task and distribute them using Git. I also love that I could tailor my assignments so that they reflect a task a candidate would also perform while working at the company. Codesubmit supports 64 different languages and frameworks. I let my candidates choose between implementing the solution in Python or JavaScript - as those are the required technologies for us. I'm super happy with the tool and I can also happily report that the first engineer I interviewed with this tool signed the contract last Friday. So if you're also in need for the take-home assignment platform to streamline your hiring process, please have a look at codesubmit.io. They also offer a free trial, but now back to Alex.

Alex is the CEO of Bredex, a dev shop that offers tailor-made IT solutions, but also specializes in quality assurance and testing. I met Alex at an EclipseCon - a conference for Eclipse and Java developers - ages ago. There she actually led workshops for devs and testers to improve the testing strategy by using an UI testing tool that was also developed at Bredex. When we met afterwards for drinks and chit chat, Alex told me she actually has a linguistic degree and came into software development more or less by accident because she had the company improved the documentation. Fast forward a decade, and she's now one of the heads of this company. If that doesn't sound like a story that needs to be told. So I'm super thrilled to have Alex here with me. Alex, welcome to the show.

Alex: [00:01:57] Thank you so much, Michaela. I'm really pleased to be here.

Michaela:[00:01:59] Yeah. I'm also really happy. So Alex looking back 10 years from today, or something like 10 years, what do you have imagined that you are going to be the CEO of products?

Alex: [00:02:10] No 10, 10 years ago. Definitely not. Um, over, over the last few years it became, when it became, I became a team leader and I knew that, uh, one of the, one of the current CEOs was going to be leaving. So we, we have three and I knew one of them was leaving. And at that point I was like, Oh, is this may be a thing that I could be is that possible, but I think 10 years ago, um, I'm, I'm not so great with the sorts of five-year plans for me personally. Um, and so 10 years ago I would have probably be like, my aim this year is to go on a nice holiday and teach more people about testing. Um, that would have been, that would have been it, so I, uh, 10 years ago no, and yeah, it kind of started to get more concrete as the years went on.

Michaela:[00:02:57] So more or less it grow on you or in grew on you?

Alex: [00:03:01] Yeah, much like software development itself. Uh, actually, and, and, and IT, um, I, um, I'm a great believer in exploring. Um, one of the, one of the, um, my favorite approaches to testing is, is exploratory testing. The idea that we find something out and we learned from that, um, what we've learned, we put into practice in our next steps. And I think that's very. I think that's a very agile way of doing things. And I also think that's how I tend to do things. Um, I, I go and explore something and then I find out what that means. And then I learned something and then I adapt it. And that's, that's been basically every step of my way, just doing things and seeing what opportunities come up and saying, yeah, I think that I want that and, and going forward.

Michaela:[00:03:46] And so before you became the CEO, what was your last, your last, um, title or role or what were your responsibilities? Were they already like similar? You said like a project lead and things like this, very similar to what you have or the responsibilities that you have now, or very different.

Alex: [00:04:03] Say my last title and I've, and I've kept it because it was important to me, um, is, uh, is head of quality. Um, so I, in that role, I am still, obviously I'm delegating more, um, because I have to, um, but in that role, I'm still responsible for what strategies we have. How are we working in projects with customers? What things do customers need? What, uh, what things are coming up in the future in terms of testing and quality that we need to be aware of and how are we making sure that quality isn't just brought into teams via testers. And, but also the developers are, uh, working on that, um, whole team quality, all these kinds of things. Um, and that was alongside that role. That's kind of the domain role that I had. And I was also a team lead, which meant that I had, um, uh, I was responsible for, I was a line manager for, for various people and that's something that's, that's stayed obviously. Um, over the last few years, the company has really been working towards making sure that we move decision-making capabilities closest to the people who are affected by the decisions and who are able to actually make the better decisions. So being a team lead in some ways was very, very similar to the things I'm doing now, um, because a lot of the time it's the group of team leads that makes the decision and not somebody at the top, as it were saying, no, we're going to do this. Um, what's changed though, is that, (laughs) and I still find myself doing this, um, if I have a question that I'm like, Oh, I don't know how we're going to deal with this. And we're not, you know, we're not coming to a conclusion with all of the team leads, in my mind I still go to one of the other CEOs to be like, Hey, what are we going to do about this? And I'm trying to catch myself doing that now and be like, wait a second, Alex. This might be something that you have to learn to once. (laughs) So instead of kind of going off and being like, I have this question to think, okay, what would I do about this right now? And then I can still go and test that and see how, you know, see how someone else was more experienced with react. Um, that's the big gap for me right now: Realizing that. Uh, there's not, it's not necessarily the case that somebody else is going to give me all of the answers. I might be responsible for more of the answers now.

Michaela:[00:06:09] Yeah. Yeah. Um, so I think, I think right now they're, um, much, yeah, much more people with a non-traditional background in tech because the resources are there. I mean, I don't know how you experienced it, but 15 years back, right when I started or even a little bit longer, um, the internet existed, but it was not that you just went on and you learned whatever you need to know. Right. It was really, there was not a lot of information and you had to go to, you know, um, libraries and get books and even books were as scarce resource, I think, information and knowledge wasn't there. Maybe you needed, I mean, I hear it often, right? You needed less knowledge as you need today. But because of that, I think there were not so many people that came from a non-traditional background. So I think you really stood out at eclipseCon at that point when you were saying, well, actually, you know, I studied linguistics and not computer science or, you know, R and did some, some background or have some background education in this. And, um, so, uh, What, and now I think there are more people, you know, with this non-traditional background and I think they want to know, you know, how can I move from where I am because I think it's still hard. Right? It's still hard. You have to know so much. So even though there is more information now available, you have to know more, right? So the bar somehow has been raised, I think. And it's still really hard, I think, to start into tech and really be successful there. So if you think back, um, Did you know how you came from this non tech techie background into a techie background? Right? So I imagine it like this, right? You start by reading tech documentation to try to improve it. And so you have to learn about what you want to improve. And so somehow this somehow transformed you into a techie from a non-techie, but I guess there were different steps that you had to take, maybe learn something on the side, or you do a workshop or whatnot. And so. How did you do this transition into tech?

Alex: [00:08:15] Yeah, it was. I mean, the, the short answer is that it's a long transition and it's still ongoing. Right? I mean, I am, I'm never going to be done learning. Um, at the very beginning it was, it was incredibly, it was incredibly difficult, but in a challenging way. Um, I'm not the kind of person that likes being in my comfort zone. I like being in my learning zone. I sometimes push myself into my panic zone, which is maybe not ideal. Um, and I think I was looking at the time because I went, when I started, it was basically a summer job. So the stakes were low. I could, if I wanted to, I could, you know, I could move back home. That was the plan after two months to move back home, that plan didn't work. And in those two months it was a, it was a nice, safe space to just be like, well, I. I don't know anything about this. I mean, I thought I was just going to be translating, which was something I could definitely do. And, and I wasn't, I was writing the documentation and it was with all kinds of tools and markup languages. I didn't even know what markup language was. I mean, like, um, and so at that time I said, okay, who can sit next to me and help me? Who can I go and ask for questions? I've never been afraid of just, uh, Approaching people and asking for help. Um, I did some reading. I made a lot of mistakes, um, and, and that really gave me just those first two months, I think made me realize, wait a second, even though this is something I've never ever done before, I am capable of learning here as well. Uh, and I was already noticing that some of the questions I was asking that they were actually quite useful to the people I was working with. Um, and. Well, actually one of my teammates asked me last year, she said, okay, how can I become, okay, this, you know, how can I become more technical? And I'm, I'm doing air quotes because there's this whole idea about people who are, and aren't technical. And I read a fantastic thing the other day in a book about language that says that anyone who is capable of using any tool like the apes used to, to hit things with, we are technical as humans, we are technical. What I meant, what she meant and what I, well, I mean, with it is knowing more about the specific tools and techniques and methods that we use in, um, in software development. And I basically, I think some of the things that I started doing deliberately, where I would go to our company, uh, all hands meetings, listen to talks about features in Java or Frameworks or and I, I understood practically nothing to just really sit there and go, if I'm lucky, I've understood the problem statements. And this is something that I always look at now when I'm reviewing people's talks or whatever. I don't care where it goes, but if I don't understand what the problem was in the first place, then I think that that's a bad sign of a badly structured talk. And sometimes when I understood the problem and I'm like, okay, I think I understood this. Then I would go and ask someone afterwards, either the speaker or someone who I, who I trusted to, to give me an answer that I would understand and be patient with me. And over many, many, many weeks and years you start realizing that, Oh, I know this. And then I added on, you know, and then I went and put myself in the situation where I'd be at conferences and listening to talks I didn't understand. Um, or I'd work closer with developers or other people. And I think it's just being comfortable with throwing yourself reasonably, constantly into something where you're like, I do not know this and accepting the pain of feeling stupid and not knowing something. Especially if you've come from some of the kind of, uh, you know, I had, I got really good results for my linguistics degree, like, um, and then, and then feeling, and then feeling kind of stupid even sometimes because you just like, I just can't get this. Um, I took part in some courses, I did a Java development course. Um, I've done it a few times and I think the third time it finally stuck. And now I would say, I understand actually a bit of Java. Uh, now no one uses it anymore right now. It's still, it's still very much used. Um, but the first time it was very much a course for people who already spoke or spoke already used three languages and just needed to figure out how Java works. And I was just like by day two, we were onto arrays and I swear to God. I spent so much time learning about arrays. And then I found out that there's something called lists, which make your life easy. I'm like, I feel really like, why would you do this to me? Um, But, um, but doing all of that, I always got the feedback that the things that I learned when I was then asking questions that people were like, that's a good question. And I realized that fed into my testing and fed into my, uh, my exploration around all the things and that the questions I was asking because of the things I learned that they were good questions. So I always had that feedback of knowing I was on the right way. And that's how, that's how I still do it. Um, yeah.

Michaela:[00:13:02] And so did you, do you have the feeling I probably right now you have, but when, when was the time that you felt you arrived, that you belong in tech? Do you know? Or did you have this feeling very early on already?

Alex: [00:13:15] I think I can't remember exactly the dates of it, but I think that the few, the few pivotal moments for me was, um, and this, this must've only been about a year or two years, maybe after I joined the company, but I was playing World of Warcraft. So first of all, I was playing World of Warcraft. Obviously I'm a techie now. Um, and something went wrong and I instinctively knew that probably what it was, was just a UI problem. And I needed to refresh. And that moment of, I understand how things work and I have an assumption and it turns out to be a correct one. But even if it wasn't correct, I have an assumption of what, what is going to happen here and what I need to do, that was one of the moments. Um, around about that time at some point I made a joke. Like a computer science joke. And I was like, wow, I used to be cool. Actually, that's a lie. I never used to be cool. I'm just geeky in a lot of different ways now that's fine. Um, and then around about the time, I think it was 2007, maybe 2008. When I started going to conferences and talking about the things that I was learning and the things I knew, um, I was like, wow, I am, I'm five years, three years out of uni. And I'm speaking at a developer conference and I'm not even a developer. He, he, um, so I think those were the, those were definitely the points. Um, and I've, I've been so, so lucky to always be surrounded by people who, who supported me and never made me feel like I was other, um, uh, and who've been like, it's actually good to have your perspective in on this. Uh, so it was pretty early on and I still definitely have my days when I'm like, Oh God, I'll never understand all of this. And I still don't think I really knew what Kubernetes is, does. Like it's like it keeps changing and it keeps being more things, but I'm, I'm, I'm good. I'm good at buzzword bingo. And I think I'm better at, just than just buzzword bingo. Um, so, uh, so I keep learning and I keep asking and I feel very much like I belong here. Um, and it's nice to look around and see that I am not the only person like me who also belongs here. That definitely has changed like you were saying.

Michaela:[00:15:23] Okay. Yeah. So. Maybe to give also my listeners, a little bit of background. Um, can you tell me a little bit about Bredex? Yeah. And also how this company grew over the last years. Right. So what was Bredex 10 years ago? I think companies also change, right? The identity of a company has changed the direction, but do you think they were going or what they're becoming, uh, changes or maybe it's the same? I don't know, but I think there is some, you know, change, uh, in every aspect of our life. And also you mentioned it really briefly that you came for the internship, but you are actually from England. Right? And so Bredex is actually a German based company. So can you tell me as a little bit, like, you know, what are the roots of Bredex and where are you heading towards?

Alex: [00:16:07] So when I, when I joined in 2005, uh, there were fewer than 30 people who worked at the company. I was, um, the only person who wasn't a developer. Uh, I mean, we had, so we had a back office, um, and like a secretary, um, but I was the only person in teams that wasn't a developer. Um, and so I was the first, that was, that was a big, and I think I was, I was the first, like people had come from different backgrounds, like physics or other things, but they had all become developers and I wasn't going to be that. So that was a big, I didn't see it at the time, but that was probably a big moment for the company now that I can see it from the other perspective. And they took a chance on me, which I thought was fantastic. Um, and now I'll fast-forward and then I'll go to the bits in between. Now we have 150, um, employees. Um, I do know most of all of the names and I have to practice because the difference between knowing 30 names and knowing 150 names is big. Um, so I do practice because that's incredibly important to me to know who people are. And, um, I'm making sure that I, I, I can, I can say hi to them and I know what they're doing. Um, that has become something that's become just more efforts. Um, you know, it used to be the case I knew everybody on their husbands or wives name and, uh, their dogs and their cats. And now I know that mostly for my team. Um, and yeah, for, for other people, you, you just have to go out and talk to them and make sure that there are enough opportunities to talk out, you know, outside of your own team. Um, we have, we have grown and diversified a great deal. Um, and I think one of the, one of the big changes is definitely in terms of how we are structured as a company. So up until 2013, Uh, like I say, we've, we've always had three CEO's and 2013, the original CEO left. Um, and I believe you might have met him as well. His name was AchimBrede, um, which is where the name comes from Bredex. Um, he retired and he he'd been the founder. Um, and that that started a shift that was necessary. Um, not because he'd done things wrong, but because we definitely were growing. Um, so we could no longer have the one person, um, at the top who knew everything and was making all of the decisions, um, that just even three people, right. That just doesn't scale at some points. Um, and, and it's not agile, it's not a good way of doing things. And we, we believe very much in having an agile mindset and being, and learning and adapting and being resilient. Um, one word that I, I prefer not to talk about people or companies being strong, because that sounds kind of brittle. It sounds like a thing that you have, or you don't have, and it can break. I like to talk about resilience because that means that it's something you can practice. It's something elastic and it means I'm adapting to whatever this new situation is. And I'm showing strength through that. But it's not just this thing I, I have already, um, And so over the last few years we've done a lot of work. And like I say, having this, yes, it's a hierarchy. So if we, I hope we're not doing it wrong and I don't think we're doing it wrong. If it was bad, it basically would be, Oh, it's just another level of management to get to the management. But the focus has been on very much, Those people who are these team leads are responsible for their own decisions in their own departments and and cross department. Then we have to work together. It can't just be this kind of "I'm in my box and I don't care about your box" mentality. So we do a lot of talking. We make sure that we're making decisions quickly and, or even delegating decisions back to project leads or back to people themselves. Um, And obviously sometimes there's things that we at the C level need to say, okay, this is the direction we're going in, or this is no, sorry, this is how we want to do it. That doesn't happen all of that often because we have good people who we've trained to think, not like us. And it's still hard for me to talk about us because I'm still getting used to being there instead of at the other level. Um, Not everybody thinks the same, everybody brings in their own perspective. And then we, we work through that. Um, and, uh, and that's, I think the big, big change that we've had, um, in terms of, in terms of culture and working together, uh, and it's fascinating and interesting to see. And we still have work to do, you know, there are some things that we notice, okay, that's still maybe a vestige or a remnants of when we were a lot smaller and it used to work like that. And we find those things and we find them painful and then we find a way of dealing with them. And I think that that's normal.

Michaela:[00:20:44] Yeah. And so, um, the main focus of this company is this tailored software development for other companies or what is, what are the core functionality? I looked on the website and it definitely changes over time. Right? I mean, we typically are doing something different than with 150 people. Um, but so what is the, what is the heart of what you offer at Bredex?

Alex: [00:21:06] Yeah, the heart is that we offer software solutions for things that need, I mean the new word is, where does things need to be digitalized, right. Um, but that's, that's just a word. If you have a process that is either being done manually or being done partially, manually, or being done in, Yeah, let's say Excel, um, and you need software for that for various reasons. Um, and so the, the heart of what we really do is we say we can work with the people who need that software to find out what they really need, get it to you, get it rolled out to you. And, um, that's been, that's been one of our most important things for a long time, we don't just do that in the sense of "Okay. Here's the team of software developers" Since I started, we've also had quality assurance being embedded into teams for a few years now. Uh, we've also had UX. We also have data protection. Um, so we, we say all of the things that really need to belong to a software project - we put them in at the right time so that these things don't end up being forgotten or done at the end. Um, and of course, then once you do have like domains, like quality assurance and UX and data protection, those are things that, so sometimes we just go to customers just to do one of those things. Right. Um, but I'd say 80% of our, of our business is that we are working either alone as a company or with other companies because we partner a lot because partnering is important, um, that we are working in teams where we have all or most of these roles fulfilled.

Michaela:[00:22:41] And so can I imagine that the other companies that are hiring you, do they normally have their own IT department or are these companies that don't have their IT, or they don't have their programmers and developers yet?

Alex: [00:22:53] Sometimes yes. Sometimes no. I mean, we're, we're active in some, some rather large companies where they do have their own IT. And we are one of many, many, many people who are working for them. Um, that's and that's something that we're very, very good at, like, being able to do software for kind of a huge conglomeration or a concern, being able to make sure that you're delivering value. I'm going to say despite a lot of the processes and hoops that you have to jump through and things that you're like "But this makes no sense right now" Um, but still being able to have those conversations with customers and get, get things through the door and make things, make sure that things happen. Um, that's a skill that I am very proud that we have. And I think that there are a lot of people that don't do that as well as we can. Um, the other side is, and this is something we're moving into more and more is yeah going to customers who don't have their own IT department and saying, you know, what do you need? Um, That brings whole new, interesting challenges, because if you are very used to working with customers who even if, sometimes you're like "okay, uh, this process is maybe a bit weird, but sure, that's the process" If you're working with customers, who've never done IT before you actually have quite a lot of work to do to teach them what it's about. And that's. Uh, it's, it's fascinating. It's um, because all of the things that we know and just live and breathe, uh, they're going to not assume the same things that we do. And, uh, and it's our job as a, as a good company to make sure that they know what's going on, what they can expect, what we expect from them as well. Um, and, uh, and that's the thing that we've been working on, um, in the last couple of years as well.

Michaela:[00:24:36] Yeah. So, um, what I ask, especially if I have people on my, on my show that, um, run software projects or develop software for others is how much of the processes are you dictating? Or, you know, are you keeping on to and say, well, we are not going to change that. Right? So even if you are developing software for you, these are the things like how we are doing it. And we are not, not super flexible on, you know, going around here. And what are the things that you say, well, we can work with your process over here or even, you know, with the good process over here.

Alex: [00:25:09] Yeah. So I think the, the easy way of saying that, that anything that's reasonably internal to the development team, um, is, is something where we really say, look, this is where we are the experts. Um, so we, we do work with customers who have, um, they have an external testing department, their tester or their Quality assurance processes have to have to, it's just, it's it's there in the process. They have to do it. They have to take a look at the things and we're like, okay, that's fine. We're not going to be able to convince you not to do that. But we are still going to have an embedded tester in the team where we're going to have lots of automation we're going to use. Even if the project itself is still reasonably waterfally, which some of them are, especially for, especially for legacy systems that have been going on for so long. They are so important for the customer that they are running and, to be fair there's no need to do them in an agile way because we know the technology and we know the scope and we know what we need to do, you know, but at the same time, because we're developing we're saying, okay, we need to have automated tests at various levels. This is what we're doing. Your, your test team can look at it later, fine. And if they find anything we've missed, then we'll learn from that. But we kind of assume that they're not going to find anything bad. So that's something where we say, sorry, that's how we, that's how we do it professionally. For other things, in terms of like, We would really prefer to go through a different process of how we get, uh, get the project and how we get paid for it. Right. We can, we can request all we like, but (laughs) that probably, or if, you know, I think everyone who works in software companies or any company well knows, yeah: "We we'd like to have a 14 day, uh, 14 days payment". And the big concern is like, "That's nice that you want that, but we're going to say no". So, um, so there are always going to be those kinds of factors. And again, here, a lot of it comes down to human communication. People can be very pragmatic and, and follow that, follow the correct processes, but be pragmatic as well. But you have to have that trust. You have to be able to be having those conversations with your direct customer contacts so that they know, okay, if I do this, which is maybe not a hundred percent exactly how it should be, but it gets us close enough, I need to know that that's going to be fine for me. And that's the trust that you've got to build up.

Michaela:[00:27:20] Yeah. So, um, I think you are the right person on my show to ask that question. I ask that quite often. Um, but I I'm really interested in your, in your answer and you've hinted a little bit to it. Um, here already is. So now everything is going like agile or you know, well, um, continuous deployment, continuous integration, I guess you're doing that, uh, at Bredex as well. Um, What is the role of testing. I'm still baffled with that. Right. I get different answers. And most of the answers that I got here on my podcast, I'm not super satisfied with them. Like they are like, Oh, but there's no concrete answer. So maybe I tried with, I would say a tester. I think you are tester by heart.

Alex: [00:27:57] Yeah, I am.

Michaela: [00:28:00] And, um, so how do you see that? What is the role? I mean, automated testing. I totally understand. I mean, this is the backbone of a dev ops, right? And, and this, this, Continuous integration, continuous deployment that you have your tests and they're running instantlyish,

Alex: [00:28:15] "ish" (laughs)

Michaela: [00:28:16] Depending on how large they are and how long ago they ran. But let's say within minutes, hours, something like this, right. Uh, but what do we do with manual testing? How does this black into, when are we, you know, When are we activating our manual testers to test something new and are they testing over and over again the same thing or, you know, uh, what, how, how are you handling that?

Alex: [00:28:44] Yeah, so I have, I have very strong, What's the nice word, uh, strongly held, loose opinions, um, or loose, no loosely held strong opinions. That's the correct way. So I'm always willing to learn. I'm always willing to learn more on this, but my experience and sorts of my crystal ball really puts me in a very specific, uh, way, which is I, I believe firmly, and this is never going to be a hundred percent situation, I have, I even have examples of teams that don't do it like this and they're fine, however, I believe firmly that, um, having a tester role on a team instead of just having testing competencies is a good idea. I have, and, and I have multiple reasons for this first of all. We said at the beginning, you said at the beginning, there was so, so much going on now, even developers say, come on, I'm actually more front-ends or I'm more, I'm a backend. So even within development, we're seeing much more of a split from this "full stack" to "there is too much, I cannot do everything". And I don't understand how we can get into the idea that these people who were saying "development itself is too big and I need to focus" that they would also say, "Oh, but sure. I can also be enough of a specialist in testing and UX and data protection and business analysis as well." That's ridiculous. Anyone. I believe that anyone who understands the agile manifesto or scrum as "The dev team is only developers on, they all have to be able to do anything". I believe that they have may be fundamentally misunderstood it. Cross-functional teams and diversity is good for us. So. And, and I, in terms of what is the role? I, I see testers and it's very context dependent, but I see them doing things like exploratory testing as soon as features are ready, or even before. I see them pairing with developers on things like unit tests and TDD. Um, I see them doing organizing ensemble testing sessions or ensemble programming sessions, because that's something that helps the quality above and beyond "Did I find an error or did I not?" I see them being involved in conversations with product owners. I see them talking about risk. I see them talking about, "okay. When we are deploying, once it is deployed. Then doing exploratory testing in production". One of my favorite buzzwords right now is observability. So what are my unknown unknowns that I only find in production hands-on testing. And I believe so strongly the exploration is something that we will need so, so much more in the future because the amount of unknown unknowns is increasing. So people with exactly that skill are going to be in high demand and they will probably also need other skills as well, because there's just so much to do. And, um, I forget where I heard it. It was agile testing days. I think it was Damian Synadinos. Um, he talks instead above, uh, of T shaping people of having comb shaped people. So I have, I have, uh, I have a lot of things that I can do generally. And instead of just having one or two things that go down where I have a special specialty and I have multiple, and some of them are small. Right. I'm just learning. I'm like "I don't have much of a specialty" but it's a bit more than maybe that person and I can help, or I have a very, very deep specialty. Um, and I think getting teams together of comb-shaped people who still, and this is the balance you have to get, no one person is the silo. It can't be the case for testing, for database, for whatever. No one person is the silo, and yet they are the person that brings maybe the most specialty, encourages the rest of the team to always have this, has a certain degree of ownership and in an agile sense, not in a, this is mine and I won't share my knowledge, but "I am the one that cares the most about this. I have the passion." This is one thing that I talk to about developers about. I'm like, "I want you all to do testing as well", but all of any developer who says, "Oh, we don't need a tester in the team because we can do anything." Then I often ask the question, "okay, are you really, are you really willing to start going to testing conferences and talking about testing only in your team and making sure that you stay up to date?" and often the answer is "no, not really." So my point is the people who want to specialize, who have the passion, I want those to be in those specialist roles, but not in the sense of "I have everything", but "I am helping everywhere. I am bringing my perspective everywhere and I'm teaching everyone on this team to know more about the thing I'm doing". And at the same time, I'm learning from everyone on this team about how I can help them and how we can work together. And I think that's, that's a long way. I haven't found the simple word for that yet, but that's how I see how I see the role evolving. And it does evolve five years. Well, when we, when we met, I said, testers should not program. That was a thing I believed. I now believe that it's very, very useful for testers to be able to do some coding. Um, three years ago. I would've said testers shouldn't also be involved in the team in writing maybe production code. I've got three examples of testers who do that now. That's fine. It, every team is going to find its way of who needs what in different ways. Um, and that's, that's,t hat's great. Um, so I think, yes, we need people who have this testing specialty and we need them in teams and the whole team always needs to be learning and growing together.

Michaela:[00:33:54] So if I understand correctly, it means that let's say we have a team, let's keep it really small just for our demonstration purposes. Right. Let's say we have a team and there's like, a backend developer, a front-end developer and the tester. Right. Let's keep it small. And so the best would be if the backend knows a little bit like in this comb shape thing, and knows a little bit about front end so that they can communicate well with the front end developer, which has a very deep expertise in front end. Right. But the front end also knows a little bit about backend and both of them know a little bit about testing, but the main passion about, you know, staying up to date and really knowing every thing about testing is the person that has the testing specialty. So they are overlapping. Um, and that helps them to communicate in, in a better way and also understanding their viewpoints a little bit better. Um, and so this is also how they are connecting, right? It's like a puzzle somehow they are like having this, this, uh, dots where you can connect them together.

Alex: [00:34:45] Yeah, exactly.

Michaela:[00:34:48] That makes sense. Another thing that you actually said was like, uh, ensemble, uh, software development. Can you tell me a little bit how, how you do that and how does that influence, um, how, how, how you structure your software development processes and why is that so important?

Alex: [00:35:07] Yeah. So the idea of, of, um, and it's been, it's well known at the moment as mob programming and because of the connotations of the word mob, uh, a few people in the community, Maaret Pyhäjärvi is one of them, um, have been saying, "Hey, why don't we find a different name for this?" Um, and so then a new word that is going around is ensemble because that means kind of together and as a group. And the idea is it's, it's very, very similar to a strong style pairing. So you have somebody who is, who is driving, uh, and another person is navigating, uh, and the person who is driving is not allowed to think they are not allowed to navigate. The difference is: With the ensemble it's not just two people. It can be five or 10. Um, I don't know. I've never tried it in really huge groups apart from, uh, conferences when it's a bit different. Um, but the idea is that all of the people who are relevant to solving a problem, including testers and product owners and the scrum master as well, like doc tech, technical documentation writers, that everybody is involved in working on this thing at the same time. So you have all, you, you have no friction anymore of, "Oh, well, we're going to have to do a handover to that person." "We're going to have to ask this person." There is still friction because of course there always is when we're developing and, but we have everyone that we need there and everyone rotates. So. Uh, a reasonably good way to start is to say maybe about five minutes. So you don't want anyone to be the driver for too long. Um, and you rotate. And the great thing about being the driver, I have, I have done this, is you, you don't need to know anything about how to, because if you have someone who's the driver, um, and they know nothing about working with an IDE, then you say to them, okay, click on line five, type, this, this, and this. And if, of course, if you have someone who is the driver, who is a developer, um, and does that full-time then you might say something like, okay, create the classes that does this, but you don't want to have it too big because then the drivers also going to start thinking. And then of course, when you're part of the ensemble, um, regardless of what role you're in, you can be, even if I don't know how to do something, I can be like, "We need to think about the fact that this could be null", or "We need to think about the fact that we said that multi selection has to work and I don't see that happening yet". So even without the knowledge of how to do that, I can be talking to people about that we need to do it. And then of course, if you have the tester there or the pro wait a second, I thought we said this. I understood it differently. Wait, wait, wait. If we do it like this, how am I going to test it later? Also doing, for example, TDD as an ensemble. Right. Um, and we have, uh, we have qualities dojos where people practice just that, uh, outside of, outside of the project. So it's safe to fail, um, learning about test-driven development, learning about ensemble programming, learning about design, um, Yeah, that's, that's how that works. And it's, it's a cool way of getting new people on board, because it'sa great way of sharing knowledge, because you have to talk about what you're doing. It's not just watching somebody and then, okay, well, that's the black box of stuff I don't understand. And it's also a really good way of working on some gnarly problems because you have everybody who's potentially going to help they're in the room, instead of it just being one person going (whispers) "I have no idea how to solve this" (laughs)

Michaela:[00:38:14] But so as I understand it, it's one thing that you can take out of your toolbox and you say, well, we do this right now for, let's say an hour, or, you know, like today and tomorrow, or is it something that this is how we develop software. And every day when I'm coming in my office in the morning, I'm going not into my office or on my desk, but I'm going in this room. And I have all the other people in there doing that together day in and day out.

Alex: [00:38:37] At Bredex that's something that we definitely have in our toolbox and we, and many projects use it. Uh, at times they say, "you know, we're going to do this once a sprint" or for a specific thing or, or whatever I know of companies who, who do it for hours on end, that is their preferred way of developing. Um, I think that that can take a bit of time to get used to. Um, and I, like I say, I know examples of people who do that very, very, very frequently. Um, I would, I would recommend trying it out. Um, it sounds very counterintuitive and yes, at the beginning it can be a bit like, Um, we've had examples of this, like, "Okay, I could have developed, you know, I could have written the code for this in, in a lot less time." If it's something that's very trivial, trivial, then you can definitely feel the pain. If it's something that's very difficult, you will feel the pain of getting started. But what you're gaining isn't this, this is one of the nice things, right? Um, "TDD and ensemble testing will slow my team down." Well maybe sometimes they need to be slowed down because we need to be thinking of, are we doing this right? Is this what the customer needed? Is this a good way of doing this? Are we making this testable? Those are questions that it's best to ask while we're writing the code and not later on. And so sometimes that slowing down and actually being more explicit about what we're doing can be really, really helpful.

Michaela:[00:39:56] Yeah. I, I see it definitely, as you know, in, in certain instances and certain times and certain questions that'd be, or have to ask, or, you know, certain times in a project, as you say, the beginning of your not even sure what it is exactly that we are developing. I think this is, uh, can be really powerful. Um, maybe what's a little bit connected to that, and I would like to, to know how, how you think about it and maybe how you practice it at, at Bredex is a code reviews. Right? So, um, do you do code reviews? And, um, what I would like to know is, are testers part of code reviews, and if so, why or if not, why not?

Alex: [00:40:34] So, yes, we do code reviews depending on the team. Yeah. That will be, uh, less formalized in the sense of, um, Hey, this was so, I mean, and this is the great thing about context. If you have a team that have been steeply working together on a technology and on a domain for quite a long time, um, I'm not saying that you'll never find problems in the code review. I'm saying that. You might find fewer problems, right? Because everyone's practiced and that's part of a quality strategy that can work and we need to be aware of it. We shouldn't just rely on that. So that in those kinds of teams, we will have more informal, Hey, I did this. It was a bit harder than I thought it was, or I'm having some problems here. Can you come and look at this with me, then you'll have teams that have it. A lot more formalized because it's part of the definition of done. And I recommend that teams at least try having that as part of the definition of done. Um, and then they will have things like pull requests. So even in terms of the technical process until it's been reviewed by someone else, it can't, um, it can't be, it can't be pushed. Um, our test is involved. Yes. Sometimes. Um, I, I have a couple of examples of, uh, Uh, of testers who, um, who really say, okay, I'm going to take the pull request or I'm going to do it with someone else, or I'm going to go and sit next to the developer because I'm currently writing API tests, or I want to be able to write UI tests afterwards for this. Um, and I need to, I want to know how it works. I need to ask questions. I have risks that I'm, you know, looking at the code helps me see, okay, that's a risk I didn't even know about. And here's a risk I had. And at least in terms of how I see this piece of code written, it's probably less likely so I can guide my testing later on so much better. Um, I know that in one of the teams, uh, One of our tests has created like a checklist for code reviews. Um, from the perspective of a test of here are the things that I'm going to be looking at, let's get together right now and make sure that your code does that already. Cause otherwise I'm going to find too much low hanging. Yeah.

Michaela:[00:42:28] Yeah, yeah. That's good. That's a really good thing. Yeah. And so, um, What I would like to know, especially with, you know, with you told me about your, your practices that you have at predates that are quite diverse as well. Uh, depending on, you know, what teams need or what projects need and things like this, how did the pandemic shape that? I, I'm not sure if you're still all in office. I, my assumption is not. Um, and, and. Assembled programming might be a little bit trickier now in this setup. So how did that impact you and what were some of the strategies? I mean, now you're a recent, uh, CEO, right? And there's like this big challenge for everybody, I guess. Like, I mean, it's not, it's not the easiest year to,

Alex: [00:43:09] it really has not been the easiest yet. I have to been very, very glad for the people around me who, uh, uh, who have some of whom have more experience, uh, like, uh, like Andrea's. Uh, and the other, the, the other team leads. And, but yeah, so we were, I'm going to say we were well-prepared and to be fair, we didn't know how well-prepared we were until it hits because we had, we had everything in place that we needed. We have, um, we have a Hungarian, um, or Hungarian company. That's a sub company of breed X. So we've been doing, we've been, I'm going to say we were remote. Ready. Because we'd been working with, uh, people from Hungary in our teams doing things. So we had a lot of the stuff that we need already available outside of our own infrastructure. Um, using things like teams to do pairing or to do code reviews or to even instead of just all sitting together. Um, so we'd always said we're remote ready? Um, that's a little bit like. That's a little bit like saying we have backups, but we've never actually tried to, uh, try to use them. Um, so I think there was an element of look that we manage our preparations were the right ones. Um, and when it's. When the lockdown in Germany started the first time, um, I will. So my timing is fantastic. I was actually struck on a cruise ship in the Caribbean at the time. So I wasn't even, I was still trying to get home yet. That was not fun. Um, so I was, uh, I was not involved in the decisions that were made to that. However, I am proud of us as a company and the people that were doing those decisions within, I think a day and a half, the whole company was in home office and working. Basically without large problems. Um, and from since then we do a lot more. So do we do ensemble programming, uh, and ensemble testing? Um, remotely. Yes. One of my colleagues wrote an article on it recently about how they've do it and you know, what the good practices are for that. Um, we've been doing all of our strategy. Meetings and discussions remotely, because you had to, and that's an interesting and fascinating at how quickly a whole industry can adapt. And even again, customers who had sometimes been like, Oh, we don't really want you to be working remotely. We'd prefer to have, when you have to. You do on it wicks and it's been working and I'm not quite at the stage. I don't think I'll ever get to the stage where I'm glad that this is happening. I am however thankful for some of the things that I am. We have been able to learn from it, like remote working works.

Michaela:[00:45:44] And so. At the beginning, you said, well, I'm practicing the names of people. And so I imagine that it's becoming much more challenging to be connected with like 150 people and feel a connection. And also have not only you, right, as a person that oversees this 150, but that it's mutual, that they also feel like I know

Alex: [00:46:06] Alex and I know our, you know,

Michaela:[00:46:08] one of our CEOs and,

Alex: [00:46:10] um,

Michaela:[00:46:10] how, how do you keep that going?

Alex: [00:46:12] Um, Yeah. I've um, my, so festival for what I've just started doing now, because I'm not going to maybe see them in the, like in the company as much. Um, is that for anyone who's, uh, who's just started, I make sure that we get like a little 15 minutes team session where I can be like, Hey, this is me. And to tell them to start to tell them so that they hopefully notice I try and be okay. I try and be incredibly authentic. Um, I don't come from the same background as other people. I don't communicate in the same way as a lot of other people, I have sometimes different values as other people. Um, and it is important to me to remain that. So I tell people, you know, Hey, you can come and talk to me. I, I'm never gonna bite your head off if you've, if you've made a mistake, I'd rather know I want your feedback. I am. And I try and just be as, as a hundred percent me as I possibly can. Um, so meeting them in that kind of a context helps me maybe to see that, um, I am. I am painfully aware. I have still haven't found out how to do this yet. I think that there were people who knew me before I was a team lead and people I've basically grown up with. Um, and who've been in my team for a very long time. That's I think, and I hope that they're still very like, Oh, this is Alex. We can still talk to her. I'm painfully aware of the fact that there are people who have started in the company since I became a CEO who, for whom I can't force them. I can only, I can only live. I can only be myself and be explicit about what, like, I don't know this I'm going to have to find out or Hey, that was, um, that frustrated me at the customer as well, or, yeah, I'm scared about that possibility too. Like really, really being open and vulnerable about how I see things and how I, how I do things and hoping that they noticed that, or the other people who do know me better know that you can come and talk to me, uh, that they will say, look, you really actually can't. Uh, do that. Um, I have a few other ideas I want to maybe do, like, I dunno, sort of remote coffee with projects. I don't have quite so much contact with just literally inviting myself along and be like, Hey, can I have coffee with you? Um, and let's just chat. Um, because I I'm aware that for some people that may be like, Oh my God, the boss is coming in and looking at us. And I think I still have the character. I think I'm still. Close enough and kind enough that people like, Oh, it's cool. Alex wants to come and talk to us, but you never know. I it's important to me. And, and it's difficult. Those two things are true.

Michaela:[00:48:41] Yeah. Very often they are true

Alex: [00:48:43] for many things like,

Michaela:[00:48:45] well, Alex, I think we actually reached the end of our, um, our time together today. So I was really happy that you have been here with me. Is there something that you think we haven't talked about? The new one too, you know, Let my listeners know something that you want to share with them. Maybe, especially with people that have

Alex: [00:49:02] a non traditional

Michaela:[00:49:04] background that you can give them, you know, some advice that you can give them

Alex: [00:49:07] on their way. I'd say, I'd say believe in yourself and believe that you belong, um, by finding a network of people who are different, like you or different in different ways. Um, you will always have people that you can go and talk to. Yeah, you, you belong here. You, you do. Um, so if that's something that you needed to hear from me, then, then I can tell you that. Yeah,

Michaela:[00:49:32] that's really beautiful. Thank you so much, Alex, and enjoy your day and thank you so much. Okay. Thanks. Bye.

Alex: [00:49:39] Bye.

Michaela:[00:49:41] I hope you enjoyed another episode after sup engineering unlocked podcast. Don't forget to subscribe. And I talk to you again after the Christmas break. End of January.

Alex: [00:49:53] Bye.