People Deserve The “What”

I don’t read blogs nearly as often these days as I used to and as I wish I currently did. A lot of this is the result of generating increasing amounts of my own content in various forms, and the rest is probably that I spend most of my time these days in coaching/administrative sorts of roles, rather than with large stretches of uninterrupted desk time. Nevertheless, I do try to sneak in a few posts or articles per day, albeit sometimes behind the bleeding edge.

The other day I noticed this post from Uncle Bob, which referenced (and thus led me to watch) this video:

One Hacker Way – Erik Meijer from Reaktor on Vimeo.

Here’s a wikipedia entry on Erik Meijer, the speaker, who, among other things, is responsible for Linq. He has a suitably impressive resume that I bore in mind my absolute love of Linq and listened through the duration of the talk, which seemed mainly to have the loose thesis, “everyone sucks at everything and I hate you, yes, specifically, you.” Removing tongue from cheek, it seemed to be garden variety contrarian talk: “{Whatever} is popular, but I’m hear to tell you that everyone is wrong and {whatever} actually {sucks/is dead/ruined Christmas} and {very new, vague concept} is what you need to do instead.” You can usually schedule a follow-up talk in a couple years of the form “{Very new, vague concept} was a great idea when I had it, but you all screwed it up, so it’s time to dust off and retry {whatever}.”

Sometimes I find this sort of thing thought provoking. I try very hard to be able to justify any practice that I use beyond just “well, that’s the way the winds are blowing” or some such. My preference is to be able to defeat serious frontal assaults out of nowhere on any given thing that I may be doing (not that I prefer to spend my days doing this, but I’d like to think I could, if necessary). So, watching critiques of practices that I employ, such as TDD, puts me into a position where I consider whether there might be better ways to solve problems that I have than the ways I’m currently solving them.

This talk didn’t have that affect on me — it didn’t really have much of any effect on me, and it actually reminded me of meetings that drone on and start to try my attention span. But that makes no sense; it’s a guy using colorful language, obviously possessed of a sense of humor, and saying things that are provocative and in direct disagreement with the way I do things. I’d expect some mix of amusement, indignation, annoyance, etc — not inattentiveness. I had to think on it a bit before I realized why this was: at the end of the day, it’s someone telling me what to do without explaining how those marching orders help me solve any kind of problem.

(Paraphrased) “Agile sucks. Commit code or you’re worthless. Quit your job if they want you to practice TDD.” My response is, more or less, “that’s… dramatic… but how does this information solve any problem at all that I have?” It’s like some kind of mandatory ISO meeting where someone explains to me that everything I’ve ever done is terrible and hell, fire and brimstone await and there are all of these important compliances and audits and such. It’s all very impressive in the presentation, but abstract and hypothetical enough that it’s hard for me not to zone out after a bit (though I have a specific personality trait/defect that I struggle mightily to pay attention to information that I don’t perceive a use for at the moment).

To pull back and get a little more abstract, let’s consider modes of information exchange where one person is delegating, in some fashion, to another person. There is the “what,” which is goal-oriented, and the “how,” which is process oriented. One or both may be present in a form of delegation (if neither is present, then what you have isn’t actually any kind of delegation). Let’s consider the three cases this allows.

How, but not What

This is really the least helpful case when it comes to knowledge workers, and it’s the least effective form of delegation. It’s the category into which Erik’s talk and the hypothetical ISO meeting fall. You’ve got someone telling you what to do, but not really tell you why you should do it or what they think will be accomplished. It’s usually from a position of authority, most typically a micro-manager. Erik’s apparent likening of software developers to military and a hierarchical organization like the Catholic Church is sort of telling here, as these are the types of institutions that espouse an operational philosophy of “it’s not your job to think, grunt, just do as I tell you.” Or, “don’t worry about what or why, just concern yourself with the how.”

Erik’s authority comes from his status/accomplishments in the industry. ISO guy’s authority comes from bureaucratic rules and civil laws. General’s authority comes from the command and control structure. All of this is effective for easily-automated process or purely tactical thinking, but it’s tended to fail pretty repeatably throughout history for knowledge workers. See, for instance, development shops that believe it’s effective to bring on a couple of architects to be the brains of writing software and then hiring legions of unskilled grunts to do the mindless work of programming.

And, apart from this being pretty ineffective when it comes to delegating to knowledge workers, it’s also a bummer. Being micromanaged sucks all of the fun out of our jobs. Imagine sitting there programming and someone comes up to you and starts telling you to adopt different coding standards and change your indentations and such. When you ask, “why,” he just calls you and idiot and tells you that “what are we trying to accomplish here” is above your pay-grade, peon.

How and What

This is probably the most common scenario these days in a lot of shops for most interactions. You get a mixture of the goal and the process — the what and the how. An iconic example of this is the former-hero developer that’s been promoted to architect/team lead/dev manager and who no longer has time to work on all of the features she otherwise might have. She fights the urge to just roll up her sleeves and do it, knowing that doesn’t scale, but that doesn’t stop her from saying, “you need to get this information stored for later… and, you should do this by using the repository pattern to encapsulate this particular…” and so on.

