Harassment: ASML 1st team: team architect conflicts

Wed, Feb 19, 2025 ❝A team architect role with a lot of overlap with the devteam.❞

Contents

Okay, so this is essentially utterly ridiculous. This essentially started as soon as I started working at ASML, with ASML being the customer of the consulting company.

This story was forcibly made relevant, because ASML seemed to think it funny to set up circumstances in the third team to eerily similarly reflect those of the “team architect” conflicts in the first team. Except, when I joined the third team in the role of “team architect” (which I always – I think correctly – mentioned is not really or very limitedly an “architect” role, due to the limited scope), by then I had a very clear view of how I would fill it in to not interfere with other team members. However, it seems some other ASML employees, including the scrum master, did not agree and set out to be excessive assholes for no (apparent) reason. With what later turns out to be just fabricated bullshit excuses to forcibly be assholes to harass me, without absolutely any doubt this referred to the conflicts described in this story.

Now, to point out: there was no reason for these attacks. Every step of the way, I have been straight-foward in trying to get this friction resolved and I have been nothing but constructive towards finding a way to make it work for all of us. However, if people set out just to attack me to make a point, it doesn’t matter if you do it right, they will find an excuse. In case of the scrum master, it was making arbitrary demands outside his domain, such as insisting on using WhatsApp for team communication including sharing of photos of whiteboards and planning materials, and arbitrarily interrupting productive discussions, contributing “bad ideas” who he most definitely knows were bad (and were not part of his role), and derailing otherwise productive meetings. (All of this is not actually part of this story, so I’ll leave the more intricate details for a later story.)

Introduction and context

So I start at ASML, getting some introduction into the domain. Integrating into the team always takes some time, because you have to understand some minimum amount of the functional domain in order to become self-sufficient and start being productive. I was very well supported by two senior devs, .. at least let me put it like this .. I think they were quite straight-forward and clear, both had significant amounts of knowledge and had very different styles, i.e. ways of working, meaning I managed to pick up different types of information from both of them. Actually, come to think of it, I don’t think either of them were ever a problem, and I’d like to think we worked well together. They later moved out of the team. This particular story started before that time, i.e. first months at ASML, and continued slightly after that.

Development teams (SCRUM) usually consisted of developers, but also had a senior to outline some direction, and a person well-versed in the functional domain (usually either maths or physics background) to clarify the functional domain for whatever specific purpose was needed. In some cases there was a “team architect”, although I never found out how this role was quite (expected to be) filled in. (In the third team, I defined my own way for this role. This will be a different story.)

Ideas, invisible role lines

Now, during several meetings there were the inevitable discussions on new functionality and changes should be implemented. The maths/physics person would be the first person to check for any questions within the functional domain. The two seniors mentioned above were very knowledgable on the development aspects. The “team architect” was completely an unclear role to me.

So we start discussing functionality and implementation details such that we can clarify/detail “stories” (on a SCRUM board, used for planning and task delegation) such that sufficient information is available for developers to start working on their own, at least until a sufficiently fine level of detail is reached that subtleties might require a second opinion or double-checking of facts and formulas. When discussing these implementation details, and the occasional discussion on how to handle technical debt, or whether or not to incur a bit of technical debt, this “team architect” would arbitrary jump in and shoot down an idea without clear expression as to why. Instead, one seemed to have crossed this invisible line and now we’re suddenly on his domain and everything you say from then on is fucked-by-default.

Now, I took this as a challenge and provided arguments why I would think my arguments were valid and worth discussing, and/or ask questions concerning why he made his points the way he did, i.e. clarify your proposals. As you would expect in any healthy way of working. There was little of that and regardless he kept insisting.

Now, I don’t mind this per se. What I do mind, is that with no clear boundary, no clear line, my ideas get shot down for no apparent reason, and on top of that productive discussions are hard to achieve. So there is a bit of a heated discussion, and when we finish the discussion, I left it at that. Apparently, he as still pissed off. Now, to note: this person had a background in math/physics (I think physics, but I’m not 100% sure) and he transitioned into this somewhat “in-between” role. He had no, or little, software development experience. So the discussions would often be in my favor, especially because we would discuss matters that are plainly in the “design” domain, usually within the agency of software engineers. Within the “team” scope, there isn’t a large scope for architecture matters. And the larger scope was concern of the enterprise architects.

Similarly, when there were questions concerning maths or physics, we would primarily check with the designated contact for our team, because they would be more deeply read-in or involved in the matter, so they could provide a better, more refined explanation to these questions. So, I end up with a situation that there is a person in the team that I don’t know when to address, I don’t know what questions to ask, and whenever I try to contribute my share to the team activities, I would step on his toes and there would be another heated discussion.

Senior team-members leaving

Essentially, we managed to make things work, usually. I think he always was still angry at me. I was brand new in the team and every discussion, every contributions ends up leading into these arbitrary unclear discussions. In a way, the PO being very pushy towards implementing new functionality would neutralize some of the discussions, because there would be an occasional discussion that was not at all about engineering matters, but rather about whether or not to resolve technical debt, so then discussions would take on different concerns.

