Transcript

[00:00:00] 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:09] Mike:

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

[00:00:14] Christopher:

And how did it come to be? I forget.

[00:00:17] 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. 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, actually. The product was not changing. It was just they recognized, like, oh, yeah, thank you for your feedback. That's it.

[00:00:55] Jessy:

Silent.

[00:00:55] 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:32] Christopher:

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

[00:01:39] 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 were 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, the design. 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, 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 onto. This is the Holy Grail.

[00:02:37] Christopher:

There's a lot of work gone into this.

[00:02:38] Mike:

There's a lot of work going 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? Who is our customer? And then start from there. And it was after three or four months, I guess I let go of that presentation and thought, you know what? I have to form my own vision on this. I'm not sure if I'm allowed to speak for every engineer out there, but I'm quite lazy in general. I try not to do too much repetitive work. And if there's repetitive work, I try to automate it and get rid of it. And 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 documents. So I actually read the document at that time. But since then, I have rarely read any other document that has passed my desk. I've only spoken to people, asked people what their problems are, and translated that into documents which I have to write. So I still need to write them. But I truly believe in the power of communication, I think. I'm not sure if it's Agile or Scrum. I always get those two mixed up.

[00:04:03] Christopher:

Don't worry about alone. Agile actually says it says yeah, I can't even remember it now. The interactions of people of a process. People of a process, right.

[00:04:12] Mike:

I truly believe that you can only get information across by having a dialogue between people. 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 any documentation I've rarely found a situation where the documentation is so good and so sufficient that you can directly get to your product. However, I think the tendency in companies in general that I've seen is that it's more documentation over people. I think recently I had to integrate with a different department. I wanted to know how their interface worked and I wanted to know what kind of information I needed to send via the interface. And what I was expecting was someone who would be able to explain it to me. So I asked, who is the contact person? And the only thing they could do is redirect me to a documentation page. Like, now you can find everything in the documentation. Now I can tell you, to me, that already gives a bit of resistance to me because I don't like documentation, so that's kind of my problem. But okay, I went to the documentation and then you get this problem, like, okay, wait, there's many versions of this. What's the latest version? Where can I find the latest version? Am I sure I'm reading the latest version? Is this the right document? Because there's five more documents in the same folder. So you get all these questions and then you start opening the document. You see it's like 150 pages and you're like, OK, what's the most important part of this document and in what kind of context should I be reading this? So there's so many questions that are popping up and I think the people who wrote the document for them, it's probably very clear because they understand the context and they understand why they wrote the document. But someone who doesn't has never integrated before, has no idea what this department is doing, is just lost in such a such a big document. So that's why I believe that if I would recommend anyone, how they want to work is have someone to contact, give a bit of explanation and guide someone through. You can have documentation as like background material. Like, I'm going to guide you through the process. I'm going to give you the context of our situation and the final guidelines. You can find in section X of paragraph such and such.

[00:06:30] Christopher:

In other words, you need to be spoon fed.

[00:06:33] Mike:

I think 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:07:01] 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. That means really sitting down in detail with them. And spoon feeding is a good analogy because they just sit back and you have to push the information into their brain. 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. And when you're getting people up to speed on anything, it should take effort on your part.

[00:07:29] 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. Time is the most powerful gift you can give to other people. And sending someone towards a document, I think that's rarely erode 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:08:14] Christopher:

What else did you discover when you came on to the project?

[00:08:19] Mike:

The people who are representing the business or the people who are representing the customer, they are not in fact the end customer that 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 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 said no, 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 what I realized then is talk to the proxy, but I also immediately talk to the customer themselves, which is kind of it's a very great 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:10:15] Christopher:

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

[00:10:19] 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 there's 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 that 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. 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. That was not my intention to make anyone angry, of course. I guess it had just been implanted in me due to my previous experiences to avoid this. 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 want to deliver something quickly, but that's not the best way to keep everyone on board.

[00:11:56] 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:12:11] 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:12:27] 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, you would fly to other countries, literally, and observe these guys operating and using the product.

[00:12:55] Mike:

I remember we asked the project leader at the time, like, can we have a testing environment which is representative or identical to the 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 offer worked. So I flew to Korea, I think it was. So that was a good 14 hours trip to go there. 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 get 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:14:00] Christopher:

How do you mean?

[00:14:01] Mike:

Yeah, so we had a 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:14:11] Christopher:

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

[00:14:18] Mike:

That was our production and apparently the software. I never realized that because I never encountered problems like that. There could be a limitation on the hardware. It doesn't matter how beautiful you make your software, it just doesn't work. I think 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:14:46] Christopher:

Is that how it went?

[00:14:47] Mike:

Yeah, that's how it went.

[00:14:48] Christopher:

What did you see?

[00:14:49] Mike:

Yeah, well, we couldn't use it. I mean, I couldn't even control the touchscreen. It's a touch screen.

[00:14:55] Christopher:

Yeah.

[00:14:56] Mike:

So I think it was less than five minutes that I went back and.

[00:15:00] Christopher:

We'D spent, what, months longer?

[00:15:04] Mike:

We would have spent one and a half years already on this.

[00:15:07] Christopher:

And then we're doing agile. Weren't we doing scrum?

[00:15:10] 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:15:21] 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. An old web browser.

[00:15:43] Mike:

I think it took quite some time before we realized it was Firefox. I don't know, is it ten or something? Like something an old version? It was an old version at the time. Indeed. I think the 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:16:30] Christopher:

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

[00:16:34] 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:16:51] 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:17:04] 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? 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:17:56] Christopher:

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

[00:18:03] 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 start you do take the product owner roller, you take it's 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 that 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 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. Getting to the good product is possible. That can be possible if you know the end customer really well. 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 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:20:55] Christopher:

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

[00:21:03] Mike:

Usually the easy thing you would ask like, who's the most important? You won't get an answer, or 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:21:30] Christopher:

How do you make that decision?

[00:21:32] Mike:

Only by understanding the customer. Because you're trying to understand what is the sole problem they want to solve. And based on the problems that all these stakeholders are mentioning, you start thinking like, okay, this problem relates significantly to the problem I need to solve. And these problems seem relatively minor compared to the problem that needs to be solved. And then I start prioritizing like, okay, I think this person is quite aligned with the problem that we need to solve. Then this person seems more important than the next person.

[00:22:01] Christopher:

In large companies, there are personalities. Some are big personalities, some are not. And it's quite hard to figure out who is making sense or often is the one shouting loudest that you tend to listen to.

[00:22:14] Mike:

Yeah, I think that is definitely a pitfall, but 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 find, many.

[00:22:27] Christopher:

Of those people.

[00:22:31] 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 telling the conclusions, you will realize, okay, which people actually know what is going on and what needs to be done. And I can tell you that that chain can be quite long before getting to the right person.

[00:23:53] 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:24:09] Mike:

If there's something in there that does not relate to what's something you can explain in the business, that probably means there's a lack of understanding in that area. We had the same in our solar car team. We had this weather model to predict what kind of weather we would be expecting and what the performance of our solar car would be. And I remember that there was this factor in there. They called it the unknown factor, and they just put it on everything, and we honestly didn't know what it was. And we asked a lot of times, but they said, no, you need it. This factor, you cannot touch it.

[00:24:41] Christopher:

What was it for?

[00:24:43] Mike:

It was an uncertainty factor on solar input. And in the end, the engineer, which was in our team, he actually refined the model. He got the proper weather models from the metrological institutions, and we didn't need this factor anymore. But basically that showed me, like, okay, every time there's a factor somewhere or there's something being done, that's just a lack of understanding or maybe some information is missing. 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 that you 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.

[00:25:24] Christopher:

There's no reason not to sit there and just check with the developer as though you were pair programming.

[00:25:29] Mike:

Almost, yeah, that's how I also experienced it. The most developers that I've sat with, it's mostly just to clarify logic that I've described in user stories and stuff like that.

[00:25:38] Christopher:

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

[00:25:49] Mike:

Get you to do, I still do that.

[00:25:50] Christopher:

Do you still do that?

[00:25:51] Mike:

Thanks there, Chris. But I guess that's also a 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. 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? And to be honest, I didn't even like those exercises because I was like that'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, they 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 like, 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.

[00:27:33] Christopher:

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

[00:27:45] Jessy:

If you can get just a bit of business context, it's just really valuable. Like the example we talked about earlier, like, 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 that's really helpful. But 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:28:16] Christopher:

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

[00:28:22] Jessy:

Exactly. Just build what you want.

[00:28:24] Mike:

Yeah, that's the interesting balance because 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 basically I'm not the end customer and I'm not the developer. So 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:29:31] 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. I don't know any better.

[00:29:39] Mike:

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:29:46] Christopher:

They always seem they always claim, don't be fooled.

[00:29:49] Mike:

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 mark 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. So they say, like, oh, no, I need this done. So I'll do it. 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 yeah, 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 context. But actually designing the solution is not really my core skill. I really need the expertise of the developers there too, to know what are the possibilities. So, yes, 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.