Harassment: ASML, Interim - 2nd team high-prio project

Thu, Apr 3, 2025 ❝The 2nd team high-prio project described with focus on content.❞

Contents

This story essentially embodies the remainder of the group-lead fuck-up story, told earlier. There may be some overlap, as it concerns the same project, though I try to focus on the content primarily. Chronologically, this follows up on the adventures in the first team.

Switching teams (cont’d)

As described at the end of first year, team one, I was “asked” to switch teams. That is, I was asked repeatedly, with both PO and group lead having ulterior motives to do so, even though others indicated it might not actually be a good idea. Then in the last days before and after reluctantly agreeing to switch teams, PO pushed and trolled with various snide remarks, making clear I was not wanted, at least according to him.

The team I am asked to join, has its share of problems and has become known as a “problem-team” in that it is significantly under-performing and is a problem in the department that needs fixing. At the moment I switch, i.e. start in this other team, this “problem-team” is pushed onto the critical path (presumably) by circumstance. A customer for which a targeted solution/experiment is about to be developed, requested a desktop-application first, such that there is more control over (intermediate) results and circumstances, and a better ability to observe. This team is the dedicated team to do this, with a Litho InSight server team (out of several) now becoming secondary because of changed priorities.

Situation outline from management

So, either the Friday prior or that Monday, I get asked to attend a morning meeting that outlines this new “high-prio situation”, the concerns and goals involved, the 3 teams involved. They explain the reason for this situation, the parties involved. Next we align on a way of working to quickly transition into this project: the original team is to finish up urgent maintenance work that is already planned. This can take a few sprints, during which time, me and the two seniors from the other teams are supposed to start requirements analysis, preparations. The one senior focuses on the requirements and over-all project architecture. Me and the other senior focus on further requirements, analysis, design, (story) preparations and any team-specific concerns. That is going to be the way-of-working for the next few months. It makes sense. Too many people involved will only hold back a fast-paced process and there is a lot of information to uncover, evaluate and analyze.

Several managers and group leads are present during this introduction as well. My group lead, who already knew he was asking me to solve his problems, knows I’m now asked to guide this team while on the critical path in a full-blown change of plans. I don’t recall how strict of a deadline there was, so I won’t make any statements on that but during this whole time there was significant urgency.

Our team was the appointed team for this particular application. The second team was the “Main Application” team, which maintains the over-all application framework, which hosts all of the available tools. They are involved such that “UI Framework” and ideas that are defined by the UX competence can be adopted by a real-life application. Essentially, a mutually beneficial arrangement that provides us with extra developers and them with opportunities to directly work with and influence adoption of these new UI controls and plans. Although we’re the primary team when project work is concerned, the other team essentially takes on the full spectrum of tasks as well. Logic shared between desktop application and server, is implemented by one of the Litho InSight teams in a separate part of the code-base.

Note that, as far as the label “problem-team” is concerned, I had reserved judgement if only for the fact that my own experience was different concerning how circumstances got explained and where the “real” (process) problems were. It does seem reaonsable to assume the comments such as work-floor conversations being in Romanian and regular commutes back and forth, may lead to obstacles or delays.

For all intents and purposes, my first team could have become a problem-team just as easily, if we hadn’t constantly been fighting back against various stupid circumstances and discussions. I knew very well, there were many circumstances to consider and that just pushing a team around wouldn’t work. We were well-functioning because we constantly pushed back and considered all concerns, even if others wouldn’t.

Introduction

I had to put some effort in recalling the exact details, but I believe this is an accurate representation of the project of the time.

The focus (sub)domain for the team is metrology. I don’t recall exactly what this team’s original tools focused on, but also in metrology (sub)domain. The high-priority project switched to a new idea: special “test-wafers”, which are especially constructed for testing purposes and generally have more coarse structures on them, are suitable for configuring and tweaking the settings for metrology devices, but they also produce their own subtle deviations and anomalies, in part because of the coarser structure. To further refine the settings, i.e. the “awareness” of the true deviations" there would be additional measurements that measured on production wafers with very predictable (patterns of) structures. These specially crafted patterns could be generated in some variations, and offered other ways of evaluating the metrology equipment for accuracy, though these production-type wafers did not allow for all types of measurements so would not by themselves fully replace the “test-wafer” method for metrology.