At some point, these two seniors leave for their own teams giving them more opportunity to grow and grow their respective teams. And there is this rather sizeable project upcoming. Around the same time, fairly early in this project, the team architect is absent for .. I think 2 weeks. Me and another team member, we were both in the team around the same length of time, I think he was there 2 months longer, got some hints to try and tackle this project’s software engineering concerns. We both take this on with both hands. There is little conflict of interest because we have different focus and cooperate well to tackle the complexities and complications of this project. As we get our bearings, and we both work to outline the general idea for the project on a dedicated whiteboard, where we annotate individual necessary components as well as progress and key requirements, between the both of us we manage to have a very good grasp of this sizeable project.

So, as the team architect is absent for two weeks, we use our contact for maths/physics background, our (stakeholder) contact from customer support for more customer-specific concerns, and contact the enterprise architect (we only needed the one) as necessary for the higher-level concerns. Although there is a lot of information to manage, between the two of us taking different focuses but both focused on the requirements-level, and the rest of the team providing input on any matters of software engineering design and implementation, we have quite solid grasp of the project and its needs. (Well except for this one “workstation” thing in the architecture, that we deferred to the last moment because nobody could tell us what it stood for or more importantly why exactly this component was necessary. :-P .. it later turned out to be useful to do a preparation/conversion for an output file, thus benefiting integration.)

By the time our team architect came back, we were reasonably well read into the subject matter and managed to get things rolling along. And I think at that point, he was somewhat left out. He moved to focus on other things. I tried to get him involved, but didn’t quite know what to ask without being deferred to other contacts.

We ended up finishing this project pretty decently given our level of experience. I will skip on all of those details, to keep focus on the original topic.

The role is not/badly defined

So after this project, we end up in a similar situation with the occasional conflict and quite frankly it just isn’t clear what his role is. So I try to outline the roles, trying to get him (and later also us) to actually define where he sees this boundary to be.

For me, the matter is quite simply: I do not want to go into every meeting wondering when I’m going to step on someone’s toes because an undefined role means arbitrarily being cut off and discussions not being possible due to someone having to defend an undefined role against a bunch of engineers who (very reasonably) assume they’re arguing on design matters.

We end up scheduling a few meetings with … I think: PO, scrum-master, me, other senior dev and team architect, to see if we can define the role. My intention with this is crystal clear with not a single other unspoken intention: how can we draw the lines such that we can all contribute without the friction, i.e. crossing on other roles during every meeting. There was never any backstabbing, never any back-handed intentions, I have been perfectly straight-forward and honest and constructive. I never regarded him as an adversary or opponent. It was difficult, though, because of his lack of software engineering experience and the ease with which conflicts arose. There was always this unnecessary factor of friction.

We had two or three meetings trying to figure this out, and I think, i.e. IIRC, that we eventually settled on him focusing partially on functional domain research, taking on a sort of split-role. I’m not sure if it was a proper resolution from his perspective. (I think I also had my doubts at the time.) I don’t have enough experience to reach a conclusion. However, it meant that software developers could actually make design decisions that always seemed an obvious part of the engineering role. As I mentioned at the start, to my understanding, he wasn’t fluent enough in the “architecture” domain, coming from the “functional domain”-side, and as a consequence we always seemed to meet and conflict on design matters. As I noted at the start, I was very aware of this problem, in part due to these meetings and conflicting roles, and filled in my (otherwise undefined) role differently when joining the third team. Although he seemed to drift away for a bit, he did have a significant role with “functional domain” knowledge in a later project, due to him preparing and investigating this in the mean time, IIRC.

Conclusions

I strongly believe that the “forced conflicts” and other bullshit attacks present in the third team were due to the events happening here. Additionally, after leaving ASML, I got attacked significantly, repeatedly for many years over all kinds of remarks concerning these matters of bullshit, and my contributions and opinions utterly ignored.

As I mentioned before, there was never any reason to. The role was badly defined, especially given his expertises. At the start, joining the team, this was less of a problem because these two seniors initially present had a strong weight in decision making, so discussions were taken over when needed. When these left, these discussions became more problematic and the roles, being equally overlapping, resulted in more conflicts.

Attacks afterwards

The attacks of various kinds, were unjustified. I never attacked him as a person. I never had a goal to “get rid of him”. I simply looked for clear bounds such that we knew what to expect and what to respect (in terms of roles). The mismatch between role and experience, and on top of that, the fact that Scrum doesn’t actually prescribe dinstict roles within the dev-team thus does not lend itself for different roles within the development team, is what caused the majority of the conflicts. And I have always said so. And this isn’t only my opinion. I reflected on this quite extensively with another developer. The scrum master was present in these meetings and can attest to making that the focus of the discussions. And I have said explicitly (probably repeatedly) that this was my focus and my intention all along.

I was attacked afterwards on matters very reminiscent of the events that occurred here. Again with ample use of manipulation, twisting of words and circumstances, and misrepresentation of situations. I was attacked for “skipping the team architect” and instead going directly to enterprise architects, while this was necessary at the time, due to team architect’s absence.

Now you’d think: so, just tell them. However, those fucking assholes involved in this, didn’t disclose sufficient detail at once, instead giving me half facts leaving it to me to piece together all the attacks. And this was after leaving ASML, so the attacks executed during the second and third teams, were already part of this persistent harassment campaign. There was already ample backstabbing and harassment, essentially for no reason.

The many attacks, however, were very clearly aimed at me as a person and were very much an effort to forcefully fuck up my effort and discredit me.

Changelog

This article will receive updates, if necessary.

• 2025-02-19 Initial version.