speaker-0 (00:07.778)
Welcome back to Adventures in DevOps. I've never heard anyone say we need viewer tests. And that's why we've grabbed almost 20-year veteran in building reliable software, executive consultant, and is currently the CEO and founder at Itacama, where they're guiding businesses to success or forcing them when necessary to adopt the best practices that the industry has already known about for decades. Pia Viedemeyer, welcome to the show.

speaker-1 (00:32.588)
Hi, Warren. Thanks for having me.

speaker-0 (00:34.562)
I think we just have to get this out of the way first. I see almost two modes in every company I've ever interviewed or interacted with. That's the no quality whatsoever, because it's no one's responsibility. Or no quality whatsoever because there's a single person, team, or organization with quality in their name, effectively isolating from the whole system, having quality built into it. How does this even happen?

speaker-1 (00:59.07)
my god. If I if I would know how that happens, dear, I think I'll be a billionaire already. Honestly, I feel there is so much history behind that. Well, I used to work for quite a long time in in so called quality roles. So I had the quality or the testing thing in my in my job title and only just recently got into a company. But I can tell you a bit more on that later where

there was like this, okay, no quality, we don't not we don't need it, but there is no like person or or department responsible for that. I feel like it for me it it's a lot about okay how we used to work in in a waterfall way. When like right, so this one after the other and it seemed to be clear that okay

My as a as a business analyst, for example, my responsibility is to write all the requirements, pixel perfect, a hundred percent, and then I'll hand it over to developers and then they take care of it and they do the developing, writing, coding stuff. And then when they are done and and that used to to be defined by okay, the code is there, but testing is not part of my job. I've experienced that a lot. Not so much anymore these days. That's good.

but then, you know, it got handed over to this, there is the quality person, department, team, whoever, and they will magically, you know, build that quality in or test it in or and I never understood how that should happen. How how this should work. It it just seemed stupid to me from the very beginning.

speaker-0 (02:40.584)
Do you do you think that it's heavily related to the fact that people are trying to well identify what their core responsibilities are in in their job or in the organization that they're in? And for them that means identifying like my job starts here at this point and ends over here. And for the parts that they feel like they understand and have the capability to actually do, they put that within scope. And for everything that they feel not comfortable doing, they try to just find someone else to be responsible for that.

And it may not even be you know, totally conscious. It may just be like, okay, I can do this. I was pr hired as this because my title is, as you said, you know, business analyst or software engineer. And if you're the analyst and you say, Well, okay, that there's software engineers or developers at my company. I don't do the code, I just do this part. And then someone else magically takes over a responsibility for that. I can imagine the same thing happening elsewhere. I don't remember going through my own academic career and being taught how to

make tests or make reliable software. Like that was never a core aspect to what we were building. So I can totally understand where if you get to the professional arena and you get into a job which says you are a software engineer, you still don't think you need to do testing. And especially not if you had a an organization present in your company that says, you know, we are responsible for, you know, QA.

speaker-1 (04:01.204)
Mm-hmm. Yeah. Yeah, absolutely. And I think it's it's very human, right? So it it helps us to have these clear definitions or guardrails like this is your job from here to there. It gives us security. And and as human beings we we like that kind of, but also we we like to have freedom. So I think it it's all in the mix, but I feel it helps people to have this, I don't know.

job role definition and then whatever is written in there helps you to orient yourself in the organization, in the company. It gives you a feeling of belonging to this or that group. Of course, there are always different types of people and characters and people that are more open or or curious to to learn and to, you know, look over the fence and see what what the other roles are doing, what their job is. And then there are other people that

don't feel like that or they they feel good where they are and they like to to work like stay in their garden and be the masters there. And I think both is okay. But what I don't like is just, you know, giving away responsibility for or ownership for a product that we are all together working on. Right. Because like if you work on a software product, I I don't care if you are like

a scrum team or an agile whatever team or if you're organized in in in silos or tradition more traditional ways or any any kind of way I don't care it's like you build that one product together. So it's you all have to take your your the ownership for for that product and so forth quality.

speaker-0 (05:44.59)
No, I I totally I I I absolutely agree. I I think one of the challenges there is on the flip side of the other extreme is you have these giant meetings with 150 people in them where everyone's responsible for getting the product out.

And then those meetings no are also not effective in in some regard because I don't know how you can ever do something useful in a meeting with 150 people in it where it's not like a broadcast meeting or a meeting where you know you're you're going over maybe the the current status of the company or something. Like it's not it's not the level where everyone can participate. So how do you find the sweet spot here between having the individual teams or team members completely isolated and only working on the parts that they think they should be working on and having too many people

present in the meeting. Like how do you know who should actually be there?

speaker-1 (06:30.796)
So first I would always start small, right? because I I totally agree. Like it there is no point of like having like this many people in one room and I would f start with people who are interested in okay, how how do we make sure that our product is the right product and and does what it should and and makes the users happy in the end. I like the word build in quality and I don't care about any framework.

