Form Follows Function on SPaMCast 421


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!

Leadership Patterns and Anti-Patterns – The Growler

Grizzly Bear Attack Illustration

Prior to starting my career in IT (twenty years ago this month…seems like yesterday), I spent a little over eleven years in law enforcement as a Deputy Sheriff. Over those eleven years my assignments ranged from working a shift in the jail (interesting stories), to Assistant Director of the Training Academy, then Personnel Officer (even more interesting stories), and finally, supervisory and management positions (as many headaches as stories). To say that it was as much an education as a job is to put it mildly. I learned useful lessons about human nature and particularly about leadership.

One of the things that I learned is that leadership and management (they are related, but separate things) have patterns and anti-patterns associated with them. Just like in the realm of software development, it can be difficult to distinguish between what’s a pattern and what’s an anti-pattern (there’s an interesting discussing to be found on this topic in the classic “Big Ball of Mud”). Hammering a square peg into a round hole “works”, albeit sub-optimally. Pattern or anti-pattern?

One pattern/anti-pattern from my time with the Sheriff’s Office is what I call “The Growler”. A high-ranking member of the department was a master of this technique. When approached for something, particularly when the something in question was a signature on a purchase requisition, the default response was a profanity-laced growl (the person in question had retired from the Navy as a senior NCO) demanding to know why he should grant the request. This was extremely daunting, but I learned that the correct response was to growl back. When he growled, “%$@$ a !#&^ing $@!#*. More $%&^ing computer stuff, why the @#*& do you need this?”, I would answer, “You know when you ask me a question and I respond in five minutes instead of three hours”. This would result in a shake of his head, a “Yeah, yeah”, and most importantly, a signature.

More than just an endearing quirk of his character, it was a triage technique. If the person who wanted something tucked tail and ran, it wasn’t important. If, however, the person stood their ground, then he would put forth the effort to make a decision.

Right up front, I should make it clear that I don’t recommend this technique. First and foremost, Human Resources finds “salty” language even less endearing today than they did twenty-five plus years ago, and they weren’t crazy about it then. There’s also a big problem in terms of false negatives.

Most of my coworkers back in my badge and gun days were not shy, retiring types. Consequently, I never saw it backfire for that person. Later on, though, I did see it fail for an IT manager (and yes, while gruff, he was significantly less “salty” than the one at the Sheriff’s Office). This manager had a subordinate who would retreat no matter how valid the need. Consequently, that subordinate’s unit, one that several of us were dependent on, was always under-staffed and under-equipped. When his people attended training, it was because someone else had growled back for him. It was far from the optimal situation.

While not quite as bad as the “shoot the messenger” anti-pattern I touched on recently, “The Growler” comes close. By operating on a principle of fear, you can introduce a gap in your communications and intelligence network that you rely on (whether you know it or not) to get the information you need in a timely manner.

Fear encourages avoidance and no news now can be very bad news later.

“Microservices and API Complexity – Inside and Out” on Iasa Global

The signature benefit of a microservice architecture is that its highly granular nature allows for a great deal of flexibility in composing applications. Components are simplified by virtue of a high degree of focus. The ability to replace individual components is enhanced by the modularity inherent in the style.

A very significant drawback to microservice architecture is that its highly granular nature can lead to a great deal of complexity in composing applications. Highly focused components can force service consumers to become more involved in the internals of an interaction than they might otherwise wish. Unwanted options can become more of a source of confusion than useful modularity.

How do you resolve this paradox? See the full post on the Iasa Global Site

Fixing IT – IT as Concierge or General Contractor?

At your service

Last fall I had the pleasure of engaging Jeff Sussna, Christian Verstraete and Christian Reilly in a multi-day discussion on Twitter regarding IT’s relationship with cloud providers. As it developed, the conversation morphed into a discussion of potential metaphors for IT.

