Chris and Jessy discuss the idea that Scrum incentivises software development teams to under perform.

Most people in tech don’t work

I've been employed in tech for years, but I've Almost Never Worked is the title of an article that a colleague sent to me. And I'm going to read a little bit from that article. So, reading from the article, after being employed in the tech sector for years, I have come to the conclusion that most people in tech don't work. Look, I don't mean that we don't work hard. I mean we almost don't work at all. And when we do get to do some work, it often brings low added value to the company and its customers. All of this while being paid an amount of money that some people wouldn't even dream of. What is happening right now in tech may be one of the greatest market inefficiencies or even deceptions in history. I know my statement may sound a bit hyperbolic. How could people be constantly paid a lot to do close to nothing? Surely that can't be right. Well, let me share some examples from my own experience. Five months ago, I was hired as a software developer by one of the world's most prestigious investment banks. Since the beginning of my employment, I've worked for around 3 hours in total, not counting non focused Zoom meetings, which I attended without paying much attention. When I first joined the company, I was excited. However, since I joined, they've only given me tasks that were exceedingly easy to complete in just a few minutes, but allocating days or even weeks to them. At first, I wanted to speed things along. I genuinely wanted to build a cool product. So I connected with people across the organization to ask questions about our intended users, their needs, and how our product would satisfy them. But it was soon made clear to me a few times that I shouldn't do that. One person told me, I don't want to tell you not to ask too many questions, but and she basically told me not to ask too many questions. I soon realized that the project was overstaffed and most people were pretending to work. And I also realized that was the job I was hired to do. My job was to pretend. If this had been the only time this ever happened to me, I would consider it an anomaly. Unfortunately, this has been the case with almost every tech job I've had in years. Consider the case of my previous tech job in which I was hired as a data engineer for one of the world's largest telecommunications companies. In the year and a half that I worked for them, there was only one two week period during which I worked at full capacity. Other than that, I did almost nothing at all for 18 months. Outside those two productive weeks, most of my work involved attending irrelevant meetings, performing small tasks to pretend that a broken product worked well, and even generate fake results. It felt ethically compromising, and it was boring. I only worked half an hour, a week or so. Non focused meetings aside, this isn't just me. All of the people I know who work in tech seem to be going through the same thing. One of my former colleagues, for example, told me all he does at work is watch coursera courses. He's considering resigning after the company sponsored coursera subscription ends. Another former colleague was hired a year ago as a data scientist for a large oil company. All she does is prepare a PowerPoint presentation every week and she's utterly bored. Another one of my friends was hired two years ago as a quant for one of the world's most important investment banks. The interview process for that kind of job is among the hardest you can imagine. Brain teasers, differential equations, graph algorithms. He was very excited at first, thinking he'd be building cutting edge technology. However, while people always seem to appear busy from the outside, in reality he does almost nothing and is horribly bored but well paid. It's hard to speak with others about this. For a lot of people, the idea of being paid a lot to do nothing sounds like a dream come true. However, while we may not do almost any real work, we do have to constantly pretend that we do. That can be extremely frustrating and soul draining. And that was taken from an article written only last year by a software developer. Jesse, what do you make of that? Yeah, it's first reaction can't be surprised. I can't say I've gone through years like that, but I've definitely had work where if I hadn't generated my own work I could have been doing that. Yeah, that's kind of the status quo. These organizations and talking about the big ones here, everything just takes so long. So if you have simple tasks you can just say it's going to take you a long time and they won't even question it. So if you want to make it easy for yourself then that's so doable. So that makes stories like these very unsurprising. Yeah well you touch already on an interesting point as to whether software developers are taking advantage of the inefficiencies of large organizations. I suspect that's not the primary problem but we'll come back to that I think. Let's read on to see what else the author has to say. Back to the article business people love predictability. They like to estimate in advance how much a project would cost and how long it would take. This can be surprisingly difficult in some disciplines. Even when building a physical thing like a railway, projects often overrun significantly. Imagine how much worse the situation gets with intangible products like software, where it's hard to define exactly what it takes to deliver the product and even what the product is. So in the early two thousand s a philosophy called Agile, which sought to improve software development as a process, became really popular in tech. In Agile, software is developed in very short cycles, as short as two weeks, and the result is validated and goals realigned between cycles. Every couple of weeks the team gathers to plan the tasks for the next cycle. But in this planning phase, something really strange happens. It has become the standard practice to highly exaggerate the efforts required to perform a task which we'll call Task Bloating. In the planning session, hands on people, managers and other stakeholders all agree that each task takes an abnormally high number of hours to complete and requires an abnormally high number of employees. Let me share a couple of examples so you can see the extent of the problem. One of my recent tasks at the investment bank was to analyze what a couple of software code templates provided by Microsoft could be used for. Anyone familiar with software development would be able to do this in a couple of hours at most. However, in our planning session it was collectively considered that this task required many days of work and two people. The difficulty of tasks is chosen by vote in this company and in this case, the collective wisdom decided that the task was relatively hard. I voted that it was easy, which didn't match the majority vote. When they inquired about this, I conceded that maybe it was more difficult than I thought. After all, it is hard to disagree in those situations because it seems you're going against the collective wisdom of the team. Also, when you notice that every single task is bloated this way and no one says anything, you don't want to challenge the system. As two of us were assigned to this task, we ended up splitting it into two even easier parts, one for each. I completed my part in a few minutes and pretended it took much longer. In the following cycle, I was assigned the task of writing a paragraph summarizing the results of the previous task. I voted for a difficulty score of one, the lowest possible, as it was a ten minute task. However, my colleagues didn't agree. They voted that my task was harder than it looked and worthy of several days of work. While the mechanism of estimating tasks in this way will sound familiar to most, I think, but this tendency to overestimate, or task Bloat, as he called it have you ever seen that, Jesse? Every refinement, yeah. I've never been convinced of, or perhaps never fully understood the rationale behind story points or this obfuscation of time. I mean, we're trying to estimate that's the purpose somebody has said it's important to get estimates and story points make it more obscure. It kind of reminds me like when you're at a festival and you buy, like these tickets rather than money and then you go out spending these tickets but you kind of lost the value of what you're actually spending. It kind of feels like that in a way. I know what you mean. It's an abstraction. Yeah. And that's the thing, you're spending an abstraction now, so nobody really knows what that means. And then three story points, it can be a day or two days or three days. Anyway, story points are just a detail. There's a real underlying issue here which I think is best described in this next part of the article. So reading from the article again, work must be divided into clearly defined cycles, usually called sprints. And we must try to predict the difficulty of tasks to make sure they fit within a sprint. The structure encourages. Task Bloating. Employees want to deliver on the promises they make for the sprint, so they end up bloating the tasks to be sure to complete them. Productivity is sacrificed in the name of predictability, I take it that's recognizable. If you want us to be predictable no matter what, then I'm going to make really sure that the work I do will actually fit within this period. But that's not your benefit in terms of what you'll get. We should be aware that that's the choice we're making. Yeah, I was just going to say as long as you're honest about it, then it's fine. If you want predictability, that's okay. But that's just an expensive thing to ask for in terms of you pay productivity to gain predictability. Yeah. Another way of looking at this is that if you observe that your development team consistently hits sprint deadlines, sprint goals, consistently delivers everything that they say they're going to deliver, then you can almost be guaranteed that they are, I'm not going to say unproductive. It's still possible that they produce a good amount of work, but at any rate, they are less productive than they could be. Exactly. All right, perhaps we've somewhat established that this business of estimating tasks and then fitting them into a two or three week sprint cycle doesn't always yield the desired effects and perhaps even has some unintended side effects. But why are we doing this anyway? What's the purpose of it? Yeah, well, it's as the article said, business people love predictability. Now, they don't just love predictability for the sake of it. Everyone loves predictability. We can plan then. What if we've got some real world event that cannot be changed for whatever reason? Well, then we have a deadline that matters. So if you find yourself responsible for a significantly sized software project and your commitment is to deliver that project on time to a specific deadline, well, apart from being in an uncomfortable position and a challenging position, your focus is not going to be on the process. While you will need a process, even the most capable and willing team will fail if operating in complete chaos. But the process is not the thing that you're going to be relying on to deliver on time. That's really going to hinge on your ability as a leader and building a narrative around this mission that you're on. The challenge will be to get buy in from everyone working on the project and that means their full commitment. Your deadline needs to be their deadline. But how would you do that in a situation where somebody has a company and just wants his product to go out as soon as possible or whatever but there's no actually real world event, he just wants to have it done quickly. Well, this is the case where you want productivity, right? So it's again not about throwing away all process but the part that doesn't help us in terms of productivity is where we go and estimate little tasks and try and fit them into a two or three week period. We've already established that that won't help productivity so we can eliminate that aspect of things. And to be clear, it really is the combination of estimating and then fitting it into a two or three week period. I don't really see a problem with having a bunch of tasks, estimating them and then making decisions based on those estimates. Plenty of useful things can come from doing that like let's deprioritize this because it's going to take too long or we can't estimate this at all because there's just too many unknowns. Those are useful things and that exercise can be completely separate from anything else. Similarly, this idea of coming together every three weeks for feedback and updates and checking the direction, that's a good thing, there's no reason to throw that away. In fact you'd be encouraged to do that. But the idea of combining these two things, as we've said, doesn't yield the results you would expect. It's almost as though the process is now leading and we've forgotten what our objectives are and the fact that we have people involved in this process who are going to respond to incentives that you put out there. Yeah, but that's what makes the original manifesto, agile Manifesto, pretty good. Like there's real nuance in there, it's good to focus on people but we're not saying process is wrong. Correct. But if you need to choose, we're suggesting you let the compass needle of your decision point towards directing the people. Yeah, indeed. And speaking of the nuances of the Agile Manifesto, we should also realize that this way of working that we've been talking about has the added disadvantage of creating a certain unwanted dynamic between the business and the developers. And that's the dynamic where the developers kind of feel like they're being checked up on and the people who have set the tasks feel like they have to check whether the tasks have been done or not. I mean, it makes sense to they've been committed to upfront, it doesn't make sense not to check that. But that's exactly the dynamic that Agile tries to warn against. It's the contract negotiation part of the manifesto and there's just no getting around it. Each sprint is or at least can descend into something like a mini negotiation, a mini contract and that is definitely not the dynamic that you want. I said earlier, in fact, when you've got a project where you need to hit a deadline that the most important thing is to get the commitment of everyone on that project. Well, the same is true even when you don't have a deadline, you still want the commitment of the people. But what happens sometimes with scrum is that the process becomes so mechanical that there is nothing to commit to in an emotional sense. There's nothing to get behind. There's nothing to motivate other than completing tasks on a list. And the worst thing about that is you probably did have a rather motivated and committed team because software developers tend to be that way. They don't like to sit around and be lazy and do nothing. They want to have a challenge. They like solving problems. And it's sometimes the case that the process ends up robbing them of any intrinsic motivation that they had. Okay, I'm going to finish up here by going back to the article and reading what it has to say. In summary, the principles behind agile software development are commendable and much more suitable for the job than old school ideas. So many organizations have strived to be agile. However, they've done so by adopting agile recipes which are a step by step guide supposed to make a team agile. The adoption of a recipe results in a box ticking exercise that makes companies believe they become agile just by strictly abiding by a set of inflexible rules. The effect is the opposite. The most common characteristic I see behind truly productive tech work is that the people involved prioritize building the right product above everything else. They build it in small cycles and validate it, which follows the agile philosophy. But they don't limit themselves to a strict agile recipe. They sometimes borrow some elements of an agile recipe, but only because it helps them build the right product. The title of this article says I've almost never worked when employed in tech. But that doesn't mean I've never worked. In fact, I've worked really hard and been part of some amazingly productive teams which deliver top notch products in record time and clients love them. There's actually more in this article that I think is a good idea to revisit on another time, on another day, Jesse. But for now I think we'll wrap it up. Thanks a lot for coming. Thank, thanks for giving your input. Yes, you're welcome and thank you for listening.