just to say that right in the beginning. But for me really it it's all about building quality into the product from the very beginning until until production and and maintenance and all that stuff. When I used to work in like separate testing teams, I always tried to find some way to go to connect to to the developers, whether this is at the coffee machine and you know, just having a chat and and asking them, okay, what what feature are you working on today? And then

most of the people are super open to just tell you because it's their baby, right? They they built it, they are proud of it. And then you just, you know, you have already your conversation started. And I I was always curious to to see how that works. Like all in the background. I mean I have a very basic knowledge about well like one semester at university or so in coding and nobody wants me to code. But I'm actually able to follow when somebody shows me something, I can follow.

And and yeah, it and I'm always curious about how how they build up things and how all the things connect together with all the you know interfaces and all that stuff. And from my experience, just show interest in the people you work with and just just ask them, Hey, what are you doing? Can you show me? And then you're there, right next to them at your desk. And then for example, you could ask or I ask them, okay, cool. So

How how do you make sure that this won't crash when we, you know, connect it with all the other parts of the of the application or of with the surrounding systems? And then I go, yeah, well, good point. Well, I have my unit test, but actually I did not think too much about integration tests yet. Then I what about this and that? Have you thought about or maybe why?

speaker-1 (08:48.386)
haven't you thought about connecting this or that system? And then you have I never got like stopped in a way that like people didn't tell me like I why are you asking me those things? You will see you will see the the feature when it gets shipped to your QA environment and then you can take a look. Right. So

speaker-0 (09:09.718)
I I'm surprised you never ran into I mean, 'cause you mentioned that engineers may or who it's not necessarily an engineer, but anyone who's built a a product or a project themselves and consider it their their their baby, to go up to them and ask them questions. I I feel like there is this historical challenge of i professionally even

to not crush the f the fragile fragile developer ego that comes with owning a thing and to come up to them and, you know, suggest that maybe part of it is broken or isn't working right. I I'm you must have run into issues like that.

speaker-1 (09:43.418)
yes. Yeah, yeah, yeah. I did. I did. But for me, like the the the the big difference or what made the big difference for me was when I actually proactively approached them in a very positive way, showing them respect for their work. Because I think it's I had a hard job, right? I mean I don't I also I didn't like to, you know, always be the one at the end of the process having to tell other people who put a lot of effort into their work.

To tell them this is not good, this is not working, or this is shitty, or whatever. Of course they they didn't like to hear that. nobody likes to hear that. Yeah, for me, I very soon in my career found out that I want to do it differently, to to find a different approach that works for myself and to connect to the human and not only talk about like this the the technical product and that makes a big difference for me.

And and also for for the people I worked with. Of course, nobody, not everybody was open to my suggestions, no matter which way I tried. but that's okay. But most of them, when I really, you know, I came out of my testing room, I crossed the hallway, I went to the other office, and there I was. And then like, you know, the first time is the tester, right? She made probably she found the park or more than one. Right. And then I was like, So I was like, Hey, how are you doing?

What are you working on? Yeah, but yeah. Most of them opened up and they just thought, okay, she's a human too. Okay, she's interested in what we're doing. And then also I got it back. I really believe in what you send out comes back to you. And when you send out like, you know, positivity and respect to other people, then then this comes back.

speaker-0 (11:29.824)
And so I I feel like it's natural then that you graduated from working with just software engineers and and I I feel like testing is such a dirty word sometimes, validating, you know, what was actually being built and that it was being built correctly, not necessarily just from a technical side, to consulting for for companies and running your own to do executive consulting or helping companies, organizations transition from building software in their current modes to something more.

reliable or sustainable in that way. And I I feel like from what I saw on your on your profiles, they're usually about changing organizational structures. And something that you actually mentioned earlier was that you see less of a challenge now with testing than you had seen historically. And I don't know if you were alluding to something specific that's happened recently for that transition or or something else.

speaker-1 (12:24.46)
Well, let's see if it if it goes into the other direction again now with with our AI helpers. But yeah, so so recently what I mean, I've met more and more people, not only developers, like basically like everybody you have working on a on a software product, all the different roles, whatever they are called. I feel like that more and more people are interested in, you know, the other disciplines and learning a bit more here and there, just to

to be more effective, productive as a team and and to also be able to support each other better.

speaker-0 (13:00.462)
I was gonna say, I want your career experiences because you seem like such the optimist. Like everything's been great, you know, people are working and want to collaborate together. And here I am thinking like

Is my experience unique? You know, am I am I the one? Or maybe I'm the problem where I've seen I remember some of my early jobs. Like if if I met someone in QA, they were they were on some sort of social media for 90% of the time until right after code freeze, where they would review stuff. And then you'd get the most ridiculous questions ever, like

Why doesn't this work according to our testing documents? And I'm like, I don't know what is in your testing documents. Maybe your testing documents are wrong. And so it it's great to see this other perspective that even if organizations aren't set up optimally, that there are there have been companies and engineering orgs that have been able to figure out their way through it and still evaluate and build software correctly.

