Interim: impersonal feedback

Tue, Oct 28, 2025 ❝Objective, impersonal feedback or "not taking things personal"❞

Contents

Not not taking things personal

Let’s start with the obvious. The comment of “not taking things personal” is never, or should never be, about personal attacks that “supposedly” are freely allowed to be launched upon the “receiver” because the “receiver” should “just” accept all the crap thrown at them as-is. There are many varieties. One can often not argue that these comments are illegal, which is a different matter entirely. However, there is a very clear distinction between taking a personal, targeted comment personally, or taking any arbitrary comment as-if it is personal, or looking for a personal reason in an argument that refers merely to objective concerns.

There is a very clear and obvious distinction for whether things are or are not personal, in the straight-forward case. (See last sections for elaboration.)

There is a flip-side to this coin. When having to, i.e. being forced to, deal with people who have chosen such a malicious attitude that there is no longer room for reason, decency or civilized discourse, and their attacks are no longer based in reality, then their attacks no longer serve any sensible purpose.

“Taking things personal”

They say “taking things personal is when the ego gets involved”. However, what does that mean exactly? It is a rather vague statement and, as such, can be and has been abused. That need not be the way to argue for or against “personal feedback”.

Telling someone “just not to take things personal” is not an excuse to justify any kind of harassment or abuse by simply claiming that receiver “should just not be bothered”, no matter scale, severity, scope and what-not. That is a manipulative and malicious explanation that essentially demands rejecting reality, and invariably lays blame on the (passive, unwilling) receiver as opposed to the (deliberate) aggressors.

There is a valid reason why people say “to not take things personal” and that is when you are objectively discussing matters that are not inherently connected to the individual. An idea or solution can be discussed by itself. By not invoking the people involved when there is no need to, you keep criticism focused on improving the solution, or conversely on identifying problems and drawbacks.

Evaluating solutions and ideas

By working with factual data, such as requirements and properties and characteristics of a solution, you discuss concrete matters and allows claims to be verified, challenged, argued. It avoids the need for subjective, unverifiable and arbitrary claims. And, to be fair, one could invoke the people involved, but equally keep both criticism and discussion based on objective terms. Instead of calling something a “stupid choice”, one can point out there are several drawbacks while another option only has one drawback. Or, how one decision tackles only 1 requirement and another solution tackles 2 requirements at the cost of some unnecessary restriction. These facts can be challenged if one thinks they are incorrect, similarly with misinterpretations, misunderstandings, and what-not.

One might think that any criticism should be on an anonymous basis as to who the originator of the idea is, but that is not ideal. In a collaborative environment, discussing a solution or idea with the originator, allows you to ask for confirmation on e.g. identified potential issues, making it possible to dissect a solution and gain proper understanding and align on (assumed) understanding. Not by making the person anonymous, but rather by discussing to the benefit of a common goal can you make this about progress rather than superiority, and build upon each-other’s ideas instead of competing.

I will use requirements as the collection of everything that prescribes how the solution should behave functionally, operationally or developmentally. This is not intended to be a complete prescription.

Now, for sake of convenience, let’s consider the following terms:

• good: any solution that satisfies the necessary requirements.
• better: any solution that, compared to another solution, offers more advantages and/or less disadvantages, or otherwise is preferred.

There exist better and more precise terms when describing solutions in detail, and solutions can be broken down in component parts whose properties can then be evaluated. All of it provides specific details as to the characteristics of a solution. I instead use these very general terms, in this post, as a sort of minimal expression of the two qualifiers that we need.

note “good” and “better” are useful qualifiers. There is no need for a “best” qualifier. For all intents and purposes, the “best” solution is a solution, for which there is no “better” alternative, i.e. the most interesting solution.

Actually comparing solutions can be as simple as comparing number of advantages, taking into account disadvantages, and in case of equal numbers, to look at relative priority between properties involved. (Solutions may be better but still not good/sufficient.)

There should be both a drive to include the necessary requirements and also to avoid excessive requirements and restrictions. Excess restrictions may interfere with or impede later developments, same with (premature) additions to a design that are not yet needed or are incomplete. They can, of course, be revisited at the cost of extra effort.

Tangent: prioritization

There are many ways of prioritizing. Each have their reasons and merits. However, priorities only really matter if there are trade-offs to be made under pressure of time, i.e. impending deadlines, or resource constraints. For the purpose of this discussion, it will (almost) always suffice to define a linear order of all the concerns involved with the highest priority being at one outer end, and lowest priority at the other end, then everything in between starting next to highest priority task then decreasing in priority until reaching the lowest priority task.