The production-wafers with test-patterns would be carefully selected and constructed to encourage or avoid certain side-effects given their smaller scale structures and possible effects on this scale.

Where I’m not exactly sure anymore, is whether measuring special patterned production-wafers was done to calculate the offsets between production- and test-wafer-measurements, or for tweaking settings directly without relating the measurements to the test-wafer. However, I would assume we compared with the test-wafer in order to complement those settings. If I remember correctly, the short-hand for the idea was “MTD” (metrology-to-device), though this only refers to the approach of measuring a production-wafer.

Getting started (early preparation)

On the personal front, I had not yet acquired much knowledge in the domain of metrology, data concerning the YieldStar. The previous team worked with tools concerning the scanners, TwinScan. So, there would definitely be a learning curve for me there. The team would be able to fill me in on that domain. Their original applications, IIRC, also existed in that domain. (I’m not sure, because we quickly and almost fully transitioned away into the project anyways.)

On the team front, this specific metrology correction case that is to be tackled, is a new experiment, thus this is new terrain for all of us, including the other teams and the seniors.

On the organizational front, there was good forward thinking in that several rooms were reserved for full-day or even full-week use by our teams. We could interact and intermingle as necessary and have the necessary essentials for work to be done. This is invaluable, because we seniors could take a separate room and align, analyze, design, document and write all that was needed. Whether documents to outline high-level overview, or writing stories to make tasks accessible with sufficient detail for teams (developers) to pick up.

Especially in the first months, the work essentially consisted of: going from meeting to meeting; using spare time to document findings, agreements, analyses; updating our resp. teams; and then gradually transitioning from more abstract analytical matters into more concrete practical designs and team-specific alignment and preparation. Anyone with some idea of how these projects go, will probably consider this reasonable and predictable. If you consider an urgent situation, you’ll imagine that one can easily fill a week with meetings, analyses and alignments. We needed to have an approximate 2-4 week head start, i.e. 1-2 sprints. If we can stay ahead for at least 1 sprint, our respective teams can do work while we’re not blocking them with our analyses and designs.

I, quite literally, drop by the team on occasion to brief them on current state of affairs, what we’re focusing on, how far along we are and what to expect in coming days and weeks. This is as ad-hoc as you imagine.

New team composition

In the first roughly month before we even transition into the high-prio project, the one Romanian senior developer already part of the team, is finishing up with some remaining maintenance then plans to switch teams. This means that the team almost immediately loses a senior, while being a “problem-team” with a lack of seniority.

I noticed, in the first few weeks, there was a reluctance to share information. I didn’t want to draw immediate conclusions, but I noticed then already that there was opposition. Given that I was away for extended periods of time and not well read into the functional domain yet, I found it hard to put a finger on the extent of this. I mentioned it to my group lead at the first noticable signs of opposition.

I also happened to casually mention it to a friend in a very abstract description, along the lines of “I’m not sure. I just switched teams, but it seems like the new team is actively opposing me already. Most likely from the start.”, when he asked how I was doing. I had essentially mentioned to have just recently switched teams and noticed some immediate opposition and that I had a bad feeling about it. It might not have been “appreciated” that I mentioned it. On the other hand, when the full-on attacks started, this was a clear sign that I had noticed early opposition and that could thus be confirmed. I had mentioned the same to my group lead. Of course, my group lead organized the now “problem-team” in the first place, so he didn’t much care as long as I got it done.

After the second or so week, I got some more time in to learn the specifics of the subdomain that the team was familiar with. So I schedule some meetings with members so they can inform me. At this point, I start to notice the “reluctance” to share information. Not knowing how to handle this exactly, and considering that we would need to transition into that new project’s domain, I didn’t want or think I needed to act on it immediately. So I left it be for a while.