It’s better than how without what. You’re being told the goal and you’re part of the discussion, and I consider that table stakes for effective knowledge work. But in this case, it’s like getting a math textbook with all of the answers scribbled underneath each problem. It’s helpful for getting right answers quickly (assuming they are right), but it’s not helpful for your own learning or morale.

The trouble is, this is natural for the former hero-dev and anyone in her position. She knows what the problem is and she knows a workable solution. So wouldn’t it be beneficial for her to just share that knowledge? Well, maybe, but it’s nuanced. And I’d argue that the longer term cost of this quasi-dysfunctional arrangement tends to outweigh the short term gains.

What but not How

This is the best situation for knowledge workers. It allows for the ‘ideal’ distribution of work, if you will, since it’s like two systems being a generalized service interface. Former-hero tells you what she needs and leaves it up to you how to do that. She worries about her stuff and you worry about yours. If one of you needs input from the other, you approach that on an as needed basis and the relationship is one of mutual trust. Knowledge workers thrive in this sort of environment. Knowledge work requires creativity and creativity flourishes in low pressure, non-contentious, free environments.

Interestingly, to bring things back full circle, this is an excellent working arrangement, but it would make for a poor talk/book/blog post. Telling you what but not how would mean I’d make a post like, “I think the Java language could really be improved, but I’ll leave it to you to decide how in the comments.” Effective presentations need “How and What” — “here’s a problem that you have, and here’s how I propose that it might be fixed.”

So What?

Why do I draw these distinctions? To encourage you to be mindful of the how and the what in your interactions with others. In code, good encapsulation and separation of concerns are achieved by having public method signatures define “what” and private implementations define “how.” I think this is a good model for dividing work with others. When dealing with them, encourage them to define what they want from you rather than how they want you to do it. And when delegating, try to avoid telling people how to do things, telling them what it is you want instead.

This scales much, much better than anything else. Life is simply too complex and short for you to spend your time knowing how to solve everyone’s problems better than they do. Like it or not, you’re going to have to rely on the expertise of others, so rather than micromanaging them, trust them and spend your time getting your stuff right and figuring out how to surround yourself by as many trustworthy people as possible. And, if you do find yourself in a position to be explaining the how of something — maybe you’ve been asked or are casually conversing or whatever — make sure that you supply the “what” to go along with the “how.” If you can’t put a “what” to it and make it convincing, people will be hard pressed to care about your “how.”

Annihilating Complexity

I think that I’ve been blogging long enough to earn a bit of latitude when it comes to making up pseudo-scientific ‘theories’ to describe the universe.  So, indulge me, if you will, as I abuse concepts of physics by using them as staging points for a narrative of human behavior.  I think it’ll be fun for all involved and it’s my hope that, on the other side of this, I’ve advanced the course of human knowledge rather than lowering everyone’s IQ.  But, hey, caveat emptor.

If you ever had the good fortune to take a high school chemistry class, you might have studied endothermic and exothermic reactions.  I say good fortune because these reactions involve the flow of heat into and out of systems, so appropriate demonstrations almost certainly involved melting things or blowing things up.  To (over) simplify the situation and avoid you needing to precisely define “system” or to ask the question, “what on Earth is enthalpy,” let’s just say that exothermic things spew heat into the world and endothermic ones remove it from the world.  Like I said, indulge me.

In a talk called, “Simple Made Easy,” Rich Hickey describes “finding” a term for the introduction of needless complexity to a system: “to complect”  (literally meaning to join together by weaving).  I’ve come to think of and use this word to describe times where a solution to a problem is actually more complicated than the problem itself, meaning there has been a pointless introduction of additional complexity.  Now that I spend my days in the world of Java again, I’m reminded of the witticism: “I had a problem and I used Java to solve it — now I have a ProblemFactory.”

Now, to bring this apparent non sequitur to heel, here’s what these two concepts have in common in my mind.  I’d like to define two camps of people: “endocomplectic” people and “exocomplectic” people or, “endocomplectics and exocomplectics.”  Endocomplectics are people who remove complexity from their surroundings — something about their nature allows them to simplify things, essentially absorbing, or at least deflecting complexity and making the area around them simpler for others.  Exocomplectics, on the other hand, add complexity to their surroundings, and make life harder for those nearby.

To get a bit more specific, let’s define three conceptual scopes: the world, the group, and the individual. The world is, well, the world. The group is the setting in which you can observe this in action — typically your team room or something similar in a work capacity (though it can also certainly apply to non-work considerations like families or groups of friends). And the individual is, not surprisingly, the person in question. Let’s also further divide the exocomplectics and endocomplectics into sub-categories. Exocomplectics include complexity creators and complexity adders and endocompletics include complexity removers and complexity annihilators. I’m operating on a hypothesis that this is the essence of what you need to seek or skip in interviewing and that any behavior from being a good teammate and human being to solving problems effectively can be expressed on this spectrum.  Crappy people create complexity and awesome people annihilate it.

Complexity Creators

