Timelessness

Timelessnessless?

© 2025. All rights reserved.

Harassment: ASML, UX Trojan horse

Thu, Mar 27, 2025 ❝UX circumventing normal processes and abusive practices within its competence.❞
Contents

A “Trojan horse”. That’s roughly what it behaves like. It’s a stakeholder, but also with representation within each team. And these team members tend to push features in with cheap excuses instead of them being treated like any other stakeholder and having features introduced through (and in collaboration with) PO, with proper curation, prioritization and proper treatment among stakeholders. The following is more specifically about the complications that arise from this behavior.

First team

In 1st team stories this contribution was already reasonably discussed. So I will try to not touch on everything again.

During 1st team, UX just started to emerge. The other developer that started around the same time with me, took that as his focus. He was smart enough to understand that you can’t “force UX at all costs” and expect it to be viable, reasonable, and received with loud applause and fireworks, he has – in my opinion, assuming I’m not biased – taken a position that allows for cooperative alignment. We managed to accomplish a lot, because we knew how to make trade-offs such that would allow for a balanced approach. Yes, they introduced the whole UX concept in this larger project, but that was such a significant feature. However, we did push back on plenty of the “slightly more exotic” ideas that would take considerable amount of time. We also looked UX features that were low hanging fruit, or isolated pieces of work. Essentially, we tried to find parts that we could slot in with other demands and needs. Because this UX representative, being a developer, didn’t relentlessly push where it simply wasn’t feasible, we could manage to do both.

Now, apparently opinion differ on how much bad intention is involved on part of this developer. I received (indirect) hints at several occasions afterwards, indicating that a joke got out of hand. I have no reason to think he was acting purely maliciously. Furthermore, the “joke getting out of hand” in part would be explained by the extreme stupidity of many other people, and the utter lack to question or discuss anything that might have seemed extreme, contradictory or completely ridiculous. At this point, I do not know exactly, how to rate the intentions of this developer, but I will assume reasonably good intentions for the majority. The other reason to generally assume good intentions, is the fact that we didn’t have competing focus and interests.

During the large project, also described in the “ambitious”/malicious PO story, we collaborated well. Given that he understands there is a need to prioritize and it was in the interest of the PO at the time, we could have these UX changes without sacrificing project functionality. Note that in all this, it is important to realize this person is a developer by trade who took an interest in UX. It is important to understand the Scrum process. The PO story mentioned above, goes into more detail about this. Given that we managed to finish the project in time and have good results, shows that at the very least we had made reasonable trade-offs in that respect.

Second team

In the second team, it is important to understand the dynamics already present: multiple teams, multiple seniors, other complications already present, need to switch (sub)domain, focus on high-priority goal with UX to the benefit of the project as long as it doesn’t become a stumbling block. UX wasn’t exactly prime concern. It was supposed to be a useable, possibly pleasant, experience for a tool that needs to work and produce the results needed for the demonstration / proof-of-concept. (Not sure how to classify to be very precise, see story for more detailed explanation.)

Here, UX competence kept pushing for more and more. It is evident at this point, that the strategy was different from “let’s see what we can accomplish” as in the first team, to “try to push in whatever we can”. There have been several meetings with multiple seniors pushing back on account of “nice idea, but that’s not exactly how users are expected to work with this”, and “this is completely overkill for what it tries to accomplish”. With the two ASML seniors being very well aware of what the tool and many similar tools were supposed to and designed to do, it becomes easy to push back against overreach. Discussions often concluded on a note of “this is enough to make it user-friendly”, i.e. nice but also functional.

I don’t know to what extent UX-competence was trying to benefit from the “visibility” aspect in that a lot of what is visible and apparent in a project, would have some UX influence, possibly giving them attention this way. We had to push back on many things that just weren’t necessary, i.e. they made up a nice story, but it’s just that.

UX representative was not a developer by trade, so one could notice there was less understanding for the technical complexities and complications that are already involved. Furthermore, it is easy to “ask”/push, if a lot of the complications aren’t your concern.