speaker-1 (13:55.436)
Yeah, but I mean not not everything is is perfect, also in my experience. So I have been working with those teams and those organizations where I felt like I am the problem. Like it's it's like like okay, they don't get it. I have no idea what else to do. And there were points in my career where I decided to leave a project because there was th they didn't get it.

I was like really I was the unicorn and they they gave me the feeling that I'm totally crazy and what I ask or what I want to do is just bullshit. So I said, Okay guys, then if you wanna tell me how quality assurance or or building quality works, I'm the wrong person. Because I wanna make sure that we all together

like a line and make sure we build a cool and and high quality product. Of course. There are those those folks and it's okay. yeah, but I just hate it when okay, now you got me. So I had once a job, I didn't stay for long, where and I and I put it in a how do you call it in English? In the quote in quotes, yeah. So a so called enterprise architect.

I I don't know what what this guy was doing, but definitely not architecture in any sense. And and and that guy I was quite new in in that in that team and I it was as a financial t institution here in Zurich and I've been hired as a test manager. And I took it over from from from a junior colleague and I should, you know, organize, plan all the test management. I've been doing this for quite some time before.

I went there and then this this this whatever architect came into our office and didn't even look at me and and only at my my colleague and and telling like basically talking over my head but talking to me at the same time and telling us how to yeah this listen girls this is how you you should plan the testing and this is how blah blah blah.

speaker-1 (16:07.594)
And and this is how my developers built it because I painted it in PowerPoint and and I stood up and and you know walked in front of my colleagues so that that guy actually had to look at me, which he still didn't do, you know, and somebody just basically looks through you and I went there and I said and I, you know, offered my hand and said, Hi, we don't know each other. I'm Pia and I'm the test manager for this project.

So thanks for all your insights. I see you have a lot of experience here in this company. I appreciate and yeah, I'll think about it. And and he continued with his behavior like he started, and then I thought, okay, come on, seriously? And then I basically mimicked what he was doing, right? So I also said, Okay, yeah, whatever. Yeah. And then just didn't look at him anymore and

You know, I just and then he went off and my colleague was like, you cannot talk to him like this and I'm like, Well, what what the hell does he think he who he is talking to us like that? And by the way, I mean, is he the test manager or yeah, but he's always like, you know, he won he he he always provides a good insights on the architecture and blah blah blah and I thought mm girl, you have a lot to learn.

Yeah, that was weird. That was super weird and there was only one one example in in that company where I really felt, okay, I'm with stupid. It's just it it's I can't.

speaker-0 (17:47.406)
I mean, honestly, I'm so amazed because I don't think I would have ever had the wherewithal to to stand up and shift the conversation like that, especially earlier on in my in my career. that's that's and to I I know how those the th those bank and enterprise architects in in Switzerland are. So that's that's even even another level on top of that.

speaker-1 (18:11.214)
Yeah, but there are there are really great ones. I have to say they are out there and there was and that's and I know that and when I met this guy I was so shocked that I thought, no, no, this no no job title in any anything close to software development should be with this guy.

speaker-0 (18:29.326)
Yeah. So that w that was earlier on. And did that have an impact on how you decide like which clients to actually pick up now for your company?

speaker-1 (18:38.7)
Yes and no. Well I really I really I think the financial industry is an interesting one.

speaker-0 (18:45.301)
No one ever.

speaker-1 (18:46.894)
Sorry? I don't know. It it just happened that I I always ended up from project to project, either in a bank or but in different kinds of you know smaller ones like regional, then more the ones focusing on on private banking and here and there in insurance. I don't know. So but right now I'm I'm super happy or I really enjoy working with smaller companies, with with startups that

are in the scaling phase and then it's the time the point in time where they need to, you know, build up some structures, a bit more organization. So so this is where I'm very good at and and I also feel like it helps my clients the most. So it's it's a win win for everybody.

speaker-0 (19:34.616)
I these these are the companies that they they finally found pro product market fit for some part of the ver spectrum and they now have enough money to start fixing the things that in their organization that have gone so totally wrong. And so what I want to ask is like is there a most common pattern that you see in these scale ups that, especially in Switzerland, that keep falling into, or is everyone sort of like a special snowflake and have their own

special flavor of of problems that you have to come in and like adapt to.

speaker-1 (20:06.678)
Yeah, there are there are patterns and it's not only with the smaller companies. Basically the same also in the very big organizations. I feel like too much too much transformation or change at the same time is not good because the people you you have you have humans in your team, right? Whether it's a small team or it's a big organization, you should not forget to to take them with you. And it's what I see

both in in in startups and in big organizations is that management, whoever that is, they they spend a lot of, you know, time and thinking about okay, where do we wanna go and how do we wanna organize our teams and and our product road but blah blah blah. And then they wanna do it all at once, all at the same time, because now they have already spent so much time in thinking about it. maybe not

sometimes not even so much time. and now they even now they even give it to the AI so they have the result in like five minutes. That's perfect. And so it should also be adapted like in I don't know five days and then the whole organization works perfectly. Which