• most-important
• slightly less important
• slightly lesser still
• even less important
• least important

The reason for this is simple: There are always choices to make when having to decide between two concerns. Priorities usually only matter under pressure, at which point constraints may eventually demand a choice between any two tasks, given that it has become infeasible to do both. Either the choice is made deliberately (explicitly), or circumstances will force a decision (implicitly), in which case not always the one that is most beneficial. Even if tasks are executable in parallel with no dependencies, there is no harm in ordering them. Hence, a basic linear ordering of tasks suffices as a prioritization.

note, to emphasize: this list exists to pre-align on priorities, such that it is possible to base decisions of priority by its order of importance. There is no bigger meaning or further restriction. Any number of tasks could be worked on simultaneously. The only purpose of the list is to assist in decision-making and when time/resource constraints necessitate a choice/trade-off to fully realize an task.

note Making priorities concrete allows alignment among several parties, e.g. stakeholders, who might not otherwise align (or communicate). In case of departments, it makes concrete priorities among departments which might otherwise not want to align, or who compete through (excessive) demand of a team. Furthermore, pushing (prioritization) conflicts back to stakeholders usually forces conflicts back to the source, where they should be (should have been) resolved in the first place.

Tangent: design vs architectural concerns

As I write this, I realize that I never finished a post that evaluates a clear and rather trivial distinction between design and architecture: the premise is that design are all the concerns looking inward, i.e. considerations for the solution itself, while architecture concerns itself with looking outward, i.e. how does the solution fit in its larger context, where context is its environment, the bigger picture, established architectural concerns, the infrastructure, company risks and concerns, possibly national or international risks and concerns, etc. Essentially, architecture restricts design by imposing extra requirements. The post intended to make the point in more detail that precisely and most-generally expressed architectural requirements (that still cover their intended concerns) are ideal as they least restrict freedom of a solution’s design. A solution can be anything, such as a script or a program, or a tightly folded piece of paper to be used as a wedge.

Keep this in mind, as discussing things in an impersonal manner depends a lot on being able to take an objective disposition.

In this summarization, I leave out the distinction between involvement of business and architecture. Business is usually involved with functional concerns of the larger context, where architecture looks at technical (operational, developmental) and any remaining concerns. Business concerns need not map directly onto design decisions. Design may deviate as it takes in other considerations and may, as a consequence, choose to represent functional concerns in terms of logical constraints, guard expressions, state management or data management, restrictions or relationships.

note ‘Architecture’ itself is a very broad concept also used at the strategic level, so I have used the term somewhat more broadly than one is used to on the work floor of a software development department.

note At this point, I only discuss a solution as a whole. I did not go into detail. For example, architecture and design concerns may conflict. This may be solved with structure (partitions) at which different architectural concerns are expected to hold. Joe Armstrong famously talked about Erlang employing a supervisor as part of the Erlang-runtime, that would intervene in case of errors and crashes. One can view this supervisor as a separate partition, a hierarchical (management) layer, of the solution. As a whole, though, a solution should satisfy (imposed) architectural requirements.

Arguing on-topic

Now, given a list of requirements, both design and architectural, and their (relative) priorities, there can be many diverse solutions that satisfy these requirements to some extent.

The matter of arguing on such solutions (proposals) can be as simple as evaluating which requirements hold, both design and architectural. One can then compare solutions and compare results and priorities. One can argue about many things that concerns the solution as a whole, any individual items satisfied or otherwise, or consequences of properties of the solutions. All of these do not require any personal concerns, such as who the originator/reviewer of the solution is, and evaluated in this way, the originator/reviewer should not matter to the evaluation itself, because it concerns quantifiable concerns and facts. One may equally deep-dive in specifics and argue whether claimed properties of a solution hold. One may equally challenge the necessity of requirements or their interpretation or ambiguity, all of which can be discussed on a factual basis. We often unnecessarily restrict ourselves by making assumptions or depending on requirements that are more restrictive than needed.

The key property is that the person (or role or any such property) needs not matter when discussing solutions. One can simply discuss a solution by its merits.

As mentioned before, when discussing solutions using requirements, properties and such, you keep matters objective. Their argument holds or not. Their claims hold or not. One can verify claims. One can challenge restrictions. One can challenge the relevancy or significance of proclaimed properties. All based on facts, proper representation, correctness, logic, soundness and other scientific qualities. One can discuss these matters as peers, at which point an architect may be able to enlighten on specifics of architectural requirements, without having to force a decision.