I've been employed in tech for years, but I've Almost Never Worked is the title of an article that a colleague sent to me. And I'm going to read a little bit from that article. So, reading from the article, after being employed in the tech sector for years, I have come to the conclusion that most people in tech don't work. Look, I don't mean that we don't work hard. I mean we almost don't work at all. And when we do get to do some work, it often brings low added value to the company and its customers. All of this while being paid an amount of money that some people wouldn't even dream of. What is happening right now in tech may be one of the greatest market inefficiencies or even deceptions in history. I know my statement may sound a bit hyperbolic. How could people be constantly paid a lot to do close to nothing? Surely that can't be right. Well, let me share some examples from my own experience. Five months ago, I was hired as a software developer by one of the world's most prestigious investment banks. Since the beginning of my employment, I've worked for around 3 hours in total, not counting non focused Zoom meetings, which I attended without paying much attention. When I first joined the company, I was excited. However, since I joined, they've only given me tasks that were exceedingly easy to complete in just a few minutes, but allocating days or even weeks to them. At first, I wanted to speed things along. I genuinely wanted to build a cool product. So I connected with people across the organization to ask questions about our intended users, their needs, and how our product would satisfy them. But it was soon made clear to me a few times that I shouldn't do that. One person told me, I don't want to tell you not to ask too many questions, but and she basically told me not to ask too many questions. I soon realized that the project was overstaffed and most people were pretending to work. And I also realized that was the job I was hired to do. My job was to pretend. If this had been the only time this ever happened to me, I would consider it an anomaly. Unfortunately, this has been the case with almost every tech job I've had in years. Consider the case of my previous tech job in which I was hired as a data engineer for one of the world's largest telecommunications companies. In the year and a half that I worked for them, there was only one two week period during which I worked at full capacity. Other than that, I did almost nothing at all for 18 months. Outside those two productive weeks, most of my work involved attending irrelevant meetings, performing small tasks to pretend that a broken product worked well, and even generate fake results. It felt ethically compromising, and it was boring. I only worked half an hour, a week or so. Non focused meetings aside, this isn't just me. All of the people I know who work in tech seem to be going through the same thing. One of my former colleagues, for example, told me all he does at work is watch coursera courses. He's considering resigning after the company sponsored coursera subscription ends. Another former colleague was hired a year ago as a data scientist for a large oil company. All she does is prepare a PowerPoint presentation every week and she's utterly bored. Another one of my friends was hired two years ago as a quant for one of the world's most important investment banks. The interview process for that kind of job is among the hardest you can imagine. Brain teasers, differential equations, graph algorithms. He was very excited at first, thinking he'd be building cutting edge technology. However, while people always seem to appear busy from the outside, in reality he does almost nothing and is horribly bored but well paid. It's hard to speak with others about this. For a lot of people, the idea of being paid a lot to do nothing sounds like a dream come true. However, while we may not do almost any real work, we do have to constantly pretend that we do. That can be extremely frustrating and soul draining. And that was taken from an article written only last year by a software developer. Jesse, what do you make of that?

Yeah, it's first reaction can't be surprised.

I can't say I've gone through years like that, but I've definitely had work where if I hadn't generated my own work I could have been doing that.

Yeah, that's kind of the status quo. These organizations and talking about the big ones here, everything just takes so long. So if you have simple tasks you can just say it's going to take you a long time and they won't even question it. So if you want to make it easy for yourself then that's so doable. So that makes stories like these very unsurprising.

Yeah well you touch already on an interesting point as to whether software developers are taking advantage of the inefficiencies of large organizations. I suspect that's not the primary problem but we'll come back to that I think. Let's read on to see what else the author has to say. Back to the article business people love predictability. They like to estimate in advance how much a project would cost and how long it would take. This can be surprisingly difficult in some disciplines. Even when building a physical thing like a railway, projects often overrun significantly. Imagine how much worse the situation gets with intangible products like software, where it's hard to define exactly what it takes to deliver the product and even what the product is. So in the early two thousand s a philosophy called Agile, which sought to improve software development as a process, became really popular in tech. In Agile, software is developed in very short cycles, as short as two weeks, and the result is validated and goals realigned between cycles. Every couple of weeks the team gathers to plan the tasks for the next cycle. But in this planning phase, something really strange happens. It has become the standard practice to highly exaggerate the efforts required to perform a task which we'll call Task Bloating. In the planning session, hands on people, managers and other stakeholders all agree that each task takes an abnormally high number of hours to complete and requires an abnormally high number of employees. Let me share a couple of examples so you can see the extent of the problem. One of my recent tasks at the investment bank was to analyze what a couple of software code templates provided by Microsoft could be used for. Anyone familiar with software development would be able to do this in a couple of hours at most. However, in our planning session it was collectively considered that this task required many days of work and two people. The difficulty of tasks is chosen by vote in this company and in this case, the collective wisdom decided that the task was relatively hard. I voted that it was easy, which didn't match the majority vote. When they inquired about this, I conceded that maybe it was more difficult than I thought. After all, it is hard to disagree in those situations because it seems you're going against the collective wisdom of the team. Also, when you notice that every single task is bloated this way and no one says anything, you don't want to challenge the system. As two of us were assigned to this task, we ended up splitting it into two even easier parts, one for each. I completed my part in a few minutes and pretended it took much longer. In the following cycle, I was assigned the task of writing a paragraph summarizing the results of the previous task. I voted for a difficulty score of one, the lowest possible, as it was a ten minute task. However, my colleagues didn't agree. They voted that my task was harder than it looked and worthy of several days of work. While the mechanism of estimating tasks in this way will sound familiar to most, I think, but this tendency to overestimate, or task Bloat, as he called it have you ever seen that, Jesse?

I've never been convinced of, or perhaps never fully understood the rationale behind story points or this obfuscation of time. I mean, we're trying to estimate that's the purpose somebody has said it's important to get estimates and story points make it more obscure.

It kind of reminds me like when you're at a festival and you buy, like these tickets rather than money and then you go out spending these tickets but you kind of lost the value of what you're actually spending. It kind of feels like that in a way.

I know what you mean. It's an abstraction.

Yeah. And that's the thing, you're spending an abstraction now, so nobody really knows what that means. And then three story points, it can be a day or two days or three days.

Anyway, story points are just a detail. There's a real underlying issue here which I think is best described in this next part of the article. So reading from the article again, work must be divided into clearly defined cycles, usually called sprints. And we must try to predict the difficulty of tasks to make sure they fit within a sprint. The structure encourages. Task Bloating. Employees want to deliver on the promises they make for the sprint, so they end up bloating the tasks to be sure to complete them. Productivity is sacrificed in the name of predictability, I take it that's recognizable.

If you want us to be predictable no matter what, then I'm going to make really sure that the work I do will actually fit within this period. But that's not your benefit in terms of what you'll get.

We should be aware that that's the choice we're making.

Yeah, I was just going to say as long as you're honest about it, then it's fine. If you want predictability, that's okay. But that's just an expensive thing to ask for in terms of you pay productivity to gain predictability.

Yeah. Another way of looking at this is that if you observe that your development team consistently hits sprint deadlines, sprint goals, consistently delivers everything that they say they're going to deliver, then you can almost be guaranteed that they are, I'm not going to say unproductive. It's still possible that they produce a good amount of work, but at any rate, they are less productive than they could be.

All right, perhaps we've somewhat established that this business of estimating tasks and then fitting them into a two or three week sprint cycle doesn't always yield the desired effects and perhaps even has some unintended side effects. But why are we doing this anyway? What's the purpose of it? Yeah, well, it's as the article said, business people love predictability. Now, they don't just love predictability for the sake of it. Everyone loves predictability. We can plan then. What if we've got some real world event that cannot be changed for whatever reason? Well, then we have a deadline that matters. So if you find yourself responsible for a significantly sized software project and your commitment is to deliver that project on time to a specific deadline, well, apart from being in an uncomfortable position and a challenging position, your focus is not going to be on the process. While you will need a process, even the most capable and willing team will fail if operating in complete chaos. But the process is not the thing that you're going to be relying on to deliver on time. That's really going to hinge on your ability as a leader and building a narrative around this mission that you're on. The challenge will be to get buy in from everyone working on the project and that means their full commitment. Your deadline needs to be their deadline.

But how would you do that in a situation where somebody has a company and just wants his product to go out as soon as possible or whatever but there's no actually real world event, he just wants to have it done quickly.

Well, this is the case where you want productivity, right? So it's again not about throwing away all process but the part that doesn't help us in terms of productivity is where we go and estimate little tasks and try and fit them into a two or three week period. We've already established that that won't help productivity so we can eliminate that aspect of things. And to be clear, it really is the combination of estimating and then fitting it into a two or three week period. I don't really see a problem with having a bunch of tasks, estimating them and then making decisions based on those estimates. Plenty of useful things can come from doing that like let's deprioritize this because it's going to take too long or we can't estimate this at all because there's just too many unknowns. Those are useful things and that exercise can be completely separate from anything else. Similarly, this idea of coming together every three weeks for feedback and updates and checking the direction, that's a good thing, there's no reason to throw that away. In fact you'd be encouraged to do that. But the idea of combining these two things, as we've said, doesn't yield the results you would expect. It's almost as though the process is now leading and we've forgotten what our objectives are and the fact that we have people involved in this process who are going to respond to incentives that you put out there.

Yeah, but that's what makes the original manifesto, agile Manifesto, pretty good. Like there's real nuance in there, it's good to focus on people but we're not saying process is wrong. Correct. But if you need to choose, we're suggesting you let the compass needle of your decision point towards directing the people.

Yeah, indeed. And speaking of the nuances of the Agile Manifesto, we should also realize that this way of working that we've been talking about has the added disadvantage of creating a certain unwanted dynamic between the business and the developers. And that's the dynamic where the developers kind of feel like they're being checked up on and the people who have set the tasks feel like they have to check whether the tasks have been done or not. I mean, it makes sense to they've been committed to upfront, it doesn't make sense not to check that. But that's exactly the dynamic that Agile tries to warn against. It's the contract negotiation part of the manifesto and there's just no getting around it. Each sprint is or at least can descend into something like a mini negotiation, a mini contract and that is definitely not the dynamic that you want. I said earlier, in fact, when you've got a project where you need to hit a deadline that the most important thing is to get the commitment of everyone on that project. Well, the same is true even when you don't have a deadline, you still want the commitment of the people. But what happens sometimes with scrum is that the process becomes so mechanical that there is nothing to commit to in an emotional sense. There's nothing to get behind. There's nothing to motivate other than completing tasks on a list. And the worst thing about that is you probably did have a rather motivated and committed team because software developers tend to be that way. They don't like to sit around and be lazy and do nothing. They want to have a challenge. They like solving problems. And it's sometimes the case that the process ends up robbing them of any intrinsic motivation that they had. Okay, I'm going to finish up here by going back to the article and reading what it has to say. In summary, the principles behind agile software development are commendable and much more suitable for the job than old school ideas. So many organizations have strived to be agile. However, they've done so by adopting agile recipes which are a step by step guide supposed to make a team agile. The adoption of a recipe results in a box ticking exercise that makes companies believe they become agile just by strictly abiding by a set of inflexible rules. The effect is the opposite. The most common characteristic I see behind truly productive tech work is that the people involved prioritize building the right product above everything else. They build it in small cycles and validate it, which follows the agile philosophy. But they don't limit themselves to a strict agile recipe. They sometimes borrow some elements of an agile recipe, but only because it helps them build the right product. The title of this article says I've almost never worked when employed in tech. But that doesn't mean I've never worked. In fact, I've worked really hard and been part of some amazingly productive teams which deliver top notch products in record time and clients love them. There's actually more in this article that I think is a good idea to revisit on another time, on another day, Jesse. But for now I think we'll wrap it up. Thanks a lot for coming. Thank, thanks for giving your input. Yes, you're welcome and thank you for listening.

Wouter de Vaal has been 'around the block' so to speak. Since starting out with a short stint as a tester, he soon realized that wasn't for him. Throughout the early 2000s he worked at numerous large companies in the Netherlands and, as we know, the big companies is where all the drama is. Some of the stories he shares are quite outrageous. In this episode we cover:

The early 2000s may as well be 100 years ago when it comes to the tech industry. Wouter tells us some stories about what it was like to start a career in IT back then and his encounters at some very traditional companies. The tech has advanced since then, but what about the rest?

Journeyman developer stories from back in the day