Somewhat later, I schedule a meeting with the team member, that we know well for opportunistically trying to profit from the knowledge-transfer sessions and other dubious actions, who shared virtually no information. One day later, in a 40+ person meeting with all teams present, she ventured a question for me to “share the knowledge I had gathered” with the others. (At this point, it should be obvious that there is malicious intent.) I refused. She was clearly and openly opposing me, being from the “problem-team” with “lacking seniority”, being put on the critical path.

Note that blaming this fully on me for not “including her” is short-sighted, as she had demonstrated several times to be unreliable and untrustworthy. Furthermore, it was deliberate to keep the alignment meetings small, 1 representative from each team, to act fast and efficiently. I also did my best to keep things clear, transparent and update the team whenever there was an opportunity. And, of course, there was maintenance work to finish up, so it wasn’t like they were twiddling thumbs.

Rather soon after I joined the team, in a matter of weeks, one of the senior developers would switch to another department. The team member that previously worked on Proguard configuration for protecting the software. They made clear that “he got an interesting opportunity and is thus leaving the team”. It also meant that the “problem-team” was losing a senior developer that even if only for a longer time at ASML, meant he had better understanding of the company culture than new, regularly commuting hires.

Collaborating teams

Our team, being the “primary” team for this project, was working in their intended (sub)domain. We switched to this project and were the obvious primary candidate. As mentioned, we collaborated with other teams.

The “Main Application” team, by their own admittance, took a bit of a gamble. They needed support and adoption of their UI Framework plans. Given the sudden need for this desktop tool, them assisting would mean they had an opportunity to have first-class experience and support for the UI Framework. The team architect, being one of the seniors I had worked with earlier, mentioned this. He was absolutely also a valuable help given his knowledge and prior experience. He did mention he saw risk in involving the “Main Application” team so directly, because of concerns that ASML management would be … well, in my words: “too stupid and shallow to understand that there is value in temporarily collaborating” and that the team shouldn’t be dissolved or abused in this way for just any next situation. If I remember correctly, we thus kept the exact nature of collaboration vague for certain management, to avoid such stupidity. (Which, I think, was an idea of one of the teams’ scrum master.)

I briefly mentioned in the UX Trojan horse that we actively worked on establishing and cementing an identity for the “Main Application” team to prevent other such disruptions where possible. I also later mentioned about an attempt to disband the team to use as some development team for specific “plain” (sub)domain development work. I also mentioned having several presentations and explanations prepared to explain the purpose of the Main Application team in terms understandable by non-technical users with business-perspective.

The “Main Application” team thus learned a bit of the metrology (sub)domain and MTD and we got to learn their ideas concerning the application framework and UI framework that they had prepared and envisioned. We continued to collaborate with our team’s emphasis on the functional domain matters and “Main Application” team focused predominantly on technical framework concerns. Though both worked on essentially the full technical range of the application.

The Litho InSight server team had a smaller, in terms of time-allocation, role in that they provided the logic for that part of the new tool that was to be shared with the Litho InSight server. This included the most intimate computational work for the offsets calculations. Given that focus was on desktop tool first, that’s the extent of their (early) involvement. The server support, as per the original circumstances of the high-prio project, were pushed back in preference of the desktop tool.

Getting the team along

Getting the team along was mostly a process of inevitability, given that I was 75%-80% of the early weeks in meetings, to align on requirements, analysis, architecture and designs, with stakeholders and other teams’ seniors. This gradually transitioned into a significantly larger percentage of time spent in designing. For a significant amount of time, it was a race between senior team representatives (requirements, analysis, designs) and teams (developers), to have sufficient work prepared for the next sprint in time for developers to refine and work on. This dynamic remained as such for most of the project.

We managed to keep the pace mostly, with IIRC at one instance a sprint to delay development-team to get some refactoring done and designers to catch up. Although, with everything going on at the same time: requirements, analysis, architecture, designs, UX/UI, Main Application infrastructure-contributions, etc. there was always a lot to take into account.