Apart from the UX role, there was some manipulative bullshit going on, that I discuss in interim 2nd team story.

I don’t recall UX being a huge stumbling block here, because there were plenty of other problems to be resolved already.

Discussions with UX developer from first team

This happened somewhere along the 2nd year, as I had left the team. Possibly the first mention was already during the first year.

As mentioned in other stories, the UX developer and I kept in contact even after I left the first team. We occasionally discussed events. By his own admission (if I should even call it that), in his own words, he said that the UX lead had said on several occasions that “his background in development was (occasionally) a stumbling block for UX”. (I may be paraphrasing here.) More likely, given what we now know about the malicious, abusive attitude of the UX lead, his capacity for reasoning and ability to evaluate trade-offs with development work, made him someone who wasn’t as easily manipulated into bullying the development team. This was him voicing this criticism in conversations with me. In terms of context, this was probably discussed either as result of: 1.) him reflecting on his results, or 2.) in response to my questions in trying to understand UX given the endless conflicts and discussions. I remember it being mentioned several times.

Note, that one may argue this particular detail was discussed in a private conversation. Let me be clear about this: if anything, this criticism says more about the UX lead given all of the manipulative bullshit that has been going on, than it does about him as a person or his qualities. If anything, he probably does not get enough of the UX “credit” for the first accomplishments and given all I’ve come to learn about this UX lead, he was probably a good example rather than a “bad example” as she’d like you have believed. If “understanding the need for trade-offs, careful planning, mutual consideration for team members and other stakeholders” is viewed as a weakness, then I very much wonder what “amazing accomplishments” are realized when the UX team member is being manipulative, even subtly abusive, towards their own team, while being bullied by UX to the point of burn-out and walking out of a presentation or meeting crying. This simply doesn’t add up, no matter which way you look at it.

Also note that they clearly preferred non-developer team members (afterwards). The UX developer was very likely responsible for the first big “UX win”, when we worked on the larger project in first team and he focused on the UI/UX contributions.

UX member coming and going

As mentioned before, I try to create some sensible linear chronological order. I may be slightly off for specific events.

At some point, someone new with UX ambitions was hired into a team. I don’t remember exactly which team it was. Essentially, he was primarily involved in UX competence. He was there for a relatively short while. I’d guess a matter of a few months, probably not even a year. From my understanding, he left relatively suddenly.

I think I remember discussing this with someone and we both came to the conclusion that he was just gone one day. To my knowledge he was, again, a capable and reasonble guy, who wouldn’t adopt an attitude of “bullying a team until your UX goals are realized”.

Third team

Now, here are some suspicious activities going on. As soon as I and one ASML senior who was also involved in the second team’s “high-prio”-project, suddenly someone from UX also needed to join. This was very likely deliberate, and very likely intended from the start to initiate and coordinate harassment. Note that the “visualization developer” is in contact with UX competence and he was already a team member. Now, recall that the UX competence lead was also the one who fucked up the licensing introduction, possibly also the obfuscation introduction, who also had one designer leave very early on with burn-out, etc.

I got into the third team by swapping positions with an ASML senior. The team that offered support and was interested/invested in having the UI framework adopted, the “Main Application” team who also facilitated the over-all application framework to host the various tools, was this supporting team. Their senior ASML team member was looking for more of a challenge within a functional domain, while I was looking for a different challenge and had shown clear interest in having these supportive mechanisms properly supported, implemented, etc. So we decided to switch positions, recognizing a benefit for both of us. (Of course, that’s when “suddenly” a UX representative, again not a developer, also was pushed in.)

First months in the team

A bit of background, given that we had worked with the two teams together, everyone from the teams knew each other already. The switch was a well-informed choice for the both of us. To my understanding, both teams were also satisfied with this solution as it would ease tension and complications. (Also note that there were efforts to “recreate” earlier conflicts/situations, so that would imply deliberate action rather than “bad circumstances” or shitty behavior on my part.)

