Harassment: ASML, near-shoring "productivity" hacks

Thu, Nov 27, 2025 ❝Harassment concerning near-shoring "productivity" hacks and tax-related restrictions❞

Contents

This post describes the organizational and abusive shitshow at ASML concerning the near-shoring hires that were originally loaded up in droves, initially to work at a Dutch ASML location, and later also for 50%-50% remote work.

Way of working

Let’s first go through some considerations with regard to the way-of-working when remote teams or remotely located people are involved. This was roughly the way-of-working in our case. Most of it should be obvious. Essentially, we’re working with and around the restrictions that are imposed by circumstances of having team-members in remote locations. In this case, specifically the near-shoring country of origin.

These arrangements are (apparently) such that there is up to ~50% of time available for working from NL, without there being “additional obligations” required by Dutch taxation. Please read the phrase “additional obligations” as deliberately vague, because this information is acquired through person-to-person conversations, without me having looked up every little detail and fact.

Whenever it concerns team-members at a remote location, alignment would primarily go through digital means: daily stand-ups, reviews and retrospectives via video-calls. Work-related alignment, information gathering and processing and progress indications would go through various tools such as issue-tracking, code-repository, CI/CD, code-reviewing tools, etc. Some attempts at medium-term planning, to the extent enabled by business, could be done in issues (stories and epics). And when specifics need to be discussed, one would make a video-call. High-level and functional knowledge would be recorded in wiki and collaboration tooling, such that we created a knowledge-base for the team’s concerns.

The team would need to take into account that there are remotely located members, such that more of the communication and interaction would need to go through digital systems, as opposed to casual conversation. When it concerns (high-level) requirements gathering, more time is spent documenting issue-descriptions, such that team-members can work from the issues without them requiring extensive in-person clarification.

Legitimacy of complaints pro-actively destroyed

The events are more elaborately described in Group lead team composition fuck-up. In short, the group lead, who originated from same country as near-shoring hires but was in employment of ASML for a significantly longer period of time, insists on creating an all-foreign dev-team, going against several recommendations from ASML personnel. Fast-foward about 6 months. (To be clear, I do not have the exact timespan in mind because it happened near my start and was one of these events outside of my own team before I had sufficient awareness and understanding of the many happenings within the department. It might also have been 5 or 8 months.) The team is performing far below expectations, and has gotten to be known as “problem-team”.

Group lead has a problem to fix. He has a badly performing team (of his own creation) and there are several notes of criticism concerning the way the team operates. These are the criticisms as they were initially explained to me: there is little transparency because they mostly speak their native language. Deliveries are slow. They lack seniority that is needed for certain inter-team interaction and alignment, and for the larger design or (small-scale) architecture arise. On top of that, the most senior developer is moving out of the team.

Note that this first attempt immediately proved that it would not be so easy to scale up department growth through mindlessly loading up on near-shoring hires.

From the start, it was also noted that in part ASML would be able to operate as well as it did through its company culture of conversations and alignment. However, with the fast growth and near-shoring hires only being at most 50% of time in NL, this culture could not properly disseminate. Presumably, culture in the near-shoring country of origin is also counter-productive in this matter.

Team adapting to remote circumstances

With a significant number of team-members now foreign and some working remotely, the team needed to adopt a more flexible way of working. The most prominent of which is the later starting times and stand-ups.

Now, it is important to point out the other matter that is the vague and undefined role of “team architect”. I put effort in filling that role in such a way that it minimizes interference with software-engineers. The “team architect” role itself is relatively minor, as concerns are almost immediately domain of software architects, infrastructure architects or enterprise architects.

As early as during the first team, I have advocated, also in alignment with SCRUM principles, to allow teams some agency and self-sufficiency. This agency would allow a team to work as a team, and adapt to changing circumstances and demands. With that, the team would also need to be allowed to push back against unrealistic or unnecessary demands.

For me, personally, adapting to remote team-members meant shifting my starting time to later in the morning. Starting late was the more beneficial choice given local traffic and some stakeholders could be found late in the day and stand-up and other team meetings would be late as well. Furthermore, whenever applicable, I would put in extensive effort to try and have issues well described and to have investigations or progress documented. That is, one can no longer assume a casual conversation suffices to update team-members, or rely on casual conversation for necessary information to disseminate.

