Pride, Prejudice, and Professionalism in the Business of IT

Twenty-plus years in IT have led me to believe that there are very few absolutes when it comes to software systems. Two that do seem to hold true are these:

1. Creating systems is esteemed far more highly than maintaining systems.
2. Systems that are not maintained, will decay.

There are a variety of reasons for this situation, many of which are baked into the architecture of the enterprise. Regardless of the why, however, the two facts remain. Without a response to those issues, entropy is inevitable.

Over the past few days, I’ve seen several blog posts by two different authors dealing with this situation in two different ways:

• Jason Gorman posted “IT’s Original Sin: Separating Authority & Expertise” Saturday and followed up with “Do It Anyway” yesterday.
• John Cutler posted “Learned Helplessness and the Ops Death-Spiral” Sunday.

Jason complains about the non-technical “leadership class” in his first post:

And hence we get someone making the big decisions about healthcare who knows nothing about medicine or about running hospitals or ambulance services. And we get someone in charge of all the schools who knows nothing about teaching or running a school. And we get someone in charge of a major software company whose last job was being in charge of a soft drinks company. And so on.

Again, this is fine, if they leave the technical decisions to the technical experts. And that’s where it all falls down, of course. They don’t.

The guy in charge of the NHS insists on telling doctors and nurses how they should do their jobs. The woman in charge of UK schools insists on overriding the expertise of teachers. The guy in charge of a major software company refuses to listen to the engineers about the need for automated testing. And so on.

This is the Dunning-Kruger effect writ large. CEOs and government ministers are brimming with the overconfidence of someone who doesn’t know that they don’t know.

In his second post he follows up with how to respond:

My pithy – but entirely serious – advice in that situation is Do It Anyway^TM.

There are, of course, obligations implied when we Do It Anyway^TM. What we’re doing must be in the best interests of stakeholders. Do It Anyway^TM is not a Get Out Jail Free card for any decision you might want to justify. We are making informed decisions on their behalf. And then doing what needs to be done. Y’know. Like professionals.

I disagree. Strenuously.

If you go to the doctor and they tells you that you will need surgery at some point for some condition, would you expect to be forcibly admitted and operated on immediately?

If you were charged with a crime, would you expect your attorney to accept a plea bargain on your behalf without consultation or prior permission?

If neither of those professionals would usurp the right of their client/patient to make their own informed decision, why should we? Both of those examples would be considered malpractice and the first would be criminal assault in addition. Therefore, I disagree that acting on someone’s behalf without their knowledge or consent is a viable option.

John’s approach, rejecting helplessness and confronting the issues by communicating the costs (with justifications/evidence) is, in my opinion, the truly professional approach. We have a responsibility to make the problem visible and continue making it visible. We also have a responsibility to operate within the limits we’re given. We know far more about our area than someone higher up the management chain, but, that does not equate to knowing more in general than those higher up the management chain. Ignorance is relative. Micro-managing, getting deeper in the weeds than you need to is ineffective. If, however, you’re in the weeds, do you have the information necessary to say that the issue being “interfered with” is one without higher-level consequences? Dunning-Kruger can cut a wide swathe. Trust needs to cut both ways.

Imagine riding as a passenger in a car. You see the car drifting closer and closer to the shoulder. Do you point it out to the driver or do you just grab the wheel? You might prevent an accident or you just might cause one by steering into a vehicle coming up from behind that you didn’t see from your vantage point.

[Plymouth Savoy photo by Christopher Ziemnowicz via Wikimedia Commons]

Fear of Failure, Fear and Failure

Some things seem so logically inconsistent that you just have to check them out.

Such was the title of a post on LinkedIn that I saw the other day: “Innovation In Fear-Based Cultures? Or, why hire lions to be dogs?”. In it, Michael Graber noted that “…top-down organizations have the most trouble innovating.”:

In particular, the fearful mindsets that review, align, and sign off on “decks” to be presented to Vice President-level colleagues often edit out the insights and recommendations that have the power to grow the business in new ways.

These well-trained, obedient keepers of the status quo are rewarded for not taking risks and for not thinking outside of the existing paradigm of the business.