speaker-0 (21:20.694)
Yeah. I I was gonna say you're being you're being generous to say that they they thought through it. And I guess I guess one one retort would be that they're thinking through it now more than ever with access to LLMs before there was no thinking, before trying to roll out changes, and now they have the benefit of whatever thinking the LLM provides.

speaker-1 (21:41.622)
yeah, coming back to C level or or yeah, management in general thought it through. I feel you always had those folks where they really put a lot of thought into whatever they wanna change. And then you have the other extreme people that are just simply wanna, you know, we try it now, but who said that? Was it was it Zuckerberg? Just like move fast and break things. I feel like you have a lot of those extreme people. And for me

I I'm missing the mix. I like to plan a lot. And then it it's hard for me to do to make the actual step into to try it out in production. Right. So I've been dreaming of having my own business basically for 30 years. And it took me incredibly long to finally do it. That's one extreme. And then there are

colleagues of mine who just let the AI wing something and then just deploy it to production and yeah, we'll test in production, we'll see how it goes. And you know, I I get I get super nervous when her hearing that and I feel like we should be honest with ourselves, no matter on which extreme we are, and just to see that okay, it it's much better in most of the cases when we try to work together with the other extreme.

And I think a lot of us know that person and then just get their opinion and then you would have a nice mix, which I think is a very good which gives you a good point where you can say, Okay, now it's it's safe enough to try. Right? You don't and you cannot it's also what I had to learn. You cannot plan everything. Although I would love to.

speaker-0 (23:24.408)
Do you have any secret tools to help convince the startups, small me or scale ups to actually make the transitions that you think would be beneficial for them? No. I use my divining rod and I throw the the sticks on the ground and they point in the appropriate direction and then all the founders listen to me.

speaker-1 (23:44.332)
Yeah. But yeah, thank thanks for the idea. I love it. I should try that out. Yeah.

speaker-0 (23:50.956)
I think the one the one that definitely works is it has to be their idea. Yep.

speaker-1 (23:54.862)
Yes, absolutely. What helps me is I I also have have an education in systemical coaching, but that's only one part, right? I was alwa always interested in, you know, how how are people like how do you work together with different characters, people from different regions, from different cultures, not having all the same native language. And that helps me a lot in my work.

but also in my private life of course. And this is what I try to also tell my clients. The goal is that they that it it it makes click in their heart and then they see things they haven't seen before. And then what you just said, it's their idea.

speaker-0 (24:39.712)
One of the things that I've seen come up a lot is that it's challenging to find real world research actually done with even a modicum or a small amount of scientific rigor when it comes to anything related to AI productivity. And I think many people are standing on one of the extremes, right? Like they without any any even the single piece of data. One of the extremes like, everything is better. And on the other side, it's the worst thing ever. We'll never use that. But I feel like you must have been able to come by at least some data points from these organizations that

may I I can only imagine our trying to transition to a a different mode of operation with pulling in LMs into some part of the workflow.

speaker-1 (25:17.794)
Yeah, absolutely. Yeah, we currently at one one of my clients which is yeah, it's international startup. It it's not a startup anymore. It's it's a bit bigger now. So they are having currently round something between fifty and sixty employees two, three months ago. they decided to it's how d how did they call it? Like they said, okay, full steam AI development. So all the

not all the engineers, but like a bigger part of the of the engineering team was put on the side to to run an experiment. That's how they called it. basically it this is how we work now. but I will start at the beginning. So it started out as an experiment. first thing was they already it started already with forgetting to involve the QA into this experiment team.

speaker-0 (26:15.438)
Off to a great start. Yeah.

speaker-1 (26:17.922)
Yeah, yeah. also the product owner was also not super included in there. surprise

speaker-0 (26:28.206)
I love this already. You know, you know what? We're gonna do this right. We're not gonna do this wrong. We see all these companies who are just introducing AI and forcing everyone to do it. We're gonna do it differently. We're gonna run an experiment and we're gonna make it make sure we record metrics and that it'll be super successful, and then we can decide whether to roll this out to the whole organization. Our experiment, we don't need testing or product managers involved. We're

speaker-1 (26:49.036)
Yeah. No, we only start with the coding part, right? So you can forget about the rest. No, I just I'm kidding. It was like there we had like those two extremes, right? So the one part of the company which wanted to do exactly what you just said, right? So really a scientifically kind of like experiment, plan it, have everybody involved who should be. And then there was other parts of the company saying, No, we need to move fast because otherwise

our competitors they will be faster and then we're screwed and you know everything will go down in flames. Yeah. And then very quickly the the more organizational folks, more structured folks, they were they went quiet because it

Started and I was super shocked that this happened so fast. And we had those two two sides basically, like the ones that are, yeah, we need to do it with AI, and AI is so super and we'll be so much faster and so much better, blah blah blah. And then the others that are, yeah, but what about, but what about? And then the AI folks, they were like, You are against AI, so you're kind of against us. This is how we felt.