For the team, or alternatively all of its team-members, we had to migrate to using more digital means and consequently also reliance on those means. Availability of software was not an immediate problem. However, there is a convenience and flexibility in taking a marker and drawing something on a whiteboard, and for that new solutions were needed. Thus also a need to discover a way of working that works well with remote team-members. There needs to be more of a habit of describing information in issues, such that information is available digitally and/or accessible remotely. A key distinguisher is that local team-members might have picked up on discussions and know to find information, while remote team-members would have not been able to acquire any knowledge. So unless informed by local team-members, they are (metaphorically) “blind” to this (awareness/existence of) information. Meetings require more alignment, and for remote viewers to make requests for physical actions to be performed at NL location as part of the meeting.

Mindmapping with hyperlinks

Without going into too much detail, there is an unconventional approach I want to describe. I got attacked on several occasions over my use of mindmaps. Considering that we needed to take into account remote team-members and would need to rely on and ensure sufficiently well-described issues, I had tried using mindmaps for initial information gathering and for creating the overview of related and dependent issues. Then, for each element in the mindmap, create issues whether Epic or Story, and link to it in the mindmap.

Even though this may be “childishly primitive” as requirements gathering, architecture tooling and methodology, it gave me the possibility to create a high-level overview with direct links to corresponding issues, which I was expected to richly describe such that remote team-members would have all the necessary information available. The mindmap would help to gather initial information, and to give a complete overview with dependencies and such, while not containing actionable information itself. An export as SVG-file allowed for easy communication and interactivity. Mindmapping-tools are a fast and efficient way of structuring information initially, and gathering thoughts.

2nd Team: failure writing a recipe

note I realized weeks after writing this post (and the one before that) that I never documented the event about a programming mistake that caused a bug. This wasn’t intended as a way to obscure information. That would have been pointless, as I already documented this event more concisely in early X/Twitter posts, a mild early attempt that I had hoped would silence, or at least signal, the – at that point already 5 year long – persistent, on-going abuse. When I decided more elaborate effort was needed, in part because my tweets got censored by “technical failures” and the harassment and abuse continued, I had forgotten it among the massive amounts of stuff that needed documenting.

note I will make a key assumption here, that the video-stream interruptions that suddenly started happening, are due to fuck-up that happened here, as described. I posted about this earlier to allow for verification/correction. (That, frankly, I did not expect to happen.)

Given the nature of the malicious abusive shitshow at #ASML, I will assume for my next story that the video stream interruptions are on purpose, orchestrated by the management shitshow at #ASML because a bunch of Romanian scumbags falsely blamed me for their fuck-ups. This perfectly matches the abusive way in which the #ASML cult tried to retaliate for the incompetent team architect organizational shitshow of 1st team.

Let me know if in reality this is a bad assumption on my part.

Concerning the above, I have had to deal with, by now, about a decade of organized harassment and abuse, and I am literally still struggling trying to figure out why I am under constant attack in this massive shitshow, because there simply has not been proper communication in any way. I am literally under constant attack for matters I have no knowledge of, did not do wrong, or did not do.

note if the message does not sound very professional, it is because at the point of writing there were already 5+ years of ongoing constant harassment and abuse, with constant callbacks to those situations, attacks, false accusations, lies, and whatever else there was to unjustly attack me over. There is clearly malicious intent involved.

For context on this subject, I describe organizational circumstances and the project itself. For the next subject, the project is, roughly speaking, past the half-way point. The work is starting to come together in more than its barest incarnation, and a next test is scheduled with the customer. If my memory serves, this was not the first time a test had been scheduled at the customer.

The concept

For convenience, I’ll summarize the idea of the project briefly. As previously mentioned, I am writing this from memory, so someone with intiminate knowledge will probably discover inaccuracies. For the story, it should be precise enough. Actually, as I’m writing this, I’m wondering whether the metrology recipe (wafer measurement) or the scanner recipe (wafer fabrication) was generated at this exact point, as it has been a while.