Starting out in the third team, there were a number of seemingly intentional obstacles. There was one older developer who seemed to be “resistant” to some of my ideas. Now, I know how this sounds, but it isn’t what you think. During the whole of the third team, people were trying to challenge me, my ideas, my competency, etc. That’s fine. However, that one person took a position of “not understanding” and suddenly two months or so later, doubled-back telling me that “now he understood and agreed”.

I do not disagree with someone wanting more time to think about an idea. However, this was no longer being discussed, and suddenly he pops it back up. I have very strong suspicions that this was just another deliberate action to delay and interfere, trying to “invite” adversarial situations. He also later made several references, one referring to a book, that others later also did, which didn’t make sense and even now doesn’t make sense to me, but that was part of the persistent harassment going on for years afterwards. So, in all likelihood, this whole scenario was one bullshit set-up intended “to be an asshole just because you can”. Like so many others.

Anyways, focusing on UX again. There has been a constant push from first month to last month I was there, for any and all UX ideas and tasks to be pushed into the sprint at every possibility. These discussions would just never end. Sometimes the “arguments” got into the space of “but we need this” and other less well-argumented opinions, and always the approach was to skip the Scrum process (e.g. prioritization, balancing stakeholder concerns, etc.) and trying to push them in regardless through this team member. On several occasions, I also pointed out that the technical concerns I brought to the table, were always also aligned with PO, such that I wasn’t taking “shortcuts” either.

On two occasions, there were hints by UX representative, that she was under considerable pressure. We, several from the team backed me up, tried to explain that she should prioritize the team over UX competence as that was effectively just another stakeholder. She kept refusing. That would mean, that by necessity, these excessive fights and heated discussions would need to continue, because UX –in the end– is just another stakeholder. (This also interferes with PO ability to properly do their job. And makes for frustrating discussions with the team.)

Note that, on several occasions, we also tried to patiently explain why following the process is actually beneficial to the team. That the team is granted some agency according to this process, which is both to benefit of a nicer team dynamic, more freedom, and also to benefit of business. We also explained how the PO is able to balance stakeholder demands, push back against badly prepared business demands and conflicts, and they are there for a clear reason and purpose. Essentially, the whole process was explained again and again. They simply didn’t want to hear it. (I won’t rehash the whole of Scrum. See 1st team PO story for several explanations of Scrum process.)

Advanced UI library

The “Main Application” team, has had a developer with advanced knowledge on visualization already for a while. If my memory serves, he joined somewhere during the cooperative effort with the second team “high-prio project”. As me and the other dev had swapped, and the “Main Application” team was released to its own work again, we started to plan for that team’s purpose. The “visualization developer” –let’s call him that for convenience– had a clear purpose and goal in mind: set up an advanced UI library to support all the domain-specific goals and needs for our department’s software.

With “advanced UI library”, I mean to say a library with prepared, specialized building blocks and composite components that represent concepts of the various (sub)domains. With “building blocks”, I mean the term that other developers would use: base components, possibly with one or more parametric types, that are used to compose the larger, full UI components that can be dropped on a UI to represent an interactive component. With interaction, with color schemes, with most if not all the beauty and richness you would (un)reasonably expect.

As you will understand this takes time to compose. And along the way he would do a redesign. And there would be some generics puzzles to be solved and abstractions to be reenvisioned.

Next few months

Several events happened. This was a time where the team was productive and managed to find its proper direction. PO and I had been working quite hard to position the team, i.e. cementing its own identity, providing value and explaining to business and other POs what problem we solve and what they can expect from us. In short, the framework is able to provide features and functionality, such that the (metaphorical) “surface area” that individual teams need to cover to produce a fully functional tool, becomes smaller. In so many words, the teams can focus on their core competency, and we try to alleviate some of the “generic infrastructure”-concerns such as file-handling, feature-toggles, sometimes configured hardware, generic loading screens, UI interoperability, internal content storage (database), etc.

By simply drawing two rectangles, one within the other, explaining that they can focus on the inner rectangle, while we cover the generic infrastructure “bordering their core functionality” was sufficient to illustrate the benefits. So, by this time, we managed to hook on several teams every few sprints and provide proper support and extend our infrastructure and help with proper interoperability and integration.