It needs to be pointed out, that there is an important (hidden) assumption: all participants must, within reason, have the same intended goal. If arguing strictly on topic, any conflicts (of interest) should become evident from them arguing false claims or not being able to argue their claims. Alternatively, if alignment is needed, two participants may argue for different solutions and end up discussing contradictions, such as conflicting claims of priorities or properties. Usually, especially within a team, any one participant should be arguing for the “better” solution for the envisioned team goal. If one is sincere about their goals, then they should be enthused to discover a “better” solution, as-if a more elegant solution to a puzzle, instead of being insulted that the complete solution did not originate from them.

note Actually, deviating goals would hint at implicit, unspoken, or otherwise “invisible” or “unknown” requirements that result in a different understanding of what the envisioned goal is.

Manipulative arguments

Clear indicators where arguments become manipulative or deceptive in nature.

• Not allowed to mention references, e.g. which works an idea is based on; or alternatively being attacked for not mentioning references.

  Almost always, it is good to reference the ideas a solution is built upon, even if just iterations on someone else’s initial idea. Complaining that these couldn’t be mentioned, for whatever reason, is almost always nonsense. Especially in an open working environment within a team, where people are expected to cooperate. Attributing early ideas helps to negate a feeling that “the final solution” always originates from one person, or that there is malicious intent in criticizing specifics or fine-tuning a solution.

• “Don’t interrupt”, usually when false or incomplete or deceptive or otherwise questionable claims are made and no time or attention is given to them, or allowed to them, or falsity is not addressed or allowed to be addressed.

  I would say there are two core reasons to interrupt someone. Either with malicious intent, e.g. to stop them from speaking, or with positive intent, e.g. willingness to take someone seriously enough to engage. In case of the former, it would become clear. In case of the latter, not allowing any engagement is clearly a matter of avoidance. See also the bullet on not allowing discussing feedback on a case-by-case basis.

• Another variant: “We want to list our feedback first”, i.e. “shut up and listen”.

  This happened to me during second internship: I wanted to ask for clarification on several occasions, only to be shut up when these people insist on talking/listing. When they were done I asked them to clarify their stance on a number of points of criticism, which they couldn’t. I think I even mentioned that I didn’t see the point of the feedback, and that I couldn’t make sense of the comments they were making. They did not have an answer to that either. This is clear abusive behavior: just throw in arbitrary complaints and expecting them to be “honored” without justification. It resembles a manipulative way of imposing a false form of “respect”.

• Not wanting to discuss matters item by item. Whenever matters of any reasonable size are discussed, it may get complicated. It is pointless and unrealistic to think that one may list some 10+ claims and expect them to be discussed (or not even that) afterwards. Not wanting to discuss criticism item by item, is already questionable, resembling avoidance, because any objective matter should be able to be evaluated.

  This is at best a hidden excuse to allow spouting subjective “complaints” that need no supporting arguments, or an opportunistic attempt at listing lies, because the list drowns out the ability to evaluate them on case-by-case basis, or at worst is an abusive attitude to “invite” or “excuse” targeted unjustified ranting.

• Not allowing questioning specifics, origin, purpose of requirements, priorities, assumptions, or other guiding concerns. There are often hidden assumptions, excessive restrictions, ambiguity, (mis)interpretation, etc. involved. If none of these can be discussed, possibly for something as simple as clearing up misunderstandings or aligning understanding among participants, then you cannot eradicate complications and obscurity from an objective on-topic discussion.

  Whether to clear up, challenge seemingly non-sense restrictions, or to fine-tune what seem like overly broad restrictions, in any case there is very deliberate reason to question what is often considered “a given”. The misunderstanding that happens between having heard the original intentions and only being able to read the restriction as it is phrased, is what may result in misunderstandings, misinterpretations, excessive restrictions or unchecked assumptions. This is often the case with “given”/imposed (architectural) requirements.

• Interfering with a productive discussion based on hierarchical position or role, is counter-productive as it attempts to negate objective evaluation and reasoning, frustrates the process, and rejects/dismisses valid contributions.

  Demanding some arbitrary choice that seems to make no sense and cannot be explained, or is “explained” based on unshared knowledge, or “unspoken” (architectural) requirements, and makes no sense otherwise. Furthermore, when alternatives cannot be argued against, but are “wrong” nonetheless.

