Form Follows Function on SPaMCast 430

SPaMCAST logo

It’s time for another appearance on Tom Cagley’s Software Process and Measurement (SPaMCast) podcast.

This week’s episode, number 430, features Tom’s essay on product owners, Steve Tendon with more on TameFlow (in this episode, constraints), and a Form Follows Function installment based on my post “Leadership Anti-Patterns – The Thinker” (the third in a series on leadership).

The Thinker is a classic leadership anti-pattern hearkening back to Frederick Taylor. In essence, the leader does the thinking and the peons do the doing. What could go wrong? Tune in to hear Tom and I discuss all the problems this anti-pattern can bring.

You can find all my SPaMCast episodes using under the SPAMCast Appearances category on this blog. Enjoy!

Form Follows Function on SPaMCast 425

SPaMCAST logo

I’m ringing in 2017 with another appearance on Tom Cagley’s Software Process and Measurement (SPaMCast) podcast.

This week’s episode number 425, features Tom talking about annual tune-up ideas, Steve Tendon with more on TameFlow (re: kanban, flow, and throughput), and a Form Follows Function installment based on my post “Leadership Anti-Patterns – The Great Pretender”.

In my last SPaMCast segment, I discussed the Growler, which had elements of both pattern and anti-pattern. Not so the Great Pretender, it’s clearly an anti-pattern that is as if someone mixed impostor syndrome and the Dunning-Kruger effect together and skimmed off the most detrimental parts of each.

You can find all my SPaMCast episodes using under the SPAMCast Appearances category on this blog. Enjoy!

Situational Awareness – Where does it begin? Where does it end?

Infinity symbol

Situational awareness, according to Wikipedia, is defined as “…the perception of environmental elements and events with respect to time or space, the comprehension of their meaning, and the projection of their status after some variable has changed, such as time, or some other variable, such as a predetermined event”. In other words, it’s having a handle on what currently is and what is about to happen. It’s a concept that is invaluable to a wide range of interests, particularly management/leadership, architectural design, and innovation. It’s a concept that crosses levels, from tactical to strategic. Just as socio-technical systems architectures exist in a fractal space (application to solution to enterprise), so too does the concept of situational awareness. As such, it’s a common theme for this site, particularly over the last year or so.

The OODA (Observe-Orient-Decide-Act) Loop, developed by Air Force Colonel John Boyd, is a framework for decision-making that explicitly incorporates situational awareness:

OODA Loop Diagram

Coupling sense-making with decision-making is critical to achieve a balance of both speed and effectiveness. In my opinion, acting without taking the state of the environment into account is a recipe for disaster. Equally important (likewise, in my opinion), is understanding the dynamic nature of situational awareness. As Boyd’s diagram above shows, it’s not a linear process. Additionally, the very nature of a loop should convey the fact that there’s neither beginning nor end. This is a key concept.

One of the sites that I follow is Slightly East of New, which is run by an associate of Boyd’s and dedicated to his theories. A recent post on that site, “The magic of the OODA loop”, related a paragraph from a sci-fi novel, The Apocalypse Codex, that referred to OODA:

Observe, orient, decide, act: words to live or die by. Right now, Persephone is disoriented — on the run, cut off. It’s time to go on the offensive, work out where she is and what’s going on, then get the hell out of this trap.

It was an interesting post, but nothing noteworthy, until I got to this comment:

I find the phrase, “…on the run, cut off.” very interesting, within the context of “disoriented”. To me, “on the run” mean a decision has been made and acted on, whereas “disorientation” usually means that one can’t make a decision.
Likewise, “cut off” is the position you find yourself in, after all the decisions have been made and, after thinking about it, it is the posture you observe yourself to be in.
In other words, on the run and cut off is not really a disorientation, but a reality.
So, while you may not survive, you have made a decision to run or you are about to make a decision and join the otherside.
I suppose it just depends on where those words show up in the narrative, as to if you made the decision or your competitor made the decision for you.

I may be over-sensitive to the phrasing, but “…decision has been made and acted on…” and “…after all the decisions have been made…” strike me as being too static and too linear. Every action/inaction follows on decision/indecision. The point “…after all the decisions have been made…” is terminal (for the person who has made all the decisions they will make). In my opinion, it is key to bear in mind that the clock is always running and that the reality being processed is already past. Too much attention to the state of what is (or rather, was) takes away from the more important task of getting to a better “to be” state. Additionally, decisions and contexts should be thought of as not just linear, but fractal (e.g. having multiple levels from tactical through strategic) as well.

