Harassment: ASML, 1st team: PO pushing features

Tue, Mar 18, 2025 ❝PO relentlessly pushes for new features, caring only for business prestige❞

Contents

important I did not want to finish this post. However, I keep being pushed into the same abusive process, over which I have no input, no control, no ability to verify or scrutinize. A process which interferes both locally, i.e. in my home town, and on the internet. Which abusive people time and again push me into without my constent, without acknowledgement, without checking. And that, the way it is presented to me, operates on mutually inconsistent and/or mutually exclusive rules, making it a never-ending process with no proper resolution. THIS CANNOT GO ON ANY LONGER. This post will be posted, hopefully the last, because even within an abusive inconsistent process they lied to justify continuing this, while I have VERY OFTEN, VERY EXPLICITLY indicated to stop. I believe I have been very patient with this going on for 6+ years while providing me with very little information – leaving me in the dark – and violating my rights all this time.

My patience is gone, both for such manipulative, coercive, tyrannical “processes” and threats. They, i.e. everyone involved, crossed a line when they put a helicopter in the air on multiple occasions, because I explained with good intentions, in good faith, to have worked with the licensing code, in the hopes of clarifying a misunderstanding. Actually, I touched on it in first team, but in the third team this part of the code-base was managed by my team. I have no idea why explaining this, would be interpreted as anything other than an explanation or clarification, especially given that I did not have any idea what was going on.

This “process” was initiated, clearly with bad intentions. The inconsistent, mutually contradicting, mutually exclusive rules only served to bring confusion. They also have some idiotic reason why “communication” is an issue, and apparently I am also not able to acquire direct (i.e. actionable) information about assumptions, conclusions, implications, (false) accusations, etc. I can only indirectly derive that this harassment has again restarted and/or is still continuing. This is going on for 6+ years with no clear information and has brought me so much misery.

Abstract

This is by far the largest post. Although centered around the PO pushing for new features, there are other side-tracks. These are usually a consequence of this constant push. It should become clear as the story progresses, how this push increased.

To understand this story, a bit of context is useful. My first team was also the team that maintained 2 of the oldest desktop applications of the department. These applications were developed in Swing, while soon after joining the decision was made to start developing in the JavaFX UI framework. Apart from a prototype-application that was developed soon after I joined, we built most applications in JavaFX. And as such, within this first team we had some time to establish the correct way to work with JavaFX. This would later become relevant in (preparing) the 2nd team.

To my knowledge, JavaFX was a logical next step. I am not sure when exactly this was determined, or how deliberate of a decision it was. I found it sensible next step at the time, though I am not aware who/when/where an initial decision was made.

Introduction in the team

There is not that much to say about the introduction into the team when I started at ASML. The introduction was okay. The team as it started out is fine. Early work, when I was not yet well-versed in the functional domain, included manual builds and releases, and in the mean time I helped many colleagues with the then freshly introduced git version control, such as with more complicated commands and clarification of confusions caused by in-progress merges and file-conflicts. I also helped on several occasions with parametric-type (generics) puzzles with 3-6 parameters given that these took some understanding to fix. To my knowledge, things started out going fine.

That’s as far as my limited experience of the early dynamics of the department allow me to judge. We’re talking weeks, maybe at most 2 months. It’s essentially that time-span where you are not even able to be fully productive due to insufficient knowledge and familiarity with the company, the functional domain and the technical subtleties.

There might have been a (false) accusation that I did not act on “apparent abusive situation” w.r.t. this early team member that burnt out. This is only true in the sense that I was new in the team and didn’t prominently put a stop to this. I did have the occasional conversation with her, asked her how she was doing. Usually, around an end of day when things quieted down. I occasionally encouraged her to slow down or take a break if it felt like it was needed. Until one day she no longer appeared. For a while, her user account was still present. I checked with the other developer that started a month or so earlier, he did not know anything more, other than assuming burn-out.

You cannot blame me for every imaginable action not taken, because there will always be virtually infinite actions not taken that can be twisted in whichever way to attack me over.

I apparently get attacked over more nonsense accusations that are taken wholely out of context, exagerated, maliciously twisted to attack me over. Just like everything else, they’re utter nonsense. I cannot even figure out in what sick ways people have been twisting facts and making up circumstances, in order to justify any of the false accusations. To some extent, I literally cannot explain it to you.

Prototype

There is a slight chance that “wafer-level control (WLC)” was not the name/goal of the prototype, and I’m mixing up names of ideas. For the purpose of the description, I’ll assume my memory serves me well. The purpose is merely illustrative to the story anyways.

So, I’m a few months in my assignment, in the first team and getting my bearings. I’m asked to (assist in) work on a prototype-application. I had to dig a bit, but if I remember correctly, this prototype was about wafer-level control, i.e. specific tunings that would fine-tune wafers by their index in linear order (also considering 2 wafer-stages). The idea being that earlier wafers would be impacted differently, such as through temperature, due to the process having “just” started. To my knowledge, with the intentions to implement a prototype for a specific use-case such that some idea can be tested with a customer. Although, at the time we had just started using JavaFX, this application was still built in Swing, such that we could reuse large chunks of the existing applications, sometimes a quarter of a screen or more of another application, in order to build the prototype quickly. (This isn’t as bad as it sounds, i.e. not criticism of the way-of-working. For a prototype, this is not an unreasonable approach to save time.)

This was organized through a subteam: a senior developer, me, and our “functional domain” contact.

As this initiative started, it was decided that I should help. That is, in the morning I arrive at work, at the team’s desks. The senior developer pulls me in, updates me, and tells me that we start working on this. Two other developers from my team later commented that I should have declined, because I passed someone over. The thing is: I didn’t “pass someone over”. I just got told to do this. If he was passed over, it’s by someone else’s decision. To my knowledge, the “passed over” developer later got another interesting assignment, so I do not see what the problem is/was. There was no deliberate action on my part. I was newest in the team, at that moment, and I just get told this information without having any further context, or proper understanding of the way of working in such cases.

As, at the time, I wasn’t at ASML for very long yet, I wasn’t that productive yet in the two (or so) weeks that we needed to implement the prototype, but we did do peer-programming. The vast majority of the problem is not being intimitely familiar with the custom in-house components. Most of which are elaborate domain-specific compositions, quite nicely constructed. The senior developer immediately knows which pieces to copy-paste, while I would be looking into their precise purpose first. Regardless, we managed to make it work in time. I was available several days and evenings after with the functional domain contact to finish up, fix bugs, and align with senior developer when he had arrived at the local office. Some days, ~22:00h to finish up in the final days for the experiment on-site by senior dev. Then security would (friendly) nudge us out. :-P

Follow-up for passed-over team member

The “passed over” team member got another assignment. He eventually left the team, not too long after having finished this prototype.

I’m not sure whether he or the two seniors were first to leave. So again, precise chronology might be off. It isn’t critical to the story.

We met, rather arbitrarily at some point, and he tells me that in his assignment there’s a need to select for a certain document-store. He mentions there are a few. I’m not sure whether he or I mention MongoDB first. He asks me what I think of it, so I explain that it has a good reputation, except there is one catch that developers aren’t always aware of: MongoDB by default is configured to not be guaranteed fault-tolerant when running a single server (instance). (This is in MongoDB v1 times.) So, either MongoDB has to be configured specifically for this use case, or multiple instances must be run. He asks me whether I would recommend it, so I explain to him: “I would consider it for evaluation”, i.e. add it to the list of candidates if you have one. I deliberately do not say that they should go with it.

However, there’s a catch. I heard previously from a colleague, a few weeks before joining ASML, that GridFS (which runs on MongoDB) was introduced. However, apparently not everyone is enthusiastic about MongoDB and they didn’t know GridFS is based on MongoDB. However, I knew there was some MongoDB present. My choice to say both: 1.) to consider it for evaluation in this investigative effort, and 2.) the well-known caveat of accidentally running a mis-configured single instance, was deliberate to help out but avoid stating a decision.

It is, of course, somewhat suspicious that it’s already running but not quite acknowledged, so there are pros and cons there.

Later, during the several years of constant avalanche of messages “incidentally showing up in my feeds”, there were also periods where they would push MongoDB topic. Whether for the initial choice or near the end the upgrade-difficulties. In neither situation, did I make the decision or phrase it as a decision. But I know these messages were deliberate.

Department is expanding

Now, as I wrote in other stories, there is talk of a need to expand the department more rapidly. We get informed that 2 Romanian developers join our team. The idea being, as is being explained, that with a few new people joining in various teams, each team can introduce them and teach them how ASML works, how projects are done, what the company culture is like, what important people and contacts are within the department and outside.

We try our best to convey the company culture to our new team members. We gradually introduce them to the applications we develop and maintain. We try to maintain a casual working relation that is conducive of cooperation, instead of all-out competition. There is a struggle that I saw in them, that I hadn’t experienced myself, with regards to the openness and ability to communicate about questions, lack of knowledge, etc. One could notice they are unsure of how far to go without being attacked for it.

