All Posts by Bob Lewis

|In: Leadership|Last Updated:

“American managers are stupid,” my correspondent offered, by way of explaining why so many ignore his perspectives.

I decided not to ask whether he meant that (1) all Americans are stupid and, by the laws of object inheritance and the transitive law of algebra, American managers, being Americans, are stupid; (2) American managers are stupider than the average American; or (3) it’s Sturgeon’s Law in action: 90% of everyone are stupid and that includes American managers.

To the best of my knowledge nobody has ever surveyed American managerial IQs to determine whether the mean is less than, greater than, or equal to 100 — IQ’s definitional IQ average. Also, IQ is a badly flawed metric.

Meanwhile, the American managers I’ve personally worked with have in general been a brighter than average lot. While employee dissatisfaction with management is both widespread and deserved, I’m pretty sure it isn’t because they are, as a class, dopes.

Which somehow or other brings us to this week’s topic.

Many companies conduct employee satisfaction surveys. Some are better than others, but I’ve yet to see any that move beyond warm fuzzies to the only metrics that matter in a market economy.

The KJR alternative: ask employees to express their satisfaction or dissatisfaction financially.

It will take only four questions:

Question #1: What percentage of your total compensation would you be willing to give up in exchange for a better manager?

Question #2: What is it about your manager that led to your answer to Question #1?

Question #3: What percentage of your total compensation would you be willing to give up in exchange for working in a better company?

Question #4: What is it about this company that led to your answer to Question #3?

Yes, yes, I know. The answers to questions 2 and 4 couldn’t be automatically tabulated, at least, not the first time you administer the survey. But which is more important — automated tabulation or useful information?

Even if you only ask questions #1 and #3, just knowing how much money employees would be willing to give up in exchange for a better work environment would give business leaders at all levels a lot to chew on.

Starting with this question: Does it matter?

It ought to matter a lot. It’s widely recognized that the best employees are at least twice as effective as average ones, and the gap is probably much wider than that.

The best employees are also the most mobile. Add to this another general-purpose factoid: Replacing a good employee costs the equivalent of about a year of compensation, counting recruiting costs, the costs of bringing new employees up to speed on their responsibilities, and the overall loss of team effectiveness as teams adjust to changes in their membership.

Do the math and it should be clear that losing your best employees is an expensive proposition.

And yet, I often run into companies whose employees privately tell me are utter meat grinders — horrible places to work. They have high employee turnover, as we’d predict, and yet they make so much money so quickly they have a hard time figuring out what to do with it all, and have over spans of decades.

How is this possible? The short answer is, beats me. The longer answer is nothing but speculation: The same management characteristics that make these companies bad places to work somehow make them resilient in the face of high employee turnover rates.

Take, for example, micromanagement. I’ve yet to hear anyone say they like being micromanaged. But whatever their flaws, micromanagers do know how to do the work they’re micromanaging. If they didn’t they couldn’t micromanage. And because they’re able to do the work, micromanagers can pick up the slack when an employee leaves.

Of course, picking up the slack adds pressure and workload, making the micromanager even less pleasant to work for.

Let the process play out for a few cycles and what you’ll get, I think, is a department staffed by mediocrities who can’t easily find better employment, run by managers for whom micromanagement is integral to how their department’s work gets done.

It’s a stable configuration. As long as the company does something else well enough to make it competitive in its marketplace, there are no forces in play to drive change and plenty in play to keep it as it is.

My guess is that similar dynamics govern other forms of stable, bad management.

If you’re one of the offending managers, please don’t take this as an endorsement of your management style. Explanation doesn’t equal approval.

And in any event, I’m just speculating. Maybe one of KJR’s more enlightened constituents has a better theory?

Comments

|In: App Dev Methodologies|Last Updated:

Your resolutions for 2018:

Resolution #1: Send me ManagementSpeaks. Keeping an ear open for these is an excellent way to keep yourself grounded. Also, my supply is getting low.

Resolution #2: Send KJRs you like to your friends, family, colleagues, and especially people you don’t like and want to irritate. They’ll thank you. Except for the ones who won’t.

