The Decision-Consequence Gap

Last time, I posted about an empowerment ratio, which can be an indicator of how much a company trusts its people to effect improvements in an organization's products and processes. Another concept I see that leads to difficulties for people is the decision-consequence gap. This term refers to the distance between a decision-maker and the consequences of his or her decisions.

Narrow Gap

When the gap is narrow, the decision-maker is cognizant of how his or her strategy is working; he knows whether unforeseen factors have made executing the plan more challenging and is aware of how subordinates are carrying out the tactics in meeting a plan's goals.

Wide Gap

When the gap is wide, the decision-maker lives in a vacuum and tends to take credit for success and pass blame for failures often without understanding how results are achieved or missed.

Gap Effects

This gap is a big factor in leadership, and most leaders seem to misunderstand or not care about it. It's not just in IT either, and dysfunction is visible within this concept across top leadership in all industries. And wide decision-consequence gaps often lead to poor empowerment ratios.

It's a harsh recipe especially in software development too, when functional owners and project managers are given strategic and tactical control over non-functional elements. Although not all will make mistakes here, under the duress of time constraints there is often a push to favor speed over quality. Non-functional concerns will be given little priority despite the advice of the developers presiding over the construction.

If you've ever supported poorly designed and poorly implemented software, then you are quite familiar with this already. The people that decide a team will cut corners to make a date are not the same people who have to support it and work the production support load.

The project manager's common refrain here is that if developers are left to their own devices, the product will never ship. I agree that developers who care and are perfectionists may draw the development cycle longer than is comfortable for the business. And it is often true too that developers, in the interest of pleasing management, will comply in promoting a shoddy release to make a date.

Cheap Fix for a Cheap Methodology

But what I hope for in a better and more mature IT world is not necessarily perfection. It is that we collectively strive for something better than the C-minus level software most corporations deal with now. Can we maybe compromise and get to a B grade? The difference between a C-minus and a B would be perhaps that:

• Some routines feature hard-coding, but that routine is properly isolated in a method that can be easily tested and refactored.
• We put more eyeballs on our database structure so that common pitfalls don't make it into production and compromise future enhancement and refactoring efforts.
• We not short the concepts of testing and training, so that fewer "diaper change" type of requests get turned into weekly flurries of productivity-and-morale-sapping help requests.
• User interfaces aren't so awful as to make our users cringe when they have to work with our systems, or so confounding and unintuitive that it leads to more support calls or worse, bad data getting into the system, which leads to more data fixes.

None of the above suggestions are terribly expensive and a lot of it is good preventative maintenance and best practice. Yes, there will be a time cost somewhere. But you can't read a magazine article about agile and then decree your teams will start using it and expect immediate benefits if you haven't empowered them to write software that is properly objectified and can be tested or maintained without massive effort. And you won't understand any of these concerns if you suffer from a sizable decision-consequence gap.

Are You Managing a Project for You or for Your Company?

Let me ask you managers out there a question. Would you tell a developer, "Oh, just do it sloppy so we can make the date?" Actually, don't answer that question, I already have experience showing the answer is Yes. Let me ask a different question instead. Would you allow the contractor building your home to cut corners to finish faster? I'm betting the answer is No, and do you know why? Because YOU have to live in that house. YOU will be the one dealing with the leaks or creaks or breakage. When it comes to YOUR home, you pay heed to the decision-consequence gap. I guess I missed the part in the PMBOK calling selfishness a PM trait.

The Empowerment Ratio

It's really hard to be a grunt in IT. It's even hard to be a manager or leader in IT. At least, it is if you care and really want to do more for your users and clients and your teams. As this industry advances you'd think we'd collectively improve based on lessons learned applied institutionally. It doesn't really happen like that though.

Yes, we do see some improvements. Since I started working in IT, several things are better than they've ever been: user interfaces, databases, source control, languages, tools, and some processes. And of course the hardware is amazing now and just getting faster and smaller and sometimes practically invisible: virtualization is a very useful tool. But even with all those trappings of the software development space getting better, the people parts of the industry continue to exhibit tremendous and appalling flaws contrary to the ideals of such intellectual pursuits.

