Harassment: ASML, organizing "Knowledge Sharing Sessions"
Thu, Feb 27, 2025 ❝Knowledge Sharing Sessions that survived a cancellation attempt by (supposed) "co"-"organizer".❞Contents
In the first team, around the time we finished a large project (see another story ..), we figured there was plenty of knowledge that needed sharing among the team members. We also recalled the earlier prototype that few people knew the details of, one of the seniors having previously left the team.
Meeting to share knowledge
During the larger project, we had also had moments where some people were split off to perform maintenance on the legacy applications, while others worked on new applications. All in all, with multiple applications, multiple levels of experience, varying skills, knowledge became rather scattered and divided among the team members. There were also some devs who were interested in more technical details of topics they weren’t yet comfortably familiar with. Whether experiences of customer visits, sharing technical expertise (OOP, generics, testing, Java’s new streaming API (at the time), etc.) or sharing knowledge on specifics of the functional domain, there were plenty of matters to share with other team members.
So I and one or few others started making a list of all the topics we could talk about. We listed them on a whiteboard so people could occasionally stretch their legs and walk up to the whiteboard to check them and possibly add more. (And vote for first to address.) As this was going on, some other team dropped by and started to voice enthusiasm, so apparently there appeared to be interest beyond our own team. People started to make a lists of topics they would be interested in, in knowing more about. So we checked if we could match up interests.
Someone outside the team voiced interest in planning more broadly among multiple teams. I don’t remember exactly, but I think we did the first few sessions with a selection of teams who had already voiced interested, before “inviting” the whole department, which by then contained quite a few development teams. In hindsight, she was very likely informed by a team member about this conversation going on. It hadn’t been for more than a day. This person (from another team) turned out to be an opportunist, trying to benefit from others’ effort. Later more on this.
Team member was tasked
At this point, we have just barely set up a list of topics, decided to schedule an event, and other teams voiced interest, then one team member tells me “yeah, you know, my manager tasked me with this”. I, personally, have no knowledge of this. This came out of the blue. So I counter with a proposal for him to take over from me. I had, at this point, already had several comments regarding “taking away” others’ opportunities (yes, even if at no decision of my own). So this seemed like an obvious resolution to a non-existent problem. His response “Well, now it doesn’t make much sense anymore, does it.” And … that was it. I don’t know if he even told the truth. Essentially, we’re setting up an initiative to ensure proper functioning of the team, benefiting even other teams. I get this thrown at me. As just another pointless, baseless, meaningless accusation that does not really want a resolution.
“Knowledge Sharing Sessions”
The first sessions are planned. Invites are shared among several teams, allowing it to grow steadily over the course of a few sessions. We decided to plan a one-hour session every other week. We gathered some topics, made some slides. Some topics hardly needed slides, like the customer visits we had done and could talk about. There were also topics about specific developments in the teams functional domain, that would be relevant to share among teams as to spread knowledge of what the department was really doing.
It is worth to note, when I had just joined we would have shared sprint review sessions with “all the teams”, which were only few. All teams would be updated on every other team’s work. This was no longer the case for a while now. So these sessions kind of filled in for that.
I just remembered this, as I was writing. At the time, we mostly identified knowing less and less about what other teams were doing. Especially given that most teams worked on their own tools, so another team might not even fully (or at all) understand what another team’s tool was (useful) for.
At the height of the knowledge sharing sessions, I suspect we managed to gather and inform up to around 80+ audience members, not necessarily all developers. I don’t think it is an exageration to say that we had 30+ different sessions and topics, though this is an casual estimation years after the fact.
Opportunist benefiting from other people’s work and efforts
I mentioned this opportunistic person before. This is the same person who was also part of the “problem-team” and also supposedly had a double role as a “group”-contact/-manager for a subset of Romanian developers for the near-shoring consultancy company.
When we started the sessions I did most of the organizing. We managed to gain some traction and she found a few people willing to speak. Now, I mentioned the contempt around everything I did or accomplished. So, at some point she proposes to speak about a topic. We schedule an event. As soon as the event arrives, I check up a few minutes before, and find out that she isn’t prepared and we should cancel the meeting.
I cancel the meeting itself at the last minute, and postpone the topic for next meeting. Canceling the meeting itself is fine, although I am disappointed that she didn’t even bother to send me any notice. An email message is everything it takes. Other than that, it would be unreasonable to demand anywhere near high priority for what are talks organized among team members of various teams. So we schedule it for the next session, two weeks later. Long story short: there are 3 more cancellations, no prior notice, that makes 4 cancellations in total resulting in 10 week delay. This most definitely a clear and obvious interruption in a smooth, well-running effort that benefits both individuals and the company.
At the fourth cancellation, I had prepared a somewhat improvised alternative as fallback. A somewhat interactive session in which I wanted to illustrate various git operations in steps of commit graph mutations, to illustrate how they worked. Git operations like interactive rebase would occasionally be useful and many people knew the command but didn’t really understand what operations were performed. One notices by the questions being asked about where to put what commit-hashes/refs when performing the rebasing. On occasion, another dev would show a useful parameter to me they had needed, so this could serve both to explain and clarify the nature behind such operations, and also to highlight interesting parameters. As you might imagine, such a session is somewhat dry and theoretical in nature, asking of the audience to understand what goes on under the hood when performing git operations. This is not a presentation that bursts with energy. It is also for this reason I had asked at the start to make it interactive. It is exactly this presentation, out of plenty of other presentations that I’ve given, that I was repeatedly attacked over later.
As I also mentioned at the time, the idea came from someone who presented the same idea at a conference with a lot more preparation and detail. I recognize a good idea when all the signs are there for people to benefit, and the commit graph representations are essentially git-operations modeled in the essentials for their users.
Now, if the effort would’ve died it would be a shame. But, the story didn’t quite end here, because I managed, in meeting and checking up with the new enterprise architect for the infrastructure concerns, to get him interested in using the Knowledge Sharing Sessions. Actually, to be fair, as I explained the concept and that it was going well, he (correctly) recognized it as an opportunity to reach a large number of members of his target audience, as a way to introduce and share upcoming efforts in his domain. The timing of this was, in suitably appropriate terms, absolutely fucking perfect. It meant that, not only was the (in hind-sight) obvious sabotaging attempt frustrated, but I hadn’t shared this in advance with her because she had neglected, i.e. had not even bothered, to send even 1 email. So we have his session, he shares a lot of details to about a full large meeting room. She is pissed off “because I neglected to inform her”. All in all, by far the most prevalent thing she did was benefit from other people’s efforts.
update to the best of my ability, I cannot recall exactly, whether I cancelled the meeting or did the git-presentation as fallback. I thought I did, but I am in doubt at this moment. I don’t think it matters much for the gist of the story.
Eventually the effort died out
We had a decent amount of topics, enough to warrant a list on a company wiki that served as historic record with links to presentations and in later instances with recordings. We filled up plenty of sessions. The recordings were additionally streamed to Romania to provide to the various near-shoring developers that happened to be (or mandated to be) working from their consultancy’s office.
Eventually, when department concerns changed, when the department grew larger, when there was more pressure and especially when large-scale longer-term projects with 4+ teams got going, the effort died out. There was simply too much going on. I don’t recall any specific event to meaningfully attribute the root cause to. And it was at a time where I was also busy with team concerns and at this time the recurring needless/pointless attacks were also already happening. In part, the in-flow of topics to discuss lessened. The need had died out.
Attacks, knowledge sharing
As mentioned, out of plenty of presentations I had done, the one presentation I did as a fall-back to the malicious intentions of the “co”-“organizer”, was used repeatedly to attack me over. The presentation itself wasn’t bad, but the audience wasn’t “interactive” in any way and this involves basic graph pictures and theoretical understanding, so you can only make it so interesting (while being economically sensible). Afterwards, I have been attacked over this one presentation only countless of times. So, now you hear the backstory to why this “boring” presentation came to be.
This particular attack involves an open-source project I used as a real-world, proven-to-work example case for the application of the State-pattern. As a hobby I worked on this open-source project, and apart from having advocated the State-pattern for certain cases at work, this was my way of saying: “Hey, I’m not just bragging. Here’s a real-world case that you can check and disect.” Now, even if you still don’t buy that I wasn’t just “bragging”. I spent time to help people, to teach about the pattern (and other design patterns), to show its strengths and compare it to the state of our “in-need-of-refactoring” application, etc. I also pointed out, that the UI suggested that certain strict separation would be viable, but that it might be good to investigate first how much of the internal state could actually be partitioned. Now, some of the applications had veritable “god”-classes. These grew massive, with all new state accumulating in it for fear of incorrectly distributing state among smaller classes. Essentially, a lack of time or analytical capability to understand the internal state. As a consequence, all new logic and state just started to pile up.
For the attacks concerning my suggestion of using the State-pattern, there was also a “cheap” follow-up “attack” in that: after I was more or less forced to switch teams, when I’d check back, at one point they said they tried to implement the state-pattern and it didn’t work(???) Now, this is another one of these awfully inconvenient after-the-fact jabs where I supposedly had the wrong idea (even though I said to analyze first and I wasn’t present at all) and I have not a sliver of information on why it failed or if they even tried. However, they made sure to throw this arbitrary statement in my face.
Changelog
This article will receive updates, if necessary.
- 2025-02-27 Update in-line mention of an uncertainty.
- 2025-02-27 Initial version, with small updates.