At the time of writing, I wonder what the true company culture is, but I strongly suspect that it had been poisoned by the sudden influx of new people and the rapid growth of the department itself. Group leads originating somewhere else, many new developers and also existing developers that only experienced the culture in several-month periods of time, due to regulatory requirements to commute back to Romania.

After a while, the two senior developers move out of the team. Each have their own next step to make. This happened fairly close to the large project getting focus, that is being discussed in the next section. Close enough even, to have one of the developers inform me that this is going on and giving me a short introduction and pointing me towards a sensible starting-point for its preparation. The team holds their own quite reasonably.

Preparing for large project

Now, this is some time after the discussions with team “architect”. The two senior developers are leaving the team. One pulls me in, for a quick 10-minute update to explain that he heard the initial rumblings for an upcoming “larger” project. (With “larger” here, he/I mean that it takes considerable time and effort to prepare for.) He says I am the most likely developer to be able to pick this up. He also hints at the fact that I should just do this, as this is the easiest way to roll into the process and get preparations going.

Although I like the opportunity, I notice that the other developer, who started around the same time, notices there are things coming up, and pretty soon we’re both investigating. Instead of making this a competition, we pretty much worked together on this for the entire project. Which isn’t that surprising as we did cooperate well and we had different ambitions, for my part I saw it as an opportunity to tackle this together. In terms of scope, this concerns interaction and interoperability from Litho InSight server + desktop tools + file formats + some “TwinScan workstation”. Prepation easily took weeks and easily took several sprints. However, that’s getting ahead of ourselves w.r.t. the story.

Requirements and design

Now, this is where things started to get fun, both literally and figuratively. And, in hind-sight, this is likely where further back-stabbing took place.

We may not have approached this in the classic way, but we tried to be transparent and thorough and relatively efficient. Well, given that we were both relatively new to this and the circumstances. (At least I was, for my part.) Our team architect was absent for a few weeks. We contacted customer support contacts, functional domain contacts and enterprise architects ourselves as needed.

We used a whiteboard to outline the state of affairs, both with a situational representation in a schematic of all connecting components to illustrate where our concerns and focus are, who our stakeholders are, where interoperability (connections, file-formats) exist, and where unknowns existed. Furthermore, we indicated references to where concrete information could be found in epics/stories. We could also indicate the parts that needed alignment with other teams and/or were aligned. The stories, for their part, contained the factual information and clarifications. These were aimed to be sufficiently informative such that we, the dev-team, would be able to include them in the (scrum) refinement process.

Metaphorically speaking, this was an absolute beauty to behold. Obviously I’m partial, but we achieved a reasonable level of transparency for our team. We managed to capture sufficient information, as we went on to investigate the remaining unknowns and find further clarification necessary to detail each element. We could explain the high-level overview to anyone interested. Team members that were involved in the maintenance of our other applications, still had an easy way to follow along with the progress being made at least at a high level.

I think several team members were enthusiastic to be able to be part of the process, even if observing from a distance. I know, from several instances, that not all developers care for the high-level analysis and requirements aspects and this gave them an impression without them being unnecessarily bothered with the “tedious work”.

I later got attacked for passing by the team architect, contacting the enterprise architect directly. However, there was a period of time where the team architect was not available. We had sufficient information to contact other stakeholders as needed, as these were mostly already known as part of the over-all project information.

Back-stab by PO?

it is at this point, that it becomes more obvious that we had matters in control and we managed to make things work by ourselves. At that moment, the PO suddenly started to press me about removing the other developer from the preparation task. At the time, I was both surprised and shocked concerning this sudden change, and very clearly stated that this isn’t a preparation I can easily manage by myself. I also said that I would stop the preparation if he would take other developer away.

I hadn’t thought anything of it at the time, except that it was a “strange sudden move” as everything was going well, but it was most definitely a way of trying to interfere. On top of that, they likely tried to “prey” on my supposed “arrogance”, by trying to bait me into removing the developer and having me think that I could handle everything by myself, and consequently failing. However, as I then, without even a second thought, voiced strong protests he backed off. I remember mentioning that I didn’t have the bandwidth to handle all of this new information by myself. It would probably have been manageable if I was fully integrated in the functional (sub)domain, but I was there (probably) for only a little bit more than half a year (if already that), and you always touch on new areas.

Notice how this and also the absence of the team architect all just happen to align (or coincide?). Later on, when the team architect returned, he couldn’t really provide much value (anymore) as intermediary, given that we had already established recurrent contact with enterprise architects and customer support and other stakeholders as well as interoperating development teams. We already were “on top of it” as far as the preparation was concerned. The team architect, at that point, wasn’t caught up on affairs anyways.

Note that both me and the other developers each also had concerns in our own respective area, where I focused on more technical concerns, and the other developer on UX concerns. We managed to team up well and bring the project to favorable conclusion.

UX involvement, UI designs changing

This was (to be) a JavaFX application. Additionally, the first sightings of the UX competence showed by asking for UI with particular characteristics. The other developer who prepared the project with me, focused more on the UI/UX side of things, as I focused on more technical aspects. Even among us two, there was some discussion and some concern regarding the extent of UI demands, because these would have an extra penalty as we needed to develop the elementary UI controls as well as implement the application. I think we managed to make a good trade-off between making the new UI work and also maintaining feasibility (and keeping to our deadline). This wasn’t so much a matter of conflict, but rather a matter of much discussion, weighing concerns and questions.

The up-side to the UI controls, is that both he and some other developers could independently work on those controls, so they were easily taskable as long as there weren’t too frequent functional changes. It was also at this time, that the other developer started to explore the JavaFX specific intricacies that allowed for more efficient development and more responsive behavior (and less code). After this and later projects, some of us would capture these learnings in best practices. I later used those in the presentation for the second team. (For another story.)

As I got attacked significantly over UI/UX concerns, let me emphasize this very clearly: I have never been opposed to these matters. With the other developer, there was a very healthy conversation and discussion concerning these matters, but it was definitely not UX-gets-all or UX-gets-nothing. However, you cannot just make up a whole new paradigm (as far as application design goes) and expect all the time and resources in the world to realize your work. So there was give-and-take concerning UX matters. I think both ASML and UX competence should be very happy with what we did manage to establish as a team, because it functioned as a cornerstone for both the UI designs, as well as UI controls (software).

It is also worth mentioning that the tools developed, would sometimes require a level of expertise for use in production scenarios where several team members would question how much benefit there was to a guided UX “wrapping”, as opposed to a panel with controls. One could argue “power-users” wouldn’t always rejoice when a new UI forced them in a certain order or pattern of practice and it depends highly on whether the user of the tool would be a “power-user” that would use it or “just” any regular semiconductor engineer. This wasn’t used as an excuse to dismiss all UX proposals, but rather a reason to consider how much of and where a transformation was necessary.

Note that the PO attempting to interfere, was likely only in defense of team architect or possibly for his personal reasons, because we would only later discuss his disposition against software development. See later in this post.

TwinScan bug

As high-level overview was clear for a while and preparations were progressing, we were also planning parallel activities with the team and stakeholders. For example, we needed to get the first data from the TwinScan in order to make sure that all the data was there, was available under the right circumstances, and we also had samples to work with for software development.

Our work relied quite heavily upon some information that was present in a document, a TwinScan report, of the type ADELasla. However, under the specific circumstances which we were interested in, i.e. were required, the TwinScan would not produce that report. (Or maybe the document was produced but didn’t contain the right or insufficient data. I.e. the produced document wasn’t suitable.) The scrum master, being an ASML employee and definitely a few years senior to us, helped us track down the right people to contact. It turned out this was a bug. (That’s how we summarized it eventually. I think this is one of those circumstances where the report is simply not produced under those circumstances or the needed data wasn’t present. We were likely the first to care.) We quickly discovered that it could easily take more than a year for the TwinScan developers to correct this, as it wouldn’t have sufficient priority, and then of course it would require these software changes to be rolled out to the hardware. We couldn’t fit that in our schedule.

The scrum master then managed to find a team, located conveniently close in Building 21 (IIRC), that did some highly specific data analysis, and occasionally employed some custom Python tooling to extract data directly from the TwinScan binary-encoded logging data. One of their tools was capable of close to the same data that we needed. We contacted them, aligned with them and explained the circumstances. They planned our request for a “cut-and-paste adaptation” for exactly the data extraction that we required and delivered a well-obfuscated single-binary executable that was now part of the tool-chain for this experiment.

I took a bit of time to experiment with decompiling and reverse-engineering the tool to test that the obfuscation was decent, and couldn’t trivially extract any source-code. So I would be confident that we weren’t taking a “problematic, risky binary” to the customer. (Let’s say that it was significantly better protected than the licensing.)

With that tool available, we had mitigated our critical blocking issue, even if we only had certainty a few sprints before the effective deadline.

What’s with this “TSWS” thingy

As we are far along with preparations, we keep running into the same unexplained, unknown element with some abbrevation (TSWS?). It’s not a TwinScan, but only a TwinScan would make sense there. Both the other dev and I figured that .. “Hey, let’s skip this thing for now, until we can figure out why it’s relevant, and we’ll figure it out along the way.” (Now, it is relevant to note that this element was at the end of the interoperability graph. So whether TwinScan or this unknown element, it concerned a small limited interfacing operation. You cannot as easily ignore an element smack in the middle of a large project.)