Loops that have an end are no longer loops. Likewise, we have to be able to strike a balance between just focusing on what’s relevant (too much context/backstory can cause information overload) and the point where we’ve trimmed away necessary context.

Actively thinking about sense-making and decision-making can seem overly academic. The activities are so foundational to nearly everything that they can feel instinctual rather than learned. I suspect that’s a case of “familiarity breeds contempt”. Depending on the application, contempt for developing the best possible situational awareness could be fatal.

[OODA Loop diagram by Patrick Edwin Moran via Wikimedia Commons]

Form Follows Function on SPaMCast 421

SPaMCAST logo

This week’s episode of Tom Cagley’s Software Process and Measurement (SPaMCast) podcast, number 421, features Tom on vanity metrics (“feel good, less useful”), Steve Tendon discussing TameFlow, and a Form Follows Function installment based on my post “Leadership Patterns and Anti-Patterns – The Growler”.

Ever deal with a “crusty” leader who used an “unwelcoming” attitude to filter demands on their attention? Tom and I discuss this leadership pattern (it works, sort of, so you can’t rightly classify it as an anti-pattern) and the very real downsides that make it problematic.

You can find all my SPaMCast episodes using under the SPAMCast Appearances category on this blog. Enjoy!

Babies, Bathwater, and Software Architects

'Fixing Problems' - XKCD 1739

I try to be disciplined about my writing (picking themes, creating a backlog, collecting notes and links on those topics, etc.), but it seems like serendipity won’t be denied, no matter what I do. On the same day that XKCD published this cartoon, Erik Dietrich published “Software Architect as a Developer Pension Plan”. While I agree with a lot that Erik says in the post, I think he also gets into a “throwing out the baby with the bathwater” situation by dismissing the need for the software architect role, part of which the cartoon illustrates.

Before I go any farther, I do need to point out that I’ve been following and interacting with Erik for about four years now. It’s a friendly disagreement; meant to be more debate than argument.

In the post, Erik makes the point (which I largely agree with) that companies see the role of software architect through a Taylorist lens. They see the software architect as a “thinker”, meant to drive a herd of “doers”:

The modern corporation, like Taylor before it, loosely divides into three categories of humans: owners/executives, managers, and grunts. Owners own and charge executives with executing their will. Executives delegate to managers. Managers think and assemble the workers into org charts designed to optimize efficiency. Workers keep their simple heads down and do as they’re told.

Theoretically, proponents would say, this applies to any domain and type of work. Corporations form themselves into these pyramids without considering any other options, whether they’re private military outfits, gigantic manufacturing facilities, or companies designing and selling software. Of course, the reality turns out to be that not all operations do well splitting thinking and labor. Let’s pick one at random. Oh, I dunno, say, writing software.

We try it. We hire junior developers to be directed by senior ones. And all of them fall in line under the watchful guise of a “tech lead,” who defers to a council of architects. And somewhere at the center of the organizational maelstrom stands The Lead Architect, directing elaborate bucket marches, water flows, and all sorts of magic, like Mickey Mouse in Fantasia. It’s a beautiful, cascading symphony of work flowing from the cleverest down to the simplest. Or… at least, that’s how it goes on paper.

Erik rightly argues that this model is fatally flawed. This is doubly so in the case of the example he gives, an individual offered a position as a software architect doing the thinking for a set of offshore “commodity” developers. Offshore development can be done well (that’s a post I’ll save for another day), but not using that model. Where Erik goes wrong, in my opinion, is in adopting this flawed definition of the software architect role.

Developers should be perfectly competent to do their own thinking. If they’re not, no software architect will be able to help. Even if that person were capable of handling the load of providing detailed directions for several developers, doing so would prevent them from attending to their own areas of concern. It would require being able to anticipate and make all the functional design decisions up front, as well as communicating them to multiple “typists” quicker than they could mindlessly hammer out the code, while still having time to consider all the requisite cross-cutting, quality of service considerations for an application. Do we really need to bother with experiments to determine that this is beyond improbable?

There is a separation between the developer role and software architect role, but it needs to be clearly understood as a difference in focus. A developer’s focus is more vertical, concentrating on implementing functionality while maintaining/improving/not harming the quality of service (aka the horrendously misnamed “non-functional”) aspects of the system. A software architect’s focus should be more horizontal, concentrating on the architecturally significant quality of service aspects that will enable the system to meet the needs of its stakeholders (or, at least, not unreasonably prevent the system from doing so).