I, in my part, looked at several different ways of being able to improve quality and control complexity and unexpected surprises. For example, a trivial but useful addition, is to set a default “exception-handler” in the application framework, such that unanticipated errors get properly logged. This would allow teams to discover problems they didn’t know existed. Obviously, this is a triviality from a technical perspective, but it provides insights you didn’t have before.

Note: this should probably be discussed in a different story, but it is at this point, when we have the attention and understanding from other POs and teams, that we prove that made this team work and the “Main Application” as framework viable, that someone from management tried to have the team disbanded and merged with some other team. Without given the team details, we asked for input to convince him otherwise. Although someone voiced concerns desiring otherwise, I did give the team the details of what was attempted, after PO and I had managed to successfully and with full certainty dissuade that particular manager from this idiotic plan. (In hind-sight, there is no way that this was a coincidence.) Note that this would have destroyed both the “application framework” efforts and the “advanced UI library” efforts by the visualization developer.

At some point, UX had a “marvelous” idea that was essentially a tab-control-pane where the tabs had an additional function as a button. The concept was reasonable, but there was simply something missing in the total picture such that it was extremely non-obvious that the tab itself was also a button. Let me be clear: I have met no-one other than UX, that thought the idea was good. It simply didn’t make much sense the way it was envisioned.

At some point, the ideas was to be presented in two-weekly meetings with stakeholders present, probably the sprint demos. During first two presentations, UX represtative would be on holiday, so someone else had to present. As, by this time, I had had quite some success and was involved in many things, I very much suspected that UX rep thought I had presented the idea. However, there was a very obvious candidate to do this who was by far the most supportive of her work. So, I had immediately thought to ask him to do the presentations. I think he did a very reasonble job, especially given that the idea just wasn’t very good. Both times, reception of the ideas was lukewarm with quite some criticism. Given that stakeholders were present, feedback came from several people, including several enterprise architects.

Note: also, let’s be realistic. At this point, there had already been frustrated discussions every other week or so, so it was also “safer” that someone else would do the presentation. (Not that I minded –in the least– that I wasn’t presenting.)

Also, one of the things that gets very tiring very quickly, is the overly broad, exagerated, insistent requirements of UX rep. A story grows as large as needed to put in all kinds of extra requirements. They are clearly trying to “smuggle” in as much as possible, and/or exagerate their needs. So, every other refinement session, there would be discussions, in which all developers would participate, on “why this or that is part of this story, or why it is needed at all” and UX would reproduce some convoluted story that has nothing to do with the claimed goal, just to “justify” why this was also needed. (This was literally the forced upon dynamic by having UX representative absolutely refusing to participate in their proper role according to the process that everyone was expected to follow.)

Now by the time the third opportunity for the presentation had arrived, UX rep was back from holiday again. She had heard about, and we had obviously warned her about, the bad reception of the idea. She primarily dismissed it with comments of it needing better explaining. She does the presentation, and receives the clearly, direct, strict criticism from several audience members. Now, to be clear, there are different kinds of people present and if I remember who spoke, most likely there were some gentler voices of feedback there too. Regardless, the criticism landed roughly and by the time she had finished, she had tears welling up in her eyes.

After the meeting finished, the first conclusion she came to was that during the first two presentations, we had “fucked up the explanation already” (paraphrased, in the first two meetings). Furthermore, she criticized the audience for “They just don’t get it.” What bothered me (a lot) about this, is that the criticism that was provided, was clearly based on concrete matters: pointing to parts of the idea, to elements on the screen, pointing out that possible actions aren’t clear or evident from what is visible, etc. Her immediate gut reaction, is to blame the other presenter. Which, and I don’t think she knew at this point, was the developer who supported her in mostly everything.

I strongly suspect that the criticism (“fucked up the explanation already”) was directed at me, but I cannot be sure. So, I’ll point it out as commentary instead of including it in the story itself.