Resolution #3: Let me know how I’m doing … not only on the subjects I write about, but also on whether I’m writing about the right subjects.

Resolution #4: Give up on TOGAF.

This one might need a bit more explanation …

For those unlettered in the arcana of enterprise architecture, TOGAF stands for The Open Group Architecture Framework. According to the Open Group, TOGAF®, an Open Group Standard, is a proven enterprise architecture methodology and framework used by the world’s leading organizations to improve business efficiency.

Before diving into the important reasons to abandon TOGAF, a question: In what way is TOGAF proven? I Googled “TOGAF SUCCESS RATE” and came up dry. So far as I can tell neither the Open Group nor anyone else has even defined a TOGAF success metric, let alone tracked improvement against a baseline.

And a quibble: According to the above explanation, TOGAF’s goal is business efficiency. But … efficient with respect to what? Cost? Electrical consumption? Weight loss per hour of exercise? “Efficient” is meaningless without this information. And anyway, efficiency isn’t always what’s most desirable in a business. Effectiveness is the better goal; efficiency is one form of effectiveness among many. Target the wrong goal and the rest really doesn’t matter.

More important (but not most important) is a TOGAF intrinsic: It’s a high overhead approach to business and technical architecture management that ends up fostering rigidity rather than agility.

Documenting the current state is labor intensive. Designing the desired future state is labor intensive. Maintaining the documentation for both as projects finish and IT deploys new or changed information technology is labor intensive.

Meanwhile, attempts to secure funding for architecture remediation generally fail in the competition for budget and staffing with projects whose purpose is delivering direct business value.

But we’ve covered this ground before in KJR. What’s new that makes TOGAF abandonment a 2018 imperative?

TOGAF’s foundation contains a fundamental flaw. We’ve been able to wallpaper over it so far, but won’t be able to ignore it much longer. The flaw: its fixed-layer model.

In the world according to TOGAF, which to be fair has, until today, been quite similar to the world according to KJR, architecture has four layers with well-defined boundaries: the Business layer, Application layer, Data layer, and Technology layer.

But their boundaries are increasingly blurry.

Start with the technology layer. It’s really two distinct layers, infrastructure and platforms.

Infrastructure includes everything applications run on and data are stored in and managed by: facilities; networks; virtualization technology; servers, both physical and virtual; and so on.

Platforms are the tools IT uses to build applications. Except that in many cases the tool IT uses to build an application is an application, not a platform. IT organizations create new capabilities using tools or APIs built into ERP packages, Salesforce, and, for that matter, SharePoint all the time.

And it’s even messier than that, because increasingly, IT doesn’t build applications using just one underlying application as a platform. IT uses an enterprise service bus (ESB) or some equivalent integration technology to create a virtual “source of truth” service out of a collection of “systems of record.”

It builds applications out of these services rather than making direct use of application APIs.

Unless they’re expert systems built out of business rules … and it isn’t remotely clear whether business rules are code or data.

Then there’s intersystem integration, something TOGAF has never represented well. Too bad, because in my experience, integration is where most of the architecture improvement opportunities lie.

Somehow, most companies have still failed to replace their tangle of custom, point-to-point, largely batch, poorly documented and increasingly fragile inter-system interfaces with well-engineered integration. And yet even depicting systems interfaces and integration is pretty much an afterthought for TOGAF and its brethren.

SOA (service oriented architecture) with an ESB provides tools for building engineered integration, but not a methodology for designing it. Documenting the current mess? Even less.

So stop trying to implement TOGAF. Instead, clean up your interface tangle while waiting for the Open Group to address TOGAF’s deficiencies.

And finally …

Resolution #5: Stop making resolutions. Resolutions motivate people to be better than they are by making them feel guilty when they don’t live up to them. But really, don’t you have enough people in your life trying to make you feel guilty without piling on yourself?

# # #

Elsewhere in the news: Check out Bob’s latest in CIO magazine: “How to kill a dead project.” Okay, that isn’t really a resolution. Check it out anyway.

Comments