And I was super shocked because I really like every single person in that team. But I was like, What? What is going on here? Are we crazy? Don't we see what's just happening with our team? Because it's like just, you know, pulling us more and more away. And we've worked so hard to to get closer to each other because we are already separated you know, around the world and and in different cultures and all that stuff and now

just because of this AI hype. It's really sad. I would love to tell more positive stuff. But I feel like when we can say so the positive thing is I feel now being in the in the in the third month of this not so experimental experiment right now, people started to realize what happened. Right. Because yes of course we we delivered a lot of code, but

speaker-1 (28:57.174)
Not all of it is what we've expected. So whether it's the structure of the code is not what a senior developer would, you know, how you would build stuff, right? A lot of duplication or like simply spaghetti code, right? I mean it works on the surface, but yeah, if you look behind it then so that's one thing. Then the other thing is like it's super important that you know what you want, right? So this

not including the product owner from the very beginning and not like really trying to to solve all the open questions there were. Just simply assuming that yeah yeah the AI will figure it out and it will work as surprise, surprise. It did not. And what we wanted to deliver in four weeks, we didn't deliver in eight weeks because there were so much gaps to fill and and open questions to discuss and

The AI couldn't help with that. So the product owner had a lot of meetings, had to explain stuff over and over again. Yeah. And then also the QA, right? I mean, she's also forced to to put more effort in into automation, also using AI to help her automate tests. But also she she found out so yeah, it's nice, it delivered good looking API tests, but it just simply like the AI produced tests that simply trusted the wrong API responses.

So they were worth nothing. So it was important that she reviews the output of the air sort of so it's it's a process for the people to sometimes I feel people need to to feel the pain themselves. And then it's like when you tell your children not to put their hands on the you know, on the plate. Yeah, on the stove. Exactly. Yeah. Yeah, you shouldn't do that, you shouldn't do that. It's hot, you're gonna burn your hand and they do it. And then hopefully they learn in the end.

speaker-0 (30:44.472)
So,

speaker-1 (30:53.898)
And you're you are there, ready to write with the ice.

speaker-0 (30:58.306)
Do you think do you think that going back the company would be able to construct an experiment more like I I hate to say correctly? Yeah, let me try that again. Do you think that if the if the company would go back and repeat creating an experiment to see whether or not LLMs would be an effective use, do you think that that would be an a successful experiment this time? Not necessarily that it would turn out that it would be better, but they would be able to derive some learning from it rather than it being a complete mess.

speaker-1 (31:28.556)
I do hope so, but I'm not sure. But it's not it's just because I because I know the mix of the people. Yeah and how they who they right. I think like when you I think it would be better when they do it the same because now also some super enthusiastic folks learn that okay, not everything is gold just because it looks like

speaker-0 (31:52.128)
Yeah. So do you think that a large part of it is the tools that we have available? Like it's not whether or not we can introduce L LMs and see if there's an improvement. It's that the tools themselves make it a struggle to actually even have an experiment. Or do you think it's an organizational problem? The people performing the ex experiment don't have good attention to what their internal processes already are, understand what they're actually changing by switching to L LMs. Is it a

A human focused problem.

speaker-1 (32:22.86)
I feel it's it's more I think it's it's a mix, but for me it's more on the human side. Because when looking back in my career, when I used to work in in the testing area, there was the same thing happening with automation and and all the testers were like so, my god, now I need to learn how to code because otherwise I won't have a job anymore, blah blah blah. And everybody went crazy like chickens without heads running around and also they are

speaker-0 (32:29.446)
interesting.

speaker-1 (32:51.882)
it wasn't the tool that caused the problem or for me it was never the the tool. So now it's also not whether AI tool or or any other tool. It's we as humans we we cannot outsource something to a tool, especially not when it says it's it's intelligent. that that's my my feeling, right? So I think we need to do our homework ourselves. Yes. Whether we like it or not.

And and

speaker-0 (33:23.874)
That's good though, because I I mean it sounds optimistic because if you say that it's not the tool set or chain or companies that are providing products for us that make it difficult for us to experiment, it may be just our lack of expectations or knowledge in a particular area that are are holding us back to effective experimentation with scientific rigor. That means that we can learn and improve. We're in full control of that as an organization and you can rely on third parties to come in and potentially help.

an organization actually run effective experiments. I think that that's for me a little bit of of a positive side here. What I do want to ask is that not everyone's in a leadership position that can help influence directly how the experiments are set up or how the tools are integrated in the organization. So given that you have a unique position where you're often integrating with the leaders of these technical organizations, what can

engineers, more technical people, ICs that are on the ground do to convince, say, their leadership that their current decisions or their processes that they're trying to put in place actually have, say, a negative impact on the business.

speaker-1 (34:32.174)
Personally, and I know it might not be everyone's thing to do, but I would always think why did me did they hire me in the first place? So really focus on that and not let yourself get crazy just because of this ooh, there is this AI thing now and this will take away my job. 'Cause I see that a lot now, across all the roles. and also sometimes I feel it myself.