Wouter, when you started your career, that was around the time of the.com bubble bursting in 2000. Do you remember much of it or were you even aware of it?Yeah, it didn't really register with me because I didn't really have a context yet how these things work and all that. I was a student and I went to work. I had no idea what I wanted. So the only thing palpable was that when I had my new job, there was actually introduction days. We had three days with a new group of people. They hired a whole house for that. Just some holiday home to stay there for a couple of days and get trained up. We had some improvisation improvisation lessons. That was actually fun. There's this group of people in Amsterdam that's still doing that over there. So one of these people came along just to give us improvisation lessons, which was fun. And we had bike rides outside and all that. And I thought working is nice was downhill from there on.Oh, dear. And then all right, tell us what you were doing at that time and who were you working for?I was working for Logica back then, and the client was Telfort. Anyway, I was a tester, so I had no idea I wanted to do with my career. And so I was put in this little team test factory. Okay, we're just going to test new release stuff from the billing software that they had kind of software that you need to configure, and all these configurations need to be checked. And sometimes there was some SQL and some scripts. Anyway, so I was the guy who needed to test that. That work was also kind of ridiculous because I had no idea how that system worked. So the script came along. Can you test this? I'll need help from a developer from this. So a lot of times testing was just, okay, developer sits, he does his changes. I'll look, he tells me it's okay. I say, yeah, okay, it's okay. So that was my work there. And I had a manager. She was American, and for her I needed to bring a suit because in the beginning, I didn't wear a suit. I just had a blouse and normal trousers and all that. Trousers not too bad. Not shabby. Presentable, presentable. Normal shoes. Anyway, she told me, you need to wear a suit. And I said, Why do I need to wear a suit? And I pointed to a guy who actually wore a tie, and it was like, probably not Mickey Mouse, but really close. And I look better than him. Why should I wear a suit? You need to wear a suit. And then she got replaced by a Dutch guy, and I stopped wearing suits, and that Dutch guy was actually disgruntled with me. So I'm your boss now and you don't wear suits? No, I'm not going to wear suit unless you give me good reason, and he had none. Yeah. And actually, I found out he was writing over hours while he wasn't there, so didn't really have anything on me.That's funny.Yeah. I survived because I had nice colleagues, but I hated the work. At one point, there was an opportunity for me to go into that engineering part, like the people who are actually giving us software. But the account manager from Logic, I was reluctant because I was making them money, but I pushed with my supervisor from Logica, sorry, I need to do this. I cannot do the testing anymore. I'm done. Two more weeks, okay? Two more weeks, I'll survive. And then at one point, I got a call from the account manager. Yeah, we really like you to stay as a tester. I said nah, I really don't want to do that anymore. So he tried to convince me, okay, can you please give me your manager? So I handed the phone to my manager. Was actually two years younger than me.And how old were you?I was 25, so he was 23. So he took the phone, and then he started humming, like, yeah, okay, I'll tell him. And then he dropped down the phone, and he told me, you have to stay anyway. At that point, I called my other boss. I said, no, either you give me that job, or I'm leaving. So in the end, in two weeks, I left for that other job, but I started interviewing for new positions.I remember you telling me that you worked for a number of banks at the start of your career. Do you have any interesting stories about those days?One of an interesting story, small story, is with Fortes, and that's the bank that now doesn't exist anymore, they went bankrupt back in the days. Had some weird moments over there. At one point, it was taken over by the Belgians because it was a Dutch operation. But then the Belgians came along, so the whole thing was hosted in Brussels, and at one point, there was a bug, and from my side, I was mostly working from home. Sometimes I went to the office, but I had all the code on my laptop, so it wasn't really needed. I couldn't just run anything. When I fixed something, I emailed or chatted the lines of code that needed to be fixed by a guy who was working there on something else, but he could compile my shit. So he ran it there and say, yeah, it's working now. Okay, cool.So, you would past the code into chat?Yeah, something like that. Or email. I cannot remember it. But anyway, so we couldn't figure it out back then, so I needed logs, but they didn't want to give that. No. Instead of sending me the logs, they made a meeting. They wanted to analyze the program and see what's going on. We were told to come to Brussels, Brussels north, and then walking to the center where the office was. Really nice old office. So I had my Dutch manager with me from Fortis and then in the room were like in total ten people or something, totally different culture over there. And as I was just a programmer, I didn't sit at the table, I sat in a corner on a stool. Keep your mouth shut. You're kidding. Really? No, that's how it happened. And it was this woman manager in Belgium and she was all over the place and because it looked like the issue was on their side no, this is not our problem, can be. That was her whole thing. She wanted to make sure that it wasn't her problem. But we didn't care whose problem it was, we just wanted to solve it. And I was sure if I would have seen the logs it would have been no problem. But yea security here and it cannot be our fault and whatnot. So that meeting went on for one or 2 hours and then in the end there was kind of a compromise. So I was allowed to walk with her to one of her minions and the minion was able to open the log and show it to me. So we're there and I think one, two minutes, I spotted the problem. There's your issue. If you fix that, it's done. So that whole day with all those managers could have been done. If you just send me the logs I could send it back and there's no problem. Wow, brilliant.After that I remember you telling me that with some banking experience you took another job at a bank, although it wasn't a job that you necessarily wanted to take?I took that job because I had to get a job. It was past 9/11 and there was no work. So I took the first job I could. And the people were fun, I had a lot of fun there. But the job was awful. They needed an integrated because they had all these branches in their system. So every week I needed to integrate all the branches from all the people that were working and then see if it's still built. And that was actually a full day job. That's why they hired me.Just to do merges.Just to do merges. So that was the work. Only merges was really ridiculous. And also I needed to find out stuff. Okay, how does this work? So you start googling looking up online. That was already possible back then, luckily. But my workstation doesn't have internet, so I had to go to the hallway to the internet PC. So most of my time I spent on the internet PC because of course I was also doing other stuff there because the job wasn't really interesting. So yeah, I could sit there and do some stuff if I did that job, the merging, then everybody was pleased. But in the end I think I got some extra work there what was a little bit more satisfying. But the main job, that was just like a symptom of a system that was completely wrong. They moved from mainframe to websphere. Actually they hired a real bunch of real good Java guys and everything was working fine. So they still had these old geezers. IBM websphere was then pretty new project and this guy, he couldn't learn it, he just couldn't, he didn't understand. So in the end, I wasn't speed dial with him, I was this private help desk. Fine by me, because I had nothing else to do. I'll come by, I'll help you, help you click. Luckily when I was back eight years later at the same department and they had that shit together, so they asked how's this guy, is he still working here? Yeah, we kind of solved that problem. So they made a department, it was four guys in total. I think they called it a quality department. And they just dumped guys they couldn't use anymore because they couldn't get fired. So once in a while you see them walking around asking people if they need support with quality. Most people say, no, we got enough quality. And then they just go back to the basement and sit there, probably browsing the internet or whatever. Waiting for pension.Yeah, after that you had even another job at a bank.My third stint as a freelancer was at ING and there was all these financial guys, typical, you get some all fast and smart and snappy and not really IT. And then there was the IT department and there was kind of archetypical IT, couple of boring guys, bunch of nerds. There was a secretary there, he thought she was really, really important. And then you had these three guys actually leading department, which were really old geezers, and they grew into a manager role. And I cannot really remember what they programmed, but there was just the type of guys, nine to five jobs, biking to work, everything steady.Okay, I got it. So it's you and your three programmers, managers, tech guys and then this finance department which are like the business for you. What happened?Yeah, a bunch of things happened there because it was so messy. The financial guy wrote something in Delphi because he thought he could program. So we were analyzing that thing and there's no transactions here. If it crashes, database gets fucked up. So I started querying on the database. Yeah, records were gone. Some money stuff was missing, I think. Yeah, I think you're missing a couple of million here. No big deal. They just shrugged. I think you should fix this. And that guy that programmed it, he wasn't hearing it like, no, this is just working, that kind of guy. So we were writing this stuff. So we were doing that for half five months or something. And the prototype we written could replace that thing. That was already something. So it was helping. And it was supposed to become a big project and the project was being set up with the boss of the financial guys. It was an okay guy, but he was like straight to the point and I want results. Will probably take a couple of years. If you can make it, it will be worth your while, but if you don't do a good job, then you get kicked out or you got sanctioned or whatever. And I was just a programmer, but they listened to us because we were in that department and we're actually delivering stuff and we had some a bit of experience and we saw how this was, but actually we kind of rented out our bosses to that manager, like, you're not going to get that from these three guys. And then those bosses came to us kind of furious in a way, trying to be furious, but didn't come across really strong. If the manager from the finance got angry, then you were really scared, but with the other guys, okay, is this angry?Not convincing.Not really convincing. How could you say that? And don't you trust us? Don't you think you can do the job? No, I don't think you can do that now, to be honest. The colleague of mine said the same thing, but yeah, okay, if you think you can do it, you know what the terms are. So in the end, they declined the offer to do the thing. They could have made a real good career out of it if they would have done the project, but they knew they will fail.Sometime down the line, I guess you ended up going to Phillips, so I want to talk about that because I was also there, although you and I didn't really work together as such. But tell me what you remember of it and tell me what your role was there.My role was let me think. Oh, yeah, solution architect. There were quite a lot of teams over there.Yeah. Wasn't it like eight teams in the end?In the beginning when I was there was three. And then they had an extra team offshore and they bunched it up to eight teams. Incredible.Yeah. And it was especially incredible because this was the first time the entire company had ever done Scrum. I think nobody there had ever seen it before. And so everyone was trying to learn this new thing and they even had an external agency or consultancy come in to try and get this thing started. Right.Yeah. CapGemini had a field day there. They put in a lot of people there just to get this going because there were so many teams and so many work, so much work. And while Scrum as a one team, you can learn that quite easily, but to divide work over eight teams and put it all in one product, that's quite a challenge. And they did a nice job, actually. The people from CapGemini. They were fine, but it was just a shitload of overhead.Was it actual, like, agile coaches and scrum training?Yeah, we had an agile coach and then we had the product owner. Like I said, CapGemini had a field day there. They could experiment, play around, do stuff. Yeah.And remind me of that system that they had for dividing up the work.Yeah, they had this system of buckets. The type of work fit into a type of bucket. You can imagine this part of the website or some technical bucket or whatever, and then the buckets get divided with the teams. And there was a special fuck it bucket.Hahaha yeah.So if there was something we didn't want to do, I just put it on the fuck it bucket.That's funny. Yeah. They definitely always had a good atmosphere there.The atmosphere was good. They made fun. Also the product owner and all that with that bucket. But in the end, we were not productive. Hardly. There was one team, they did that mail grooming thing they delivered because that was just a nice little project. You just build it and go and the rest was just faffing around.Yeah. And that reminds me of how they used to do bug fixing and support. You mentioned that there was a remote team, an offshore team, and you had to transfer everything, all the code you'd written, to that offshore team. And they would do the support and the bug fixing.Yeah. So that support thing, that was just that amazed me. I told them, Why are you doing this? We are creating the bugs. We should solve them. No, this is cheaper. Okay, why is this cheaper? Yeah, these people we don't have to pay him anything. Yeah, but you have an extra transition manager, so there's an actual role being created, a Dutch role, a manager, which are not cheap, just to do that. And if there wasn't that role, it's just, okay, the bug comes to the team, they fix it. Done. And I remember one meeting with this guy because we needed to talk about, okay, how do we transition the information? And it was more about, okay, how do we write it down? And then he came up with this Excel sheet. Are you okay with that? So we had a meeting about it that lasted five minutes or so because fine, it's an Excel sheet. We'll fill it in if you want. All right, so we have 25 minutes left of this meeting. Shall we talk about anything else? No, I'm done. You can sit here all you want.He didn't know you, obviously.I'm going back to work. Jeez. Filling the time. Yeah. Such types that were there. It wasn't brilliant.I also remember that the whole thing didn't really last very long, did it?Well, it ended abruptly as well. It did, yeah, because we had eight teams and it was chucking along. The burn rate must have been massive. And then suddenly the news came. There need to be cuts. So I heard the news. I thought there that now. It's over. It's just stupid. There's so much money to save here and we came to work. No, we're not hurt by that. That's something else. Two, three weeks later meeting announcement. Everybody needs to be there. We're going from eight teams to one. My role was Tech lead back then. I moved myself into that position to have a more higher role, to improve the quality. Didn't really succeed in that, I must say. So there was nothing to tech lead. But they didn't kick me out. I found it strange and I was hanging around there. I just fired myself. Came in one day and went to my manager. Why am I here? I don't know. Shall I give you my laptop and patch? Yeah, that's probably a good idea. Here you go. Bye. And that was it. My unceremonious exit from Phillips.

Wouter, when you started your career, that was around the time of the.com bubble bursting in 2000. Do you remember much of it or were you even aware of it?

Yeah, it didn't really register with me because I didn't really have a context yet how these things work and all that. I was a student and I went to work. I had no idea what I wanted. So the only thing palpable was that when I had my new job, there was actually introduction days. We had three days with a new group of people. They hired a whole house for that. Just some holiday home to stay there for a couple of days and get trained up. We had some improvisation improvisation lessons. That was actually fun. There's this group of people in Amsterdam that's still doing that over there. So one of these people came along just to give us improvisation lessons, which was fun. And we had bike rides outside and all that. And I thought working is nice was downhill from there on.

Oh, dear. And then all right, tell us what you were doing at that time and who were you working for?

I was working for Logica back then, and the client was Telfort. Anyway, I was a tester, so I had no idea I wanted to do with my career. And so I was put in this little team test factory. Okay, we're just going to test new release stuff from the billing software that they had kind of software that you need to configure, and all these configurations need to be checked. And sometimes there was some SQL and some scripts. Anyway, so I was the guy who needed to test that. That work was also kind of ridiculous because I had no idea how that system worked. So the script came along. Can you test this? I'll need help from a developer from this. So a lot of times testing was just, okay, developer sits, he does his changes. I'll look, he tells me it's okay. I say, yeah, okay, it's okay. So that was my work there. And I had a manager. She was American, and for her I needed to bring a suit because in the beginning, I didn't wear a suit. I just had a blouse and normal trousers and all that. Trousers not too bad. Not shabby. Presentable, presentable. Normal shoes. Anyway, she told me, you need to wear a suit. And I said, Why do I need to wear a suit? And I pointed to a guy who actually wore a tie, and it was like, probably not Mickey Mouse, but really close. And I look better than him. Why should I wear a suit? You need to wear a suit. And then she got replaced by a Dutch guy, and I stopped wearing suits, and that Dutch guy was actually disgruntled with me. So I'm your boss now and you don't wear suits? No, I'm not going to wear suit unless you give me good reason, and he had none. Yeah. And actually, I found out he was writing over hours while he wasn't there, so didn't really have anything on me.

Yeah. I survived because I had nice colleagues, but I hated the work. At one point, there was an opportunity for me to go into that engineering part, like the people who are actually giving us software. But the account manager from Logic, I was reluctant because I was making them money, but I pushed with my supervisor from Logica, sorry, I need to do this. I cannot do the testing anymore. I'm done. Two more weeks, okay? Two more weeks, I'll survive. And then at one point, I got a call from the account manager. Yeah, we really like you to stay as a tester. I said nah, I really don't want to do that anymore. So he tried to convince me, okay, can you please give me your manager? So I handed the phone to my manager. Was actually two years younger than me.

I was 25, so he was 23. So he took the phone, and then he started humming, like, yeah, okay, I'll tell him. And then he dropped down the phone, and he told me, you have to stay anyway. At that point, I called my other boss. I said, no, either you give me that job, or I'm leaving. So in the end, in two weeks, I left for that other job, but I started interviewing for new positions.

I remember you telling me that you worked for a number of banks at the start of your career. Do you have any interesting stories about those days?

One of an interesting story, small story, is with Fortes, and that's the bank that now doesn't exist anymore, they went bankrupt back in the days. Had some weird moments over there. At one point, it was taken over by the Belgians because it was a Dutch operation. But then the Belgians came along, so the whole thing was hosted in Brussels, and at one point, there was a bug, and from my side, I was mostly working from home. Sometimes I went to the office, but I had all the code on my laptop, so it wasn't really needed. I couldn't just run anything. When I fixed something, I emailed or chatted the lines of code that needed to be fixed by a guy who was working there on something else, but he could compile my shit. So he ran it there and say, yeah, it's working now. Okay, cool.

Yeah, something like that. Or email. I cannot remember it. But anyway, so we couldn't figure it out back then, so I needed logs, but they didn't want to give that. No. Instead of sending me the logs, they made a meeting. They wanted to analyze the program and see what's going on. We were told to come to Brussels, Brussels north, and then walking to the center where the office was. Really nice old office. So I had my Dutch manager with me from Fortis and then in the room were like in total ten people or something, totally different culture over there. And as I was just a programmer, I didn't sit at the table, I sat in a corner on a stool. Keep your mouth shut. You're kidding. Really? No, that's how it happened. And it was this woman manager in Belgium and she was all over the place and because it looked like the issue was on their side no, this is not our problem, can be. That was her whole thing. She wanted to make sure that it wasn't her problem. But we didn't care whose problem it was, we just wanted to solve it. And I was sure if I would have seen the logs it would have been no problem. But yea security here and it cannot be our fault and whatnot. So that meeting went on for one or 2 hours and then in the end there was kind of a compromise. So I was allowed to walk with her to one of her minions and the minion was able to open the log and show it to me. So we're there and I think one, two minutes, I spotted the problem. There's your issue. If you fix that, it's done. So that whole day with all those managers could have been done. If you just send me the logs I could send it back and there's no problem. Wow, brilliant.

After that I remember you telling me that with some banking experience you took another job at a bank, although it wasn't a job that you necessarily wanted to take?

I took that job because I had to get a job. It was past 9/11 and there was no work. So I took the first job I could. And the people were fun, I had a lot of fun there. But the job was awful. They needed an integrated because they had all these branches in their system. So every week I needed to integrate all the branches from all the people that were working and then see if it's still built. And that was actually a full day job. That's why they hired me.

Just to do merges. So that was the work. Only merges was really ridiculous. And also I needed to find out stuff. Okay, how does this work? So you start googling looking up online. That was already possible back then, luckily. But my workstation doesn't have internet, so I had to go to the hallway to the internet PC. So most of my time I spent on the internet PC because of course I was also doing other stuff there because the job wasn't really interesting. So yeah, I could sit there and do some stuff if I did that job, the merging, then everybody was pleased. But in the end I think I got some extra work there what was a little bit more satisfying. But the main job, that was just like a symptom of a system that was completely wrong. They moved from mainframe to websphere. Actually they hired a real bunch of real good Java guys and everything was working fine. So they still had these old geezers. IBM websphere was then pretty new project and this guy, he couldn't learn it, he just couldn't, he didn't understand. So in the end, I wasn't speed dial with him, I was this private help desk. Fine by me, because I had nothing else to do. I'll come by, I'll help you, help you click. Luckily when I was back eight years later at the same department and they had that shit together, so they asked how's this guy, is he still working here? Yeah, we kind of solved that problem. So they made a department, it was four guys in total. I think they called it a quality department. And they just dumped guys they couldn't use anymore because they couldn't get fired. So once in a while you see them walking around asking people if they need support with quality. Most people say, no, we got enough quality. And then they just go back to the basement and sit there, probably browsing the internet or whatever. Waiting for pension.

Yeah, after that you had even another job at a bank.

My third stint as a freelancer was at ING and there was all these financial guys, typical, you get some all fast and smart and snappy and not really IT. And then there was the IT department and there was kind of archetypical IT, couple of boring guys, bunch of nerds. There was a secretary there, he thought she was really, really important. And then you had these three guys actually leading department, which were really old geezers, and they grew into a manager role. And I cannot really remember what they programmed, but there was just the type of guys, nine to five jobs, biking to work, everything steady.

Okay, I got it. So it's you and your three programmers, managers, tech guys and then this finance department which are like the business for you. What happened?

Yeah, a bunch of things happened there because it was so messy. The financial guy wrote something in Delphi because he thought he could program. So we were analyzing that thing and there's no transactions here. If it crashes, database gets fucked up. So I started querying on the database. Yeah, records were gone. Some money stuff was missing, I think. Yeah, I think you're missing a couple of million here. No big deal. They just shrugged. I think you should fix this. And that guy that programmed it, he wasn't hearing it like, no, this is just working, that kind of guy. So we were writing this stuff. So we were doing that for half five months or something. And the prototype we written could replace that thing. That was already something. So it was helping. And it was supposed to become a big project and the project was being set up with the boss of the financial guys. It was an okay guy, but he was like straight to the point and I want results. Will probably take a couple of years. If you can make it, it will be worth your while, but if you don't do a good job, then you get kicked out or you got sanctioned or whatever. And I was just a programmer, but they listened to us because we were in that department and we're actually delivering stuff and we had some a bit of experience and we saw how this was, but actually we kind of rented out our bosses to that manager, like, you're not going to get that from these three guys. And then those bosses came to us kind of furious in a way, trying to be furious, but didn't come across really strong. If the manager from the finance got angry, then you were really scared, but with the other guys, okay, is this angry?

Not really convincing. How could you say that? And don't you trust us? Don't you think you can do the job? No, I don't think you can do that now, to be honest. The colleague of mine said the same thing, but yeah, okay, if you think you can do it, you know what the terms are. So in the end, they declined the offer to do the thing. They could have made a real good career out of it if they would have done the project, but they knew they will fail.

Sometime down the line, I guess you ended up going to Phillips, so I want to talk about that because I was also there, although you and I didn't really work together as such. But tell me what you remember of it and tell me what your role was there.

My role was let me think. Oh, yeah, solution architect. There were quite a lot of teams over there.

Yeah. Wasn't it like eight teams in the end?

In the beginning when I was there was three. And then they had an extra team offshore and they bunched it up to eight teams. Incredible.

Yeah. And it was especially incredible because this was the first time the entire company had ever done Scrum. I think nobody there had ever seen it before. And so everyone was trying to learn this new thing and they even had an external agency or consultancy come in to try and get this thing started. Right.

Yeah. CapGemini had a field day there. They put in a lot of people there just to get this going because there were so many teams and so many work, so much work. And while Scrum as a one team, you can learn that quite easily, but to divide work over eight teams and put it all in one product, that's quite a challenge. And they did a nice job, actually. The people from CapGemini. They were fine, but it was just a shitload of overhead.

Was it actual, like, agile coaches and scrum training?

Yeah, we had an agile coach and then we had the product owner. Like I said, CapGemini had a field day there. They could experiment, play around, do stuff. Yeah.

And remind me of that system that they had for dividing up the work.

Yeah, they had this system of buckets. The type of work fit into a type of bucket. You can imagine this part of the website or some technical bucket or whatever, and then the buckets get divided with the teams. And there was a special fuck it bucket.

So if there was something we didn't want to do, I just put it on the fuck it bucket.

That's funny. Yeah. They definitely always had a good atmosphere there.

The atmosphere was good. They made fun. Also the product owner and all that with that bucket. But in the end, we were not productive. Hardly. There was one team, they did that mail grooming thing they delivered because that was just a nice little project. You just build it and go and the rest was just faffing around.

Yeah. And that reminds me of how they used to do bug fixing and support. You mentioned that there was a remote team, an offshore team, and you had to transfer everything, all the code you'd written, to that offshore team. And they would do the support and the bug fixing.

Yeah. So that support thing, that was just that amazed me. I told them, Why are you doing this? We are creating the bugs. We should solve them. No, this is cheaper. Okay, why is this cheaper? Yeah, these people we don't have to pay him anything. Yeah, but you have an extra transition manager, so there's an actual role being created, a Dutch role, a manager, which are not cheap, just to do that. And if there wasn't that role, it's just, okay, the bug comes to the team, they fix it. Done. And I remember one meeting with this guy because we needed to talk about, okay, how do we transition the information? And it was more about, okay, how do we write it down? And then he came up with this Excel sheet. Are you okay with that? So we had a meeting about it that lasted five minutes or so because fine, it's an Excel sheet. We'll fill it in if you want. All right, so we have 25 minutes left of this meeting. Shall we talk about anything else? No, I'm done. You can sit here all you want.

I'm going back to work. Jeez. Filling the time. Yeah. Such types that were there. It wasn't brilliant.

I also remember that the whole thing didn't really last very long, did it?

Well, it ended abruptly as well. It did, yeah, because we had eight teams and it was chucking along. The burn rate must have been massive. And then suddenly the news came. There need to be cuts. So I heard the news. I thought there that now. It's over. It's just stupid. There's so much money to save here and we came to work. No, we're not hurt by that. That's something else. Two, three weeks later meeting announcement. Everybody needs to be there. We're going from eight teams to one. My role was Tech lead back then. I moved myself into that position to have a more higher role, to improve the quality. Didn't really succeed in that, I must say. So there was nothing to tech lead. But they didn't kick me out. I found it strange and I was hanging around there. I just fired myself. Came in one day and went to my manager. Why am I here? I don't know. Shall I give you my laptop and patch? Yeah, that's probably a good idea. Here you go. Bye. And that was it. My unceremonious exit from Phillips.

Renske Wijmans-Sterrenburg gives her answers to various questions related to why there are so few women software devs.

Renske gives a down-to-earth assessment about being a woman software developer in a male-dominated industry.

The Software Engineering Gender Gap. What's The Problem?