None of this is particularly shocking, a culture of fear is pretty much the antithesis of a learning culture and innovation in the absence of a learning culture is a bit like snow in the desert – not impossible, but certainly remarkable.

Learning involves risk. Whether the method is “move fast and break things” or something more deliberate and considered (such as that outlined in Greger Wikstrand‘s post “Jobs to be done innovation”), there is a risk of failure. Where there is a culture of fear, people will avoid all failure. Even limited risk failure in the context of an acknowledged experiment will be avoided because people won’t trust in the powers that be not to punish the failure. In avoiding this type of failure, learning that leads to innovation is avoided as well. You can still learn from what others have done (or failed to do), but even then there’s the problem of finding someone foolhardy enough to propose an action that’s out of the norm for the organization.

Why would an organization foster this kind of culture?

Seth Godin’s post, “What bureaucracy can’t do for you”, holds the key:

It lets us off the hook in many ways. It creates systems and momentum and eliminates many decisions for its members.

“I’m just doing my job.”

“That’s the way the system works.”

Decisions involve risk, someone could make the wrong one. For that reason, the number of people making decisions should be minimized (not a position I endorse, mind you).

That’s the irony of top-down, bureaucratic organizations – often the culture is by design, intended to eliminate risk. By succeeding in doing so on the mundane level, the organization actually introduces an existential risk, the risk of stagnation. The law of unintended consequences has a very long arm.

This type of culture actually introduces perverse incentives that further threaten the organization’s long-term health. Creativity is a huge risk, you could be wrong. Even if you’re right, you’ve become noticeable. Visibility becomes the same as risk. Likewise, responsibility means appearing on the radar. This not only discourages positive actions, but can easily be a corrupting influence.

Fear isn’t the only thing we have to fear, but sometimes it’s something we really need to be concerned about.

---

This post is another installment of an ongoing conversation about innovation with Greger Wikstrand.

Leadership Anti-Patterns – The Thinker

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

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.

Leadership Patterns and Anti-Patterns – The Growler

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.

Form Follows Function on SPaMCast 399

This week’s episode of Tom Cagley’s Software Process and Measurement (SPaMCast) podcast, number 399, features Tom’s essay “Storytelling: Developing The Big Picture for Agile Efforts”, Kim Pries on deliberate practice, and a Form Follows Function installment on customer-centricity for IT.

Tom and I discuss my post “A Meaningful Manifesto for IT”. It seems obvious that the business of IT is meeting needs, but how many organizations are really happy with what they’re getting? The prevalence of “shadow IT” would seem to indicate that there’s some real discontent.

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

A Meaningful Manifesto for IT

“Customer-centricity” is one of the biggest tags in the tag cloud to the right. My first post this year was “Is 2016 the Year for Customer-Focused IT?”. It’s a concept that I find vitally important to IT for the simple reason that to the extent that IT is not fit for purpose, it’s a waste of money. How well (or not) we’re meeting the needs of our clients determines that level of fitness.

Seth Godin’s recent post, “A manifesto for small teams doing important work”, contains a great deal of wisdom for IT, primarily because it starts with a customer-centric approach:

If you make a promise, set a date. No date, no promise.

If you set a date, meet it.

If you can’t make a date, tell us early and often. Plan B well prepared is a better strategy than hope.

…

Talk to everyone as if they were your boss, your customer, the founder, your employee. It’s all the same.

It works because it’s personal.

Trust is a crucial basis for a relationship, and IT is in the relationship business, or it’s operating at a disadvantage. IT is pricey, so without the value provided by a good relationship, there is a tremendous incentive to shop based on price. If corporations had been better at managing outsourced software development, insourcing might not be the current trend. The current issue of “shadow IT” certainly belies the notion that companies are happy with the service they’re getting.

IT doesn’t exist in a vacuum. IT systems, the social system(s) by which they’re provisioned, and the social systems which make use of them must all work together in reasonable harmony or risk dysfunction. I’m of the opinion that embedded IT (whether literal or figurative) would be useful in bridging the gap. Humility and responsibility would go a long way toward helping. Likewise, tailoring solutions to problems would help better than chasing fads is a good strategy. Meeting needs will get a better reception than attempts to control, particularly when we attempt to control what we don’t own. At the very least, we need to learn to communicate.

