Imagine you lead an organization. Now imagine you want to improve how things get done.

It’s a redundancy, because if you lead an organization and haven’t identified something that can be done better than it’s being done right now, you’re coasting. As a business leader, your job isn’t to make sure things get done. It’s to build an organization that makes sure things get done; then to make sure the organization constantly gets better at what it does.

Here’s your challenge: Improving how something gets done is mostly beyond your control.

Say, for example, you decide ITIL (a popular version of what constitutes good IT practice) isn’t just in your organization’s future, it is your organization’s future.

Now what?

ITIL is a process framework. It provides an organized catalog of the processes IT has to master to be considered competent at what it does. To implement ITIL, you need to:

  • Select: Decide which processes are most critical to your organization’s success right now.
  • Assess your current level of competence in those processes.
  • Focus: Determine how the six process optimization parameters rank in importance (fixed cost, incremental cost, cycle time, throughput, quality, and excellence).
  • Target: Optionally, set specific quantitative criteria for what constitutes successful improvement.
  • Design the future state (ITIL doesn’t prescribe a single “best practice” for each process, understanding there is no such thing).
  • Plan: Figure out how you’re going to get from here to there.
  • Implement: Follow the plan until you’ve made if from here to there.
  • Iterate: As an alternative to designing, planning, and implementing, identify the weakest process link, fix it, and repeat until the process is in good shape.

Except that when I said “… you need to,” I meant the organization needs to. As its leader, at most you should be part of selecting, assessing, focusing and targeting. After that, your ability to influence is indirect.

Which leads to a skill all business leaders need to develop if they want to be effective at effecting change. To coin a phrase, call it Leadership Intervention Points analysis (LIP).

Leadership intervention points are, as the name suggests, the places a leader can intervene without micromanaging or otherwise violating the system of delegations that comprises the organizational chart.

Imagine IT’s capacity planning process is an improvement target. Now imagine that as CIO you decide to personally involve yourself in future state process design and implementation planning.

Now imagine your head of IT operations isn’t completely and utterly pathetic — something that had better be true, because otherwise IT’s biggest challenge is your ability to recruit, select, hire, retain, and promote talent.

Your personal involvement subverts the authority of the person you put in charge and disenfranchises the staff who should be responsible for making things work. You’re telling everyone what to do — delegating tasks instead of goals (if it isn’t clear why this is undesirable, you seriously need to read Chapter 3 of Leading IT: (Still) the Toughest Job in the World).

Worse yet, it prevents you from setting goals and targets, because once you tell everyone how they’re supposed to do their work you take away their autonomy … having prescribed the means, you now have to accept whatever ends they cause.

And worst of all, you’ve put yourself in the position of having to manage the process personally from this point forward. After all, you’ve made it clear that how everyone goes about planning capacity matters to you personally, so if you don’t supervise how they do it … not just the result … you’ll puzzle everyone.

Compare this situation to what happens if you give it some LIP. As it happens, in our consulting work we’ve identified the 150 or so factors that drive IT organizational effectiveness, including the thirty or so that comprise a CIO’s LIPs and their interconnections. Tracing through these interconnections it becomes clear that a CIO wanting to improve capacity planning, or any other operational process has just two LIPs to work with. They are: training, especially process management training; and culture, especially the establishment of a “culture of process.”

That’s it. CIOs can make sure their managers know what it means to manage a process instead of, or as a complement to managing the work. And they can do quite a lot to make operating through well-defined processes “how we do things around here.”

It might not seem like a lot. Luckily, though, it’s more than enough, because with those two factors in place, the processes will take care of themselves.

Or, more to the point, everyone in IT will make sure the processes are in place to take care of everything that needs taking care of.

Can you stand one more Steve Jobs retrospective?

I’m not sure I can either. But as so much of what I’ve read seems to have missed, not just the point, but both of the points (there are two) … well, what the heck. And so, let’s try to answer the question, why did Steve Jobs matter?

What Answer #1 isn’t: He started it all. He didn’t. Not even he and Steve Wozniac together get the credit.

Jobs and Wozniac (note to Apple: Aren’t you embarrassed that “Wozniac” doesn’t pass an iPad spell-check?) (10/11/2011 note to readers: Yes, this was my mistake – “Wozniak” passes the spellcheck just fine! – Bob) were part of a thriving community of people fascinated by the potential for personal computers. They built, not the first PC, but the first commercial PC … the first that could do something useful for mere mortals right out of the box.

Why this doesn’t matter all that much is that, had they not done so, someone else would have before much more time had passed. They got there first, and deserve credit for it. But it isn’t why Steve Jobs matters.

What Answer #1 is: He made the user interface important. As you have to know, Jobs had nothing to do with the invention of the graphical user interface. Douglas Engelbart did most of that work, with a team at Xerox PARC labs finishing things up.

But Engelbart lacked influence, and Xerox lacked interest. Jobs saw the result and had the key insight: The user interface, all by itself, mattered, independent of the specific use to which anyone put it. This led to the Macintosh, which led to Windows, making the graphical user interface ubiquitous.

The notion that making computers easy for humans to figure out should be the centerpiece of the design effort was uniquely his.

Or, if you’re more cynical, Steve Jobs was partially responsible for the ongoing dumbing down of the American public. The downside of an immensely friendly user interface is that the user has less learning … and thinking … to do.

Think of the GUI as the automatic transmission of computing, encouraging more drivers, including worse drivers, to share the road.

What Answer #2 isn’t: Solving hard problems. Don’t get me wrong – smartphones and tablets matter, and while Jobs no more invented these than he invented the PC, without him they’d be a whole lot less interesting and transformational. But nothing about them was hard.

Apple has nothing that corresponds to the old Bell Labs or IBM’s Thomas J. Watson Research Center. Apple won’t invent the next transistor or scanning tunneling electron microscope, nor will it discover anything as consequential as the cosmic background radiation.

Heck, iOS doesn’t even provide e-inking as an operating-system-level service, let alone something as important, relevant, and difficult as handwriting recognition.

Apple takes on the easy problems. This isn’t an indictment. Figuring out new and interesting things you can do with what has already been solved is tremendously useful. It shouldn’t be confused with doing something hard, though.

What Answer #2 is: Providing a leadership model lots of companies should follow. From what we know, Jobs didn’t lead as CEOs should lead. He was an autocratic micromanager, unable to delegate and deeply involved in the details of product design. Let’s hope, for Hewlett Packard’s sake, that Meg Whitman doesn’t follow suit.

But, and these are crucial, Steve Jobs focused on potential, and he insisted on excellence.

Nothing about the iPod, iTunes store, iPhone, or iPad was safe. Jobs focused on upside potential, not downside risk. Like the great generals in history he preferred offense to defense.

As for excellence, he insisted on it in the technical as well as general meaning of the word. Technically, “excellence” refers to the presence of desirable features people want to buy, as opposed to “quality,” which refers to the absence of defects … a characteristic Jobs didn’t particularly care about.

Under Steve Jobs, every Apple product had to be so desirable that its customers were willing to pay premium prices for its designs while forgiving it for serious lapses in quality.

So pay attention, because this is why Steve Jobs mattered most: He had no obvious interest in “maximizing shareholder value” or increasing Apple’s profits. He was far from the highest-paid CEO in America and never seemed to worry about that, either.

Along with Bill Gates and almost nobody else at the helm of a corporate behemoth, he personally loved his company’s products.

Like Bill Gates, Steve Jobs demonstrated that if a company’s CEO focuses on building products people want to buy, the rest will happen.

Imagine if General Motors had been run like that.