This was the best approach. The slightly annoyed response from the enterprise architect (who also wrote the project architecture) was kind of amusing, when we did finally find out what that thing represented. We pointed out to him that no-one could tell us what it was, until now. It turned out to be a computer that is a stand-alone replacement for a TwinScan, with the software available to make the necessary changes or load/include/adapt/store the necessary documents (recipes) and prepare them for use on a TwinScan, without the TwinScan hardware having to be available at that moment. (I think it was essentially a TwinScan without the hardware.)

I have mentioned on a few occasions, to strongly suspect deliberate actions to interfere. In this case, I’m not so sure. We did ask quite a few people, but at the same time, I suspect this isn’t often mentioned as an explicit element. We planned for those remaining bits of work at the tail-end of our planning. It ended up being implemented by the team, as the other dev and I traveled to South-Korea. The implementation wasn’t done during our first visits, but we were investigating and testing and debugging other parts then. By the second week, the implementation was finished and we had a full application ready to go.

Finishing up implementation

As we neared the deadline, more time was allocated to the large project. I don’t quite remember if there were developers who never worked on it at all, or that those later joined in. I strongly suspect that they later joined in. Additionally, we benefited from having to implement individual UI controls, which were very self-contained, isolated tasks, which would be easier to slot in for spare time.

There was little effort left in preparation, except for aligning final plans regarding the small python support tool, the interoperability with some other teams, and discussing and aligning on what to expect at the customer site and possible risks, stumbling blocks, concerns, etc. We spoke with our customer support contact, and several people with functional domain knowledge provided information. Although, frankly, there were some unknowns left especially concerning the circumstances in the vendor room, how a particular customer would operate, how to schedule the visit for this customer and such specifics.

Security concerns for the visit

I have been excessively attacked over a mistake I made. I want to outline the full context, because I don’t know if it is much of a problem, but certainly it isn’t properly put in context. Now, to be clear, this incident is known and discussed, but there was never any follow-up.

In preparing for the visit, I talked with a number of people. (The other developer would probably not have been present for every conversation.)

I talked with the customer support representative, who didn’t know exactly what the circumstances in the vendor room would be, but that security would be pretty tight. They would need to schedule our visit.

The functional domain contacts indicated that there are a lot of unknowns regarding the ASML laptop in the vendor room. There was speculation that there might be a keylogger installed. There was speculation that the customer would be watching along. There were concerns whether or not we could take information out of the vendor room. (Usually not much more than writing notes on small pieces of paper.) It wasn’t clear what it would take to get information in. All-in there is very little actual details on what is or isn’t possible and a lot of conflicting information. Customer support says that it isn’t a big deal at all.

Note that in hind-sight, I cannot know exactly how reliable the input from the other functional domain contacts is, as they might also give “tweaked” information due to the team architect conflict, who originally worked physics/math concerning the functional domain, at least that is my understanding.

For our part, there were 2 separate groups involved: software development, and customer support. With software development carrying the (obfuscated) full release-build of the software and our supplementary (also obfuscated, specialized for this specific use-case) python tool, and some small convenience open-source tools, among which a secure-deletion tool to remove unwanted traces from the ASML-laptop of the software we brought for the experiment. It was a precaution, as I don’t recall any urgent need of it. From my understanding, there is little risk in any of those, in part because it is a joint experiment. There was warning against taking source-code or our development laptops to the customer, both of which we did not do. Customer support needed to verify certain calculations, so they would compile their own subset of tooling to take with.

We primarily brought the secure-deletion software because we couldn’t know with 100% certainty that the Customer Support tooling could load/run directly from the read-only (because of CD) hidden encrypted container. In case anything needed to be copied onto the laptop itself, we could securely wipe it afterwards.

As we traveled to South-Korea, in preparing for the visit, we further tried to figure out what the vendor room would be like, what the security concerns would be. Whether or not we could consider the ASML laptop trustworthy, etc. Customer Support contact, who was also there and had responsibility and accountability for this project, said that it should be okay. Customer support people are quite regularly at customer sites, so I would expect them (him in particular) to have some knowledge of this. At this point, there are a lot of uncertainties and we/I have to work with whatever decision or information is “deemed likely true” in the first place.

It is important to note, that at various times after the visit when discussing other matters concerning security and also in noting my concerns about this incident, the enterprise architects told us that we “trust our customers.” The thing is, and this is the part that is literally conflicting with the way in which I get attacked over this: he makes it sound like it is a non-issue.

He has difficulty in getting his tooling prepared. I ask what to do now. He doesn’t quite know. So, I give him the option of preparing a CD with his subset of the scripts in an encrypted container. However, this is important to add: I explain to him that, the encrypted partition is the protection for the situation where we might lose the disc. Because that’s the whole point of why we protect this. I emphasize that: if there is any kind of keylogger or remote access/viewing software on the ASML laptop in the vendor room, there is no way I can protect against that. And I have also warned him of this repeatedly earlier, when we were preparing his tools. He seems to be certain that the laptop is trustworthy. So, he has a decision to make whether or not the encrypted container is sufficient to mitigate for the case where the disc is lost. He was okay with that. We prepare an encrypted container with hidden section for a few (critical) project-files. (Only customer support files, in my memory.) The supplementary tools in a normal part of the encrypted container. At every visit we prepared our tools, and constructed the disc in the same way.

Note: if you hadn’t guessed yet, we used Veracrypt for the encryption. To my knowledge, by far the best choice given the circumstances.

Now, we still didn’t know about the other security, how to take the disc with, and what circumstances there were. We tried to get the meeting to schedule. That worked, though most visits would only be possible in the second week, so we needed to extend the stay. (I won’t bother you with the details, but some last-minute arranging was necessary.) The matter of taking information in and out, was a curious matter. So, they would essentially only allow handwritten notes to be taken out and sparingly at that.

I don’t actually know how to take media/information in, because they tried to hand me the disc to hide and I refused. So instead, our local office contact hid the disc beneath his clothes, and we went through security that way. I wasn’t happy about this. I don’t know why they did it. It wasn’t my responsibility to question .. or maybe I should say that I had very little stake (left) in the matter, as we had our angles covered with the prepared (obfuscated) release-builds of the software. I did question it, as-in ask about it. The answer was essentially “it’s complicated”. Probably more effort and involves forms, or something. The Customer Support contact seemed to be fine with it.

I think these kinds of things are critical parts that were always left out of the attacks, so that’s why I note them here.

Note also how it came to be really convenient that I had virtually complete understanding of the build process, the obfuscation, etc., making it possible to do the full release-builds without even having to ask other developers for support.

We went on several visits, sometimes I would join and sometimes the other developer. I would always prepare the disc beforehand and as such we would always compose them in exactly the same way. We had to leave practically everything at the local office: smartphone, electronics, passports, etc. At the final day, we went with the three of us (and the local office contact). There was some “confusion” with the password, so I whispered a part, then got annoyed and typed it in myself. So, again, I don’t know the extent of the security and whether this was an issue at all. We had a long password for a reason. Everything otherwise succeeded. Calculations were done. We had only this one trivial calculation error left in the end. Customer Support contact had done calculations and could explain it, so we only needed to trace the origin in the source-code.

When we left the vendor room for the last time, someone said for me to take the disc, but I didn’t see where it was. It missed it, thinking someone else had picked it up already. A contact from the customer picked up the disc. But in the end, threw it in a “secure mail” (instead of something like ‘incinerate’) box. So, it seems he wanted the disc. I don’t know if this was a problem. It wasn’t for our department. I never heard anything about it. Other developer and Customer Support were aware as well, and nobody intervened (or bothered to). If there was any issue, it would’ve concerned Customer Support.

In hind-sight, I started wondering whether this was on purpose because I had fixed and enhanced the obfuscation. There would be a certain symmetry in having this occur, as well as asking me to take the disc on the final day. It is for this reason, that I pointed out that the encryption is the mitigation in case something like this might happen. (And already a solution to Customer Support contact’s original problems.)

It is unfortunate that it happened. Given repeated emphasis by enterprise architect that we trust our customers, the Customer Support contact didn’t seem much bothered, and there was otherwise no follow-up at all, I have no idea why there would be a concern. The incident was openly communicated. If they were just looking to shift blame onto me, then maybe this would be a convenient excuse. But again, software development department had their bases fully covered. In any way, we would release the tool as part of the application anyways.

The other developer got some opportunities to meet with a few project members from the customer side to discuss ideas and ask questions concerning UX. There was a meeting for scheduled that puprose as well.

By the time of the final report meeting, we managed to do everything save for that one calculation error that Customer Support already tracked down and explained. The other project team, had only managed to succeed in two or so goals and quite a few “fails”. Essentially, everything but breaking the last disc was a success for us. By the time we had traveled back to Eindhoven, our development team had traced down the bug.