One of the things that has most frustrated me, and I'm betting it also dogs many of my industry brethren, is a concept I call the power-responsibility ratio, or the empowerment ratio. I mention it in this post because it's a concept that will be used in a future post. It's a problem not just in IT, but in all industries. The power-responsibility ratio is the rating of power a person has to effect change relative to the amount of responsibility they have over a particular process or domain.

Example: the typical IT support team has responsibility for an application's operation. This includes being the first point of contact for anything that can go wrong: network infrastructure, hardware, software defects, user error, process error, data error, interfaces, cross-system discrepancies and reconciliation, bug fixes, new features, project management, data fixes, source control, documentation, and probably a dozen other things I've forgotten to mention.

Now that's a lot of responsibility. But if any one of those factors in the system ecology isn't efficient, it can affect the total productivity of the team. So if there's a problem, the team just changes it right? Not exactly. IT grunts are increasingly beholden to productivity sapping cruft and dense processes invented by people that don't have to suffer the consequences of these process deficiencies:

• Want to change to faster hardware? Get permission from someone else.
• Want to move to a more efficient document system? Get permission from someone else.
• Is there a particular user that's proving intransigent about using the system correctly and doesn't want to learn, but continues to create problems? Good luck replacing him.
• Someone on your own team proving unwilling to follow the best practices everyone else is? Didn't you hear corporations don't fire people that are incompetent anymore, they only fire people that are politically incorrect.
• Want to upgrade the software to the latest version of a framework? No can do, the project manager thinks that effort is wasted because it's not part of the business needs.
• Think you found a way to reduce the overhead in those data fixes that are killing the team's capacity for more strategic work? After filling out forms in triplicate, you find out it was denied because the powers that be just don't feel it's that important; powers of course who don't have to suffer with processing the repeated data fixes.

I'm being a little facetious here because not all management says "no" to everything, just most. But the point I'm making here is not about the having to ask, though that's part of the inefficiency of it all. It's more that IT workers may be the least empowered people in modern organizations. Accounting has a lot of power because it manages finances and in the case of some controllers, accounting actually has to take managerial responsibility for some regions and therefore must understand the business. IT is similar in that it learns about the business and the data that flows through a company, but do IT people have the power of accountants? Not really. R&D, they're usually getting to do things that help the company and as they're seen as a part of the company's core business and its future, so they are deservedly respected and have some influence. HR certainly seems to have garnered a big part in organizations now. Sales and marketing? Please. But IT is expected to be on-call 24x7 and can't get approval for even simple changes.

That's an incredibly frustrating position to be in: You hold significant responsibility over a domain but have very little power to improve it.

What's really sad about this is that the solution has long been documented. In the military, effective leaders know they have to trust the boots on the ground to be able to manage their unique situations, and those boots need to be able to make changes efficiently, or at least as efficiently as possible in the behemoth military. [Note that I'm not saying the military is all good here, it's certainly had its share of gaffes, key leaders are often clueless, and it is hardly a universal exemplar of a properly applied empowerment ratio. But selected groups, like the Special Forces, have figured it out.] And in many management books the concept of empowerment has been a popular one. It's not like this is some secret that can only be implemented with excruciating pain or arcane spell casting. The solution is a simple thing, a single word: trust.

A lot of organizations have a long way to go before they will be able to take advantage of truly superior IT.

Corporate America, You're Doing it Wrong: Part 2

So how do you fix it? Last post, there were three things that have gotten pooched: products, employees, and clients.

Let's fix the most important part first.

Clients

A lot of Corporate American heads like to say, "I'm a profit center along with my vaunted staff of silver-tongued gilded warrior salesman. Even Peter Drucker said so. The rest of you are shit, er, I mean, cost centers."

According to a Google search [full disclosure: blogspot is owned by Google], Drucker indeed coined the phrases "cost center" and "profit center." And yes, he used the terms to split a company's resources into two camps; the revenue generators and...the rest. And his book was probably on the corner of a lot of coffee tables in a lot of executive suites, so of course everyone believed it. It wasn't totally ridiculous and Drucker presented it professionally, so there you have it.