Note that the developer who supported her most, did speak critically in trying to explain a situation or his understanding. Regardless, he defended and supported her. I want to point out the nuance of him understanding the friction the UX rep was (unnecessarily) causing and deciding/choosing to support her regardless.

This is the kind of persistent attitude that is prevalent, where UX is concerned. During other (stakeholder) meetings UX lead would also step in mostly when “dismissing concerns as UX knows best” or with somewhat of an explanation. (As I’ll discuss later, these explanations are often dismissed the very next week if it doesn’t fit their goals anymore.)

During all of these months, from the start, several team members had already casually expressed their disdain and futility of discussing anything with UX representative. Most meetings were in one way or another weighed down by this. Some responded somewhat mockingly, essentially implicitly expressing the stupidity of her actions, while some others were just annoyed, tired or apathetical towards a situation of which it was already clear, wasn’t going to change any time soon.

UX persistent, urgent demands

During my whole time in the third team, but especially when the team gained some steam and traction, the relentless insistent need for UX tasks continued. A particularly frustrating characteristic is that everything is urgent and everything is needed. If we argue for implementing it later, or finding a team with a project that needed it, there was always some excuse why it was needed urgently. They will even argue about a hypothetical far future. There was no healthy discussion as in the first team. There was no narrow focus or target as in the second team. This was UX “wanting everything and wanting it now”, and on top of that, usually not able to produce a consistent narrative or explanation for their demands. And, not to forget, that (virtually) none of these requests would follow the proper procedure, i.e. addressed at the PO who would prioritize them as with all other stakeholders. Because UX rep “enjoyed” being a team member so we would have these tasks pop up in our backlog, always urgent always ready to be defended against removal, when they shouldn’t even be in yet.

Note that even if we would take all of UX’s supposed urgency at face value and believe everything they claimed, then there is still the matter that the absolutely refuse to follow proper procedures, while they are most definitely just a stakeholder.

UX team-member heated discussion with UX lead

At one point, PO took me to a coffee corner near a meeting room. She mentioned something and soon after UX team-member is heard in heated discussion, already distressed possibly already crying, then soon after walks out of the meeting, crying, “defeated” (in the emotional meaning of the word) as she walks away.

At this point, I have been in so many undeserved frustrating discussions that I have a hard time feeling any empathy towards her predicament. Now, to elaborate: at this point, we with the team, have attempted several times to convince her that she should side with the team, i.e. push back against unreasonable demands from UX. I had my share of experiences and stories about UX already, so I knew exactly what I was proposing and why it would be the better option. We’ve had several discussions trying to explain how things would go a lot smoother if she would also follow the process that everyone is supposed to follow. This is not a matter of not understanding, but simply refusing to follow. We have had many alignment meetings in attempts to try and foster an understanding and take into account UX demands (and developments). We’d have had the 3-meeting UX component presentation in which she failed to explain the idea and subsequently blamed the team for “presenting badly and ruining the explaination” and her audience for “not understanding her idea” even in spite of clear concrete criticism aimed at the idea itself. For months already, regularly, meetings would be frustrated with UX demands or pointless, endless discussions on UX needs, or other UX surprises. She would be manipulative in sharing her information, or demand that “UX knows better” and all these kinds of excuses that interfere with healthy discourse. She would, most definitely, also deliberately heat up discussions in attempts to frustrate me personally, as was already the case on several occasions. This was most likely a “tactic”, just like in the second team there were attempts to retroactively blame me for “maliciously registering my worked hours” when I waited for someone for half an hour or so. (Which, as mentioned in another story, I would subtract from the registered working times.)

Note: I say “manipulative”. An alternative explanation would be that she unknowingly misrepresents the situation. I do not believe this is the case. I think this is deliberate. And I think, in part, this is a tactic to distract from healthy discourse and circumvent the process. (A process that they most definitely know would keep them in check.)

It’s hard to have any (feeling of) empathy left at this point. She, literally at every opportunity, chose to work against the team –siding with the UX competence– often ruining the atmosphere within the team in the process and starting up endless discussions on priority which always boil down to “UX is urgent and important”, and now I’d have to feel sorry or otherwise “I’m the problem?” It’s just not how that works.