Now, it is also important to note, that I had been struggling with dry eyes, especially during the first half of working at ASML. They were all informed of this. I cannot help but think these things are related. Considering also the conflicting information received from functional domain people. The discussions with the team architect, and the change during preparation that the PO tried to pull. Also, the other developer having focus on UX, had been interacting regularly with UX lead who was previously the PO during introduction of the licensing. (A lot of parts connect here.)

I never did get any information on whether a keylogger was involved or otherwise remote viewer/access software. If this is the case, these protections wouldn’t have made any sense at all. (There wouldn’t even have been a point in encrypting anything.)

After the visit

During the two weeks in South-Korea, the team worked on the application to finish the interoperability with the “TwinScan Workstation” thingy, to correct the functional change due to overlooked difference in area of functional domain, and to correct for bugs.

After the visit was finished and we returned, by the time we had arrived in Eindhoven, the team had already figured out what the single calculation error. That had been the only unresolved issue left over from the visit, so in this very next week we had been able to fix what we needed to make things work and could pretty much conclude that project. I don’t recall if there was anything else that needed finishing up that’s specific for the purpose of the visit. I presumably under-document this part as the team that stayed in Eindhoven would be more aware of the subtle details that they didn’t bother communicating during our visit.

Exclusivity deal?

Now, we were explained that this involved an exclusivity deal for a certain period. I don’t remember exactly how long it was, but certainly at least a year. Let’s say 1.5 years, for the sake of illustrating the idea. This was an experiment that was done in cooperation with the customer. After the project ended, our team went on with other work. Eventually, the other developer got another opportunity to travel to South Korea. This was certainly not more than a year later. As he visited the local office there and later also several customers, he noticed that other customers were talking about the experiment quite freely (and enthusiastically, is my understanding). I have no idea how this came to be, but it was clear that it was “public” (as-in, within semiconductor circles) information by then.

Endless discussions on maintenance prio

In sprint plannings, we would have stories ready for maintenance and tech-debt concerns. We would argue for significant amounts of time to get these planned. These discussions were seemingly endless and ended up in (multiple) cycles.

PO would have plenty of reasons, such as “it’s working”, “we don’t make many changes to the application anymore”, “business is focusing on other things”, “we’re one of the best performing teams”, “tech-debt is in irrelevant tools”, “tech-debt has no relation to upcoming work/projects”, “business has ridiculously high demands, we cannot afford to delay right now”, etc.

Note: take these reasons for their general idea. I don’t recall them all by heart.

Additionally, there was also the prototype that we developed earlier, that was somewhat in between “unsupported” and “recognized official tool” and of course it was not developed extensively past prototype-quality. (I don’t remember exactly, but this may also have been a reason for later discussions on what a “prototype” would mean for functionality, quality, maintenance.) For this case, it doesn’t even matter which side argues for inclusion or expulsion. The tool was a prototype that proved an idea, and to officially support the tool, it should also satisfy some reasonable expectations.

Temporary team member for testing

Next a new team member is introduced for assisting in various testing efforts. This team member was specifically requested for this purpose, i.e. to prepare, extend and run a testing set up that was more advanced than our basic unit tests.

Getting the tester to do his thing was tedious at best and he produced little results. I haven’t spent enough time with him to know whether this was a matter of motivation or skill or experience or lack of support / sparring partner. However, effectively, there were very few results.

I did address this with a team member of the same (as me) consultancy, who wanted to wait it out for a bit. I’m fairly certain I also discussed this with the scrum master, maybe somewhat later. It wasn’t sitting well with me.

He also later got reintroduced in the 2nd team where he was slightly less useless, but in my opinion, he still underperformed. There was also more pressure to achieve results then.

Increased focus on projects and new features

I previously hadn’t thought anything of it. Right now, I wonder if the “sudden need” for HR to (temporarily) move in close to our team’s desk, had something to do with earlier attempts at attacks and/or the larger project. This happens roughly around this time, i.e. in chronological ordering. Given their later comments that I’m “suppressing ideas”, they are clearly looking for excuses. Given that there was no follow-up on anything from before, it seems they’re more interesting in looking for new excuses.

In previous section, this was already hinted at. At this point, business departments get the hang of things, and the application is growing significantly, that is more tools are added and existing tools are extended with more functionality or support for more (edge-)cases or capabilities. Given that the number of development teams was already growing steadily for a while, it becomes quite a sizeable collection of tools.

Now, our team has some of the oldest “legacy” applications in maintenance. Those do not get much attention in terms of changes and technical debt. There is not much interest in refactoring. In addition, these tools were built in Swing, while pretty much every other tool is implemented in JavaFX UI framework. The legacy applications are part of the same application framework, though bolted in through a component that accepts this old UI-style. Furthermore, the legacy applications were still a “collection of controls” for power-users, while newer applications had taken considerable effort to guide less experienced users. This meant, that the “legacy” applications were legacy in (at best) several ways and this had consequences as well.

The strong push towards new work also came with bigger plans and higher expectations from tools. Larger scope meant that it took more time to implement a tool. However, it would also mean that preference would be on continuing new work, as opposed to reserving capacity for maintaining existing tools and resolving tech-debt. New effort was put in UX (as the other developer in the team focused on that) and this also demanded certain amount of attention and demanded a more evolved tool code-structure as well as time spent on preparing new UI elements for use. These additional concerns are (justifiably) all counted towards “new work”, but also meant that there would be more work to be done in total.

It’s somewhere within this chronological order of events, that the third Romanian team member joined. When the team went downstairs for a break with a coffee, we all got better introduced with some casual conversation. There were some stories about doing programming in C++ and also traveling. However, except for very high-over stories there wasn’t anything concrete about what she had done. I think the point was that she was new to Java. That in itself doesn’t bother me. However, as we continued talking, it didn’t become at all clear if there was any experience and in what way/area/etc.. I had very little information to go on and decided to let her be for a while. Even if I wanted to help, I had very little information. I decided to wait it out and see if there were questions. Of course, I, like any other team member, were involved in the introduction in the team and naturally she was welcome in the team (at least as far as I’m concerned). My criticism here is specifically about having so little of an indication on her technical knowledge.

Several months later, one other Romanian team member commented, with a bit of a mocking laugh, that she didn’t manage to deliver much at all. This essentially confirmed my earlier suspicions. Now it’s important to point out that I do not make myself “unapproachable” at all. And, if anything, we were quite busy with other issues, matters, getting things in order and getting work done. So, I wasn’t by any means trying to avoid her, and I have undoubtedly asked an occasional question. I just wanted to leave her be, because I had practically no useful information to go on and too many other things to be concerned about already. I was also wondering, and somewhat expecting, that the other team members would take it upon themselves to support her with it. As we did always have and continuously tried to cultivate a team culture, I was hoping to see that happen, especially given that the three Romanians were from the same company.

Later on, when implementing the internal equivalent of our “special python tool” from the prior project, she picked up this work and a neighboring team maintained a C/C++ library for reading the binary-encoded log file, and she took up this task to do the implementation. That worked out fine.

The previous larger project we had to prepare for was successful enough that recreated the highly specific functionality of the python tool inside the tool. This required reading these binary-encoded log files to extract the proper data necessary.

The department also grew/had grown from 2 to 4 group leads with probably roughly same growth in number of teams. Improvements efforts started to be more pronounced, occasionally with a group lead involving themselves. One of the efforts was to get the business departments to communicate on upcoming plans earlier and more clearly, such that there was time to prepare for upcoming (larger) projects. There would be some use of Epics to outline high-over plans and that would provide some insights. It would at least provide team leads with some insight into what to prepare for next, as opposed to being surprised by the sudden need or switch.

As I write this, I wonder if our team has been used as an excuse to push harder to get more new features and tools implemented, simply because our PO conveniently neglected to report on the fact that maintenance and tech-debt reduction keep being deferred. (Likely, with the dismissive attitude of “the developers want to make things perfect, but it works so it’s fine” kind-of attitude. Essentially the same way discussions about capacity for technical improvements get dismissed. See later section on “PO disposition”.)

Third Romanian team member

In the previous section we already shortly discussed the third Romanian team member joining the team. Having given very little indication of experience or skill, neither the extent or any hint that she had little experience, I let her be for a while. Naturally, one treats them like any other team member, including introductions of the person, into the functional domain, and into technical matters and the code-base, the occasional question to check whether things are understood. However, I decided to not pay her any special attention and instead focus on the various issues already going on in the team.

Now, I suspect that this team member was supposed to be a distraction, or a set up for an excuse to attack me over. By this time, they would’ve failed to be the distraction “at initial introduction”. At this point, one of the Romanian team members would have acknowledged, thus confirming my expectations, that she had limited skills and was slow to deliver results. (Those criticizing my words, I am more detailed about this in earlier section. I decided to let her be for a while and focus on team concerns.) She, in the mean time, has become a bit more provocative. Shows off her “new jeans” bought in Amsterdam in a local store, by appropriately sticking out her ass. In a later incident, she was wearing a sufficiently translucent top that her light/white bra was visible through her top in the office environment itself, even if it was a sunny spring day outside. Just before she left I tried to point this out, near the elevator and as I mentioned something that got twisted and used as an attack. This situation, among others, leaves me with the distinct impression that multiple actions such as the initial introduction, and also what is described in next section, are constructed scenarios in repeated attempts (to construct an excuse) to attack me.