To actually “getting the team along” meant to spend every moment to update them to the state of the preparations, getting them started with the JavaFX UI framework (as I had some experience from first team and they hadn’t any yet, see next section), slowly getting basic structure up for the application, aligning the plans with UX and the format of the UI framework and the ideas behind that UI framework. So, to a significant extent, this was about providing lots of new information from various parties, teams and stakeholders.

I get criticized for “doing it all by myself”, which is a very malicious way of representing a complicated situation with little to no time or room for “organization preparation”. We started off going with the flow and gathering information on plans and timelines, and slowly transitioned into concrete information, designs and plans for the team to work with. This process was mostly organic because three teams had to be (more or less) in sync. We, i.e. team seniors, essentially just did this together and offered the work as soon as it was concrete enough to be handled by the team members. For both teams (Litho InSight team was to a lesser extent involved in certain stages) and team architect, there was essentially equal representation: 1 person each. It’s as simple as that.

Presentation with JavaFX key practices

Early on, during project initiation, we knew we would need to start developing in JavaFX UI framework. The UX plans and the Main Application’s UI framework also built upon JavaFX. Given my experience with JavaFX in the first team, I compiled a list of best-practices, code samples and outlines for use by the team, as to benefit from the useful mechanisms specific to JavaFX. For example, (advanced) controls bindings to have very responsive UI interactions with reduced and more “functionally-natured” code, that define links of various kinds between controls such that JavaFX (implicitly) propagates changes by itself. This would allow for more detailed and more complete responsiveness than writing “UI control update logic” yourself, while being generally easier to express, at least for most bindings.

The presentation was a short introduction to key differences, these kinds of specifics, code-structure that we could benefit from, and the MVVM design paradigm for how to separate state and view. The latter was necessary because bindings would immediately propagate changes, so a separate state for “desirable values” actionable by the rest of the application logic, would be necessary.

I don’t remember the exact details of this. Essentially, it boiled down to this, because we would want to carefully guard valid vs. invalid values, while not interfering with the framework’s bindings and propagation mechanisms.

I later got some off-hand comment from the then PO that I should/could make an example case to demonstrate this. I mentioned that it might be useful if I had the time to work on this. Considering the insane amount of preparation, requirements, analysis and design necessary, there wasn’t time for this. We ended up setting up the basics as we went along, as the desktop application got its first work in.

Team opposition and addition of senior developer

In repeated conversations with my group lead, I had discussed team opposition. Initially, refusing to transfer knowledge on the metrology (sub)domain and challenging me on my supposed “lack of knowledge”, later in ignoring or dismissing agreements and providing little or unclear progress information. It was essentially becoming a split between developers and me, where I’m for a large part involved in requirements, architecture and design activities by necessity because no work would otherwise have been prepared for the team to pick up.

Very early team opposition and loss of team’s more senior developer, had resulted in a situation where there wasn’t an obvious candidate to take up this role with me, and (as mentioned before) I am not sure whether that would have solved anything. Regardless, clearly this would have been a “mitigation” anyways, because the fact that other team members are all from the same consulting company and have several interests to oppose me, made for the core problem.

I had discussed with group lead that my role (possibly my approach) should be clarified such that that arguments in direction of “he does it so he can benefit personally” are dispelled. I also mentioned that this situation results in a severe imbalance in the team when discussions or conflicts or conflict resolution are concerned. He chose to add another team member, similarly a senior.

The fact that, he acknowledges somewhat mockingly that “they wanted a senior but didn’t expect the seniority that comes with” (while explicitly and by necessity pushing me into this position) but then did nothing for a significant period of time while we all knew this caused friction, bothers me in this. I was supposed to solve the problems he caused while being thrown into a high-priority situation. To my understanding, he essentially acknowledges that the (developers) team members themselves and their attitude are the problem. He doesn’t improve on team members accepting me/my role, and makes a clear attempt to solve it with a mitigation. (Conflicts would, obviously, not resolve themselves so these would continue.)