Those are principles I can get behind.

Negotiating Estimates

In my previous post dealing with Ron Jeffries (since revised) “Summing up the discussion”, I focused strictly on the customer-focused aspects. I did, however, note some language regarding negotiating estimates that I wanted to touch on:

“Negotiating” estimates is deeply embedded into most cultures. It probably started in the marketplace in the village in ancient Greece, where the carrot guy tried to get three hemitetartemorions for his carrots, and your great-to-the-nth grandmother talked him down to one.
We assume that a contractor’s estimate has fat in it and we assume that we need tough negotiation to squeeze it out. The better the contractor is at estimating, the more this process hurts him, because he has nothing left to squeeze. And in the end, it hurts the buyer as well: the only way the contractor has to survive is to cut quality.

Jeffries is absolutely correct that negotiation is an ancient tradition. Likewise, he is correct that shaving an accurate estimate may well end up costing the customer in reduced quality (especially if giving point estimates, which is an incredibly poor practice, in my opinion). What he fails to mention, however, is that negotiating an estimate need not happen. In fact, negotiating an estimate without negotiating the deliverable is pretty much the worst possible thing you could do. You’re risking either your profit margin or any future business with the customer and quite possibly, both. It’s a bad idea for a vendor and incredibly ill-considered for in-house IT (it’s not like you can take the money and run).

In my opinion, when someone is willing to change an estimate without a change in what they’re estimating, it’s a bad sign. If you adequately understand the information at hand, have some experience, and have made a good faith effort, there’s no reason to be willing to change the estimate without learning more about what is or is not needed. It’s not really a negotiation if only one party is getting what they want, particularly if the other party is getting abused. For the abused party, striking back (by shaving quality without the customer’s knowledge) is counter-productive. The only negotiation should be what’s in scope and what’s not.

In a balanced relationship, the provider can explain what the customer is getting for their money and the customer realizes they won’t get something for nothing. Communication and collaboration can provide the basis for trust. Trust is essential for both parties to become partners in delivering the best possible product.

‘Customer collaboration over contract negotiation’ and #NoEstimates

Since my last post on #NoEstimates, the conversation has taken an interesting turn. Steve McConnell weighed in on July 30th, with a response from Ron Jeffries on the following day. There have been several posts from each since, with the latest from Jeffries titled “Summing up the discussion”. In that post, he states the following (emphasis added):

The core of our disagreement here is that Steve says repeatedly that if the customer wants estimates, then we should give them estimates. He offers the Manifesto’s “Customer collaboration over contract negotiation”1 as showing that we should do that. (It’s interesting that he makes that point in a kitchen where surely he expects that the couple and the contractor(!) are going to negotiate a contract.)

To anyone who has been even minimally involved with business, the idea that a contract will be negotiated should not a surprise, no matter how agile the provider. In spite of his footnote warning “I confess that I am singularly unamused when people bludgeon me with quotes from the Manifesto”, I have to note that the Agile Manifesto does say “…while there is value in the items on the right, we value the items on the left more” rather than “only the items on the left have value”.

In the post, Jeffries says that in an agile transformation, the “…contractor-customer relationship gets inverted”. I have to confess that the statement is a bit baffling. A situation where “the customer is always right” can certainly degrade into a no-win scenario. Inverting that relationship, however, is equally bad. Good, sustainable business relationships should be relatively (even if not perfectly) balanced. Moving away from minutely detailed contracts that prevent any change without days of negotiation just makes sense for both parties. Eliminating all obligation on the part of the provider, however, is a much harder sell.