Her company’s group contact, which these Romanian devs have to align with – as it was explained to me – just happened to also be the same problematic developer from the second team that also tried to opportunistically benefit from the successful knowledge-sharing sessions and, curiously, also wanted to be a “partial” (part-time?) scrum master. I suspect with the ignorant, mis-guided (mis)understanding that this would grant her an semi-“lead” role. I say ‘ignorant’, because somebody who knows Scrum well, knows that scrum master is strictly a referee role with no inherent say in non-process matters. She will also rant 10+ misguided or manipulative (false) accusations to your face without leaving room to discuss. (And then considers it “feedback” or “resolving an issue”.) I say “no room to discuss”, because I tried to stop her after the first to discuss, and got barked at for “interrupting”. So this foreign near-shoring consulting company, as far as my impressions of them go, already demonstrated some very curious situations.

It is likely that the set-up was intentional, and there have been several attempts, possibly because of discovering the lousy solution they apply for licensing. The bad introduction made it stand out. The 3+ bugs causing issues with team members made the licensing logic easy to find by virtue of the application crashes of several blocked team members pointing that way. The same PO that fucked up the licensing, also became an abusive competence lead for the UX-competence. In later story in 3rd team, one team member would walk out of a meeting with this lead while visibly and audibly crying. In a later follow-up section of this post, a sudden suggestion to switch to a HTML-based UI would also comfortably fit in the same PO/UX-lead’s area. (I was attacked over “rejecting” the suggestion, but I didn’t.)

Dubious email

To clarify: I need to describe this from the facts and observations I gathered, because I cannot claim to possess a full picture of the events of what happened. As such, I’ll describe this as the events that happened and one can draw their own conclusions.

I previously mentioned a third Romanian developer joined the team. If my memory serves me, she joined after this large project, while we were picking up lots of smaller pieces. At some point we also redesigned and implemented the prototype-application, but I don’t think that has happened yet. That happened a bit later with other things getting or requiring focus first. I “derive” this from the fact, that there were first some discussions on how much quality and/or maintenance and/or support we should give to what was originally considered a prototype, hacked together quickly to prove an idea.

This is a particular thing that has bugged me for a while, and I have only various facts to work with but not enough to draw definitive conclusions.

I mentioned previously, that the large project required support of a small highly-specific Python tool to fill in for a bug in the hardware. So, after a successful experiment and positive response, we included (or rather left included) the tool in the application. This meant, that we needed to provide for the functionality then present in the Python support-tool. Thus we needed to implement some rudimentary capability to read the binary-encoded log and extract those (few) values that we required. When it was time to fully include and support the experiment as full-fledged tool in the software application, she took an interest in implementing this part. Given her proclaimed experience with C/C++, IIRC, this made sense.

I contact the team who had maintained the C-library (or C++, it really doesn’t matter) for a tiny library that implemented reading the binary-encoded log-files. They happened to be fairly close to our team, in the same building, even the same floor. I align with them, get the source-code for the library that we can use to reimplement the necessary part in Java. Even before reaching my desk, she’s already there and eager to receive. So I check with her that it’s okay to give her an introduction to this particular peace of sofware in a little bit, such that she understands the context and purpose of this particular part, because everyone except for her was there when the need for the Python-tool arose. I needed to drop some notes and laptop, and then I’d drop by to give a small intro.

So, as I start walking towards her desk, which is something like the next “island” block of desks, I notice what seems like writing an email in an webmail environment whether G-Mail or something like it, then being swapped out for what strongly resembles GPG-encoded ASCII-armored content. Furthermore, I see her scroll down and up a little bit, through what looks like a sizeable amount of content. The email is then sent, as I call out to her to align. Now, at the risk of drawing conclusions for you, I would estimate that the ASCII-armored content is definitely more than just a text-message.

Now, let me be clear about this: I don’t care about any excuses about “prematurely accusing someone”. In the three years there, there have been plenty of “incidents”, “comments”, opportunism, attacks. Towards the end, some Romanian developer confirmed there was indeed a clear disposition toward opposing me. In the second team, there were deliberate actions to undermine my ability to do my work, when I was asked to save their “problem-team” (not my choice of words). Several members had started accusing me for .. as to my understanding .. for rejecting their bad solutions. As I explained in a previous section, I do not outright dismiss ideas, but instead try to point out what’s wrong. It’s for them to decide whether or not they want to correct me, to abandon or fix or revise their idea. I think it is very generous on my part, that I point out their flaw instead of a blunt, unspecified rejection. They essentially always end up having something specific to work with.

As, in this case, I point out what I strongly believe I saw: the relatively small piece of text, a webmail environment (likely Gmail), the transformation into sizeable ASCII-armored content i.e. the swap into ASCII-armored content on screen, and a sizeable amount of content to scroll through. Draw whichever conclusion you want.

It’s worth noting that, at the time, I said very little of this. (Actually, I’m not sure I mentioned it apart from maybe to an individual member in passing by. It isn’t illegal to want privacy. I had my doubts but didn’t think it enough to act upon.) I didn’t know what to think about it and assumed good faith. Regardless, both she and some other Romanians have been consistent in attacking, trying to challenge me, trying to challenge my integrity, trying to prove incompetence. Not to go into detail here, but on several occasions we looked up an architect or senior developer for a second opinion, immediately, on-the-spot, so without any ability for me to pre-align, and in all cases I was proved right on my criticism. (Among many other attempts and attacks.)

And, to be clear. Maybe she did transmit the library as I am clearly implying, but she just transmitted it to a colleague in the same department. Still, it happened immediately, i.e. within 30 minutes or so (but more likely within 15 minutes) from us receiving it. I still have my doubts whether it would be necessary. And, I have absolutely no shame in saying that I have my reservations about this whole situation, especially in hind-sight after all the attacks that have already been going on. Additionally, there is a difference between gathering knowledge of which team is involved in which types of activity, and gathering concrete artifacts.

Various suggestions

As one of the more senior people in the team, I get occasionally asked to check an idea. Particularly for technical matters. I am not so “business-oriented” as some other team members. However, I am quite capable of thinking through technical solutions. So, on occasion, there are matters that need to be evaluated or checked and I’d give my opinion.

Note: I suspect that this is where the comments originate of being “suppressive” of other people’s ideas, or “too influential”, and I have been extensively attacked on this, but they always forget to tell you some important details: 1.) I don’t “reject” an idea. Instead, I point out how I see this to fail or be a problem. This gives the discussion an open end that may be taken up on to further explain why I’m wrong or do not understand, and also gives handles on which to focus to improve the idea if it is indeed wrong. Interestingly, I only rarely get follow-ups. If I like an idea, I will often already point out the solution that I think would work that’s basically the original idea but fine-tuned. And, note, this is in cooperation with the other developer. So, when I say that I am not “suppressive”, I mean that I have no intention to outright kill ideas, and if anything give them a lead to improve.

There is one particular instance that comes to mind, which is a fairly far-fetched idea that one team member proposed. (That, just happens to be aligned with interests of a certain person that has been a cause of problems throughout these stories.) He proposed to transition to HTML-based UI framework.

Now, for context: this is in a time where we have just recently switched towards JavaFX, where, each sprint, we have seemingly endless discussions with PO to include even little bits of technically-relevant work in the sprint (and technical debt starts piling up), and discussions usually end by exhaustion when we end up going in circles.

So, he proposes the idea for the HTML UI-based framework. I explain to him that I see some benefits in this, but in the current state of affairs where there is pervasive push towards new features, I have no clue how I would “sell” or “promote” such a significant change of direction, and I don’t see how I can manage to convince the PO on this. So, my answer to him is: provide me with the right selling points, make a better case for yourself and I can support you, or try to make the case to the PO yourself, because I don’t see how I would even start on this. One only needs to feel rejected if they do not want to bother to put more effort in and fine-tune their ideas.

Note that the HTML UI-framework idea most likely originated from the same lead/PO with the abusive practices that got the early team member burnt out, was PO during the dubious license code-base introduction, later became UX-competence lead and had a member walk out of a meeting crying, and same member refusing to side with her own team against abusive lead, and same member finishing a UX presentation in tears because enterprise architect harshly criticized her (for what really were “not great”) ideas.

The observant will find there is a pattern with one particular abusive person.

Note: the issue with Proguard, might also concern same lead if she was in charge in the same way for the licensing. I believe it was a collaboration of two teams in order to set it up. I suspect, because one particular senior developer was involved who was also involved in licensing. I don’t recall ‘his team during Proguard issue’ from memory, but the logical derivation seems very likely.

This is the clearest instance I can imagine that would’ve been maliciously sold as “suppressive of other people’s ideas”, because any other (smaller) more specific ideas would most likely be “killed” by pointing out that it can’t work like that.