Yeah, I'm wondering, okay, is this what I'm doing actually can an AI replace me? Should I focus on something else? But then I go back to and and I would recommend it to every everyone, independent of where you are in the hierarchy. Really just if it's too much, take a step back, close the laptop, and remind yourself of everything you bring with you, like all the experience you have, or if it's only your gut feeling, it doesn't matter, right? So everything you bring is a human and

They hired you and they hired you for a reason. And then raise your voice. Whether this this can be it doesn't have to be like loud in front of a big round. It can be, I don't know, maybe your organization has like some anonymous, I don't know, mailbox where you can put feedback in anything. But I would really like to encourage people just say what how you feel about it.

But at the same time stay open for for all the, you know, all the technology innovation that that's coming our way. Because I don't think it we are at the end right now. I don't think AI will go away. So I feel we need to adapt and we need to find our way, every single one of us, to deal with it. Just remember why we are here in this job and and why they hired us and what makes us special.

And then they should they should listen, hopefully they listen to to what we what we have to say. I would recommend it to management that they listen to their people.

speaker-0 (36:32.173)
Yeah.

speaker-0 (36:36.814)
I I feel like you you reminded me of two things. One, it's the just the real challenge of being in any position feeling like you're with you're an imposter in that position. imposter syndrome is the is the aspect. And that you're not capable of or or you shouldn't you're afraid that you'll lose your job if if you do say something, that you don't even have the expertise to be able to stand up and maybe offer critical feedback.

speaker-1 (36:51.843)
Mm.

speaker-0 (37:05.206)
But you know, you remind the other thing you reminded me about, which is linked to that, is even before LLMs completely ruined a lot of organizations, there was this methodology that I really had in my mind that the most effective or long-term members of organizations are the ones who stand up and say something and offer feedback. because chances are they were hired, as you said, for a particular reason that was identified. Like if you made it through the hiring round where you were in a stack of thousands of

resumes in a pile and then after that got through the interview round and actually got hired and have been there for even a couple of months, then as you said, there there's something was recognized. But if you keep your mouth shut in you are completely no different than everyone else in the organization. There's nothing that that stands you out. So if something were to happen, you are not unique. You offer no extra value. Whereas if you are someone who stands up and complains, complains l loud enough, but not too loud.

then you are at least recognizable as someone that may be offering value in some way. And I I do I do understand that may be also what gets you fired at the end of the day, because there are definitely those engineers, I've I've been that one in the past that that open their mouth too wide, it there is this unique aspect where you are providing a lot of value in doing this that not anyone else is potentially doing. And if LMs do replace all software engineering and and testing and product

development lifecycle, et cetera, and support, feedback, et cetera, then the only thing left that you can offer value is by your own opinions. so it it's even better to refine the mechanism in which you communicate.

speaker-1 (38:47.51)
Yeah, absolutely. Nothing to add here.

speaker-0 (38:50.926)
So one one thing I I do want to get your perspective on, especially coming historically from the I hate to say QA. I feel like it's it's just such a demeaning label that's added just from historically in and organizational structures. People who end up taking up that those titles are heavily under evaluated for the experience and abilities that they really have. So that being said, I I I do like the the label more of a tester. And when I think about testing

which is obviously different than being a tester. a lot of people are are now standing up and saying, yeah, software development, that was never our bottleneck. Well, I guess if I take a a step back, LLMs are helping us write so much code. Software development was always our bottleneck. Now that's eliminated. And then we get lots of articles online saying software development is is was our bottleneck and that's completely over, and now we can move on to other things.

And then we get articles retorting those articles saying, no, software development was never our bottleneck. Now we have to focus on the business and doing other things. The bottleneck is really pull requests. And I'm just like, LOL. Like pull requests are are not the bottom are sure, they're a bottleneck, but they're not the real bottleneck. And I feel like we'll very quickly have companies standing up and saying, yeah, we automate pull request reviews. And then we'll get articles saying, pull request reviews were always our bottleneck. And they were that, you know, now they're resolved. And

Then there's gonna be the r the response article saying, pull requests for never a bottleneck. It was fill in the blank. What's what's the trajectory here?

speaker-1 (40:18.07)
I've seen now now I'm I'm with one client helping them out in in the product in the product team. So I'm actually now the bottleneck with defining requirements that that are that first that makes sense, right? So so scope out a feature, like traditional business analysis requirements, work requirements engineering work.

And I tried to do it with AI and I was not happy at all. So yeah. So currently me and my other colleague in Adroll, we are kind of a bottleneck. But that's okay for us. Because we've you know, we we showed the the AI fans why we are not giving everything to the AI. So what comes out, right? 'Cause when we start already at the beginning to give

undefined work in there, it only gets worse and worse. And at the end, like our poor tester, she will have no idea what to automate, or what let her AI agent automate because it's just, you know, it's basically in German we have this we have this this game, when children play it's called Stille Post. So it's a silent male when you know one they all the children stand in a line and one the first one starts to say something very