As explained in previous posts, but I’ll summarize for convenience: the recipe is intended to instruct a (very complicated) machine how to perform its task. This project was about a specially crafted recipe with finely-tuned but predictable outcomes, as opposed to the standard mechanisms already available. The project’s purpose was to then make use of these predictable outcomes for further tuning and improvement.

The bug and lead-up

Now, the nature of the bug was such that at one point during a subsequent test at the customer, the software had generally worked but produced a failure while writing the contents of such a generated recipe to file. However, somewhere along the code-path, in the function call hiearchy, an exception was incorrectly caught and silenced. Consequently, when the recipe-file failed to be written, there was no indication of failure. Furthermore, apparently – I was not present during the test and have not heard more than a brief, incomplete explanation that was itself an interruption of an ongoing conversation with the scrum master – a file already existed. Therefore, the recipe did not contain the expected data, or something alike. I presume they subsequently continued the test based on an incorrect assumption that a suitable recipe was written to the file, i.e. available in the existing file.

For this incident to happen, there must likely also have been failure to detect said issue in the following steps prior:

• The issue was not noticed/recognized during development and reviews.
• The issue was not detected during individual testing by developers.
  • Unless the issue was introduced by the most recent changes, it would likely have been detected by other developers unexpectedly running into failures on such a critical path, even as they are testing their own work.
• There was apparently no, insufficient or incorrect testing prior to the scheduled testing/evaluation event at the customer.
• Bad practices during scheduled testing/evaluation at customer, by overwriting an existing file. If all logging and error-handling had failed, one would at least discover that no file was created.
• Lack of care during testing/evaluation, as it is very likely possible and regularly done, to manually inspect resulting file(s) to ensure that the content is as expected. The files involved are XML-files, meaning that they are text-based and thus readable (to some extent). Given the nature of the project, I would expect to observe some regular repeating patterns. It should be possible to recognize and observe the same patterns, especially with intimate knowledge of the project itself. Alternatively, it should be possible to derive which values to look for with a bit of educated guessing.

  Actually, I have opened similar files to highlight important values myself in previous sprint-reviews. Given its highly technical nature, it is not uncommon to do this, as there would be highly technical stakeholders anyways.

• The application in development exists to produce special-purpose files for a well-known existing format. There already exist tools for general handling of such files. It would likely be possible to use these tools to inspect the created files.
  Or, if I phrase this more defensively: I cannot think of any reason why absolutely the only option to discover that anything is wrong with this file’s contents, is through use of the hardware itself.

  Possibly – and I’m speculating rather than working from memory on known information on the incident – old and new contents would have been similar therefore making detection harder. However, this would also be a strong indicator to take extra care and not overwrite an existing file.

comment to illustrate, I have not received sufficient information to know whether there was even a trace in the application’s logging. I could have done a full investigation myself, but I did not know that this was a big issue in the first place. The whole project had other pressing concerns and deadlines, as had the team itself. By the time I was informed, it was known what had caused the problem and what would be needed to be done to solve it.

All I know, is that which I was told in the short interruption of an ongoing conversation with the scrum master. If this whole incident is a complete fabrication, I do not know and cannot look this up. However, that means I was maliciously, or maybe ‘opportunistically’ is the better word, misinformed in the moment and it means that I am subsequently being attacked for years over yet more lies. However, to my knowledge, this incident did truly happen.

For the record: I did not create this meme. And, given the nature of the ongoing harassment, it is highly unlikely someone made this just for malicious intent. Or, rather, made this as a way of exposing the truth at a suitable moment.

“Productivity” hacks

Notice the use of quotes?

Remote work is “always problematic” in all kinds of ways, resulting in:

• little/slow progress;
• lack of information; and
• less incentive to align, leading to more missing information, more mistakes and/or mistakes discovered later in the process;
• problems, disruptions or interference;
• reluctance to communicate and/or share information;
• somehow information also hard to acquire, even though any remote team-member could check with and ask local team-member to help if needed;
• on many occasions, knowledge is present just not always (clearly) documented;
• there is always a “need to be in NL” (most likely for monetary reasons);
• at remote location “everyone starting late”, so only in the office around 9:30 NL time (UTC+1), which would be around 10:30 remote time (UTC+2).
  We had our stand-up around 9:45 NL time, and even then some would occasionally be late.