Towards the end

In the last third of my time at that team, I tried to “play the UX game” for a bit and I and UX representative had a full hour meeting, in which I extensively asked questions and she explained their ideas and the reasoning behind it all. I tried to challenge to understand, I tried to explain in my own words etc. After an hour, I felt like I had a strong grasp on their justification and clarification of the UX idea. (To be clear: this focused on a single idea and their way of explaining it in its current state. With no other intentions than simply to reproduce their explanation.) As predicted, which doesn’t take much, next week the story changed. So, we enter in a discussion again, ask her about why things are different and what happened to the other idea. I get some vague explanation, but as always the prevailing attitude is “UX knows better, we say how it is done”. So, I start reproducing the explanations from the week before. I start countering her on her defenses and excuses.

In the end, it turns out that they cannot even explain how their “new idea” evolved within the week from what it was the week before. They simply cannot. The discussion didn’t finish with a clarification. The discussion essentially didn’t finish. The “conclusion” is “UX knows”, and when there is any further challenge, it becomes “UX knows better”. And this is exactly, why I called UX a Trojan horse: they inject a team member with a hidden agenda, often with lacking technical competence, who is pressured by the UX lead into forcing through ideas outside of any reasonable capacity, while –ideally– accepting no form of healthy discourse. (I say “ideally”, because they hadn’t always succeeded. For example, the UX representative in the second team sure did try her best, but she just wasn’t the right person for this malicious attitude.)

Note: the “UX knows better” attitude is a oppressive simplified tactic that was adopted later. The developer in the first team usually would explain it as “look, we try to do more such as the customer/user interviews and such, such that we end up with a more informed and more thorough understanding.” He would also say this after having done such interviews, and would support it with proper reasoning. He would also not use it to cut off a conversation, merely try to cut short a particular topic for which he already had better arguments present. (He also backed up this claim with proper argumentation on several occasions.) I don’t think I heard the “UX knows better” argument from him. It is also because it is used to cut off scrutinization, that I started to test the UX representative with their own story from the week before. The premise is simple: I understand your argumentation and and your reasoning from the previous week. Now you explain to me what the evolution for this week entails. And they couldn’t.

Furthermore, in the last months a multi-department initiative had been started up and with SAFe as the guiding process, they pulled in 10+ teams and other supporting departments like STI, in large projects that set a focus goal and have all these teams collaborate to achieve this overarching goal.

“Main Application”-team, had by this time established a solid identity, enough that we maintained our true goal and worked on the general framework and supportive infrastructure for desktop tooling. Our way-of-working didn’t change much, except for the process mechanics and how priorities were determined. There was plenty of work to do in the UI framework and advanced components, but having done a first redesign, we had tackled the remaining complexities and were well prepared to further support teams with that too.

There’s another interesting story on how a Romanian team member challenged my incompetence repeatedly, then he got tasked to redefine the abstractions in the UI framework and tried and failed for 3 sprints (of 2 weeks), until the visualization developer took over the effort. (He mentioned something to me along the lines of “this is getting ridiculous”, then started the redesign by himself. He was very well aware that I was constantly being challenged. I do not think he bothered to challenge me and had probably long since figured out there was unjustified malicious intent.)

Side-notes

Attacks

The following attacks were apparent from these situations and circumstances.

You would be justified to attack me over some things though: I cared. I tried to make it work. I tried to keep the peace. I did the work. I accepted the challenges of other team members at various times and showed them I was right and had the balls to follow up. I chose solutions that didn’t allow me to “cheat”, e.g. no pre-alignment with whoever we looked up for a second opinion. (And they knew this well, because we immediately went looking for someone with the both of us.) Throughout my work, I played an honest part and I genuinely tried to respect everyone, despite their blatant attacks and opposition.

Changelog

This article will receive updates, if necessary.

This post is part of the Coordinated harassment series series.
Other posts in this series: