Transcript

[00:00:02]Christopher:

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?

[00:00:11]Mike:

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

[00:00:16]Christopher:

And how did it come to be? I forget.

[00:00:19]Mike:

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.

[00:00:52]Jessy:

Silence.

[00:00:53]Mike:

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.

[00:01:26]Christopher:

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

[00:01:32]Mike:

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.

[00:02:26]Christopher:

There's a lot of work gone into this.

[00:02:28]Mike:

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.

[00:03:42]Christopher:

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

[00:03:47]Mike:

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.

[00:04:14]Christopher:

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.

[00:04:28]Mike:

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.

[00:05:13]Christopher:

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

[00:05:18]Mike:

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.

[00:07:04]Christopher:

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

[00:07:08]Mike:

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.

[00:08:33]Christopher:

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.

[00:08:47]Mike:

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.

[00:09:03]Christopher:

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.

[00:09:30]Mike:

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.

[00:10:35]Christopher:

How do you mean?

[00:10:36]Mike:

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.

[00:10:46]Christopher:

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

[00:10:53]Mike:

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.

[00:11:20]Christopher:

Is that how it went?

[00:11:20]Mike:

Yeah, that's how it went.

[00:11:21]Christopher:

Because what did you see?

[00:11:23]Mike:

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

[00:11:26]Christopher:

Is it a touch screen?

[00:11:27]Mike:

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

[00:11:33]Christopher:

We'D spent, what, months?

[00:11:35]Mike:

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

[00:11:39]Christopher:

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

[00:11:43]Mike:

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.

[00:11:53]Christopher:

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.

[00:12:13]Mike:

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.

[00:13:01]Christopher:

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

[00:13:05]Mike:

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.

[00:13:22]Christopher:

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.

[00:13:36]Mike:

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.

[00:14:27]Christopher:

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

[00:14:33]Mike:

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.

[00:16:36]Christopher:

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.

[00:16:44]Mike:

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.

[00:17:17]Christopher:

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

[00:17:24]Mike:

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.

[00:17:52]Christopher:

And how do you make that decision?

[00:17:54]Mike:

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.

[00:18:02]Christopher:

Many of those people.

[00:18:06]Mike:

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.

[00:19:39]Christopher:

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.

[00:19:54]Mike:

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.

[00:20:22]Christopher:

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

[00:20:27]Mike:

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?

[00:21:21]Christopher:

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.

[00:21:32]Mike:

You to do, I still do that.

[00:21:34]Christopher:

Do you still do?

[00:21:34]Mike:

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.

[00:22:27]Christopher:

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.

[00:22:37]Jessy:

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.

[00:23:06]Christopher:

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

[00:23:12]Jessy:

Exactly. Just build what you want.

[00:23:14]Mike:

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.

[00:24:18]Christopher:

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.

[00:24:25]Mike:

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.

[00:24:33]Christopher:

They always seem they always claim to.

[00:24:35]Mike:

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.