In my defense, I was much younger then, and maybe less skeptical about consultants’ recommendations.

Also in my defense, I lacked the political capital to challenge the idea anyway – it would have happened with or without me.

And, still in my defense, when I found myself, as a consultant, leading a client’s IT reorganization, I didn’t commit the same crime.

Which was having employees apply for the jobs they’d been doing since long before we came on the scene.

Let’s start by going back a step or two, to the difference between a reorganization and a restructuring. Sometimes, the difference is that “restructuring” sounds fancier than “reorganization.” Going for the snazzier word can be seductive, even when it’s at the expense of accuracy. With that in mind, a reorganization leaves the work intact, along with the workgroups that do it and who lives in each workgroup. What it changes is who reports to whom.

A restructuring, in contrast, changes how work gets done – it divvies it up into different pieces, and by extension, which workgroup does each piece.

Which gets us to IT: Except, perhaps, for shops transitioning from waterfall methodologies to one of the Agile variants, most of the work that has to get done in IT doesn’t lend itself to restructuring: programming, software quality assurance, systems administration and so on, don’t change in ways fundamental enough to change the job titles needed to get IT’s jobs done.

The buried lede

A correspondent related their situation: IT is “restructuring,” but really reorganizing, and everyone in it will have the “opportunity” (in scare quotes for obvious reasons) to apply for a job in the new organization.

In a true restructuring this might make sense. After all, if many of the jobs in an organization are going to change in fundamental ways it might not be obvious who should hold each of them.

But in a reorganization the jobs don’t change in fundamental ways. And if they don’t, IT’s leaders need to ask themselves a question that, once asked, is self-answering: Will asking employees to apply and compete for the jobs they currently hold be superior for figuring out who in the organization will be most likely to succeed in each of the jobs that aren’t going to change? Or is basing job assignments on the deep knowledge managers should have of how each IT employee currently performs more reliable?

Bob’s last word: If it isn’t already clear why having IT’s current employees apply for positions in the new org chart is inferior to appointing them, just ask yourself how good you are … how anyone is … in basing hiring decisions on how well each applicant interviews.

Depending on your source (mine is a study by Leadership IQ), about half of all new hires fail within a year and a half.

My advice: Slot employees to jobs based on what you know about what they are and aren’t good at, not on having them apply for internal jobs as if they’re unknown quantities.

Bob’s sales pitch: My friend Thomas Bertels and his co-author David Henkin have written an engaging business fable about how to improve the employee experience and, by improving it, how to make a business more effective and competitive.

It’s titled Fixing Work and does a fine job of focusing on the authors’ goal – connecting the dots that connect making how work gets done better for both employees and their employers.

On CIO.com’s CIO Survival Guide: “The ‘IT Business Office’: Doing IT’s admin work right.” It’s a prosaic piece on how to handle IT administrivia.

As someone wiser than me pointed out, every organization is perfectly designed to get the results it gets.

As someone exactly as wise as I am (that is to say, me) has been known to point out, change happens when someone in a position to do something about a situation has concluded that how their organization does things isn’t good enough.

If you’re that person, do a bit of Googling (or, I suppose, Bing-ing) and you’ll find lots of alternatives for designing an organizational change, including such disciplines as Lean, Six Sigma, Lean Six Sigma, Process Re-engineering, and the Theory of Constraints.

Assuming you choose a change discipline that fits what you’re trying to accomplish, each of these can deliver a change design that can work.

Do a bit more Googling or Bing-ing and you’ll find a complementary change discipline called OCM – Organizational Change Management – whose purpose is to discover and mitigate barriers to organizational change. It’s essential if you want your intended change to become an accomplished change.

Try to make the change happen, though, and you might discover there’s something in the plan that’s either too ambitious, or not ambitious enough.

If it’s too ambitious you’ll find the first chunk of organizational change is too complicated by half – what’s often described as changing the plane’s engine while you’re still in flight.

Or, worse, you’re trying to convert your biplane into a single-wing aircraft without first landing.

When your chosen starting point is at the opposite end of the continuum – when it isn’t ambitious enough – it goes by the orchardarian monicker “low hanging fruit.”

Going after low-hanging fruit is a popular consulting recommendation. It’s usually a mistake because it creates the illusion of forward progress while failing to set the stage for additional forward progress. Extending the metaphor, go after low-hanging fruit and you’ll find you’re clutching a lemon in your left fist and a tree branch in your right, all while you’re trying to avoid falling off your ladder.

Or, because metaphors don’t (speaking of metaphors) build a very good foundation for a logical edifice, let’s make it real: achieve a quick win and you’re left without a plan for what happens next.

Quick wins deliver the illusion of progress, but with no momentum or trajectory.

The missing piece

Quick win proponents get one thing right – that the hardest part of most intended changes is getting started. What they fail to recognize is that staying started is harder than getting started.

We might call what’s needed a “Quick Win Plus.” Like a quick win, a quick win plus gets the change started by making a small, manageable, clearly envisionable change.

Unlike a quick win, the change a quick win plus accomplishes is one that deliberately includes ripple effects – dependencies that encourage additional changes elsewhere in the organization. Especially, they’ll encourage creation or improvement of a few competencies critical to ongoing success – that will, that is, encourage additional beneficial changes.

Some changes don’t fit this mold – they just can’t, for one reason or another, be decomposed into a swarm of small, independent alterations in how work gets done. These big, complicated changes are the ones that call for disciplined, experienced project management and diversion of staff from their day-to-day responsibilities to full or nearly full commitment to the project team.

Bob’s last word: The way the business world is evolving, big, complicated organizational change is becoming decreasingly feasible. Battle-tested project managers have always been in short supply, while the staffing levels needed for traditional project-managed change are higher than most businesses are able to sustain.

Which is why so many organizations are gravitating to agile-oriented, iterative and incremental change methods.

The quick-change-plus approach fits this thought process well.

Bob’s sales pitch: I can only wish I’d had anything to do with Good Night Oppy. It’s the story of the Spirit and Opportunity Mars rovers. You must watch it – then you’ll wish you’d been a part of it too.

It’s simply wonderful – a very human story, brilliantly told. And after you watch it I can pretty much guarantee you’ll be telling your friends that they must watch it too.

Now on CIO.com’s CIO Survival Guide: “Why IT surveys can’t be trusted for strategic decisions.” It’s an accurate title.