Regardless of how you look at it, the solution was chosen to introduce a new (non-Romanian) senior developer in the team. He would not initially focus on exactly the same work as I did, but instead focus somewhat more on development. (This was also out of practical consideration, given the amount of preparation work to be done and him needing to be updated on a larger scope.) He would, in a way, be my dual on the side of development. I’m not sure if we officially agreed, but I think there was a mutual understanding for him to be a sparring partner, as needed. Immediately during introduction, I also updated him on the conflicts and team circumstances, and that ideally he would simply be an neutral team member that could help to balance conflicts in whichever way is fair. I.e. I don’t need to be right, but I need impartial judgement in a team that otherwise consists of developers that have shown to take an oppositional stance by default.

Note that I strongly suspect that his actions were an attempt to prove that “I’m the asshole” by having another senior join and expecting me to start making problems “because competition”.

The problem with being reasonable in a dev-team that has already decided to oppose you, is that you keep giving and they will never give back. I’ll be “the bad guy” regardless, either because “I need to be right” when I’m right or because they were proved right, and any time I acknowledge them, however little, can be used as an excuse to point to me being wrong.

Only some time after the other senior had joined the team, did group lead finally give in and send a message to explain the circumstances and that my role/position was reasonable and to be expected given the circumstances. Essentially just acknowledging the role/position I was put in. (To my understanding not at all an unreasonble request.) In my opinion, many months too late.

UI Framework and UX involvement

The story UX Trojan horse goes into more detail regarding the role of the UX team member itself. I won’t go into detail here on this topic.

The “Main Application” team was collaborating with UX competence on this vision for a guided UI flow. “Main Application” had done their first preparations for the UI components and intended to work on them further during implementation. Similarly, UX team member intended to define the more precise interactions such that “Main Application” team could work on those. As mentioned earlier, the team worked with us on this project, because this project was: new development work, a stand-alone enabler, that was perfect to adopt the UX vision and UI Framework from the start.

During the various meetings, UX team member always proved a little bit too eager. Including going into and extending discussions to try and get more out of it. As mentioned, this was mostly cut short whenever it became unreasonable, because of the two ASML seniors with significant experience. My contribution in this was rather limited, but also not at all necessary. Meetings did prove rather productive, because they were kept in line. I do not believe anyone in these meetings acted with the intent to short-circuit or exclude UX. UX simply needed to be kept in check. I think this matches my other impressions and, unfortunately, it is their intended strategy to just keep asking and keep pushing relentlessly in whichever way possible, including deception and manipulation. (More comments on this in the UX story.)

Late addition of another dev for Main Application team

As the project progressed, we got into more stable waters concerning the timelines, requirements and designs. The work still needs to be done, but things are becoming more clear, more concrete and therefore more predictable.

The “Main Application” team acquires another (developer) team member. Someone that incidentally carries the same first name as the group lead. He was somewhat older, more mature, and also positioned and acted like it to the benefit of all. With circumstances becoming less chaotic, there was room to integrate new team members, without sacrificing too much time to overhead for helping the new team member integrate.

I mentioned the earlier oppositional stance of Romanian team members. Although he is also Romanian and from the same consulting company, I noticed that his attitude became more considerate fairly quickly. I suspect this is simply due to him observing early interactions and not finding me unreasonble.

I won’t say much about this new addition, because for the remaining time of the high-prio project, his involvement was not my immediate concern (or problem). Some initial opposition I’ve noticed in his personal stance toward me was to be expected, given that I already knew this oppositional attitude was infectious. I think, in this respect, he was fairly mild in attitude and was likely evaluating circumstances for himself. Consequently, there were plenty of other technical and organization problems for me to be concerned with.

Project completion

Ultimately, with very little delay and completely within reason for a project of this size and with this sudden switch in priority, we completed the work. Delivered a functioning tool including the newly envisioned UX design, and integrated and further developed UI Framework. Results were sufficiently successful to warrant a celebration in the downstairs public office-building restaurant with everyone involved, meaning that there were some 40+ people.

Switching teams with Main Application senior