Note that this “dissatisfaction” was later also voiced by my manager. So I strongly suspect that during a certain time when the “HR team” just happened to be seated close to us, they had evaluated my responses and probably were as shallow as counting the number of times I didn’t wholely approve an idea. I simply have no lead into why/when I would have incorrectly rejected/dismissed ideas.

Now, as I noted before, the introduction of HTML UIs would be beneficial to the UX competence and I find it hard to believe, with later pushes for similar if not same results, that it is purely a coincidence that this idea was proposed. Again, my problem is not with HTML UIs itself, but rather with the vastly different direction and different focus as they would also want to migrate to completely different technologies. And, on top of that, I didn’t block the idea. I simply pointed out that I didn’t see enough benefits to (fully) back the idea, especially given excessive push by PO, and that I would be open if a better case could be made.

Angry team member

Note: I don’t recall the exact moment in time this happened. It might have been a bit earlier in the linear order of these sections. It doesn’t matter much for the events that played out though.

If there was malicious intent involved, i.e. I got deceived, it would still mean work was deleted (hence I listed the facts I am aware of below). Recovery and review with another (or multiple) team member present. Multiple team members were involved. Remaining team members were informed.

So, the same member who suggested the UI framework transition earlier, (apparently) got frustrated and angry. It started to become a habit to go for a drink in the down-stairs public lunch room/coffee-bar. Some people had discovered that they served some special beers. Supposedly, after having drunk alcohol during such a Friday end-of-day drink, he had deleted the branch that contained his development work for a sprint story. I wasn’t present while this happened. I remember running into a team member on the way down, who pulled me back to help check it out and possibly recover. Now, I cannot say for sure angry-dev was drinking, because I hadn’t seen him around that time. The ‘deletion’ itself was evident from the information on the server.

I prepare to leave. Another team member drops by and warns me that he deleted the work-branch that contained his work. I go take a look to investigate with the guy informing me about it, and I am fairly sure that one or two other people from the team got informed along the way about this event. Me and the other developer check where we can recover this branch, as we’re left with very little information about the deletion in the code-repositry itself. There may have been the commit-hash that was deleted. I don’t recall it factually, but it would make sense. However, we knew that git would also keep track locally on developer workstations, so we needed to check which workstation had the most up-to-date record of his work. (Most likely, the code-repository had left a hint of the commit-hash of the deleted branch.) We would, on a workstation locally, re-attached that work to the branch that would’ve gotten deleted when new updates were fetched, and persisted that. We then checked if the code was okay. I could not fully evaluate this by myself, but the other team member was also there to review. The recovered work, as committed, carried a commit-message explaining the circumstances. With the commit being under my name, but mentioning the other people, both for the deletion and who was present as a second pair of eyes to review.

Now, if there was something wrong with this work, then: 1.) we didn’t find it during tests, and 2.) there is no reason to blame this on me. It seems, with the sort of backstabbing that has been going on, that I was attacked for “making a malicious commit and blaming someone else”. There is no reason to draw that conclusion without asking questions at the team. Also, the one developer did leave soon after. Likely forced out. If there was any excuse to attack me on this, it can only be justified by dismissing all the factual information present as part of the event. More likely, I was not attacked for this, but rather this consultancy used this as yet more excuse to harass me and (attempt to) set me up. Note also, in the story on group lead fuck-up that my (ASML) manager already had dubious biases. Now, consider also recent comments about “suppressing other people’s ideas”.

I want to outline the points as I am aware of them:

1. The branch with work was deleted.
2. The work was ready to be reviewed. (Not 100% sure. I think the other team member told me when he explained the story, i.e. along the lines of “it was ready to be reviewed, and now he has deleted it out of anger” or something along those lines. I can’t be more specific, because I don’t remember the event in that precise detail.)
3. The work was not yet merged. (Otherwise there would’ve been no change showing up after we recovered it, or integrated it.)
4. The developer later left. (Because of said incident.)
5. There was more than 1 person present to correct/recover on this incident. (So there is no reason to blame it on me alone or claim malicious intent on my side.)
6. We checked multiple workstations for the up-to-date branch. (I believe mine was up-to-date and other Romanian developer’s wasn’t slightly lagging behind. This makes sense, because I was finishing up work, and may have fetched the latest bits from the server several times in the last few hours.)
7. The commit message clearly states the circumstances and the people involved, present. There is no reason to blame this on me without any investigation.
8. There was no “investigation” of any significance, to my knowledge. So either they had heard a conclusive story or they simply made assumptions. I don’t know.
9. Team members and scrum master and PO were all informed about what had happened. I think we discussed this in the next “daily scrum”, at least in short.

important it was right about this time, that STI had further increased restrictions on the git repositories. To be clear: we found out then and there. We would’ve committed angry-developer’s work back into the feature-branch as his own unmodified, untouched commits. (Effectively “un-deleting” the branch, exactly as-is. Exactly as they lived on mine and others’ workstations.) I was not (no longer) allowed to do this, which came as a surprised to me, at the time. I don’t think this change was announced. (Recall other previous incidents and thankless behavior with STI department and builds) Now, due to these circumstances, we had to change the author into mine, so that I could push the commits onto a newly created feature-branch. That is also the reason why I clearly documented in the commit-message what had transpired, including names of people involved and dev doing review.

To be clear. I believe the circumstances played out as described above. As I was initially pulled in and informed. To my knowledge I got pulled in after this event had truthfully taken place and we wanted to recover the deleted work (feature-branch).

Note that this might also have been used as an excuse to claim “identity impersonation” for “trying to commit work to the server under another developer’s name”. This is incorrect, because these concerned unchanged commits originally committed to the server by the original developer. It is essentially a resubmission of data lost on the server. Nothing was changed, i.e. the commit-hashes were the original commit-hashes.

Aligning business and development

Some developers in particular, me included, had made significant effort to understand the business, such that we could try to more easily introduce technical changes without too much disruption or at a time when there would be additional benefit to the business. Furthermore, as the number of tools in our team’s portfolio grew, the prototype tool became a matter of discussion. That is, whether to eject it entirely, rewrite it according to the new practices for tooling, which would include the direction UX was going in, or to adopt it was is and undoubtedly suffer some maintenance penalty for the fact that is an “old-style” prototype tool.

This had already side-stepped into discussions on what to call a prototype and what would be acceptable for business for certain types of implementations and what to expect in quality, benefit and maintenance when new tools are implemented. This is in itself an interesting foray as it is beneficial to know all the “aftercare” that is not guaranteed with certain experiments, such that we can exclude the prototype in regular application releases or drop support to the benefit of more important matters. However, we cannot do so if it conflicts with e.g. expectations of quality or longevity. I consider(ed) this a positive move, as it would align business and development departments on expectations.

PO disposition

We are still in the middle of a growth spurt in the department, with much focus on getting new work and new ideas implemented. As mentioned in a previous section, the discussions seem to go on forever for any work not directly related to the “top of mind” focus of business.

It started to become a pattern that anything that isn’t the focus of the business would be dismissed in some way or another. The increasing familiarity with scrum meant that we started working with Epics and some larger plans got more concrete. But it also meant, that there was always an excuse not to do anything of a technical nature that isn’t directly related to the business plan. And, as mentioned before, there were always plenty of arguments why something else was more important. However, it also meant that our PO focused on business goals almost entirely, and the development team would undoubtedly be looked down upon (to express it mildly) when quality were to drop, or development performance were to drop, whether due to the consequences of technical debt or issues that occurred. Furthermore, the oldest “legacy” applications got (virtually) no attention. Multiple team members have concerns at this point, in part due to the endless discussions.

On occasion, when we would get at a point in the discussion that we ended up on the topic of “team concerns on quality or performance”, this would end up being dismissed because “… we are one of the best-performing teams in the department”. The thing is with these kinds of discussions: you cannot discuss with someone who will always make up an argument and circle around, indefinitely if needed.

Disposition/bias

This bothers me, because even though I know I’m not the “business-savvy” dev in the team, I don’t understand how this makes sense. I talk with PO outside of meeting to figure out what his way of reasoning is. I can somewhat understand his reasoning, but I get the distinct impression he also just doesn’t care about anything of a technical nature.

PO, having a background in physics, must have done his share of programming for the sake of achieving goals in physics (studies). He mentions that “yeah, but he didn’t really care about it or like it, and usually tried to have someone else do the programming for him”. So, at this point, it is rather evident that there is also a clear disposition opposing anything concerning technical concerns and programming. Effectively, that means our PO, which should be somewhat partial to the team or at least neutral, will most definitely side with business due to his lack of interest thus understanding for our concerns.

Now, if we look at this very methodically: this is a problem as far as the team cannot provide sufficient counter-weight to guard the team’s own concerns to uphold technical quality and keep technical debt in check. However, we have by now experienced months of PO pushing against any kind of technical initiative. Yes, obviously we managed to push in an occasional minor change. At best, we can tackle small things in spare time or on-the-go, but the technical debt increased noticably. And when “shit hits the fan”, it will most definitely be the team in error for neglect of the technical concerns.

Non-work get-together