There's quite a sentiment out there that having women underrepresented in tech is a bad thing. Do you see it as necessarily a negative or is it just a fact of life? No, I don't see it as a negative because I think in general, guys will be more attractive to this this kind of jobs than women and maybe even for majority be more fit for it. But what I do think is that we need to make sure that the women have the same opportunities so that the women that do want to do this job that they can do it. But I think if we would look at population that we always have more men and if you're going to force it any way other, I think it's just going to be problems because a lot of women I think, are not suited for this type of job. Just as well that I'm not suited for a job in a hospital. There are a few companies out there for organizations at least that think that not that it's a problem but they are at least trying to actively get more women into tech. I think that there should be money invested in some point but I don't think they should strive for equality because like I said before, I don't think equality would be ideal. I'm also very opposed to where a lot of women say there should be equal women and men in every education and everywhere in the world. I don't believe in that because I think there are main differences between men and women. The brain works a little bit differently but what I do think we need is that women get the same chances but also get people into the industry in a different way which makes it more appealing to women. I think we need to invest in that. So getting more women is fine but not trying to get certain numbers of women because I don't think that's realistic and also not ideal for the industry or for the women itself. I mean, I know there's not a direct equivalence here, but you wouldn't want to see an initiative to get more men into nursing or education. Is that my mom works in education, and I know she's always saying about we need more guys there as well, but in the same manner as what I'm saying about women in tech. We need more women, I think, but not inequality, because I think that's never going to happen. And it's not realistic and not ideal. We need to make sure that the opportunities are big enough for women and that there's equality in opportunities and in the way we think about it and not literally in the amount of women integrate. Is there anything that you could think of that would need to happen to remove barriers or to increase the participation? Anything that would help you? I think the general way of thinking about it so it's okay to think about there's more guys in tech than there are girls but at least when I was younger, when I said that I want to do something more technical people just looked at me weirdly like what? You're a woman, what are you going to do there? Who friends? Friends. My parents in high school did some testing, like, to see what profession would fit you. Like one of the things was a car technician, which was I felt really interesting, but my father just laughed at me. Of course I didn't go that way, but sort of those types of experiences do. Yeah. They influence you and you think more like tech stuff is not for me. Well, I think if you look at me for growing up, it's always been clear that I've been more interested in tech stuff. So I think that way of thinking and the way of encouraging should be different. And if that's the case, then I think the women that are suited for these type of jobs will eventually get there. I actually read an article about women pilots and they're also underrepresented I think it's something like I don't know if I read 5% or 8% and they were asking what are the reasons why there aren't more female pilots? There could be dozens of reasons but one of them was that the primary relationship that a pilot has is with a piece of machinery and I thought that's probably the same in software, right? It's your computer, that's your main thing. And women are if you read the studies, they're more people focused. Men are more focused on things. I think that's partly true, indeed. I think I've always known that stereotype didn't apply to me because I realized a young girl, I was more attracted than doing boy stuff because I wasn't playing with dolls, I was trying to climb in trees and stuff like that. But then do you think it's necessary to be of I don't want to say a more boyish type, but let's take the stereotypical boy then. Is it necessary to be that way? Otherwise you wouldn't be interested in the industry? No, I don't think so. When I started in It, I did a traineeship and there were quite a lot of women, actually. We were a group of I think nine. I think more than half was female. Not all of them were boys type, but there are certain personality features you kind of need, so the boys types might not be the right way of saying it, but there are certain qualities you need, I think, because you said. This is more maybe it's an industry more suited for mendy. Does it ever go through your mind, then, that I'm not good enough? No. I've always thought I'm good enough to do this. I might even be at some levels be better than some of the guys. The real technical stuff there if I look at my current team there are guys that are better in the pure technical stuff because I also don't have a large background in tech. But there are also parts where I think I am better and that's mostly the more analytical part. So analyzing the problem and also when there's a book really thinking about the problems and solving it what I've always been experienced that I'm better at. And I also think there are other colleges that are more generally seen in women that can actually be very helpful in tech. Like memory. Women tend to remember everything. It's probably something that comes up in a lot of relationships as well. It's not always a good that the. Woman says you forgot something again. But that's something I experience in my team as well. Very often that all the guys, they said I don't know anymore, that's about three weeks ago and then they come to me and then I still remember. That's true. Yeah. Because of course I should mention Jesse's in your team. No, I can vouch for that. It's probably like a misconception in the industry again, that everything we do is highly technical and nerdy. That's just not the case. Most things we do is not very complex. You can just learn it or Google it or find some solution for it. Yeah, it's it's definitely not as technical as the average job listing would suggest, which is expert level knowledge in twelve programming languages and a bunch of other stuff. It's something I'm always complaining about. You look at any programmer job, it's 95% tech and then there's a little bit at the bottom that says you need to be a team player and have a few skills. But I would make that 50 50 at a minimum. And I'd even be tempted to say if your tech skills are just average, that's good enough because we value other things more. It's more the analytical parts and the social skills that are really important and. Have you ever seen that to be lacking in teams that you've been in in the past? Yes, I've had a couple of colleagues who really lack that. I had one senior colleague at my last company and he always tried to explain everything from experience, from tech experience and even that wasn't very good in him. But we got a lot of books there and I always try to approach it analytically. So let's say, okay, this is what happened and it either has to come from that and that and that and he was always saying, no, that can't be it, because that's programmed very well and I think you never know if you guys code, you never know what. Happens to verify everything. Yes. You don't assume things are working perfectly and we always had discussions about it and in the end, quite often I was right. I think it's one of the qualities which if you want to be a woman in tech you need to have a little bit it shouldn't be too passive because otherwise the guys will just run over you so you need to have a little bit of assertiveness. Do you ever find yourself having to become more like that and more than you want to be even? Yeah, I do sometimes but it's mainly in the online meetings where I struggle a lot because I'm the type of person who likes to let people talk and then say something. But online meetings and then it's just. And then you have all the additional drawbacks from online where you can't read facial cues and that sort of stuff. You don't know when somebody is about to stop talking and makes it difficult. And I speak a lot louder. So even if I try to say something and they don't hear me, I think my colleagues noticed as well that if they meet me in real time that I'm a lot more present than when it's online meetings. Because I find it easier to talk than them if it's one of your. Colleagues told me that because you've only just started all of your teams meeting every three weeks just to get a bit more face time. And I think one of them said that was present. Yeah, much more present. Yeah, we talked about that because we did a sort of sort of feedback session and I think all of the guys told me that and it's true. Yeah. My former company did a lot of pair programming or more programming, so we did a lot of with someone else program with someone else and you don't need to have a huge amount of knowledge about the tech with the two of you. You can figure it out. But you do need a lot of social skills, you need to be able to communicate with each other because usually what we do there was one guy typing is actually doing coding, but the other one was telling him what to code. So you need to be able to do that because not a lot of people can tell someone in a good way how to code. One of the colleagues who are working with now sometimes struggles with that as well and he tells me something, but not what I want her to be able to actually type it in. So that's a skill you need as well and that's not easy to get. Yeah, you need the social proficiency to make that work and even the way. You say it, I mean, the way you're communicating those situations really important. Yeah, I don't want to get annoyed when somebody asks me to do I won't do it. I don't want to hear exactly technical what you need to type. It more like save something to the database instead of actually saying what you need to type in because that's way easier. And also think about it more, you. Don'T want somebody to say open your left brackets, then type to B or whatever. It doesn't work no. During the time of Corona, we still pair programmed to a Mob program. But actually it was sometimes better than in person because you could just share your screen and we had a program which we could take over each other screen. So if you want to switch, then someone else was still typing, but it's on the other computer. For instance, when we did Mob, we actually had a tool, Mob Sir, which made a switch every time. So the keyboard was switched between people. So there was always one person typing, one person being the driver, so he was telling what to do and the other guy was like the observer, so correcting. Sometimes telling the driver to say something else because there was something incorrect. And then you switched every 20 minutes. Was that useful to have that structure? Yeah, I really liked it that way. What we did have is that the guy typing is not the guy thinking. And I think it's sometimes hard to combine, especially for men who can't do. Two things at the same time. You can say that I think it's good to move around the keyboard because then you have some time to think about in between as well, because if you're typing all the time, then you're not really thinking that much anymore. Yeah, and the point from earlier still stands like you're not in a purely technical position right now. You're mostly in a social situation. And there's actually another specific thing I want to ask you about if I look at myself and also a lot of the applicants that we've spoken to, a lot of them came into this field because of their love for video games and they wanted to be game developers and all that sort of stuff. Did you ever love for video games or anything like that? I hate video games. You hate it? Yeah. That's the one big difference I noticed between me and a lot of colleagues I had. Almost every one of them loves video games or if I had played them in the past, I have always hated them. I was forced to play them with my brother sometimes, but so no, that's something I really can't my colleagues start talking about video games, I just zone out. No, what are you doing then? Maybe you're childhood, usually I was just playing sports. I was outside active playing sports or watching sports still I do that in my free time. And that's also something I noticed when I switched from sports data to Tech. I mentioned Shinky Connect, it's a Dutch shortwrack skater and there was a guy who had no idea who he was and I was thinking, oh my God, what sort of world did I end up in? No one knows who Sinkiknate is. Yeah, the sports and tech don't mix them. No, I like sports and I barely have a discussion about that. So you're not alone. I don't think that's the male female thing? No. I've experienced a couple of colleagues who like sports as well, but in general. Tech guys just doesn't really mix. The reason I brought it up is because I think there is a decent influx of game developers into this industry, but if, for whatever reason, games just aren't as interesting to women, might contribute to those numbers. Yeah, I think so, too. Indeed, the tradition is to hire from universities where the students have studied science and maths, those kind of hard engineering type degrees, which, again, women don't tend to go into as much. Looking at education, for some parts, I think makes sense, because if people choose their education correctly, it tends to say something about what they're interested in. Because, for instance, when I started looking for studies, I also looked at the more social study, and I went to, like, an open day for that. And within ten minutes I knew, this is nothing for me. And that is because the type of thinking was not for me. And I think the type of thinking you learn how to study is interesting, but I think we should widen the race. So, like, the real social studies, you might not find a lot of people you can place easily in tech, I guess, but there's a lot of stuff in between in the gray area, which I think you can pull a lot of good tech guys from. Well, speaking of younger generations, if there are women thinking about coming into this industry, what would you say? I would definitely recommend it, because if you want to, there's enough possibilities, and I really like my job, so I would go for it. What I would recommend is just if you want to do it, just do it. And don't let anyone tell you you can't do it good enough or anything. If you want to and you think you're good enough, just go for it. Nice. All right. That's a good way to end it, then. Thanks for coming on Renske. Yes, no problem.

There's quite a sentiment out there that having women underrepresented in tech is a bad thing. Do you see it as necessarily a negative or is it just a fact of life?

No, I don't see it as a negative because I think in general, guys will be more attracted to this this kind of jobs than women and maybe even for the majority be more fit for it. But what I do think is that we need to make sure that the women have the same opportunities, so that the women that do want to do this job, that they can do it. But I think if we would look at the population that we always have more men and if you're going to force it any way other, I think it's just going to be problems because a lot of women I think, are not suited for this type of job. Just as well that I'm not suited for a job in a hospital.

There are a few companies out there, or organizations at least, that think, not that it's a problem, but they are at least trying to actively get more women into tech.

I think that there should be money invested in some point but I don't think they should strive for equality because like I said before, I don't think equality would be ideal. I'm also very opposed to where a lot of women say there should be equal women and men in every education and everywhere in the world. I don't believe in that because I think there are main differences between men and women. The brain works a little bit differently but what I do think we need is that women get the same chances but also get people into the industry in a different way which makes it more appealing to women. I think we need to invest in that. So getting more women is fine but not trying to get certain numbers of women because I don't think that's realistic and also not ideal for the industry or for the women itself.

I mean, I know there's not a direct equivalence here, but you wouldn't want to see an initiative to get more men into nursing or education. Is that..-

No, my mom works in education, and I know she's always saying about we need more guys there as well, but in the same manner as what I'm saying about women in tech. We need more women, I think, but not in equality, because I think that's never going to happen. And it's not realistic and not ideal. We need to make sure that the opportunities are big enough for women and that there's equality in opportunities and in the way we think about it and not literally in the amount of women in tech.

Is there anything that you could think of that would need to happen to remove barriers or to increase the participation? Anything that would help you?

I think the general way of thinking about it so it's okay to think about there's more guys in tech than there are girls but at least when I was younger, when I said that I want to do something more technical, people just looked at me weirdly like what? You're a woman, what are you going to do there?

Friends. My parents in high school did some testing, like, to see what profession would fit you. Like one of the things was a car technician, which was I felt really interesting, but my father just laughed at me. Of course I didn't go that way, but sort of those types of experiences do. Yeah. They influence you and you think more like tech stuff is not for me. Well, I think if you look at me for growing up, it's always been clear that I've been more interested in tech stuff. So I think that way of thinking and the way of encouraging should be different. And if that's the case, then I think the women that are suited for these type of jobs will eventually get there.

I actually read an article about women pilots and they're also underrepresented I think it's something like I don't know if I read 5% or 8% and they were asking what are the reasons why there aren't more female pilots? There could be dozens of reasons but one of them was that the primary relationship that a pilot has is with a piece of machinery and I thought that's probably the same in software, right? It's your computer, that's your main thing. And women are if you read the studies, they're more people focused. Men are more focused on things.

I think that's partly true, indeed. I think I've always known that stereotype didn't apply to me because I realized a young girl, I was more attracted than doing boy stuff because I wasn't playing with dolls, I was trying to climb in trees and stuff like that.

But then do you think it's necessary to be of I don't want to say a more boyish type, but let's take the stereotypical boy then. Is it necessary to be that way? Otherwise you wouldn't be interested in the industry?

No, I don't think so. When I started in It, I did a traineeship and there were quite a lot of women, actually. We were a group of I think nine. I think more than half was female. Not all of them were boys type, but there are certain personality features you kind of need, so the boys types might not be the right way of saying it, but there are certain qualities you need, I think, because you said.

This is more maybe it's an industry more suited for mendy. Does it ever go through your mind, then, that I'm not good enough?

No. I've always thought I'm good enough to do this. I might even be at some levels be better than some of the guys. The real technical stuff there if I look at my current team there are guys that are better in the pure technical stuff because I also don't have a large background in tech. But there are also parts where I think I am better and that's mostly the more analytical part. So analyzing the problem and also when there's a book really thinking about the problems and solving it what I've always been experienced that I'm better at. And I also think there are other colleges that are more generally seen in women that can actually be very helpful in tech. Like memory. Women tend to remember everything. It's probably something that comes up in a lot of relationships as well.

Woman says you forgot something again. But that's something I experience in my team as well. Very often that all the guys, they said I don't know anymore, that's about three weeks ago and then they come to me and then I still remember.

Yeah. Because of course I should mention Jesse's in your team.

It's probably like a misconception in the industry again, that everything we do is highly technical and nerdy. That's just not the case.

Most things we do is not very complex. You can just learn it or Google it or find some solution for it.

Yeah, it's it's definitely not as technical as the average job listing would suggest, which is expert level knowledge in twelve programming languages and a bunch of other stuff.

It's something I'm always complaining about. You look at any programmer job, it's 95% tech and then there's a little bit at the bottom that says you need to be a team player and have a few skills. But I would make that 50 50 at a minimum. And I'd even be tempted to say if your tech skills are just average, that's good enough because we value other things more.

It's more the analytical parts and the social skills that are really important and.

Have you ever seen that to be lacking in teams that you've been in in the past?

Yes, I've had a couple of colleagues who really lack that. I had one senior colleague at my last company and he always tried to explain everything from experience, from tech experience and even that wasn't very good in him. But we got a lot of books there and I always try to approach it analytically. So let's say, okay, this is what happened and it either has to come from that and that and that and he was always saying, no, that can't be it, because that's programmed very well and I think you never know if you guys code, you never know what.

Yes. You don't assume things are working perfectly and we always had discussions about it and in the end, quite often I was right. I think it's one of the qualities which if you want to be a woman in tech you need to have a little bit it shouldn't be too passive because otherwise the guys will just run over you so you need to have a little bit of assertiveness.

Do you ever find yourself having to become more like that and more than you want to be even?

Yeah, I do sometimes but it's mainly in the online meetings where I struggle a lot because I'm the type of person who likes to let people talk and then say something. But online meetings and then it's just.

And then you have all the additional drawbacks from online where you can't read facial cues and that sort of stuff. You don't know when somebody is about to stop talking and makes it difficult.