you know, silent into the ear of the other one and then, you know, they just take the whole message to the end and at the end it comes out something completely different. And this is what I feel like happens when we scream like this, now, now you are the bottleneck, you need to be faster, just throw it into the AI and then like, yeah, okay, now the AI does it. For me, I'm not the bottleneck anymore. Super. But then someone else is and then in the end we end up with something not useful, not wanted.

speaker-0 (42:06.69)
Th you know what I think it's a much better name than the English version of the game, which is just called telephone. I know, isn't it lame? Yeah. yeah, so it's it's a telephone game, having having lots of middle people in in between where you're passing off messages and at the end of the day you get something

speaker-1 (42:11.576)
Yes, telephone? Yeah. Yeah. Yeah, I sorry.

speaker-0 (42:28.984)
completely different. I mean, usually more than a couple of words. So it you get some enjoyment out of what what ends up with what you started with versus at the end. It's interesting to bring LMs into that mix though and already start to see that it's compounding the confusion or complexity of of the messages that get passed around the organization and to see it in the light of still the problem of throwing the work over the wall to someone else. It's

Yeah. I I mean, if you're evaluating people's success or their careers or even assign them the label or the title to do a particular thing and they can offload all of that work to an LLM or 90% of it, then they're just encouraged to have it go through this sort of extra mutation or transformation layer that doesn't understand the original intent, that it has no like there's no reasoning or thinking process behind it. And then taking that and passing it off. I if you look at it from that perspective, it seems obvious.

that it can't end well.

speaker-1 (43:28.0)
Absolutely. Yeah. So I I really do hope that that we'll learn that. Like all of us as a society will learn that sooner than later. But there are days where I'm more worried and there are other days where I'm more positive.

speaker-0 (43:44.766)
well then that's a good point, I think, for us to switch over to picks. So, Pia, what have you brought for us today?

speaker-1 (43:51.146)
I brought one of my favorite books. it's The Culture Map by Erin Meyer. And it's all about how you deal with it's focused on the business area, but how you work internationally, you know, with people from different cultures, countries, backgrounds, and it's super super interesting. Shed a lot of light assumptions I've had about different areas or countries around the world.

It was really eye opening. Yeah, I love it how she how she describes the the differences between cultures and and she, you know, every everything is described by at least one concrete example from her own experience. So I really love that. So it's not like it's not super scientific written. It's just something you can easy read. Yeah, it's really cool. And it helped me a lot to work with my international clients now. Yeah.

speaker-0 (44:50.392)
Was there any like one particular insight that you liked above all the other ones?

speaker-1 (44:56.032)
then it's all about perspective. So for example, people outside of Germany, Austria, Switzerland, they always feel like, okay, those those German speaking countries, all the people there, they are always super on time, for example. And and now like as I am I'm Austrian, but I live in Switzerland for more than thirteen years now. And

I know the Swiss version of being on time and I know the Austrian version. And that's are completely different thing, like totally different. And it drives me crazy working with Austrians because I so adapted the the Swiss timing and and there like it it's huge. so it's always about perspective.

speaker-0 (45:42.862)
Yeah, the the being on time thing is and obviously if you extend that to other cultures around the world, it's I think in the book Aaron uses the term whether or not time is fixed or flexible. Yes. And you could definitely see some cultures are way more flexible on when they like if you say I always found this really interesting. In in German there isn't a great way to say

Like we'll meet at a particular time, but with the assumption that it's a flexible time, it's if you like if you say you're gonna meet at twelve o'clock, like you are meeting, you are meeting at twelve o'clock. Like there is no there is no other time. But in other in other cultures, that's definitely like, well, twelve could be one thir one thirty or something, like you know, stuff can happen at that point. Yeah, I I like that one. The one that actually got me in the book that I I really liked was that a better understanding of this concept of co like high context versus low context.

Where in especially like Eastern Asian cultures, when you say something, there's like a lot of different implied meanings with whatever that that statement is that you're saying. And so if I say, like your hair looks nice today, that that may mean so many different things on so many levels. Like, does that mean that like yesterday and the day before your hair was terrible and and today you finally decided to fix it? And there's like a lot of different levels to that.

Whereas in I feel like a a lot in Western cultures, things are very like to the point. They're low context. If you say something, don't try to interpret it more than what's there. There really was no extra thought put behind it. And I feel like that was a huge learning for me, especially around how different languages or cultures are constructed and whether or not you should read into something that someone is saying. Talking to someone from Asia, feel free to read into it. And so, like now, I have to be extra careful when I say things.

how it may be taken by different people. Yeah.

speaker-1 (47:33.666)
Yeah, absolutely. And that reminds me of yeah, one more thing. I was surprised. I didn't expect that. Like when you, for example, as European or l myself, when I give feedback in in a round, that's that's normal for me, right? And also with the clients like from Austria, that's totally fine no matter which level in the hierarchy they are. But it's completely weird when we have colleagues from the US in the call. So they