As I find out on a friday afternoon that this particular disposition is present, it bothers me immensely. It explains a lot too. It explains the endless discussions, the ignorant, uninterested dismissal of anything sizable of technical nature, the avoiding attitude in the conversations whenever technical aspects are addressed.

Now, to point something out first: I was more bothered by the PO’s attitude than the other developer. He was bothered by the endless discussion and the risks on the technical area. I was also bothered by the attitude in general and the endless discussions. When I pointed this out during our non-work get-together I noticed he was less enthusiastic about me pointing out a work topic, but also intrigued that something of this nature was there to discover. I explained the situation and pointed out the implications of this and we figured this would be something best addressed with the scrum master. It hadn’t taken too much time, all-in-all.

Now, it seems some people have twisted this into some “insidious master plan to take over ASML”, as I clearly got attacked on discussing this. There were also plenty of other things, but it seems that one important aspect is a confusion of individuals who carry the same name, i.e. one being a team member while the other unrelated to ASML. (Although this seems like an unlikely mistake, given that we were speaking English.)

If this impression was completely off, then at the very least “some people” (unspecified exactly which) were “very bothered” by having discussed this. Possibly, including PO feeling personally attacked. At this point, I have to speculate, because I have been attacked on so insanely many bullshit and lies, that it is impossible to make up a consistent narrative that is also attempts to be close to truth.

PO was getting all of the “business prestige” from his accomplishments. He took a very large amount of capacity to achieve this, at the cost of short-term maintenance and tech-debt increasing, pushing the team. (Pushing by itself is not necessarily a bad thing. It depends on the costs.) The team was known to be “one of the best performing teams”. However, this takes into account the back-pressure I was – for a large part – providing. (The other developer, that I had done the larger project with, also helped to push back. However, he was less fluent in arguing on technical grounds, so I guess one could say this particular topic was carried for a larger part by me.)

Working with scrum master

We try to address this with scrum master, to see what he thinks. He is obviously aware of the many discussions on technical debt that never got anywhere. Now at least we have understanding.

Intermezzo: I think it’s important to provide some background and clarification: the scrum process allows for creating high-performing, “self-sufficient” teams with some degree of their own agency. This makes it possible for the team to properly do the work they are expecting to do. This “team” includes dev-team, i.e. developers and related competences, PO and scrum master. Scrum defines some clear guides on what “team” is expected to be able to do. Among others, there are certain expectations on PO. For example, PO is expected to have some ability to make decisions of their own accord on behalf of the business that’s being represented. (This prevents infinite alignment or endless fights between stake-holder priorities that will block or delay team progress.) Similarly, PO is expected to be an interface/barrier between business and dev-team, such that dev-team does not become the “battleground” for multiple business departments that are not themselves capable (really, just mature enough) of aligning priorities, and instead “solve” this each individually harassing the dev-team. Instead, PO is this barrier with anything that concerns priorities and such decision-making. (For efficiency and to prevent miscommunication, dev-team does communicate with stake-holders directly.) Now, if PO overwhelmingly sides with business, effectively becoming an adversary to the dev-team, Scrum will cease to function, because there is again imbalance. Hence my emphasized need for back-pressure. This should provide you with sufficient background to understand why the push-back we gave was critical for successful functioning of the team.

Commentary: I have said, on more than one occasion: “If business departments are not mature enough or able to align priorities among themselves and instead push it down to developers, this will effectively result in ad-hoc decisions as circumstances dictate, because resources (time, etc.) only allow for so much work.” (See “project management triangle”, a well-known trilemma.) Developers cannot do both perfectly, because these are conflicting concerns. Providing pressure/force/threats/harassment of any kind means you’re effectively fighting against circumstances, not the team. Scrum solves this by virtue of the PO role that functions as an interface/barrier between developers and business.

Side-note: Proper understanding of the Scrum process is critical. But more importantly, as I have seen this in multiple companies already, business departments that simply “demand the work” are completely blind to the mechanics and effects of this attitude on the teams doing the actual work. This includes the “indirect decision-making by consequence of circumstance”, and that teams “becoming the battleground” for business alignment incompetence.

Scrum master, with other developer and me (possibly others involved, I don’t quite remember) planned some meetings to address this. These discussions were difficult. I think he felt personally attacked. I am absolutely sure we, i.e. both me and the other developer, have spent significant amounts of time trying to explain the “interplay” present in the Scrum roles and why some agency is good, why the PO needs to have some ability to make decisions as representation of business, why he is this interface between team and business, etc. We also mentioned that we aren’t claiming he does a bad job. That wasn’t the case. The point is simply that: you cannot fully dismiss any and all technical concerns “just because you don’t care”, when the team needs to provide quality results, timely and predictably deliver, and all the other desirable aspects. For example, maintaining a desirable level of performance is subject to dev-team being able to remove the technical debt and other debilitating factors that may emerge from focus on delivering features at expense of quality (logic, code-structure, whatever..).

The team needs to be able to take their share of responsibility for the technical concerns, because business will never prioritize those. It’s how Scrum is defined to work, and it’s why it works. The discussions were not initiated to try and side-line the PO. The team needs a PO. The discussions were there to re-establish PO as neutral party, instead of “prestige-hungry business representative that is pushing the team directly”. The PO doesn’t have to side with the team, which is equally unreasonable. However, dismissing team concerns while team does get the bad rep if things go wrong, is not how Scrum works or can work.

Note, I mentioned at certain moments that when I was moved out of the team, there no longer was sufficient back-pressure to the business ideas. At this point, it should be obvious why this is the case, and why I mean this literally and not as a “gross exageration of my accomplishments”. The push of business to focus on new work and new developments and projects is large at this point.

Note, one could say I pissed off a person with this, but that isn’t necessarily true. PO already before tried to take the other developer out of the preparation work, which I strongly suspect was for sake of the earlier conflict with team “architect”, so it seems reasonable to assume I was already in the crosshairs. At this point, I simply identified a bias such that the dev-team can provide a proper amount of back-pressure.

It should be considered that this “push-back” is not motivated by trying to take control, if it wasn’t evident from the story. The “push-back” is to allow us to provide the necessary back-pressure needed to keep the team balanced and “in control of the software”, as opposed to being subject to failures and delays due to bad quality and problematic code-base. In a later story, I get mocked by a scrum master and business stakeholder, both of clearly did not understand the Scrum process and dynamic. The key characteristic here, is that with PO having this disposition that strongly favors business interests and new features, our PO is no longer the neutral interface between the whole of ASML and the team. That problem specifically is what we pushed back against. It got out of control.

New team member joining

Another team member would join the team. I am not 100% sure whether before or after the serious discussions with PO. I know/heard she was from the TU/e, so highly educated. She showed an affinity for matters concerning requirements and design. I cannot comment on technical capabilities/skills, because in the relatively short time I would be in the team, there was less focus on that.

In hind-sight, adding the team member was likely in preparation of getting rid of me.

As she got integrated in the team, PO was putting in yet more pressure. This was very likely targeted at me, because even until the last day before switching team, he was “aggressively” making comments. Regardless, as we got to know the new member, and there was already some regularity in preparing for larger projects. In some cases, I was mostly focused on this. The other developer took an increasingly more serious focus on UX and would make an extra trip (trips?) to customers for that specific reason. As such, he would focus more on those activities. I, on the other hand, had started to focus more on the technical concerns and the functional domain corresponding to those larger requests, whether projects or sizeable tasks.

I think I already started including her prior to me being asked to leave as she showed an interest. Now this is likely preplanned as I mentioned. At the time, I didn’t think anything of it. Now, I don’t particularly blame her for anything. She seemed to me like a good enough person and she would very likely have no idea as to the extent of what was going on.

Asked to switch teams

As my manager repeatedly “hints at” or “asks” whether I would want to switch teams, I have said “no” several times. I have also mentioned that I didn’t think the team was ready yet. However, he remains persistent. Undoubtedly during one of these conversations, he would have pointed out I was suppressing others’ ideas. As mentioned earlier, he still had his “problem-team” issue. Undoubtedly he had other reasons.

At some point, I reluctantly accept, in part because of increased “friction” (supposed, claimed) within the team. I asked for at least a week, so I had time to prepare the transition and transfering knowledge. I was preparing multiple larger pieces of work at the time. PO starts being pushy and shitty as soon as the “acceptance” was “achieved”. I talk with other scrum master and he knows about and agrees with 1 week transition time.

I ask our scrum master whether he thinks I am suppressing other team members’ ideas and opinions, and he says he didn’t think so. He also mentions that he thinks it wouldn’t be beneficial for the team, but that it helps to solve “a problem ASML has” meaning manager’s “problem-team”.

Next day, a thursday, I get to hear that I must be in the new team on Monday. There is an urgent project and team is positioned on the critical path so this is all high-priority. I have approximately 1.5 days to transfer knowledge and PO clearly shows he’s glad to see me gone. I transfer knowledge to the Russian team member who showed particular interest in preparation and communication, such that she would be a suitable candidate for aligning among stakeholders. (For the record, I still think so.) Note that the preparation work would also be significantly less technical in nature, so it wouldn’t be for everyone. In the few hours we have available, I transfer all the knowledge I have and update her on the preparation done and immediate concerns/focus.

