Leadership Anti-Patterns – The Thinker

'The Thinker' by Rodin

My interest in leadership, how it works and how it fails, goes back a long way. Almost as soon as I learned how to read, history, particularly military history, has been a favorite of mine. Captains and kings, their triumphs and their downfalls, fascinated me. The eleven years I served with the Henrico Sheriff’s Office honed that interest. It allowed me to go beyond theory and the hearsay attendant in just reading about leaders. It allowed me to both observe firsthand and to get practical experience of my own.

For most of the latter part of my career with the Sheriff’s Office, I led a unit responsible for providing support services for the jail (canteen, recreation, laundry, hair-care, maintenance, and coordination of volunteer programs). In addition to their primary function, members of my unit, as sworn staff, also served as a ready reserve to the security staff during the busiest parts of the day. It was a challenge for me, because I was responsible for managing a group of experts with diverse duties. It was a challenge for them, because the way I led was something of a change for them.

Like everyone, I started my career working a security platoon in the jail. My second posting, however, was in our training academy. Roughly half of my responsibilities involved record keeping and administration of the training program. The other half of my time was spent in class, delivering training. Something about that resonated with me; I loved it and it strongly influenced my leadership style.

When necessary, I was fully capable of issuing orders to be complied with immediately. The operative word here being “necessary”. What’s necessary under emergency conditions and what’s necessary the other ninety-nine percent of the two are two different things. The majority of the time, my leadership style involved more coaching and little or no dictating.

I still laugh when I think of the first time a subordinate came to me for a decision. After her laying out the problem, rather than serving up a solution, I asked a simple question, “What do you want to do about it?” The speechless expressions I received in response were priceless. Having someone in authority ask for her opinion was so utterly foreign as to be beyond belief.

[Note – this is not the same thing as “don’t bring me problems, bring me solutions”. That type of bumper sticker philosophy is a good way to have people avoid you when they don’t know what to do, which is when they actually need you the most (and likewise, when you most need to know what they’re dealing with).]

By making sure that those who worked under me knew the boundaries they had to work with, we were able to divide things into three groups: the routine that was unremarkable, that which they could deal with on their own and tell me later, and that which they needed to get me involved in up front. Even with the last category, I asked for opinions. If it was a decision that I could make, my bias was to go with their recommendation unless I had a really good reason not to (as I noted above, most were specialists and knew the details of their position far better than I, so overruling them solely because I was “in charge” would be a really bad idea). When the decisions were above my pay grade, I would still give them credit and endorse their recommendation. My goal was to have a unit that could operate as well when I was not there as when I was.

At this point, you may be wondering where’s the information about this “Thinker” anti-pattern. All the background above, is to serve as contrast to one of my colleagues, a lieutenant in charge of a jail security platoon. This person informed their platoon that they were paid to do the thinking and their subordinates were paid to do the doing. No one other than this lieutenant was allowed to make any decisions, period. While I doubt this person had ever heard of Taylorism, they had a firm grasp of the principles of it.

Under the most normal of circumstances, there’s much to criticize about The Thinker’s way of doing things. The method doesn’t scale. It places a lot of burden on the Thinker. Getting a bathroom break in between decisions to be made is hard enough, but vacation? Forget about it.

The thing about a jail is that it’s not the most normal of circumstances, so there’s an added disadvantage. In the event of a hostage situation (something that’s more of a risk in a correctional environment), if the Thinker was the hostage, then they would be in for a very long ordeal. Unless one of their subordinates decided to ignore the Thinker’s orders and call for help, they would be stuck until someone “authorized” to think reported for duty.

Ignorance of the law (of unintended consequences) is no excuse.

Why does software development have to be so hard?

Untangling this could be tricky

A series of 8 tweets by Dan Creswell paints a familiar, if depressing, picture of the state of software development:

(1) Developers growing up with modern machinery have no sense of constrained resource.

(2) Thus these developers have not developed the mental tools for coping with problems that require a level of computational efficiency.

(3) In fact they have no sensitivity to the need for efficiency in various situations. E.g. network services, mobile, variable rates of change.

(4) Which in turn means they are prone to delivering systems inadequate for those situations.

(5) In a world that is increasingly networked & demanding of efficiency at scale, we would expect to see substantial polarisation.

(6) The small number of successful products and services built by a few and many poor attempts by the masses.

(7) Expect commodity dev teams to repeatedly fail to meet these challenges and many wasted dollars.

(8) Expect smart startups to limit themselves to hiring a few good techies that will out-deliver the big orgs and define the future.

The Fallacies of Distributed Computing are more than twenty years old, but Arnon Rotem-Gal-Oz’s observations (five years after he first made them) still apply:

With almost 15 years since the fallacies were drafted and more than 40 years since we started building distributed systems – the characteristics and underlying problems of distributed systems remain pretty much the same. What is more alarming is that architects, designers and developers are still tempted to wave some of these problems off thinking technology solves everything.

Why?

Is it really this hard to get it right?

More importantly, how do we change this?

In order to determine a solution, we first have to understand the nature of the problem. Dan’s tweets point to the machines developers are used to, although in fairness, those of us who lived through the bad old days of personal computing can attest that developers were getting it wrong back then. In “Most software developers are not architects”, Simon Brown points out that too many teams are ignorant of or downright hostile to the need for architectural design. Uncle Bob Martin in “Where is the Foreman?”, suggests the lack of a gatekeeper to enforce standards and quality is why “our floors squeak”. Are we over-emphasizing education and underestimating training? Has the increasing complexity and the amount of abstraction used to manage it left us with too generalized a knowledge base relative to our needs?

Like any wicked problem, I suspect that the answer to “why?” lies not in any one aspect but in the combination. Likewise, no one aspect is likely, in my opinion, to hold the answer in any given case, much less all cases.

People can be spoiled by the latest and greatest equipment as well as the optimal performance that comes for working and testing on the local network. However, reproducing real-world conditions is a bit more complicated than giving someone an older machine. You can simulate load and traffic on your site, but understand and accounting for competing traffic on the local network and the internet is a bit more difficult. We cannot say “application x will handle y number of users”, only that it will handle that number of users under the exact same conditions and environment as we have simulated – a subtle, but critical difference.

Obviously, I’m partial to Simon Brown’s viewpoint. The idea of a coherent, performant design just “emerging” from doing the simplest thing that could possibly work is ludicrous. The analogy would be walking into an auto parts store, buying components individually, and expecting them to “just work” – you have to have some sort of idea of the end product in mind. On the other hand, attempting to specify too much up front is as bad as too little – the knowledge needed is not there and even if it were, a single designer doesn’t scale when dealing with any system that has a team of any real size.

Uncle Bob’s idea of a “foreman” could work under some circumstances. Like Big Design Up Front, however, it doesn’t scale. Collaboration is as important to the team leader as it is to the architect. The consequences of an all-knowing, all-powerful personality can be just as dire in this role as for an architect.

In “Hordes of Novices”, Bob Martin observed “When it’s possible to get a degree in computer science without writing any code, the quality of the graduates is questionable at best”. The problem here is that universities are geared to educate, not train. Just because training is more useful to an employer (at least in the short term), does not make education unimportant. Training deals with this tool at this time while how to determine which tool is right for a given situation is more in the province of education. It’s the difference between how to do versus how to figure out how to do. Both are necessary.

As I’ve already noted, it’s a thorny issue. Rather than offering an answer, I’d rather offer the opportunity for others to add to the conversation in the comments below. How did we get here and how do we go forward?