• “lack of motivation” or “feeling alone” when only one or two team-members at remote location, and less ability to interact and help each-other.
• near-shoring company culture is sometimes not conducive to cooperation or even openly competitive, such that team-members will avoid each-other at remote location.
• naturally occurring stumbling blocks, such as something being unclear, missing information, or a need for knowledge or assistance on a certain matter, would become reasons to delay or otherwise for productivity to slow down.
• toxicity, where picking fights and endless discussions and false accusations and lies are used to distract from badly performing team.

  note I don’t argue against asking questions or criticizing solutions. It is the unreasonable attacks and subsequent unwillingness to actually discuss matters. For example, ranting about 10+ supposed points of criticism but unwilling to discuss them one-by-one and evaluate their validity and/or their (mis)understanding and/or reasons/rationale.

• in general, there is a toxic maliciousness in trying to shift blame, which is especially sad in second team which already proved severely lacking before I joined.
• messy SCRUM-process: in particular stand-ups, where one would go into details; and reviews/retrospectives being interrupted by remote viewers running into difficulty or having a hard time following along.
• In case of unreliable connection during video-calls: there would be occasional deliberate interruption to check if remote location is still present, due to high likelihood of interruptions, which would occasionally be “silent” screen-/video-freezes.

Furthermore, as was already an issue in the first all-near-shoring hires team, there is a high incentive to speak in their native tongue, thus making team interaction highly intransparent.

Progress of the tasks picked up at remote location, are not easily tracked. This is made more difficult whenever problems occur or there are questions or there are matters that warrant further investigation. One can only discuss so much in a stand-up. Furthermore, there is an aversion to having an open communication channel (video-call), due to abusive practices such as the ones that come to light nowadays, where video-calls are used to track employees. This violation of trust means that convenient ways of communication get rejected and, willingly or otherwise, progress is affected as a result, but likely also dissemination of the company culture, feeling of connectness with the team and the ability and motivation to engage in (intra-team) cooperation.

“Only 6 months per year, and only short periods at a time, in NL due to tax-restrictions”, is a common discussion topic. Even if it is understandable that circumstances surrounding assignments in NL are more favorable, this does not mean that anything else needs to be problematic by default. Similarly, there is extensive planning of trips back and forth.

There seems to be an unreasonable need to not make mistakes, or to “off-load” mistakes onto other people, such that they put themselves in a favorable light. It seems very likely, that this is due to clear and obvious benefits of transferring into employment of their customer, i.e. ASML.

Tax-related restrictions and concerns

There are several tax-related restrictions and concerns that require that hires plan carefully to avoid crossing this threshold. That is, there is clear incentive (not all selfish) to spend as much time at NL offices as possible, yet it requires that they plan carefully to avoid getting into trouble.

There are the special occasions, such as large-scale meetings, team outings, and introductions to sizable new projects that benefit greatly from local presence. However, it also means that whenever at remote location, productivity lowers significantly, and whenever in NL office, nearing end of stay, time is spent planning the trip and trying to align on beneficial options for next return, as well as traveling that usually happens during the day so it also takes up time. These are all costs that are incurred as expenses, time or productivity. Then there are cases where a legislative treshold was crossed or about to be crossed, and there needs to be planning to correct for this.

Microsoft Teams video-call interruptions

note For context, there was significantly more trouble with video-calls and other connections during time of third team, i.e. ~3rd year, although issues already started during the 1st team/year. 2nd Team was largely colocated in NL due to being on the project’s critical path.

Most common variants of issues were present at one time or another.

• Issues trying to establish call, not sure at which end of connection, or network itself.
• Sudden call/connection drops, causing immediate interruption of an ongoing meeting in order to re-establish connection.
• Establish connection, then discover either video or audio was not properly connected/routed.
• “Silent” video-call freezes or software freezes.
• Eventual “silent” drop of audio or video, possibly due to interference on the connection. Either one side was silently cut off. This was sometimes discovered late, so would suddenly require interruption to re-establish connection, or discover by means of uncomfortable silence instead of a response that communication was no longer working properly.