Note, I think at this point I started using a mindmap to gather the many snippets of knowledge and hints for these projects. This works for myself, but needs explaining when transfering knowledge and understanding to another person.

In the end, I had virtually no time to prepare or transfer knowledge or learn to understand what the new team is about. I tried to transfer as much knowledge as possible and then was pushed towards the new team.

Note, it was explained to me, that the urgency of this other team was a consequence of customer demanding a desktop-tool first such that it could evaluate (intermediate) results step-by-step. This resulted in the situation that I got pushed into a team, while the team is shifting within its functional domain and everything from that Monday on would be part of a fresh plan that I nor the team were yet informed about. (Of course, still with what is known as a “problem-team”.)

Meanwhile in 1st team …

I left the first team, though with obvious hint of dissatisfaction by the way I was pushed out. I tended to, on occasion, check up with the other developer from the first team that I had been working closely together with for most of the time. Not at first. I was absolutely swamped in preparation and as mentioned attempts at integrating were full of friction due to the oppositional attitude of the team.

Short talk with Russian team member

Shortly after my team switch, the Russian team member who took over a significant amount of preparation work from me, and I had a quick chat. I’m not sure whether she or I planned it. I guess it was somewhere between half an hour and an hour or so. I think we were just in general exchanging experiences. I remember the one question she asked: what recommendations I had. I’m not quite sure anymore what I answered, but I think it was something along the lines of there being some friction with the preparation work, and that I had tried to be very transparent about everything such that there could be little confusion/miscommunication. In hind-sight this seems like rather pointless advice, because of clear targeted circumstances towards me as a person. Hence the advice is of no use to someone else, and it isn’t even clear whether I actually did this badly or it was just the easiest target to attack.

In hind-sight, given PO effort to push me out of the team and other matters concerning the team dynamic, the readiness of manager (and likely HR) to blame me for “suppressing” others’ ideas, etc. would mean that it was a personally selected as target, rather than based on poor acting or poor decision-making. Consequently, me being naive about giving advice, I probably gave fairly useless advice. On the other hand, given my straight-forward acting concerning the issues in the team, she might have picked up on actual concerns herself.

Loss of performance

The team had gotten some time to resolve tech-debt. Though didn’t manage to complete the work in two sprints and it had been a source of dissatisfaction by PO. I know of the time I was still in the team, there were some reasonably sizeable changes to be made. We all knew, it always got pushed out to the next sprint. Now it wasn’t all being resolved in the ideal amount of time. Some structural changes to the code didn’t come out as intended or were more comprehensive. This resulted in a productivity drop by the team. Similarly, preparing for new projects didn’t go as smoothly as planned.

In general, I had heard about decrease in performance and some complications going back to the “well-oiled” self-sustained functioning of the team. I describe this in general terms as are fair for the amount of information/impression I got, some of which would be natural due to change of team composition, while some would be attributable to lack of experience.

“Crashing halt”

Now, one particular event is quite fresh on my mind. I think it happened in, let’s say the first couple of months. It is fresh on my mind, because I walked into the meeting as my team apparently followed up on them. There was an awkward discomfort and silence in the room, and clear signs of conflict. I heard then from one of the team members, that PO had basicaly said “It’s so obvious. Why can’t they understand? They don’t know anything.” or something along those lines but in similarly straight-forward, clear-cut terms.

This event proves we (I and the other developer) needed to push back strongly.

I can only comment on from what I can derive, but it seems fairly obvious that the balance between business and development(-team) was completely gone. As the team scrambled to get things working, the push from PO and business was strong as ever. (Not unreasonable to consider, as there was already clear effort to get rid of me, as evident by the snide remarks in last weeks before and after I had agreed to switch.) That comment had been the final drop that brought the team to a halt.

.. and that’s when, at the end of that meeting, I and my team walk into that meeting room.

Now, as noted in a different story, I had my own share of complications with my new team. Although these were initially less dramatic. At this point I’m not trying to be smug about that. However, I clearly warned about this. I pushed back against this for months, including with conversations with PO and scrum master to get some semblance of balance restored. I got pushed out. And then this happens.

Harassment afterwards

I think the team functioned well, but not for the reasons people think. As clearly evident from the way I was attacked on several occasions, then essentially pushed and harassed out of the team by PO (with likely some others watching in amusement) was completely uncalled for. The team functioned, because I and the other dev knew and spent a not insignificant amount of time to understand how to work well within the framework that Scrum prescribes. That framework worked in virtually all cases. It takes practice to understand how to apply Scrum in subtle cases. The scrum master was a significant help in this as well. He, like me, thought it would be better for the team if I stayed.

With all this opposition, the impression that emerged was: “the team’s perfect, but Danny just keeps whining and stirring up issues”. This was clearly proved wrong relatively soon after I left. However, it was also said on several occasions where discussions were cut short with “we’re one of the best performing teams”, “everything’s working isn’t it”, “we just need to do this”, and such. I catch the brunt of the attacks, because I noticed/identified the issues and addressed them. However, these issues were very real.

In all cases, I have tried to work with the people, who in their turn simply (maliciously) frame it as an attack. I always made clear that I tried to find a mutually-beneficial solution. It became clear in the attacks when I got comments like “skipping the team architect to go directly to the enterprise architect”, which was the case because team architect was absent. (Same for “suppressing ideas”, etc.)

Something that should be undeniable, given the events that occurred with the first team, is that the pushback was clearly necessary. Note that I am not attributing everything to myself. I’m stating that the pushback was necessary. I clearly provided significant value in ways other than “typing on a keyboard”, because otherwise there wouldn’t be such a significant change in the team’s situation. I’m not claiming that I contributed 100%. I’m claiming that I provided significant insight, analysis and discussion where the team needed it, not only on technical topics. We cannot be “one of the best performing teams” when I would be a burden, a delaying factor a stumbling block, and it doesn’t explain why the team suffered afterwards. You cannot attribute everything to happenstance when we functioned well and increasingly so for (nearly a) year.

One of the attacks that have been going on for years, is that the prototype was a way to move some “problematic” people to the side. I highly doubt this, given that there was a customer and in-person visits involved for the senior developer.

One of the prevalent attacks that were undoubtedly also used as excuse to force me to move to the other team, is the suppression of ideas. This came up on a number of occasions, and the ridiculous proposal to advocate for yet another complete UI transition while not even having any sensible motivation to back up the proposal, is just another example of this. Time already showed it was a problem. Hell, even with yet another team member, the Russian woman who joined last, could they make it work. In the mean time, their excuses put me in a position where essentially the whole team acted against me, against clear and explicit instructions/intentions of ASML at the time, and against the goals the business set. All in order to attack me.

There were claims that I “just made up” the best-practices for the use of JavaFX framework to the best of its benefits to reduce code and maximize responsiveness, claiming that I had just “written something” to have “a practice” “enforced” on others. This is again bullshit, as these best-practices were derived from the various projects including the large project where our team was the one that started this new direction of UX, when we have repeatedly looked into this. What I did, was to distill the parts and structure that were necessary to start with a proper code-structure, such that we could do things right from the start of the project. (This project is the high-prio project of the 2nd team.)

There was a claim that I supposedly should make a UI to “prove” my capabilities. That was a lie. We discussed whether or not it would make sense to have a sample project, but given the insane amount of preparation work, I didn’t have time to do that. (Again, 2nd team high-prio project, and I was also responsible for the vast majority of the preparation work of the team.)

I have had several attacks concerning claims that I manipulated words to “take control” or some other outlandish manipulative phrasing. What they “undoubtedly” meant to say is: “He argued a solid case using the Scrum rules in the Scrum process as it is employed, and made a convincing case that there were changes necessary. This pissed off some people who were opportunistically, maliciously, sometimes abusively in the wrong.” I’m sure it was “innocent” “mistake” of “phrasing”. The understanding actually came from multiple conversations with a fellow developer and our scrum master, concerning how Scrum seems to work effectively. The Scrum process has seemingly simple, concise rules. But with all things simple, this may be deceptive. The small number of rules captures a lot of circumstances and issues that can occur in companies. The problem they actually had, was that the Scrum process actually dictates how things work in various business situations where roles or departments collide, often due to priority or lack of alignment on the proper levels.

I also got several attacks for “distracting” or “interfering” with practices. The “distractions” were the reasonable, solid cases I made that there were better ways to do things, that there were other ways to think about things, and that we’re putting up unnecessary handicaps or artifical penalties for issues that are non-concerns. For a trivial example: the “number of lines of code” with some regularity causes distractions and extra work due to arbitrary numbers that make less sense in certain situations. I argued that we should be careful with judging our code quality by such arbitrary metrics, even though it is mentioned occasionally in a programming book. This seems to be a problematic opinion, as most argued “it’s in a book, therefore it must be good”.

These are essentially the core events concerning the team and Scrum process in the first year/first team.

Changelog

This article will receive updates, if necessary.

• 2025-03-18 Initial version.