And I speak a lot louder. So even if I try to say something and they don't hear me, I think my colleagues noticed as well that if they meet me in real time that I'm a lot more present than when it's online meetings. Because I find it easier to talk than them if it's one of your.

Colleagues told me that because you've only just started all of your teams meeting every three weeks just to get a bit more face time. And I think one of them said that was present. Yeah, much more present.

Yeah, we talked about that because we did a sort of sort of feedback session and I think all of the guys told me that and it's true. Yeah. My former company did a lot of pair programming or more programming, so we did a lot of with someone else program with someone else and you don't need to have a huge amount of knowledge about the tech with the two of you. You can figure it out. But you do need a lot of social skills, you need to be able to communicate with each other because usually what we do there was one guy typing is actually doing coding, but the other one was telling him what to code. So you need to be able to do that because not a lot of people can tell someone in a good way how to code. One of the colleagues who are working with now sometimes struggles with that as well and he tells me something, but not what I want her to be able to actually type it in. So that's a skill you need as well and that's not easy to get.

Yeah, you need the social proficiency to make that work and even the way.

You say it, I mean, the way you're communicating those situations really important.

Yeah, I don't want to get annoyed when somebody asks me to do I won't do it.

I don't want to hear exactly technical what you need to type. It more like save something to the database instead of actually saying what you need to type in because that's way easier. And also think about it more, you.

Don'T want somebody to say open your left brackets, then type to B or whatever. It doesn't work no.

During the time of Corona, we still pair programmed to a Mob program. But actually it was sometimes better than in person because you could just share your screen and we had a program which we could take over each other screen. So if you want to switch, then someone else was still typing, but it's on the other computer. For instance, when we did Mob, we actually had a tool, Mob Sir, which made a switch every time. So the keyboard was switched between people. So there was always one person typing, one person being the driver, so he was telling what to do and the other guy was like the observer, so correcting. Sometimes telling the driver to say something else because there was something incorrect. And then you switched every 20 minutes.

Yeah, I really liked it that way. What we did have is that the guy typing is not the guy thinking. And I think it's sometimes hard to combine, especially for men who can't do.

You can say that I think it's good to move around the keyboard because then you have some time to think about in between as well, because if you're typing all the time, then you're not really thinking that much anymore.

Yeah, and the point from earlier still stands like you're not in a purely technical position right now. You're mostly in a social situation. And there's actually another specific thing I want to ask you about if I look at myself and also a lot of the applicants that we've spoken to, a lot of them came into this field because of their love for video games and they wanted to be game developers and all that sort of stuff. Did you ever love for video games or anything like that?

Yeah. That's the one big difference I noticed between me and a lot of colleagues I had. Almost every one of them loves video games or if I had played them in the past, I have always hated them. I was forced to play them with my brother sometimes, but so no, that's something I really can't my colleagues start talking about video games, I just zone out.

Maybe you're childhood, usually I was just playing sports. I was outside active playing sports or watching sports still I do that in my free time. And that's also something I noticed when I switched from sports data to Tech. I mentioned Shinky Connect, it's a Dutch shortwrack skater and there was a guy who had no idea who he was and I was thinking, oh my God, what sort of world did I end up in? No one knows who Sinkiknate is.

Yeah, the sports and tech don't mix them. No, I like sports and I barely have a discussion about that. So you're not alone. I don't think that's the male female thing?

No. I've experienced a couple of colleagues who like sports as well, but in general.

The reason I brought it up is because I think there is a decent influx of game developers into this industry, but if, for whatever reason, games just aren't as interesting to women, might contribute to those numbers.

Indeed, the tradition is to hire from universities where the students have studied science and maths, those kind of hard engineering type degrees, which, again, women don't tend to go into as much.

Looking at education, for some parts, I think makes sense, because if people choose their education correctly, it tends to say something about what they're interested in. Because, for instance, when I started looking for studies, I also looked at the more social study, and I went to, like, an open day for that. And within ten minutes I knew, this is nothing for me. And that is because the type of thinking was not for me. And I think the type of thinking you learn how to study is interesting, but I think we should widen the race. So, like, the real social studies, you might not find a lot of people you can place easily in tech, I guess, but there's a lot of stuff in between in the gray area, which I think you can pull a lot of good tech guys from.

Well, speaking of younger generations, if there are women thinking about coming into this industry, what would you say?

I would definitely recommend it, because if you want to, there's enough possibilities, and I really like my job, so I would go for it. What I would recommend is just if you want to do it, just do it. And don't let anyone tell you you can't do it good enough or anything. If you want to and you think you're good enough, just go for it.

Nice. All right. That's a good way to end it, then. Thanks for coming on Renske.

n this episode, Mike Hoogstraten tells us some stories about his time at ASML and how it shaped his understanding of the product owner role.

Mike shares some stories about his early days as a pseudo-product owner, which began while working at ASML, and isn't afraid to admit he made a mistake or two!

Education of a product owner

Was that your first It project? Yeah. Yes, it was, actually

I was actually the customer of the It project. As a tester, I gave a lot of feedback to the design part. In the end, it led to a bit of frustration on my side. I had no clue what I was doing.

The entire design of the project was written in a PowerPoint presentation

Mike: The entire design of the project was written in a PowerPoint presentation. Mike: I truly believe in the power of communication. He says you can only get information across by having a dialogue. Time is the most powerful gift you can give to other people.

The people who are representing the business are not in fact the end customer

The people who are representing the business, they are not in fact the end customer. What I tended to do is talk to the customer, then ignore the proxy, and then build the product. It's always good to go to the end customers directly.

You need to go to the customer when you start a new project

The first obstacle you run into is who are the stakeholders? The only thing I forgot was to actually listen to the customer. It took me all the way until getting to the first production release before I realized. I should have done that much earlier.

Talking to the end customer is a different skill set than developing

Chris: Talking to the end customer is a different skill set than developing. You'd be lucky to have a developer who is good at both and actually likes doing both. The only real skill that I can add to a team is trying to understand the customer.

We were talking to Mark about a project that we did together, and you came onto that project fairly early on. Was that your first It project?

Yeah. Yes, it was, actually. I had no clue what I was doing.

Yeah, I was actually the customer of the It project. So you guys were building the software, and I was testing it on the customer side to see if it was performing as we wanted to. And in that role, as a tester, I gave a lot of feedback to the design part. Like, this is not working as expected. We expect it to work like this and this and this. And I think in the end, it led to a bit of frustration on my side because the feedback that we were giving was not really treated. The product was not changing. It was just they recognized, like, oh, yeah, thank you for your feedback. That's it.

And yeah, I just couldn't grasp why my feedback was not taken into account. And in the end, because the designer at that point decided to change jobs, there was an opening, and I thought, you know what? If nobody's listening to what I'm asking, then I might as well sit there and do it myself. And that's how I actually ended up in there. And I was quite uncertain because I've never done an It project. And it's really easy to complain when you're just testing at the end. But then when you have to think of how it should work, the world becomes a whole lot more complicated. So that's how I rolled into it.

Tell me a bit about how it was for you, your first impressions, and what you discovered when you entered the project.

Well, the funny part is, I think every time you start a project, you always see a lot of good things happening because you're unaware. And I was actually quite impressed because actually stuff was getting done and it looked very complicated. And the reason why it looked complicated was the entire design of the project was written in a PowerPoint presentation, which was, I think, about 220 slides long. That was the design of the project. And I was impressed because I was like, wow, I cannot even generate 220 PowerPoint slides. That takes quite a lot of effort to do that, to be honest. I don't have the discipline to write that amount of text in there. And that, to me, seemed, like, very structured because I think, like, oh, if these guys, I mean, if they have a document like this, they must be knowing what they are doing. So what happened was I didn't want to let go of that document because I was like, this is my rock. I have to hold on to this is the Holy Grill.

There's a lot of work gone into this. I cannot possibly ignore all this work. And it took me quite a while, I think about a lot of discussions with you, Chris. I think after two or three months, my common sense came back to me, like, okay, Mike, we have to go back to the real problem. What are we trying to solve here? Who is our customer? And then start from there. And it was after three, four months, I guess I let go of that presentation and thought, you know what? I have to form my own vision on this. And I'm not sure if I'm allowed to speak for every engineer out there, but reading documents to me is a lot of effort, and I prefer to be lazy. I would rather have someone, as you always say, spoon feed me. This is what I need, this is how I want it. So reading documents is not my strong suit, but since I was very inexperienced, I was afraid not to read the document. So I actually read the document at that time. But since then, I've rarely found a situation where the documentation is so good and so sufficient that you can directly get to a product. But I truly believe in the power of communication. I think you can only get information across by having a dialogue. Someone should explain something to you. You should be able to ask questions, you should be able to answer them, and then you have a good, healthy dialogue, which creates common understanding, and that common understanding leads to a proper product.

I think, in other words, you need to be spoon fed.

I think everyone wants to yeah, everyone wants to be spoon fed. I think I even noticed it with the developers, and I don't even think it's a bad quality. I mean, the developers in our team, I think they also like to be spoon fed in that sense. It sounds very negative. It sounds like we're all babies. But I think the good part about it is that there is a mutual discussion that you're on the same level. You can check if you're on the same page and you just want to know what you need to do. That's what everybody wants.

Well, I always say it as a joke, but what I really mean is you need to take the time to get someone else up to speed. All too often, you see, read that and ask me any questions you might have. And there's no work in that. There's no effort.

Yeah, I completely agree on that. I've read about leadership programs, and the one thing they say is that if you want to help someone or if you want to give them the feeling you're helping them, the only thing you can do is invest. Time is the most powerful gift you can give to other people. And sending someone towards a document is I think that's rarely a road that will lead to a successful end result. So I think to summarize that, because I think the point is quite clear. I think documentation is good. The goal of documentation is mainly to document it for when you're gone. But I think initially, if the person is there, if the person who knows is still available, it's always better to talk to that person.

What else did you discover when you came onto the project?

The people who are representing the business, they are not in fact the end customer. I always see in general that there is a proxy which is installed to represent the customer. And then you realize what it was is I had discussions with them. You form a vision on the road that you want to go to and then in the end, while you're developing and you're testing the software and bringing it to production, you actually get to talk to the real customer. And then you figure out that the proxy has a different vision compared to the customer who's using it. And one of the examples was that the user wanted a lot of flexibility because he had a lot of unforeseen circumstances while working and he wanted the tool to facilitate him. So he said, you know, the tool does not know everything. I know more than the tool, so I want you to be advising me, but I don't want you to be restricting me. But the proxy said no, we assume that we know everything and that the person who is doing the work knows nothing. So we want to restrict maximum what this person is able to do. Now, to me, it took very long to realize this because of course, you're first designing, you're talking to the proxy because that's the person the customer appointed to represent the customer. So you have this whole product there and you end up at the shop floor and then you realize that the guy who has to use it says this is not what I need. And then your world kind of explodes. Like, oh my God, I spent so much time in trying to make this work, and now, apparently, the world has changed completely. And, well, what I realized then is talk to the proxy, but I also immediately talk to the customer themselves, which is kind of a very gray area, because basically it already says that I do not completely trust the proxy, and that's based on my past experiences with the proxy.

How did you know that this product owner couldn't be trusted?

No, I don't think I have a one sense on this. I think this is more trial and error. The first project I had, the proxy did not fully represent the customer and then something flipped inside me like I never trust the proxy. I think I did this at our latest customer as well. We started the project and we had the proxy. And the first thing I think in our first meeting, I said I want to talk to the end users, and they were actually not really open to that idea. I didn't really detect it in our first discussion. I thought it was quite a good discussion. But within two weeks, I actually had the end customer sitting around as well. I think it was about three or four weeks later that proxy came to me and said, yeah, this is actually not usually how we do business. You talk to me. I might make the decisions on this, and then we'll see what we build, and then we go to the customer. I think it's always good to go to the end customer directly, because it's good to understand their working conditions and to understand the problems they're facing. The only thing that I would recommend that I need to improve is take the feelings of the customer back to the proxy and have a discussion about that. What I tended to do is talk to the customer, then ignore the proxy, and then build the product. That's not a good idea. I mean, that's a fast way. I think my drive was to be fast. I wanted to deliver something quickly, but that's not the best way to keep everyone on board.

It's interesting you say that, because it can be a common theme where the person who is owning the product, they are not that aware of what the product should do, and they don't spend time with the people who will use the product.

I think it's a sense of responsibility. The one thing that makes working in our team really nice is the fact that we all feel responsible for delivering the right product at the right time. And if you have that responsibility, you get this natural urge to figure out what's going on.

But there are shortcuts to that which I think people take. And one of the shortcuts can be, and this is what I've seen more often than not, is because it takes work to go and speak to the customer. And it's a lot easier to just sit back and think, they probably want this. Let's just assume that at ASML, you would fly to other countries, literally, and observe these guys operating and using the product.

I remember we asked the project leader at the time, can we have a testing environment which is representative or identical to the customer sites? It wasn't easy to get that done, actually. And we didn't get it because it wasn't deemed necessary, because we couldn't indicate why it was needed. And I remember saying, like, I don't know why it's needed. I just have this feeling that if we don't test it the way we use it, it's going to be a problem somehow. Now, I didn't know I didn't have any good reasons to believe it would fail because all the test software worked. So I flew to Korea, I think it was. So that was a good 14 hours trip to go there. Well, it's 14 hours to get there, you sleep in the hotel, then you wake up early in the morning, you get a tour, you put on the suit. So by the time I get there, it must be like 48 hours later before I actually get into a position to test it at a customer side. And then it's really, really frustrating if you walk up to the machine and then you realize that the screen is not compatible to the hardware which is in the machine.