They fa they would never do that because it's like together we stand divided we fall. This you know, this way of thinking in in the US culture I wasn't aware of because I I experienced Americans from the US always is very like straightforward, like to the point, saying what they wanna say. But yeah, now I I understand more why in certain situations they don't speak up.

Although I know they also don't agree with something, but they would not like say something against the boss in front of all the others.

speaker-0 (48:41.088)
I I think the the most common known scenario of professional workplace engagement for Americans is the feedback sandwich where you say something very nice and then you give the actual feedback and then you say, no, it's actually okay, it's not that bad. And you're supposed to you're supposed to understand that it was a really negative feedback. Things aren't going very well. But and and pull and pull that important piece out. I've always hated that. But on the other side, you know, I I I get it. So

there's also there's also this huge aspect of if you engage with people from other cultures who work in international companies, they tend to have been more exposed to other cultures and so may have picked up on some of those things more than those that if you're working like you're consulting or contracting for a a foreign comp company where that company only has employees from that local country, have only ever worked locally, then they definitely embody a lot of those. And I don't want to call them stereotypes, but they're

in a particular part of each of those spectrums in the book. So I love the pick, Pia. I the culture map is great. I still bring it up as a recommendation for people. It it's you know, even if you don't work across cultures, just even in a single company, when you're working with colleagues, they could be have their own values that differ from yours and how you understand things. And it may not be because they're, you know, maybe they're have heritage from a different place or

who they've engaged with or just personally. And I I found there's a lot of insight in that book that I think is very good.

speaker-1 (50:11.328)
Awesome, happy you liked it. So what did you bring? Did you bring something?

speaker-0 (50:15.864)
Yeah, no, I I I have I have to have a pick every single week. And so that's a lot of that's a lot of picks. My pick is well, first is a question. this one's hype a rhetorical. am I a little less human than the rest of us? And well, I've definitely been accused of being so before, but there's a really great episode of it's called The Rest is Science. it's a YouTube series where they talk about if logic is built into human tendency or not.

Is it something that we learn or something that we have and we express? And the the actual episode is called the the reasoning test. Psychologists still can't explain. And it it they talk a lot a little bit of what's called the Wasson selection task. And what it does is it goes into how, depending on the context, if it resembles something that we have grown up with or cultural standards or norms, we're very it's much easier for us to answer.

Or have intuition about that. But if the topic is very mathematical, or is based in logic only, then our reasoning doesn't kick in as fast. And that's interesting. If it's a cultural bias, reasoning very quickly. And I'm gonna have some further picks in the future, but for this one in particular, P I have a question for you. Are you a fan of proof by contradiction? You can say I don't know what that is. Yeah. Yeah. so this is

speaker-1 (51:38.968)
Contradiction.

speaker-1 (51:43.406)
Yeah.

speaker-0 (51:44.98)
Yeah, so proof by contradiction is this strategy for deter to countering arguments where you show that there's a flaw in the argument that's being made by showing the outcome of that argument directly contradicts one of the original premises. Without going into a mathematical proof, it could be that someone just says, you know, we should work on feature A because we need it for customer A, because they have some requirements, A. But when you look into it and you ask questions about that,

you find out that what the customer actually needs is the opposite of A. And you say, wait, this customer says I don't want A. And then you bring this as evidence to why we shouldn't do this feature. They want this thing and it directly contradicts this other thing. Well, it for me, this is so obvious. I had I learned about proof by contradiction and I fell in love with it. It just seems so like such a natural thing to use in a conversation or an argument.

but it only occurs to me recently that this is a learned behavior, a learned i idea or concept. It's not something that we're born with. Understanding that things contradict each other is a logical paradigm that's natural, but not something that we have a basic tendency for. And what's really interesting to me is that it may actually be incompatible with anyone that doesn't have a logical or technical background. The the concept of that we can have a discussion and we can lay out axiom or premises.

and come to a conclusion based off of that and then show how our conclusion is flawed based off of new data. That isn't something that everyone actually is born with or fundamentally understands.

speaker-1 (53:20.568)
Yeah, I agree. I had to learn that one. And I learned it actually from a good friend who's yeah, who used to work in software engineering.

speaker-0 (53:29.934)
This seems like a a a long and interesting stor a story. but for the maybe that's a another topic for another day. so it's the series is called The Rest is Science and it has Michael Stevens of V Sauce Fame, the U influencer, and Hannah Fry, the PhD mathematician out of I believe England. they're they're really great. They're very technical and they really dive into each of the topics. So

I think it's very interesting and it's definitely giving me a new insight into when I engage with conversations with other people. If I'm trying to argue against them, I also need to make sure that we understand how disagreements work.

speaker-1 (54:10.914)
Absolutely. I love it. Thank you. I'll definitely check it out.

speaker-0 (54:14.554)
okay, so with that I wanna say thank you, Pia so much for joining us this week. and thanks for all the listeners for for tuning in and I hope to see everyone back again next.

speaker-1 (54:19.544)
Thank you so much for having me.