But years after that, Drucker himself relented from this divisive concept, calling it the worst mistake he'd made. He offered a correction and identified that there is really only one profit center, that being the paying customer. Everyone else, from the CEO down, is a cost center. Painful though it may be for a lot of fat heads to accept, this new line of thought from Drucker makes more sense and is much more truthful about the whole business equation. As I said in an earlier post, if an executive thinks IT workers can easily be replaced by remote resources in India, or better yet, robots, then the other side of that is true too. An Indian PhD in business ought to be a lot less expensive than the typical American executive (and possibly a lot smarter).

Every bit of effort in a company by all its resources should be about ultimately serving the customer. Not the board. Not the executives. Not the rest of the employees.

Make great product; not an ok one, not a good one, make a great one. Then stand behind it and fix it, but make a product good enough that your customer support and production support costs are low because it works right the first time. Charge a fair price, adjusting for competition. I know, the competition includes companies from China that don't respect intellectual property so they copy your product and use cheap labor to build clones for cheap...and those damned customers will buy them. First, fix that attitude because the customers are doing exactly what you'd do if someone gave you two comparable products and had a lower price on one of them. Second, compete the best way you can: with innovation. They can copy your product but they can't quickly copy your initiative, your customer knowledge, and your customer relationship. Keep innovating and they will always be playing catch-up. How to innovate? More on that when we fix your employees.

But putting the customer first isn't how it is. Maybe in a few companies. Maybe in the past it was more like that. But not in the contemporary world. Stockholders only care about returns, and that causes boards to put pressure on getting results faster and faster. This in turn leaves company leaders to resort to putting the most obvious metric at the front of all decisions, project evaluations, and employee evaluations: the date. Get it done by a date. If it's imperfect, thats ok, we'll fix it later. And thus is endorsed a philosophy of not accepting technical debt as a necessary evil but as a strategic option. It comes from the top and it works its way into all ranks and pretty soon delivering broken shit or half-assed shit is ok.

Of course, not all companies have the same leeway here. Compromised safety standards will injure people and ultimately sales. Established companies like Toyota and BP would therefore never do such corner-cutting for the sake of short-term sales.

Looking at these pressures, you have to wonder if perhaps they're at least part of the reason Dell has chosen to revert from being a public company back to a private one. Dell offers another example here; at one time the company tried to outsource all its technical support to India, but backlash from customers caused Dell to retain US technicians for corporate customers. In the latter case, Dell recognized it had to keep its largest revenue generators satisfied. Of course the rest of the little customers got screwed, but at least some of this corroborates the Drucker correction. But it remains to be seen what Dell will do with this recovered initiative.

"The customer comes first" is an old tenet of business. For a lot of companies it's also a forgotten one.

You're doing it wrong.

Corporate America, You're Doing it Wrong

I know, you're looking at the title of the post and rolling your eyes at me being a cynical bastard again. Well, you can tell yourself that if you want. But you are doing it wrong...it's why I became a mercenary. I figured out the game and now I play it instead of letting it play me.

The More Things Change the More they Stay the Same
Well, not really. I'm still being exploited for someone else's profit, but it's better than it used to be. I've given up dreams of institutional achievement and only two constituents really matter anymore: my family and my clients. The rest of you are just infrastructure, trying to sell me on the golden rung at the top of a ladder that I know is made of pyrite.

Your Job is to take Care of Products, Employees, and Clients
Oh there's some gold there all right, but you have to sell your soul to get it, not by making a deal with the devil, but by complacently doing the same c-level executive horseshit that most of them do. You might not even be doing it intentionally but you're destroying dreams by the thousands by succumbing to the typical corporate insensibilities. Your constituent is just one entity: you. You will blame the stockholders and board of directors for making you do stupid things like purposely putting your product quality at risk, your employees in the crapper, and your clients last in the food chain. That excuse doesn't wash; if you are going to blame the stockholders and the board and then take profits, you don't understand leadership. And that's your primary job. You don't build widgets or beat the pavement anymore; you're supposed to be a strategic thinker that builds the company's future with keen decisions, reliable relationships, a vision for the future, and respect for the past. But nope. It's all about you, and it's gutless.

You're doing it wrong.