All Posts by Bob Lewis

|In: Career Management|Last Updated:

What do you do when you find a knife in your back?

That was the subject a couple of weeks ago (“Dealing with Ugly,” KJR, 10/22/2018), which also dealt with two other closely related situations, being scapegoated and thrown under the bus.

Several commenters pointed out that I hadn’t pointed out the importance of documenting everything about the situation.

They’re right. I didn’t, for two reasons. One was the column’s focus, which was on prevention. Documentation won’t help you prevent this sort of situation, for the simple reason that evidence and logic rarely help you in any situation.

Seriously — try to formulate a plausible scenario in which you explain to Someone Who Matters that the company’s CBO (Chief Backstabbing Officer) has turned his attention to you. So … you inform that Someone that it’s going on and you have documentation regarding the facts of the matter. Think she’ll actually read your documentation?

It won’t happen. More likely, the Someone Who Matters will conclude you’re just another whiner who needs to grow up and solve his own problems.

Or, you can complain to Human Resources. They’ll ask for a copy of your documentation, which they’ll helpfully add to your personnel file, where nobody will ever look at it again.

So far as prevention is concerned, about the only value documentation might have is if you’re on a project team and the project manager is preparing to make you the scapegoat for the project’s rapid deterioration. But even if you’re in this situation, documentation will be of limited value. More important is keeping your administrative manager informed, early and often, as to what’s really going on in the project.

After all, it’s your administrative manager who decides on whether to retain you as an employee, let alone what sorts of raises and bonuses you deserve.

To be clear, keeping your manager in the loop won’t prevent backstabbing or scapegoating. What it might prevent is your manager falling for it along with everyone else.

Conclusion: Documentation is close to useless for preventing backstabbing, under-the-bus throwing, or scapegoating.

Is it of more use after you’ve been victimized by the CBO or one of his protégés? You face the same gedankenexperiment (“thought experiment if you aren’t among the cognoscenti but are impressed by vocabulary-builders like gedankenexperiment and cognoscenti): Formulate a scenario where you have an opportunity to put your carefully crafted documentation to use.

Let’s see now … there’s your annual performance appraisal. Your manager downgrades your rating because she fell for the tales about you spread by the knife-wielder. You can provide all the documentation you want and you expect your manager to do what, exactly? Say, “Gee, I guess I was misinformed. It’s a good thing you have all this documentation to set me straight”?

Good luck with that.

Fortunately, the appraisal process includes an opportunity for you to challenge your manager’s assessment. By all means do so, so that your version of events is included in your personnel file, right alongside your manager’s comments. Guess how many people will have the time and interest to read what you had to say?

Answer: No people, but we might imagine that in twenty years or so your company decides to point its newly implemented Watson AI HR module at the past few decades’ worth of performance appraisal data. In our fantasy, it runs across your manager’s appraisal and your challenge to it, applies its neural-network heuristics, and concludes you were poorly treated.

Unfortunately for you, the Watson AI system truly is intelligent … intelligent enough to recognize that nobody in our solar system gives an infinitesimal damn. Applying this overriding insight it recalibrates its analytics window to only review the past five years of performance appraisal data, leaving you fifteen years too early to get any justice.

We’ve all seen enough courtroom dramas on television to imagine ourselves verbally skewering our nemeses as they quiver pathetically on the witness stand of some imagined tribunal.

It’s a satisfying daydream, but that’s all it is.

So document away, if you have time for it. But before you do, ask yourself whether it might make more sense to invest the same time strengthening one or more of your working relationships.

Because that’s the ounce of prevention that’s worth far more than documentation’s pound of placebo.

Comments

|In: Architecture|Last Updated:

In the early days of modern computer networking, SNMP (simple network management protocol) and CMIP (the Common Management Information Protocol) vied for dominance. SNMP’s main advantage was its simplicity. CMIP was more elegant and complete.

SNMP is still in wide use. CMIP is more footnote than deployed technology.

# # #

Agile development relies in part on an old, old, principle: Big systems that work started life as small systems that work. The need for TLAs being what it is, in Agile the small system that works is called the Minimum Viable Product (MVP). It’s the system’s irreducible core, and the team’s earliest development goes into defining, programming, and perfecting it. From that point forward, everything else the team builds constitutes an enhancement to the MVP.

Waterfall methodologies aren’t all that different, except for one thing: Agile teams deploy the MVP for actual business use, while Waterfall teams don’t release software into the wild until the whole application is finished. As a result, Agile but not Waterfall teams learn of needed course corrections while in course.

# # #

I know a woman who tried to launch a business. It was, she told me proudly, so complicated that she was one of the few people around who could get it started and make it work.

She wasn’t and it didn’t.

# # #

Which leads to this week’s big idea: Simple is hard. Every increment of less simple is even harder. Starting out harder instead of simpler is usually the wrong answer.

It’s that simple.

Which in turn leads to enterprise architecture, why it’s so often disappointing, and an encouraging trend.

Why it’s so often disappointing: Enterprise architecture is intrinsically complicated, and that’s before its brain trust worked as hard as it could to wrap an impenetrable lexicon around it that separates the Cool Kids Club from lesser mortals who just want to put EA to practical use (for more, see “The Dark Secrets of Enterprise Architecture,” Bob Lewis, CIO.com, 6/8/2018).

Enterprise architecture is intrinsically complicated, and if you buy into this week’s big idea, that makes implementing it intrinsically problematic. Which, combined with numerous recent conversations and inquiries over the past few months, has led to a eureka moment:

Application rationalization is enterprise architecture’s minimum viable product.

What’s commonly called application rationalization is really three different rationalizations within technical architecture’s application layer: (1) true application rationalization (AR); (2) application portfolio rationalization (APR); and (3) application integration rationalization (AIR).

Application rationalization rates the health of each application in the company portfolio, assessed separately from all other applications.

Application portfolio rationalization looks for redundancies in the application portfolio — different applications that provide similar services.

Application integration rationalization reviews the interconnections used to synchronize redundant data, and to collect and present data from multiple “systems of record” (the IT view) as if they were a single coherent “source of truth” (the business perspective.

Together, AR, APR, and AIR determine the optimal disposition of each application, and of the collection of application interfaces and integrations, and then develop a plan of action for achieving those dispositions.

These dispositions range from replacing an unhealthy application; to updating otherwise serviceable applications that are too many versions behind what their vendors currently support; to re-writing those whose functionality is necessary but whose engineering is, to use the technical term, hideous; to sunsetting all but one of a collection of redundant applications … to list just some possible potential dispositions out of the complete list of possibilities.

Also, while this description emphasizes the applications themselves, undertaking any rationalization within the application layer almost always has ripple effects throughout all parts of the business that make use of the affected applications … which is to say, at one time or another, the entire business.

Changing any application will affert how the work supported by that application gets done.

The impact could be negative — disruption. But that doesn’t have to be the outcome. Unhealthy applications usually lead to some level of pretzel logic in the business processes and practices that make use of them.

For example, a process that could otherwise happen in real time might include one or more one-day delays as a consequence of the need for overnight batch processing.

Another process might require users to consult three or four different applications just to figure out what’s going on so they can respond to what should be a straightforward customer inquiry.

So rationalizing the application layer can, if everyone approaches the situation from the right perspective, lead to more effective employees and a more effective business.

All by cleaning up the technical architecture without ever admitting that’s what’s going on.

# # #

If you need help cleaning up your organization’s application layer, don’t be shy — use the Contact form and we’ll schedule a conversation to talk it over.

Comments