I think it was during this collaboration that the other senior noticed he was more interested in the side of development that included a strong component of ASML’s functional (sub)domains. He mentioned, after the project, as he clearly was aware I was struggling in the team, whether I would consider switching teams. He had, most likely, also noticed that I had recognized concerns of Main Application’s infrastructure on several occasions. Thus it would be a win-win scenario for both, easily arranged and would solve most (if not all) problems. He spent a few meetings with me over the course of weeks to do some knowledge transfer, or rather “plans and vision” transfer. I, in my turn, had little knowledge to transfer as we had both been active on the same project for the same span of time in similar capacity.

This led us to swap teams, concluding my time in the second team at the conclusion of this project, and transitioning into the third team “Main Application”-team around (roughly) the second year at ASML.

Attacks

I was attacked for several years over supposed “promises to make a UI”, referring to the JavaFX instructional presentation that outlined proper use of key JavaFX concepts. This presentation was, first and foremost, based on practical, first-hand experience from me and the UX developer of the first team. The several years of persistent harassment was completely unnecessary and simply misrepresented framing of a conversation, and with extreme likelihood deliberate malicious framing.

I was attacked, mostly afterwards given the backstabbing attitude of some of the team members, that I was doing things “for myself”, “to improve my own standing”, … I don’t even feel like listing all the variations and permutations. Essentially anything you can think of, was made up to attack me over. In actuality, I was working according to the pre-aligned way to get started with the high-priority project and the team kept proving themselves very untrustworthy (and some of the team members had already done so in the past on several occasions) so it was hard to include anyone in the process. Furthermore, including anyone in the process wasn’t originally the plan as proposed at project start, because we had to act fast and having (many more) people involved in requirements, analysis and high-level designs would only serve to delay and frustrate the process. Furthermore, they kept proving untrustworthy by actively withholding information I needed to learn the (sub)domain and challenging me in (large) meetings.

I later got attacked for 6+ years over just any combination of facts they could think up to maliciously misrepresent the circumstances and use as attacks. This is a constant, persistent, repeating flow of lies and false accusations. Then, after 6 or so years, there was this awkward “conclusion” that .. “oh, well, if you had stayed in the team after 9 or so months of conflicts, we might have corrected all the false accusations.” This is not how things work. They’ve essentially let a bunch of psychopathic liars make up any and all attacks which were then blindly believed as truth, even to the extent that me trying to elaborate the situation was not believed. I got attacked on these matters during job interviews, on the internet on social media and for some specific serious accusations even by aptly timed news articles that would pop into view on the news feeds. Similarly, in my local town I got attacked on multitudes of false accusations with no explanation, no clarification, with almost no ability for me to understand why suddenly so many people attacked me. Essentially, this is punishing someone for transitioning away from an abusive situation, where fuck-up group lead and team members are all knowingly working on this despite me indicating circumstances are otherwise. Allowing people to just pose any lie or false accusation, means that you assume “guilt-by-default” until I can painstakingly, repeatedly dispell all of it. It also means you can generate a near-infinite number of lies and false accusations for me to have to dispell or disprove.

Several attacks afterwards concerned bad registration of work-time. This was false. There were a few instances where I stayed for a bit longer, and if not spending time on ASML concerns, I would correct this on the timesheets. If anything, I had correct amounts downwards, to the benefit of ASML. (Even if they didn’t deserve it.) Again, these things do not have a basis in truth. They simply provided an opportunity, that was repeatedly malicious abused to attack.

When these false accusations get thrown in one’s face for 6+ years for just any permutation of facts, you notice a pattern. The “excuse” of “he recognized it therefore it must be true” does not hold if it is an inescapable reality of obsessed people relentlessly attacking. Furthermore, there is a difference between identifying and recognizing, and actually having done such action. I can recognize what they’re “hinting at” (actually too mild to represent the truth) without it being the reality, i.e. having partaken in it.

Got “criticized” by own employer on several occasions, because in 2nd team there were the occasional last-minute on-the-fly standing meetings to align on the day’s events. On some occasion(s) as late as 17:15 (5:15 PM, as I already was getting ready to leave), so I would have had to delay departure and in case of meetings at the company, I would arrive somewhat late. This was likely also maliciously misinterpreted, like so many things were.

Changelog

This article will receive updates, if necessary.

• 2025-04-03 Initial version.