At the mention of “metaphor”, I’d imagine that eyes are glazing over, but bear with me while I establish its relevance to IT. Now Merriam-Webster tells us that “metaphor” is “a figure of speech in which a word or phrase literally denoting one kind of object or idea is used in place of another to suggest a likeness or analogy between them”. We find this same type of analogy used with patterns, the concept of which came out of Christopher Alexander’s A Pattern Language. In essence, these metaphors are patterns, communicating a potential solution to problems of enterprise IT architecture in the same way that “bridge” and “factory” communicate potential solutions to software design problems. As such, they provide a frame of reference to those of us within IT as well as those we serve. Their importance lies in the message they convey to both sides of the table.

Two candidate metaphors emerged from the discussion. Christian Reilly took the view that an IT department’s role should become like that of a concierge, a service aggregator. While agreeing in principle, I took the position that a better analogy was that of a general contractor. A general contractor works to meet the client’s needs, performing some services while subcontracting others out, in a manner similar to the concierge. The difference is that the contractor possesses a set of domain expertise useful for advising the client. The contractor is also bound by building codes that constrain him/her in delivering the customer’s requests. This describes what, in my opinion, the role of IT should be.

The dysfunctional situation described in the first post of this series, “Fixing IT – How to Make a Monster (Customer)”, defines the antithesis of an effective IT operation. “Fixing IT – Taming the (Customer) Beast”, the second post in the series, discusses some of the mindset changes needed to repair the relationship between IT and the business and why that relationship is so important. The third post, “Fixing IT – Products, Not Projects Revisited”, outlines the way delivery processes can affect IT’s relationship with the business. “Fixing IT – The Importance of Ownership”, the fourth post in the series, takes on how the issues of budget and ownership can affect the relationship. This post, will wrap up the series by bringing those issues together to outline my opinion on how IT can move forward in spite of the challenges it faces today.

The ZDNet post that inspired the discussion I mentioned above, “4 ways IT can rise above outside cloud competitors”, is an excellent example of how IT can turn things around by providing additional value to cloud services. This can be done by acting as a pseudo-VAR in place of acting as a competitor as the ZDNet article proposed. In either case, IT provides real value to the business via its specific knowledge of both the business domain and the in-house technical environment. This approach, advocated by Christian Verstraete in his HP Blogs post “Respond to Shadow-IT, source services from external providers”, is becoming more and more necessary because 7 out of 10 organizations are using unapproved cloud applications (according to a study from January, 2013).

IT has been in this position before. Thirty years ago the disruptive, security challenging technology that IT had no time and budget for was the PC. History teaches that that genie is not going back in the bottle. Instead, the winning approach is to enable the use of technology that furthers the goals of the business (which is all the business wants, anyway) in a safe manner.

The words “in a safe manner” above is what makes the general contractor metaphor appropriate. IT serves two sets of masters, the individual business units and the enterprise as a whole. Sometimes, the interests of a business unit can conflict with those of the organization as a whole. In these situations, IT has a valid reason to refuse to break the rules (although finding a way to achieve the desired outcome and stay within the rules is better than a flat refusal). What is important is that the rules, as such, are not owned by IT, but by the organization. IT is well placed to advise the enterprise about the technical capabilities and trade-offs around decisions regarding security, business processes, etc. It is inappropriate, however, for IT to attempt to dictate these decisions (this is actually an example of a business unit’s interests potentially conflicting with those of the enterprise). Steve Jones illustrated how counter-productive this usurpation can be in his post “Why your IT strategy failed or why the business hates IT”:

IT Guy: “The new systems have new processes and we need to tell you what they are so you can change.”

Business Guy: “Have you done an impact analysis against our current processes?”

IT Guy: “No we’ve just defined the Best Practice To-Be processes, you need to do the impact and change management. We need the meeting so we can tell you what the To-Be processes are”

Business Guy in a voice so dripping with sarcasm I thought we’d have a flood: “I look forward to our IT department telling the business what Best Practice is for our industry.”

IT Guy, completely failing to read the sarcasm: “Great we’ll get it organised”

Some take exception to referring to “the business”, observing that IT is part of the business. This, of course, is true. However, the best way to demonstrate that is not via the terms used in conversations, but via the support given to executing the enterprise’s strategy. Making things happen is the way show that support.