• Long-winded explanations, distractions, manipulative arguments, misrepresetation, circle-reasoning, refusal to acknowledge/reject claims, steering/deviating from topic, etc.

  On several occasions, one PO deliberately started very long explanations that ended up in circular reasoning. We would arrive at the starting point, which we already knew to be false, and could repeat the whole argument if this was not noticed. These kinds of endless arguments are manipulative because they exhaust the willingness to argue one’s point, while in the end no sensible argument is made.

• Attacks become unreasonable (e.g. refusal to acknowledge), claiming preferential treatment or bias, invariably challenging every criticism/solution, or challenging to an unreasonable degree.

  On a few occasions, I did the following: discuss and drill down to the exact claim of falsity/bias/misunderstanding/…, i.e. what are they claiming is bad/wrong/problematic/…? Ideally, try to agree on what you disagree on and about. Look up a skilled peer in-the-moment, i.e. no ability to pre-align, that is sufficiently skilled to evaluate both of your arguments. Explain the situation in general, then if necessary each argue your specific points, and possibly the agreed-upon difference of opinion.

• Attempting to force through malicious accusations through indirect means like “recognizing” something or “having knowledge of” something or “alternatively-interpreting” something or looking for “symbolic meaning” in something.

  There are all kinds of reasons to be involved, to have knowledge of, or speak of something. Whenever such instances of “bending of rules” and contortions of explanations and interpretations are involved, people have chosen one of any number of possible narratives based on their agenda. With harassment going on for a sufficient amount of time, reasons extend to trivialities such as recognizing (intentional) patterns.

• … There are plenty more examples. I do not want to make this post only about manipulation and deception. …

note if hierarchy and roles are involved, and a situation is such that one person is allowed to veto or decide based on hierarchical position, then one could still do a discussion/evaluation as peers and afterwards force a decision with a clear declaration that it is a veto. (Or circumvent discussion by forcing a decision.) I can imagine there being such rare circumstances, though they need not be a complicating/frustrating factor in an otherwise productive discussion. Furthermore, by “declaring a veto” (of sorts), it is made clear that the decision is not based on quality of solution but on other concerns instead (and emphasizes the role/responsibility). This is straight-forward and sincere, and is only frustrating in that a “better” solution is not chosen even though at least it is acknowledged as such.

Excluding suspicious/coincidental comments

This post is written with the (unspoken) assumption that there are good intentions and there is no deliberate subtext involved. This post is intended to discuss matters for professional situations, or at the least situations where (scientific) reasoning is accepted. I will leave matters concerning malicious intent, hidden agendas, refusal to discuss (objective) facts and matters, and other cases where reason and civilized discourse no longer hold or are deemed acceptable, completely out-of-scope. Similarly, with sufficient persistence, even in the most obscure attempts at harassment, manipulation and deception, one will eventually find patterns.

This post cannot offer advice when it concerns malicious circumstances.

Attacks

Apart from the many attacks already previously documented, at which I hint here when explaining manipulative practices, there are additional instances:

• In some of my earlier experiences, several business departments would compete for resources indirectly through (trying to) exert more pressure on a team or person. These department sometimes do not even know they are competing. However, if such a long-lasting habit turns organizational deficiency within a company, the pressure of several departments starts concentrating on a few teams or individuals. Both teams and individuals may get attacked for incompetence, ineffectivity, inefficiency, and what-not for “not meeting unreasonable expectations of individual departments”, because departments themselves are incapable or unwilling to communicate, align and prioritize.
• Being attacked for attributing initial ideas to people, on which later solution was built.
• In 3rd team at ASML, I tried to keep architectural concerns separate as much as possible from design matters, such that developers have as much freedom as they need to come up with solutions, without there being unnecessary restrictions. This was later attacked as “what if the developers don’t want that” (not posed as a question), which more or less equates to saying “what if developers don’t want to do their job”. Of course variation exists and is allowed and the goal is to have a team function as a team. There were some very self-sufficient developers with their own subdomain and some devs very focused on writing code. In case of rejecting “designing” as part of the process, it leaves little more than writing code. (ASML’s role as “engineer” implied a whole lot more expertise.) However, I know some people were intensely involved at their topic of interest, so even that attack does not hold in all cases. These attacks merely function as excuses for retaliation for team bullshit and conflicts.
• 6+ Years of constant personal attacks or misrepresented circumstances with clear intention to misdirect blame to me, then throw in some shitty remarks afterwards to “not take it personal”.

Changelog

This article will receive updates, if necessary.

• 2025-10-28 Initial version.