The difference between the roles is a matter of thinking at different levels of abstraction, not of one being superior to the other. The two mindsets are both necessary and complementary. A high-quality architectural design without quality implementation cannot produce a high-quality system. Likewise, where there is implementation without architectural coordination, the quality of the resulting system is a matter of chance. For very small systems maintained by small, permanent teams, it may not be necessary for these roles to be distinct. In my experience, however, dealing with both the broadly general and the very specific at the same time scales poorly. Non-trivial systems quickly come to require architectural leadership, otherwise people are left fixing problems caused by problems fixed previously.

Leadership has been the main theme of almost all of my posts this month and has figured prominently in several of what’s been written this year. Many of these posts are assigned to the “Architectural Practice” category. This is because I absolutely believe that the software architect role is a leadership role. That being said, I don’t consider the Taylorist model to be effective leadership practice. In fact, I consider it an anti-pattern.

I’ve long been an advocate of a more collaborative model of practice. Rather than dictating, the software architect’s role should be one of consensus building and communication. Significant architectural disagreement indicates an issue with one or more members of the team. Significant uncertainty about the architecture indicates an issue with the software architect role.

Effective systems require both breadth and depth of effectiveness. This holds true for software systems as much as social systems. For the social systems producing software systems for use by other social systems (i.e. software development teams), it is imperative.

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.

Leadership Anti-Patterns – The Great Pretender

Roman Mosaic with Tragedy & Comedy Masks as gargoyles above a water basin

My previous leadership type, the Growler, was hard to classify as it had aspects of both pattern and anti-pattern. The Great Pretender, however, is much easier to label. It’s clearly an anti-pattern.

Before entering the working world full-time, I worked in the retail grocery business (both of my parents also had considerable industry experience, both retail and wholesale). I ran into this type more than once. The type is distinguished by a lack of domain knowledge and/or experience, coupled with an apparent inability to trust anyone with knowledge and/or experience. Consequently, the default method of decision-making appeared to be “whatever someone suggests, do something different”. It was as if someone had mixed impostor syndrome and the Dunning-Kruger effect together and skimmed off the most detrimental parts of each.

I remember one July Fourth holiday where a Great Pretender tripled the order for sliced-bread and cut the order for hamburger and hotdog rolls in half. This was based on reading something that said Americans were eating healthier. Unfortunately, that message wasn’t communicated to the Americans in our community (bear in mind, this was many years ago and July Fourth) and we wound up with customers unhappy that we had run out of what they wanted to buy and a lot of soon-to-expire bread that had to be marked down drastically so that it sold before going out of date. The failure to trust subordinates with the right expertise carries costs.

Another Great Pretender questioned his stock crew when he found them taking a break while a truckload of merchandise remained in the back room. The response, “Do you know how long it takes to get all that put on the shelf?” sent him scurrying away. The crew, who were malingering, had a good laugh.

The combination of lack of knowledge and lack of trust opens the door to an interesting manipulation strategy. When you want something from a Great Pretender, you never ask for it directly. It’s always “Boss, should I do this incredibly inane thing that no one in their right mind would do or should I do what I actually want to do?” The response from the Great Pretender is always “Do that second thing” (every single time). I leave it to you, dear Reader, to only use this knowledge for good, not evil.

The idea that someone in a leadership position should be the best at all they oversee is a pretty common one. More than once I’ve seen people claim that the have no respect for a leader that can’t do their job better than them. This attitude, however, fundamentally misunderstands the nature of leadership (hint, effective leadership is more about coordinating the team than doing any one job on the team). This attitude also demonstrates a lack of understanding of the cognitive capacity that would be required to lead a team involved in a minimally complicated undertaking (hint, effective leadership is more about coordinating the team than doing any one job on the team). This attitude also ignores the fact that a leader is responsible for tasks unique to their position (hint, effective leadership is more about coordinating the team than doing any one job on the team). When a team member has this attitude, it can be a problem.

When the leader buys into this attitude, we get the Great Pretender.

Leaders have their own roles and responsibilities to fulfill. This involves dealing with what’s appropriate to their role and relying on others for what’s appropriate to theirs. This requires communication and collaboration. Micro-managing and insecurity are counter-productive. The best leaders, in my opinion, are those that can recognize talent in others and gather around themselves a team of people with complementary strengths. They’re not the experts, but expert at helping a collection of experts come together for a common purpose. That involves placing trust in those being led.

Having to know it all can be fatal.