note I am assuming no bad intent here. If there was malicious intent at play, it only testifies more to the untrustworthiness of near-shoring company, even if targeted specifically at me.

Inability to establish a connection is particularly problematic for the small 15-minute stand-up calls, because any start-up problems or interruptions immediately eat up valuable time. Especially, in cases where the SCRUM stand-up process is not well established and consequently too much time and/or too much detail is used in a person’s contribution.

On several occasions, the group lead (Romanian by origin) would attempt to diagnose the problems by traveling to Romania and evaluate the connection on their end. I do not recall that he found any concrete issues that were resolved. At one point, the idea was introduced to improve sound quality by using a higher quality microphone-array. This was particularly applicable for larger meetings with many participants. Otherwise, we would have to suffice with the machine on which the video-call is established. However, improving the microphone itself does not magically resolve connection issues.

note I had, on several occasions, already as early as in 1st team, considered setting up a Jitsi Meet instance. However, I never got to it:

1. I expected significant reluctance in adopting the solution, given the environment, previous amount of political discussion to eventually dismiss ideas, and reluctance to dedicate any amount of time to setting up a test-environment.
2. Given earlier problematic relations with STI which was also later followed with suspicious comments resembling threats. And even if STI wouldn’t be the final department to be involved in setting up the eventual solution, they would likely have been the ones initially involved, given that our department is focused on software development.
3. Hesitancy on my side, because it should not be a problem I should be spending my time solving in the first place. Especially, considering this is a general video-call solution, and the issues are of a mainstream operational nature.

I considered Jitsi Meet (only) because video-calls using Microsoft Teams proved to be a constant pain-in-the-ass.

Legitimate drawbacks

Now, I can imagine there are some legitimate drawbacks. Having some experience working from a local office or from home a few times, is sufficient to notice that circumstances are different when not colocated with team-members and stakeholders at an office.

For one, awareness of always receiving information late or having to unnecessarily “hunt” for information even within the team, can be demotivating. Both more seniority and for the team to organize in consideration with such circumstances, will help to handle this better. For example, actively selecting tasks that are well-documented, relatively independent, isolated or self-sustaining. Or, tasks that require some analysis or investigation such that you have the opportunity to (re)construct the context as well. These allow you to create your own overview instead of a shallow, narrow single (sub)task-minded view. Thus allows you to have more control and/or independence. Another example, is to do preparation and specification in a way that tasks are properly, more completely documented, instead of relying on locally discussed knowledge. Similarly, spending effort to document known knowledge instead of assuming it will always live in some team-member’s head. None of these efforts are meaningless by themselves, but they provide extra benefit in these scenarios.

With prolonged time at remote location, there can be a feeling of disconnectedness, in particular w.r.t. the rest of the team. This is not being helped by competitive circumstances despite the same customer/team/project, and particularly if culture at the remote location is such. Furthermore, with the disconnectness there is less ad-hoc interaction, social interaction with the team in general, thus also no natural dissemination of relevant information. Dissemination is much more of a planned effort, and if only one or two team-members are at the remote location, is easy to forget or delay. If this happens regularly, it naturally induces a feeling of being left out while at the remote location, even if there is no ill intent. And, in general, when not with other colleagues, the remote location might not be very inspiring, at least considering specifics of a particular customer. Possibly this feeling is reduced if issues are better documented, as there is at least proper information to get started and interaction can happen on an ad-hoc basis when looking for more specific information.

There were early concerns about losing company culture within the teams, with rapidly scaling up a department and then also near-sharing activity which would result in 50% less direct contact. The second team contained mostly more recent additions, thus unfamiliar with the culture and also from a foreign country therefore used to a different culture altogether.

Attacks afterwards

These are some of the relevant threats of the many, many, many attacks I have had to deal with afterwards.