Jeffries asserts that “Agile, if you’ll actually do it, changes the fundamental relationship from an estimate-commitment model to a truly collaborative stream of building up the product incrementally.” If, however, you fail to meet your customer’s needs (and, as I pointed out in “#NoEstimates – Questions, Answers, and Credibility”, one of the best lists of why estimates are needed for decision-making comes from Woody Zuill himself), how collaborative is that? Providing estimates with the caveat that they are subject to change as the knowledge about the work changes is more realistic and balanced for both parties. That balance, in my opinion (and experience) is far more likely to result in a collaboration between customer and provider than any inversion of the relationship.

Trust, is essential to fostering collaboration. If we fail to understand our customers’ needs (which impression is given when we make statements like that in the tweet below), we risk fatally damaging the trust we need to create an effective collaboration.

Have marketing sell the product AFTER its finished. #NoEstimates

— Chris Lucian クリス (@ChristophLucian) August 23, 2015

#NoEstimates – Questions, Answers, and Credibility

#NoEstimates #LegoSeriousPlay pic.twitter.com/429Z3MenB1

— Mikael Helldén (@MikaelHellden) June 10, 2015

@MikaelHellden So cute. So frighteningly cute. What a tangled web we weave when first we introduce estimates to manage software development.

— Woody Zuill (@WoodyZuill) June 10, 2015

@aliaslxp Gotta make the customer happy! Or at least "the process"... 😉 @WoodyZuill

— Mikael Helldén (@MikaelHellden) June 10, 2015

This is questioning?

A recent episode of Thomas Cagley’s SPAMCast featured Woody Zuill discussing #NoEstimates. During the episode, Woody talked about his doubts about the usefulness of estimating and the value of questioning processes rather than accepting them blindly.

I’m definitely a fan of pragmatism. Rather than relying on dogma, I believe we should be constantly evaluating our practices and improving those found wanting. That being said, to effectively evaluate our practices, we need to be able to frame the evaluation. It’s not enough to pronounce something is useful or not, we have to be able to say who is involved, what they are seeking, what the impact is on them, and to what extent the outcome matches up with what they are seeking. Additionally, being able to reason about why a particular practice tends to generate a particular outcome is critical to determining what corrective action will work. In short, if we don’t know what the destination looks like, we will have a hard time steering toward it.

In his blog post “Why do we need estimates?”, Woody (rightly, in my opinion) identifies estimates as a tool used for decision-making. He also lists a number of decisions that estimates can be used to make:

• To decide if we can do a project affordably enough to make a profit.
• To decide what work we think we can do during “a Sprint”. (A decision about amount)
• To decide what work we should try to do during “a Sprint”. (A decision about priority or importance)
• To decide which is more valuable to us: this story or that story.
• To decide what project we should do: Project A or Project B.
• To decide how many developers/people to hire and how fast to “ramp up”.
• To decide how much money we’ll need to staff a team for a year.
• To give a price, or an approximate cost so a customer can decide to hire us to do their project.
• So we can determine the team’s velocity.
• So marketing can do whatever it is they do that requires they know 6 months in advance exactly what will be in our product.
• Someone told me to make an estimate, I don’t use them for anything.

What is missing, however, is an alternate way to make these decisions. It’s also missing from the follow up post “My Customers Need Estimates, What Do I do?”. If the customer has a need, does it seem wise to ask them to abandon (not amend, but abandon) a technique without proposing something else? Even “let’s try x instead of y” is insufficient if we can’t logically explain why we expect “x” to work better than “y”. The issue is one of credibility, a matter of trust.

In her post “What Creates Trust in Your Organization?”, Johanna Rothman related her technique for creating trust:

Since then, I asked my managers, “When do you want to know my project is in trouble? As soon as it I think I’m not going to meet my date; after I do some experiments; or the last possible moment?” I create trust when I ask that question because it shows I’m taking their concerns seriously.

After that project, here is what I did to create trust:

1. Created a first draft estimate.
2. Tracked my work so I could show visible progress and what didn’t work.
3. Delivered often. That is why I like inch-pebbles. Yes, after that project, I often had one- or two-day deliverables.
4. If I thought I wasn’t going to make it, use the questions above to decide when to say, “I’m in trouble.”
5. Delivered a working product.

While I can’t say that Johanna’s technique is the optimal one for all situations, I can at least explain why I can put some faith in it. In my experience, transparency, collaboration, and a respect for my stakeholders’ needs tends to work well. Questions without answers? Not so much.