All Posts by Bob Lewis

|In: Organizational Effectiveness|Last Updated:

Speaking of reading — last week‘s topic, as in why so many IT professionals don’t do it and what you can do so they do …

Many, many moons ago (1974 to be precise), Edwin Newman authored Strictly Speaking: Will America Be the Death of English? an eloquent diatribe about … well, the title says it all, doesn’t it?

Newman held out “hopefully” as a particularly noxious step on the road to linguistic perdition. It means “In a hopeful fashion,” but it’s most commonly used in place of “I hope,” presumably because the speaker (or writer) doesn’t want to specify who is doing the hoping.

I hope you’ll join me this week in burying an even worse usage, worse because it not only combines bad English with bad math, but takes it from a sports metaphor.

The phrase in question: “We have to give 110%!”

Why I mention it: Several correspondents wrote to point out that making reading mandatory, no matter how it’s done, will likely crash into the all too common practice of oversubscribing staff on the grounds that, for exempt employees, “… this isn’t a 40 hour a week job, you know.”

When employees are already oversubscribed, adding a low-urgency task to the pile of work they already have won’t endear you to their hearts no matter how noble your intentions.

The flaw, though, isn’t with last week’s suggestions. It’s with the practice of considering 100% (or 110%) staff utilization to be a sign of efficient management.

It isn’t. It’s a sign of bad engineering.

To illustrate the point, consider an airport. Any airport has a theoretical limit to its capacity. Modeling it would entail something along the lines of dividing 1,440 (the number of minutes in a day) by the average number of minutes needed for one airplane to take off or land, multiplied by the number of runways that are usable in average conditions.

Imagine the airline industry was foolish enough to try to asymptotically approach this limit. Then imagine something disrupted the schedule — say a flight can’t take off because something in the cockpit broke. The only alternative would be to cancel the flight and rebook its passengers into open seats in other flights to the same destination, because if the airport is operating at capacity there would be no available time slots to reschedule the flight.

The general principle: Systems need enough unused capacity to absorb shocks — unplanned situations that require some of their capacity.

That is, if everyone is giving everything they have already, they’ll have nothing left for handling a crisis. And if their management thinks they do have enough left to handle a crisis, that just means they aren’t operating at capacity, and so should be given even more work assignments.

It’s sloppy thinking, imagining management can make 110% of capacity the new 100%.

Now I’m not so semantically intolerant that I don’t know what a head coach means when he insists players must give 110%. It isn’t that the coach wants everyone to flunk math. It’s that the players are capable of more than they think they are.

Which works just fine when players have time to rest and recuperate after a game. In a retail business it can work well enough when the challenge is handling a spike in pick-pack-and-ship warehouse demand because Cyber Monday sales were off the charts, assuming that by Cyber Thursday everyone can get back to a more reasonable workload.

It doesn’t work so well when programmers are enjoined to go above and beyond when they don’t get time to rest and recuperate after a long week of coding, any more than it makes sense to tell marathoners to try to sprint the entire race.

While we’re on the subject of time management, a phrase of advice on a related subject, multitasking. The phrase of advice: don’t do it.

As, thankfully, no sports metaphors occur to me, let’s talk about virtual memory –temporarily spinning off some RAM contents to disk, so as to load a different computing task into the just-vacated RAM for a few moments of processing, then rinsing and repeating for all other active computing jobs.

This works so long as the number of concurrent jobs doesn’t result in task switching time becoming a significant fraction of total capacity.

What’s true for computers is true for those who program and use them — when we’re forced to multitask the impact of our own switching time is very real.

Which leads to the [stunningly obvious] moral of this story: Don’t undertake workloads that are beyond your organization’s capacity.

Comments

|In: Career Management|Last Updated:

Where’s the outrage?

Last week’s column, discussing the Not Invented Here By Me Syndrome, included a shot at Apple (“Apple’s aficionados were and are more passionately loyal than Microsoft’s customers. But in IT, Microsoft matters. Apple’s products? They connect to the IT portfolio but aren’t important to it.”

Once upon a time, a statement like that would have yielded a flood of hate mail, or at least, the KJR community being a civil lot, no shortage of kindhearted souls who would take the time to help me see the error of my ways.

Does Apple really have so few defenders? Or, if you’re among them, were you just too busy to express your outrage at my disrespect?

Speaking of outrage, here’s something that causes mine: How few IT managers and professionals (yes, some people are both) read.

The world, or at least the Internet, is chock full of potentially useful information, not that I know how many bytes constitute a chock. Last week, speculating as to why IT organizations don’t take more advantage of it, I enumerated four possible root causes: Incuriosity, fear, internal disqualification, and channel erosion. Due to self-imposed lack of space I didn’t explore possible solutions.

But identifying problems and root causes without suggesting solutions is just pointless griping.

We can’t have that. And so, as a possible solution, how about making reading, or, more broadly, idea discovery part of the job?

But it has to be about more than just discovering interesting concepts, developments, and possibilities. It has to be about more than novelty. It also has to be about utility.

With that in mind, here’s a possible program: Make everyone in IT responsible for reading broadly and deeply about some subject that is, in some way, shape, or form, related to IT’s responsibilities. Their choice. Once a year they’ll be responsible for turning what they’ve discovered into a proposal for how to improve the IT organization.

Some guidelines:

Vision: Recommendations should be visionary enough to be interesting. They should also be practical — concrete enough that you can envision what success would look and feel like. And they should explain how to move from current practice to whatever is being proposed.

Benefits: They should be clear. Don’t limit them to the financial realm, but what IT and the company would get out of the proposed investment shouldn’t be vague and mysterious, either.

Teamwork: Allow teams, but limit their size to three. More than that and when their results turn up you’ll have no way of knowing how many team members actively and usefully contributed.

Source exclusion: You should probably disallow the analyst firms as sources — not because their analyses are illegitimate, but because what they do is what you want your employees to do. Letting a contributor rely on, say, a Gartner study would be akin to a professor accepting a term paper with only Wikipedia in its bibliography.

Divide and conquer: As a practical matter you probably don’t want to wade through everyone’s proposals at once. Stagger delivery so you get a new batch the end of every month. Also, divvy up the contributions so your whole leadership team shares responsibility for evaluating them.

Outcome: Whatever you do, don’t promise to implement, just as you shouldn’t make any other promise you can’t keep.

But on the other hand, do take the contributions seriously. Some will be worthwhile. Incorporate the best into your strategic and tactical planning.

Coach: Many of the suggestions you receive will be interesting enough to get your attention, but not well-thought-out enough to work as is. That suggests the contributor has potential and should be encouraged.

Recursion: Subject this suggestion to the same process it recommends for evaluating other ideas.

Understand I’m making this up. I’m pretty sure it or something like it would work, confident it would lead to significant direct and indirect benefits, and don’t personally know of any IT organizations that has tried it or something like it, let alone demonstrated its merits.

Also understand I’m anything but a disinterested party to all this. As a writer, I of course want more people to build reading habits into their personal development. And so, if the above strikes you as overly ambitious, at a minimum take the time to distribute links to on-line content you find intriguing to the teams you lead

Perhaps append the question, “Should we explore something like this here?”

Comments