• I am attacked for 6+ years over supposedly having caused this bug, with massive harassment as a “solution”.
• I am attacked over lies fabricated within the team to villify me.
• Obvious contradiction: first management needs this team to get back on track and puts the team on the critical path, simultaneously. Then somehow I suddenly get blamed for all mistakes and failures. And nobody thinks twice about how contradictory this is, or decides to do the proper investigation, even though ASML proclaims to execute ‘asking 5 times “Why?”’ (Or some number along those lines.)
• Attacks concerning “my supposed promotion” which was not a promotion. I was simply asked to switch teams, supposedly because of the “problem-team” (as claimed by several managers) and possibly because of discussions. That is blatantly abused to excuse, with no basis in reality, malicious behavior of several team-members.
• Threats, concerning nonsense excuses with malicious intent:
  • Meetings with my employer afterwards, i.e. in evenings:
    • Harassment and threats that (incorrectly) imply “illegal” work, including various forms of harassment over discussion and presentation topics such as Apache Kafka, Tor and various topics concerning Java.
    • Attacks over asking critical questions whenever I thought something was missing in my understanding,
    • “Bad priorities”
  • Minor (unrelated) system administration, almost completely transferred at this point.
  • Attacks concerning “responsibility” of the incident (previous section):
    • Suddenly SCRUM-process forgotten: this “little detail” that a team as a whole has responsibility for its results. There is an unreasonable, persistent need to blame me and claim “responsibility” which is actually just long-term harassment based on bad excuses.
    • Group lead was very explicit in that it did not involve a promotion, and was also extremely reluctant to show support, and was of course also the cause of the troublesome team in the first place.
    • There was never an investigation, never questions asked.
    • I was by far the least likely candidate for the bug, as documented in this post, as I was mostly completely swamped in preparatory work in requirements analysis and designs and related documentation.
    • No elaboration on the matter. No prior warning. Deceptive comments. Threats.
    • The comment in the meme later disclosed that another team-member was the cause for the bug.
    • Massive harassment and attacks with no prior warning or explanation, even though the project concluded as a success and within reasonable bounds of time.
  • Attacks concerning asking critical questions and providing critical feedback. (NOTE: yes, every sick excuse was abused for blatant repeated constant attacks.)
• My suggestion of opening up a video-call for a while to have a more social connection with local team-members in case of questions, discussion, unclarity, isolation, etc. was later attacked en-masse as “spying on people at remote location”. Of course, their complaining was VERY REAL and very prevalent. As also pointed out, there is no obligation and both parties are perfectly in control of the connection and can disconnect whenever needed.
• During later harassment there were comments hinting at 2nd team people fabricated a whole lot of lies, and because I switched teams after the project, I hadn’t “proved the fabricated lies and accusations to be false”. If these are excuses for sabotaging the video-calls during 3rd team’s meetings, then this is an even more questionable situation. Especially, considering how 2nd team was already known as “problem-team”, according to managers, from before me joining that team.
• There were later attempts at attacking concerning video-calling interruptions. I suspect that those were intended with the mistaken impression that I was tasked with setting up the video-calling solution. However, as software-engineer, setting up a generic existing video-calling solution isn’t part of my work. (And I wasn’t tasked with it either.)
• Furthermore, I was also attacked over being involved in too many concerns, so taking on the video-calling set-up would be yet one more. (And, to note, I wasn’t involved in too many things, but did touch on quite a few different ones in those three years.)
• There seem to have been attacks concerning setting up a Jitsi Meet instance for other purposes than within ASML. I have not discussed such plans. If anyone claims that I failed to set up such a video-calling infrastructure, then they lied. If there was such a claim concerning OTRv4, which was strictly a personal project, you got deceived. Communication and contribution to OTRv4, happened via Github issues, as I was primarily focused on otr4j as a personal project. (I comment on this unrelated topic, because I strongly suspect there was such deception going on.)
• As of moment of writing this, harassment and abusive practices are still on-going. There is a concerted effort to (try and) trigger events from stressful, abusive circumstances from the past, soon after having finished the assignment at ASML, even just this evening.

Changelog

This article will receive updates, if necessary.

• 2025-11-27 Initial version.