Yeah, so we had software where you had to scroll through a list, but you couldn't scroll through the list or I think the graphics card was not powerful enough to cope with all the modern software.

Okay, so you're talking about the computer that is embedded in the ASML machine. That was really our production environment.

That was our production and apparently the software. I never realized, because I never encountered problems like that, that there could be a limitation on the hardware. It doesn't matter how beautiful you made your software, it just doesn't work. It's not bad if you realize that in your own office where you're testing this in advance, but if you take so much time and effort to fly all the way halfway across the world and then at the first 10 seconds realize this is not going to work.

We couldn't use it. I mean, I couldn't even control the.

It's a touch screen, yeah. So I think it was less than five minutes that I went back and.

Yeah, we were longer. We would have spent one and a half years already on this.

And then weren't we doing Agile? Weren't we doing scrum?

Yeah, that's why I'm saying it's really important to test it in a representative way. But that's also why it's important to understand, because I didn't even know the customer had these kind of limitations.

It is amazing how we could go on for that long and not really think about the hardware. Well, it was running in a web browser, don't forget, so we all assumed that it would be fine, it was compatible across different browsers that we checked all the usual stuff, but you're rarely told you got limited hardware with this web browser. And it's an old one. It was an old one as well.

An old web browser, yeah, because I think it took quite some time before we realized it was Firefox. I don't know, is it ten or something? Like something some old version at the time? It was an old version at the time, indeed. I think the most important part is I didn't know it was going to go wrong. The only thing that I had a feeling was, I think it's good to test it in a representative way. And I remember even, I think, the UXers at the time, they advised us, like, we should have a stand, which is the same height, same hardware, same mouse and keyboard. Because one of the small things you just don't realize is they didn't have a mouse. There was no mouse there, and we had like a fully mouse controlled application. But that's why it's important to know the customer, because if you just don't know them, you make these silly mistakes and those are going to cost you. They're going to set you back a long time.

But do you remember why it took us so long to understand this?

I think it is understandable that it took so long to be at a production facility because, of course, the customers are far away and it's not easy with the security and with the scrutiny that goes in before going to a customer. It's not an accessible location. You don't go there on a whim.

Okay, you went out there and it was a year into development, but it wasn't release time. We were still testing, but had you not done that, we probably would have got to the rollout stage only to realize within the first 10 seconds that this isn't going to work.

Yeah. And I think for me, it was also because it was the first project, it is still the inexperience that you have this feeling like it's important to go to the customer, but you don't have any baggage yet. You don't have examples of things that went wrong to justify why you need to go to the customer, because sometimes it can also feel like just a fun trip. Like, why do you need to go all the way across the world to see what the customer does? And you don't have any examples on it yet. And to me, it was also part of the fun trip, of course, because I liked it. It was quite fun to see the customer. It's always nice to see different places. So you also have this internal struggle, like, am I just asking this because it's a fun trip or is there actually a need for the customer? And well, in time, I get these examples and I can recommend it's always important to see the customer because you just don't know what you're going to find.

Back to the start of the project, what did you do in the end to just get everything organized?

I definitely fell into a little trap because I was also not the end customer. And at some point after throwing away that document, I believed I was the end customer. I thought I knew everything. That was a tricky situation because then you do take the product owner role. You take it very serious. You make the roadmap. The only thing I forgot was to actually listen to the customer. And the reason why I guess I forgot to listen is because the customer was far away. He was not in any committee that I could easily reach out to. So then you start defining your own vision on it. And because I had a background in that work, I thought I knew what they were doing. So I guess I defined the world for myself. Like, this is how the world should look like, and this is how it should work. It took me all the way until getting to the first production release before I realized, man, I know much less than I thought I knew now. The only benefit was because I thought I knew everything. You create an image of the world, of how it should be, and if you have an image for yourself of how the world should be, and then people start giving you new input because you have a reference, you can adjust this reference. So in the end, it is good to build this reference yourself, but then allow others to be able to shape that new idea of yours. And that, I think, yeah, I did this quite late in the project. I should have done that much earlier. If I would have a way, how I would do it now, just going into a new project, I would probably start with the customer, ask him what he wants, ask the proxy how he sees it, then double check that vision and check if there are any objections in the operational side of that. And then together, of course, with the customer and the proxy, decide, okay, based on these concerns, which are at the shop floor, based on your vision, where you want to go, how can we propose a product that deals with both of them? I think that would be an elegant way to do it. I'm not saying that's easy.

In large companies, there are personalities. Some have big personalities, some are not. Often is the one shouting loudest that you tend to listen to.

Yeah, the first obstacle you run into is who are the stakeholders? Because nobody explicitly tells you, you need to keep this person happy. You need to keep this person happy. You need to keep they don't tell you they only assign you one person, but in the end, usually that person is part of the people you need to keep happy. But there's a whole line of other people that also have an influence and might even have a stronger influence than the person who is appointed. So figuring out who are the people that need to feel comfortable with the product and need to be involved, that's a major obstacle already to figure out.

And then when you find you have ten or 20 people who want to say something.

Usually the easy thing you would ask, like, who's the most important? You won't get an answer. At least I wouldn't get an answer. So what I usually do in my mind is I try to prioritize my stakeholders, like, which is the stakeholder that needs the most attention or feels the most important. But you can see it's quite a delicate job because there's a lot of interpretation on my side. I'm making a lot of assumptions. Like, I think this person is more important than this person.

I tend to respond, but that might be a personality trait. I tend to respond to the person that makes most sense. So the person that I do find.

What happens the most is that in big organizations, because the organization is really big, it is not feasible to expect everyone to know everything. And I think if you are in a large organization long enough, you tend to accept the fact that you cannot know everything. And then people start running on assumptions. And what I find usually is that people follow these assumptions. They heard it from someone who said they've been doing it for so and so many years. But what I do is I tend to ask for the source of the information. So if someone is saying it, I will challenge the assumption. I will ask from which person did they hear it? Why is this assumption related such and such? And by asking these questions, you will know if the person can follow the logic of the things that they are saying. And if they cannot answer, well, then I already get a feeling like, okay, this person doesn't know. I need to move further down in order to figure out who it is. So it's not that this person cannot follow any common logic. It's more that these people have accepted they cannot know everything and they will just run with the conclusions, but not understand why the conclusion was there. And then once you start challenging the conclusions, you will realize, okay, which people actually know what is going on and what needs to be done? And I think what I find difficult is the amount of people you need in order to get on board. It's important that all the stakeholders feel part of the project. And I can tell you that chain can be quite long before getting to the right person.

I remember Mike sitting behind one of our developers who tended to deviate a little bit and do his own thing, and you were like, I understand what this is doing, but why is it doing this now? And it just wasn't following how you expected the business case to work.

If there's something in there that does not relate to what something you can explain in the business, that probably means there's a lack of understanding in that area. But I do agree with you that the code should be actually quite readable for a business analyst like me, because I can definitely not write any code. I should not allow me near any kind of code. But usually if the programmer writes it using terms which are familiar for me, I should be able to read it and understand what's going on, there's no.

Reason not to sit there and just check with the developer as though you were pair programming.

Almost, yeah, that's how I also experience it. The most developers that I have sat with is it's mostly just to clarify logic that I've described in user stories and stuff like that. Because what I like as well is that as a business analyst, you're not the only person that understands the product. That would be a very unhealthy situation. It is fine that you are maybe the most knowledgeable on where it needs to go, but if you're the only one that's knowledgeable, that gives me a scary feeling. So I always feel quite comfortable if at least two or three developers know the direction so that they can also challenge you as a business analyst. When we worked on our first assignment at ASML, I guess I got spoiled in how It teams can work because I remember you explained to me you wanted to understand the domain you wanted to understand the domain model. You even asked me to write a domain model. I had no idea what those things were, so I had to Google it. What is this guy asking for me?

I remember in fact, I said, you need to explain a lot about why the context. So I think that was a mistake. To write it all down was a mistake. But what I was trying to get.

Thanks, Chris. To be honest, I didn't even like those exercises because I'm like it's in my head, why should I write it down? But writing it down, that is really powerful. And I felt more comfortable because first I was writing down lots of stories. But those stories to a random person who is reading those stories might not make any sense at all. They may only make sense if you have this common idea of what the world looks like. And I think that's what I really liked, to have someone on the development side to spar with and to explain what the business side of things are so that you could also trust, like, okay, I know someone within the development team knows the direction and can check if we are not going into any unintended side effects. But I guess that's also different per developer, whether you want to know about the things that you're building or whether you just want to know what you need to build. And I think that is I don't.

Know what you're like, Jesse, but I do like to know why I'm doing things. But I don't want to have to go through the process of figuring out what it is we need to do.

If you can get just a bit of business context, it's just really valuable. Like the example we talked about earlier. Had I known that the customer doesn't have a mouse, then I can make all these little micro decisions while I'm developing. Like, it doesn't make sense to hover buttons or whatever. But yeah, that's really helpful. But yeah, like you said, actually talking to the end customer, I feel like that's also such a different skill set than developing. You'd be lucky to have a developer who is good at both and actually likes doing both.

Likes doing is important. I'd rather just assume what they want and then build it. And then I can have fun building something.

Yeah, that's the interesting balance because, well, to me, it might not appear this way because I make the decisions, but I'm quite uncertain about all the things that I'm deciding on because, well, basically, I'm not the end customer and I'm not the developer. I have basically no primary knowledge of both, but I'm in between trying to make a decision for both. And that really is quite an insecure place to be in because I remember developers coming up to me that I've designed a solution, like, I think we should go this direction and that. They say, Mike, how can you come up with this? This is completely ridiculous. But because I'm not aware of the possibilities in software, I don't know all the kind of libraries you could use or all the kind of functionalities that are there. Basically the only thing I know is what I'm able to do online. I can get some experience from that. And usually I try to copy things that I've seen before. It might make it easier to adjust your vision because it might make you understand that you might also be wrong.

But developers will come with all sorts of opinions. I've seen this product working like this and I can use this little feature. They don't know any better.

No, I know, I just want to use a cool feature. True. It doesn't seem like that when I talk to them, they actually seem to know what they're doing.

Don't be fooled. But the funny part is, I do see the difference in the developers. I worked with Jesse and with you, and I remember that I still do this. I make these mock designs and I draw roughly what I think it should be. But usually those marks are quite detailed. I don't know how to sketch. I'm just really bad at sketching. So I make a very detailed, detailed thing. Maybe I should do it with pencil that it looks like a sketch. And then I have two kinds of developers. I have the developers who just literally copy it to the pixel, and I have developers who look at it and say, like, yeah, I get what he means. He probably wants to do something else, but he made a nice try, so we'll make something out of it. And yeah, I try to encourage every developer to take anything I say with just a pinch of salt. I think the only real skill that I can add to a team is trying to understand the customer, explaining the text, but actually designing the solution is not really my core skill. I really need the expertise of the developers there to know what are the possibilities? I think that's what makes a good team. In the end, no one can have all the skill sets you need for a proper product.

Mark van Velthoven recounts the challenges he encountered during one of his earliest roles as a junior software developer at a large organization. Assigned to a complex project with tight deadlines and run in a traditional manner, Mark quickly found himself in at the deep end.

Determined to succeed and despite a lack of experience he threw himself into the project. 
However, it became increasingly clear that the technical challenges were far greater than he had anticipated.
Moreover, organizational issues such as poor communication, understaffing and unrealistic expectations made it difficult to keep the project on track.

When the lead developer quit abruptly, something had to change as the entire project was in jeopardy. 
Mark''s managers brought in Jessy and Christopher to help rescue it. Mark recounts how it unfolded.

Join us in our first episode where hosts Christopher and Jessy reminisce with Mark about an IT project heading for disaster and how they managed to turn it around.

Death march to victory

A Java team asked me to help build a fully fledged web app

A team was trying to make a desktop app into a full fledged web app. The project manager didn't believe in agile. The tech lead collapsed in a meeting about why we're not delivering or whatever. Everything went wrong on all levels.

Mot: I experienced it like that. Intense period, but it was a good experience

At some point a manager higher up in the chain asked us if we wanted to do overtime. It was a good laugh and a good experience, but it was intense. The biggest value or input you gave is just taking a step back and just looking at that logical.

They invited everyone except the development team, which basically did all the work

They invited everyone except the development team. And they just forget to invite the developers. Nobody went because everyone was like, yeah, that's outrageous. Thanks for coming and sharing your insights and stories about your time in the trenches.