I’ve actually posted about this, albeit many moons ago. A complexity creator, in the world/group/individual scoping sense, is someone who has some kind of internal reservoir of “potential complexity” and, like an octopus with its ink, spews it out into the world around them, seeking to obfuscate and confuse.

Think of someone you can recall that’s perhaps out of their depth in their role or else extremely lazy or something like that. You can probably picture someone that meets this definition and the weird things that they say when you ask simple questions like, “so, what did you do last week,” or “hey, can you work on feature X a bit?” Explanations as to how incredibly hard the task is start to rain down in an onslaught of excuse-hail, bludgeoning you into taking cover. “Oh, well, there’s a lot of angles, and I had to read up on it a bit and then consult Bill and Steve over in accounting, and then I fired off 12 emails to Microsoft, and…” You stand there, jaw hanging slack, because all they would have needed to do would have been to add a few lines of markup and call it a day.

This is a complexity creator. Complexity creators are exocomplectics that actually birth complexity into existence, adding opacity and disorientation to what otherwise would have been a clear cut situation. These tend to be net-negative producers whose removal from their group would be a classic case of “addition by subtraction.”

Complexity Adders

Complexity adders don’t manufacture any complexity themselves, but they do find a way to add it to the group. If you think of complexity as a sort of commodity, complexity adders move it from the world scope into the group scope. Generally, this is done without any ill-intent whatsoever and is primarily an accident. Perhaps the easiest example to understand would be a new Director of Software Development coming into a shop, sizing up the team, and introducing some kind of development process with all sorts of gates, phase exits, orchestration components and other elaborate things designed to solve problems that the team may face someday. New director is bringing a complicated ‘solution’ with him from the outside world and introducing it to the team. Usually this sort of thing doesn’t go particularly well.

Zooming out a bit, complexity adders are those who attempt good faith solutions but inadvertently muddy the waters. In their wake, they tend to leave a fair bit of confusion. There’s also an unfortunate insidious element to this type of team member in that their effort is often unimpeachable. That is, they really believe in what they’re doing and will often put in 70 hour weeks to try to see it through. Complexity creators generate and inject complexity to hide shortcomings whereas complexity adders suffer simply from bungled execution.

Complexity Removers

These folks are probably people you think of as classic good teammates. They have a tendency to cut to the core of issues and eliminate a lot of nonsense. Pragmatic solutions that make people’s lives easier are their bread and butter. If you’ve got too much on your plate and you’re stressed out, they’ll suggest that you punt some of it over to another group. If a BA or external stakeholder comes over with garbled requirements, a complexity remover will put the brakes on and insist on better input.

Complexity removers move complexity from within the group to somewhere else. As far as the group is concerned, they’re eliminating complexity and, since the world consists of lots of nested groups, they’re often improving things on the whole by shuffling it to where it belongs. Complexity removers are people that you’ll tend to remember fondly in some capacity or another as you go on about your career.

Complexity Annihilators

These people are game changers. Complexity removers do what they do via tweaks and incremental improvements, whereas complexity annihilators do something different. The former look for simpler ways to execute the existing solutions they have to the problem whereas the latter simply define different solutions. To put a little bit more concreteness to this, consider a scenario where a team was struggling to implement a web app that kept track of todo items and let you mark them as “in progress” or “finished.” A complexity remover might suggest first putting out a version that was just a single list and then implementing states later. Or, perhaps she would advocate using a client side javascript framework instead of struggling with the home-rolled version the team was using.

But a complexity annihilator would say something like, “dude, why don’t you just use Trello? Here, I’ll show you.” And, as the look of disbelief settles over the other team members, all present can sense the complexity just winking out of existence. Poof — gone! Now that we’ve solved that, what’s next?!

This is a pretty contrived example, but it illustrates the point — the game change. Complexity annihilators find ways to radically simplify the lives of those around them and without moving complexity anywhere. They just, well, annihilate it. And they’re good at it. I mention this last bit because someone who fails at this and oversimplifies into the realm of wrong or absurd (e.g. suggesting Trello as a solution for automated grammar corrections) is actually a complexity adder, by virtue of bringing some new, irrelevant idea into the mix.

So What?

As I mentioned earlier, I have an operating hypothesis that you can classify people along this spectrum pretty widely. I’ve talked exclusively about technical problems, by way of example, but think even of interpersonal relationships. Humans and their interactions are complicated, and it’s pretty easy to do something wrong and inadvertently annoy others or create destructive tension, which is a complexity-add (since tension represents a source of impediments). Complexity creators and adders in this context will tend to foment strife, deliberately or inadvertently. Complexity removers will diffuse situations and annihilators will invent ways to make said tension impossible (e.g. preventing arguments over coding standards by implementing an auto-format on the build machine).

This idea hasn’t percolated enough in my head for me to suggest interviewing tactics to elicit complexity adders, so I’d be open to suggestions. But, if we could come up with some, I think that it could shift the focus to something more productive than trying to figure out if people had X years of C# or whatever. And, as individuals, I think we could all do well to evaluate ourselves along this spectrum. I don’t think any of us are born into one of these buckets, per se, so improvement is certainly possible. It seems a worthy goal to me that we should all strive to be complexity annihilators.