I recently read this (free-trial, paywalled) Sample chapter from the book "Managing Humans" by Michael Lopp. It is a glaring example of what's wrong with what passes for knowledge-sharing in our industry. I'm going to explain why.
The book itself was published in 2012 (I had never heard of it before seeing the link shared on a message board), but a quick search netted this blog post from the author in 2003 that is clearly an early draft of the book material.
In it (and the sample chapter), the author relates a disagreement he once had with another engineer that the author attributes, not to their understanding of the problem, but to their respective approaches to problem solving that he terms "Incrementalist" and "Completionist." Incrementalists (according to the model put forth) are: Politically savvy, opportunists; realists who have a good idea of what is achievable in the given context, but who don't have a good sense of the long-term big picture. They are addicted to being busy. Completionists on the other hand, are perfectionists; dreamers who believe that effort not put toward correct solutions is wasted effort. They spend most of their time muttering to themselves how incompetent everyone else is, while envisioning elegant long-term solutions to every problem.
The author positions himself as the incrementalist in the original anecdote, but speaks from the perspective of a manager over both "types" of engineers. Having defined his model, he then proceeds to coach the reader on how to manage such a conflict. His advice basically rounds down to: "Let them fight it out, without killing each other because they are both caffeine-addicted children." The solution from his perspective is really simple: They are complementary personality types so, "your job as manager is to find and marry these personality types in your organization." The incremenalists supply the approach and the completionists supply the vision. Apparently, this marriage will be a happy one and you'll all go on to resounding success once you, the manager make it happen.
There are many things wrong with this "wisdom." Some of them are relatively minor. It paternalizes the management role for example, implying that these two types are both wrong and a Hegelian Synthesis orchestrated by the manager is the best way to address their shortcomings. It also has a polarizing effect: When confronted with a disagreement, one need only identify with one of the roles to assume that the problem is due to the other person being from the opposite type.
The much larger problem with this analyisis is the weakness of both the author's model and the method he chooses to draw conclusions from it. The author posits an axis ("There are two types...") to describe himself and this unammed other and then generalizes from it to all engineers. He then builds a normative management theory from it that describes not only features and flaws of engineers but what managers should do when trying to cope with them.
The insidious and pervasive problem with such analysis is that it invites the reader to accept (or reject) the purported axis while leaving the entire question as to whether such axes - or such general management wisdom - are even a useful model of the problem.
In other words, if one accepts his definition of the axis, then one will begin to see incrementalists and completionists everywhere. However even if one rejects the definition, if you accept the idea that such axis-based models are useful - which clearly seems reasonable given the author's presentation and their proliferation throughout popular culture,
then one might be tempted to rebut this article by taking issue with the definition, while leaving the author's methodology unchallenged.
I initially fell for this, and quickly identified a half-dozen other axes that I felt were also relevant, turning the author's neat one-dimensional phase space into a 6-dimensional hypercube!
Now we're getting somewhere right? Clearly, this model will be even better at describing engineers than a single axis based on a single anecdote! Depending on how we define each wing of each axis, we could even construct an entire zodiac of personality types.
And it would be just as useful. See, even if the author hadn't put forth an over-simplified model based on the anecdotes and experiences of one person (he did), by taking as a premise that "engineering personality types" are even a thing, the author lures his readers into the pernicious clutches of The Barnum Effect.
The Barnum (or "Forer") effect, is the bread-and-butter (literally) of fortune-tellers, palm readers and other purveyors of pseudo-science. The audience is presented with definitions that seem very discriminating but are actually very general and can apply to anyone. Once the audience chooses (or creates) a definition that suits them, their own propensity toward feeling good about themselves ensures that they will see in every conflict a person representing the other side of their chosen position.
In short, Lopp's argument is bullshit. But it is a very special and pervasive kind of bullshit that far too often colors the interactions and decisions made in technology organizations: Take an anecdote, extract a descriptive model, sprinkle on some catchy metaphors and then start handing out normative prescriptions (aka "best practices").
In other words, I'm not claiming that Lopp made the whole thing up, or that he wishes to deceive his reader, I am saying he commits a fatal error in knowledge-sharing by attempting to extract a general model of technolgy management from a single anecdote about his own subjective experience.
It is one thing to do this sort of model building for oneself - there's evidence we all do it all the time. It's quite another however, to shop that model in a book and claim it represents delivery knowledge.
As I've mentioned elsewhere, I have been exploring what means to effectively share knowledge. Spoilers: It is really difficult. It has entire branches of philosophy devoted to it, and most of what passes for knowledge-sharing is bunk.
But clearly, there must be some value in Lopp's experience, and we need something - don't we?
Well, in this case I suppose I will have to side with Lopp's Completionists: Until we have a solid model for describing technolgy delivery, one that recognizes the shortcomings that we inherited with the Software Engineering paradigm, we will continue to make the same mistakes that we have for fifty years. Such knowledge isn't even wrong - but it can be harmful. So, no we can't substitute pseudo-science models like Lopp's for delivery knowledge, because they just reinforce what we already believe. They teach us literally, less than nothing. The only remaining value is in his experience - and he can't tell us much about it, because all available models (not just his) suck. A vicious circle indeed.
So what then?
My working hypothesis is that until we have a general, empirical model that effectively describes delivery, we will remain mired in Hume's "intangling brambles of metaphysics." We will endlessly repeat the same patterns of anecdote, hype and disillusionment. In its absence, the most effective path available to us is to lever our experiences to craft - from scratch - models and approaches that work for the people and contexts that we find ourselves in. Every. Single. Time.
No wonder technology delivery remains so difficult.