Before it all came to a collapse. Six, must be maybe a year, but I don't know, somewhere around that time. Well, everything, what could have went wrong, went wrong on all, on all levels. So like I said, I just came out of school, I did Java Eight, but I didn't really made a company software online. It was all like desktop app was proof of concept. Nothing was really on the line until then. But yeah, they thought we did a good job. So they wanted to continue it and basically make that standalone application into a full fledged web app. Yeah, with all kind of criteria like 100% uptime, all that stuff. But I will touch on it later. So I was put into a team with one or two others and a lot of promises were made upfront. Like okay, if you start this project, you will get an artifact server, a fully working like a pipeline. Build and deploy. Yeah, build, deploy, testing, Linting, whatever, everything is there in place. You can just use the modules you need and you can get going. So day one we get there and there's basically nothing is empty. But we also want to make the best of it. So we just get starting programming. So the one supervising, he made what you can call an architecture, but it was just on a whiteboard and it was there maybe for some weeks and I stared at it multiple times, but I couldn't get it in. And then we moved to another building and the whiteboard was gone and so was our architecture. I remember that architecture and I'd never seen anything like that before. It was new concepts, CQRS events, there were like multiple databases, java Enterprise Edition servers, containers. Looking back, it wasn't a bad choice. It's just that given the maturity of the team and the fact that you need some experience with that stuff so we get going. And the big brains behind the idea and how it should be done was also very occupied with another project. So when we did those reviews it was like, yeah, okay, maybe you need to work on this and this. And then we continued. And we also had a tech lead back then he was very nice, but he was maybe a bit social, awkward, or at least he worked I think with the manager before and they couldn't get along quite well. So there was already like some tension in the project. There was a project manager, of course. Yeah, exactly. We had two actually. Two? How many devs? Two. Two and attack lead and architect. Yeah. So I didn't make never a web app before. The other Java dev never made a fully fledged web app. The tech lead did, but he was occupied with keeping the managers happy. And out of, I don't know, the 40 hours we had each week, I could maybe sit together with him for 6 hours. So that just went on for weeks, months. He went on vacation, obviously, because you have vacationed. And then I was asked, okay, can you help with the sprint planning? Yeah. Actually, back then, if I look back to it, I gave them the real story, like, okay, we can maybe do these three tickets if we want to do them right with testing, like finishing them properly. But he said, no, this is the list we need to have done by the end of the sprint. I said, but yeah, that's not feasible, but we need to do it. Okay, then put them on the list. And I can only commit to those three, but we do our best. Most people, at least nowadays, they have some idea of agile, and you're not really supposed to do that. He didn't believe in agile. Okay. I think he even spoke about project manager. Yeah, project manager. I think he even said and he wasn't too shy about it, he just said, I don't believe in working agile. I mean, he even said that every month or every so many weeks, he had to go to upper. I mean, he even called it like that. Upper management or senior, I don't know. And he said, yeah, I need to explain why everything is being where all the money yeah, where all the money is going and it's taking so long. It is funny what commitments are made, the chain that you don't even know, but you let it go on for six months like this, I believe. Then the tech lead just collapsed. I think he in a meeting, I think the Uncountable meeting about why we're not delivering or whatever. So we're all explaining. And then this guy just he had enough of it, and he said, I'm going home. I'll call in sick. I remember there was just another wow moment that the manager said, don't forget to call in sick. And everyone was just amazed at the situation, and you should have had some sympathy for the guy, but just fill. In your timesheet correctly. Yeah, exactly. I don't know. It was that moment that we all came together, and Jesse came as well. And I don't remember the sequence of events, but I had a strong urge to get us out of that open plan office. We were sitting in there with the current architect, both the project managers behind us. Yeah. And you couldn't talk freely, is what I felt. You couldn't really be honest and get to the bottom of what was going on here. So I had this instinctive urge just to get out, and that's what we did. We went to another room that was unoccupied there. Yeah, exactly. So at this point, we actually had a decent amount of line of code, I think. Yeah. There was no changing and starting again. No, there was no greenfielding, but just certain concepts weren't laid out correctly or just over engineered and therefore not working. Or not working. Stable enough. And I remember me being behind the computer, the laptop, I think, then you two and also the other colleague, so it must have been four at that time, I think. Yeah. Explain the setup a little bit. What we did, we hooked up my laptop with the beamer, then basically presented the code editor and then went through something, some feature which didn't work. And then I think we took one or two weeks to get all in this room every day and then just get you two up to speed, but also to get to a conclusive answer, to say, okay, this will take another six months to get it somewhere where everyone is happy that's I think we did what we did the first one or two weeks. Yeah, because of your typing. And they were really fast. We would all just sit behind you in a way or stand behind you while you projected the code and just started typing. And we were literally saying, change this, change that. He was just changing the pedal shift on course. Yeah, but it was really a great way to code. I experienced it like that. I thought it was very intense. I mean, you don't want to be doing that for 8 hours a day, every day. But it's such a nice interface to have someone who can code. And you were like autocomplete almost as well, because very quickly I figured, you know what I'm going to say and you're just typing it out. I think that the biggest value or input you gave is just not per se the technical stuff, like, okay, use this stream operation instead of this one, or use, I don't know, an hash map instead of a list or whatever. But also you came in new and just taking a step back and just looking at that logical and just talk it through and how should it work? Is this logical? I think, yeah, that came also from my autocomplete. So when you were talking, I was like, okay, then probably this needs to be like this. And then everyone joined that conversation. And so everyone was talking and I was just on the fly, just weaving in everyone's ideas, everyone ideas. And then we did overtime. Do you remember that? I think it was leading up to a first release, I think I remember. At some point a manager higher up in the chain actually coming in for a meeting with us and asking us about it if we wanted to do overtime. It wasn't in a meeting. Yeah. You were there as well. I think so, yeah, everyone was. Yeah. I knew that this hotshot came in, which in the end was the money mule, but never seen him before. But then there he was. And what did he say? I don't know. First, a good weather story about how difficult times it was, but we were doing the all right thing and stuff like that. And then he think he asked if we were if we were okay with doing overtime just for the extra mile. Actually, it was a good laugh and a good experience. Intense period, but it was a good experience. Yeah, exactly. Well, sometimes you have like, okay, like a year ago, I did this and that and was a good experience. But actually, at that moment, it was a good experience. Even in the moment. Yeah, exactly. One of the managers, because I don't know why, but they had a feeling that as we were doing overtime, they also had to be there to babysit. Yeah, basically, it felt like that. I wish they wouldn't be there, but they had a feeling, okay, we are a team, and me, as your direct manager, I need to be there. So they were sitting there and they saw on the time, like you said, I think he at one night, I don't know, it was maybe nine, maybe close to 1010 o'clock in the evening, and he wanted to go home. He wanted to go home before that. So he was like, yeah, guys, should we maybe wrap it up and tomorrow there's a new day. But we were just now we're in the flow. Yeah, we were there. And I also remember that I think it was the last day or evening we did overtime and the day after, or maybe that same week, there was like a big demo to everyone who was showing off to one of the managers, like, look what we did. We were really proud of it. So we were demoing, really enthusiastic after all this struggling. And he just bluntly asked, so does it work? Are we good or are we set for tomorrow? And I remember looking at him and. This was the project manager on the night. Yeah. He said, Was there babysitting? And then he sat behind us for a little bit. Yeah. And we demoed it to him, like, Whoa, we got it working. Really? We were showing him detail. This is what's going on. And you click this, this happens. And his eyes had glazed over and then he woke up at last minute. So how's it work? Yeah, exactly. And I looked at him and I said, I made a joke, but I probably didn't make any friends with a joke. But I said, Chrissy, I didn't know what I said, but basically came down like, he doesn't want to know what we did, he just wants to know if it was working. And it was just such a slap in the face, like after talking about Motivating. Yeah, exactly. And then there's this guy just asking, does it work? Which is such an anticlimax, basically, after such a good period and experience. But, yeah, it's a real vibe killer. And after two months, though, I do remember he was very happy, but he was amazed. He could not believe that the whole project could do a 180. So, like, you said we turned the ship. We had good atmosphere. Things were going all right. And then so one of the project manager got replaced. The other project. Yeah. He was a completely different character. Yeah, he was more of a people's, actually. I could have a laugh with him and a talk. But he was a bit if you want to do something to be done, then he would maybe try it once, twice, and then maybe we'll probably bleed. And then that's it. Nice guy. Humble. Exactly. Fine to chat with. He wasn't really into it, let's face it. No, and not the It side of things. He was just a project manager, but not an It project manager. He had no use. But he had no affection with It technology and whatever. Yeah. So he had no love for It, and he couldn't get anything done. Exactly. What was he doing? So that's why he got replaced. And I remember so this other project manager comes in, and so we have this 5 December treat like a glass. Big glass. Traditional Dutch. Exactly. Then this other project manager comes in and with a box of those cookies, and he goes out, hand out this stuff, just only to his department. Oh, yeah. So I'm sitting well, not new at that point, but he did the UI. He was also just hired. Same team. Our team. Same team. Our team. But indeed hired via a different apartment. So he's sitting next to me. I'm really having a good time with this guy. Really nice guy. So I get this cookie. He doesn't we look to each other. We're like. Okay. WTF and then you just have to cope with that nonsense. So we had this dinner. We had this dinner to celebrate, like a milestone, like a release or I don't know what. So I come into the office and they ask her, are you coming tomorrow? I said tomorrow. What's that? Tomorrow? So they invited everyone except the development team, which basically was doing all the well, not maybe all, but, like, the work, let's say. Well, nothing would have been there. No, exactly. Right. And they just forget to invite the developers. How do you know they forgot? Well, you can see well, it was just not on the two list in the mailing list, because someone else said, I got a mail. Okay, let's look who's on it. And so it was all these people. And it wasn't a case of, we don't want to invite those guys. It was really we totally forgot about them. But then in the end, nobody went because everyone was like, yeah, that's outrageous. We could have plenty to talk about. Thanks for coming and sharing your insights and stories about your time in the trenches. And we'll do it again. Sure.

Before it all came to a collapse. Six, must be maybe a year, but I don't know, somewhere around that time. Well, everything, what could have went wrong, went wrong on all, on all levels. So like I said, I just came out of school, I did Java Eight, but I didn't really made a company software online. It was all like desktop app was proof of concept. Nothing was really on the line until then. But yeah, they thought we did a good job. So they wanted to continue it and basically make that standalone application into a full fledged web app. Yeah, with all kind of criteria like 100% uptime, all that stuff. But I will touch on it later. So I was put into a team with one or two others and a lot of promises were made upfront. Like okay, if you start this project, you will get an artifact server, a fully working like a pipeline. Build and deploy. Yeah, build, deploy, testing, Linting, whatever, everything is there in place. You can just use the modules you need and you can get going. So day one we get there and there's basically nothing is empty. But we also want to make the best of it. So we just get starting programming. So the one supervising, he made what you can call an architecture, but it was just on a whiteboard and it was there maybe for some weeks and I stared at it multiple times, but I couldn't get it in. And then we moved to another building and the whiteboard was gone and so was our architecture.

I remember that architecture and I'd never seen anything like that before. It was new concepts, CQRS events, there were like multiple databases, java Enterprise Edition servers, containers. Looking back, it wasn't a bad choice. It's just that given the maturity of the team and the fact that you need some experience with that stuff so we get going.

And the big brains behind the idea and how it should be done was also very occupied with another project. So when we did those reviews it was like, yeah, okay, maybe you need to work on this and this. And then we continued. And we also had a tech lead back then he was very nice, but he was maybe a bit social, awkward, or at least he worked I think with the manager before and they couldn't get along quite well. So there was already like some tension in the project.

Two and attack lead and architect. Yeah. So I didn't make never a web app before. The other Java dev never made a fully fledged web app. The tech lead did, but he was occupied with keeping the managers happy. And out of, I don't know, the 40 hours we had each week, I could maybe sit together with him for 6 hours. So that just went on for weeks, months. He went on vacation, obviously, because you have vacationed. And then I was asked, okay, can you help with the sprint planning? Yeah. Actually, back then, if I look back to it, I gave them the real story, like, okay, we can maybe do these three tickets if we want to do them right with testing, like finishing them properly. But he said, no, this is the list we need to have done by the end of the sprint. I said, but yeah, that's not feasible, but we need to do it. Okay, then put them on the list. And I can only commit to those three, but we do our best.

Most people, at least nowadays, they have some idea of agile, and you're not really supposed to do that.

I think he even spoke about project manager. Yeah, project manager. I think he even said and he wasn't too shy about it, he just said, I don't believe in working agile. I mean, he even said that every month or every so many weeks, he had to go to upper. I mean, he even called it like that. Upper management or senior, I don't know. And he said, yeah, I need to explain why everything is being where all the money yeah, where all the money is going and it's taking so long.

It is funny what commitments are made, the chain that you don't even know, but you let it go on for six months like this, I believe.

Then the tech lead just collapsed. I think he in a meeting, I think the Uncountable meeting about why we're not delivering or whatever. So we're all explaining. And then this guy just he had enough of it, and he said, I'm going home. I'll call in sick. I remember there was just another wow moment that the manager said, don't forget to call in sick. And everyone was just amazed at the situation, and you should have had some sympathy for the guy, but just fill.

It was that moment that we all came together, and Jesse came as well. And I don't remember the sequence of events, but I had a strong urge to get us out of that open plan office. We were sitting in there with the current architect, both the project managers behind us.

What is happening right now in tech may be one of the greatest market inefficiencies in history.

#5 Most people in tech don’t work

Our latest episode...

Previous episodes

Journeyman developer stories from back in the day

The Software Engineering Gender Gap. What's The Problem?

Education of a product owner

Death march to victory

Want to know more about QuadCast?

Check out our about page

Get in touch