Showing posts with label KJR. Show all posts
Showing posts with label KJR. Show all posts
Tuesday, September 14, 2010
Tuesday, April 8, 2008
KJR themes in the news
4/7/2008
Favorite themes from Keep the Joint Running in the news:
Zero Tolerance Policies: The use of process is the difference between effective management and bureaucracy. Effective managers keep the goal paramount. Processes guide action, help the organization learn, and are ignored whenever they don't fit the situation.
For bureaucrats, the process is the point. Following the steps is all that matters, never mind the outcome.
In another example of zero tolerance being a synonym for bureaucracy, we have a six-year-old boy who swatted a schoolmate on the bottom.
The principal, citing the school's zero tolerance policy for sexual touching, called the police. They, unlike the principal, showed good sense and dropped the matter. Sadly they did not show more good sense by arresting the principle on general principles.
Internal customers also made the news. Well, not exactly. Misuse of the word "customer" is what made the news.
Customers are properly defined as the people who make buying decisions. Many business consultants define it, incorrectly, as those whose inboxes receive the contents of your outbox.
That use of "customer" is an analogy, and as the Economist points out, "Being an analogy ... is not the same thing as being the same thing."
This particular analogy caused serious flight delays over the past couple of weeks. A story brought to my attention by sharp-eyed subscriber J. MacKenzie (Airline Safety Alarms Unheeded Washington Post 2008Apr4), reports that FAA inspectors were told the airlines are ... yes, that's right ... their customers.
More than told. When they tried to enforce the safety rules their supervisors sided with the carriers, threatening the inspectors (according to testimony before the House Transportation Committee).
The good news is, the FAA's top safety inspector isn't giving the usual "few bad apples" speech. He's acknowledging a systemic problem. That's an excellent first step in accomplishing a useful result.
The FAA episode reinforces the importance of industry regulation -- a concept that has become unfashionable over the past few decades.
Industry regulation is needed when the results of pure, unfettered competition are not in the public interest. It fell out of fashion because its downsides -- added expense, extra steps, lots and lots of paperwork, and entanglement in government bureaucracies --received excessive emphasis, while propagandists explained away its obvious successes (one example: The Cuyahoga River is no longer flammable).
Speaking of deregulation mania having resulted in even more inconvenience than the regulations themselves, the tipping-domino-like state of the world economy is also in the news. In one of the most insightful articles yet written on the subject (Chaos on Wall Street Fortune 2008Mar31), Allan Sloan dissects both the situation and what we can and should do about it.
Most past downturns were caused by a weak economy dragging down the markets. This one is different: Weak markets are dragging down the economy. The last time this happened? 1929.
As Sloan convincingly demonstrates, you can't create a mess like this with just one mistake. It took several. One was, clearly, a too-weak regulatory environment.
Following the Great Depression came minimum capital ratio regulations for banks -- basically, how much cash they must have to cover their risks. And only banks, even though brokerages and other financial institutions are now allowed to act in bank-like ways.
The result: The bank-like entities don't even know their risks. Many of their "assets" are portfolios of portfolios of portfolios of loans, packaged as investment vehicles.
It's the financial equivalent of spaghetti code. It works until it stops working, and once it does it's very hard to repair.
What possible relevance does all of this have for a working CIO with a job to do? Quite a lot, as it happens.
Also as with business deregulation, once a good thing starts to be too much of a good thing, it can become a bad thing.
Balance matters.
Favorite themes from Keep the Joint Running in the news:
Zero Tolerance Policies: The use of process is the difference between effective management and bureaucracy. Effective managers keep the goal paramount. Processes guide action, help the organization learn, and are ignored whenever they don't fit the situation.
For bureaucrats, the process is the point. Following the steps is all that matters, never mind the outcome.
In another example of zero tolerance being a synonym for bureaucracy, we have a six-year-old boy who swatted a schoolmate on the bottom.
The principal, citing the school's zero tolerance policy for sexual touching, called the police. They, unlike the principal, showed good sense and dropped the matter. Sadly they did not show more good sense by arresting the principle on general principles.
Internal customers also made the news. Well, not exactly. Misuse of the word "customer" is what made the news.
Customers are properly defined as the people who make buying decisions. Many business consultants define it, incorrectly, as those whose inboxes receive the contents of your outbox.
That use of "customer" is an analogy, and as the Economist points out, "Being an analogy ... is not the same thing as being the same thing."
This particular analogy caused serious flight delays over the past couple of weeks. A story brought to my attention by sharp-eyed subscriber J. MacKenzie (Airline Safety Alarms Unheeded Washington Post 2008Apr4), reports that FAA inspectors were told the airlines are ... yes, that's right ... their customers.
More than told. When they tried to enforce the safety rules their supervisors sided with the carriers, threatening the inspectors (according to testimony before the House Transportation Committee).
The good news is, the FAA's top safety inspector isn't giving the usual "few bad apples" speech. He's acknowledging a systemic problem. That's an excellent first step in accomplishing a useful result.
The FAA episode reinforces the importance of industry regulation -- a concept that has become unfashionable over the past few decades.
Industry regulation is needed when the results of pure, unfettered competition are not in the public interest. It fell out of fashion because its downsides -- added expense, extra steps, lots and lots of paperwork, and entanglement in government bureaucracies --received excessive emphasis, while propagandists explained away its obvious successes (one example: The Cuyahoga River is no longer flammable).
Speaking of deregulation mania having resulted in even more inconvenience than the regulations themselves, the tipping-domino-like state of the world economy is also in the news. In one of the most insightful articles yet written on the subject (Chaos on Wall Street Fortune 2008Mar31), Allan Sloan dissects both the situation and what we can and should do about it.
Most past downturns were caused by a weak economy dragging down the markets. This one is different: Weak markets are dragging down the economy. The last time this happened? 1929.
As Sloan convincingly demonstrates, you can't create a mess like this with just one mistake. It took several. One was, clearly, a too-weak regulatory environment.
Following the Great Depression came minimum capital ratio regulations for banks -- basically, how much cash they must have to cover their risks. And only banks, even though brokerages and other financial institutions are now allowed to act in bank-like ways.
The result: The bank-like entities don't even know their risks. Many of their "assets" are portfolios of portfolios of portfolios of loans, packaged as investment vehicles.
It's the financial equivalent of spaghetti code. It works until it stops working, and once it does it's very hard to repair.
What possible relevance does all of this have for a working CIO with a job to do? Quite a lot, as it happens.
- The importance of eschewing (gesundheit!) zero-tolerance policies is, I hope, clear. Policy is a poor substitute for clear principles and good judgment, and should be reserved for situations where everyone must be treated exactly the same, always, rather than being treated fairly and well.
- Treating those who use IT's services with respect, without pretending they're customers, is a key to the ongoing success of most 21st century CIOs. Those who work together in a business should collaborate as peers, not serve each other as suppliers and customers.
- Recent KJRs have emphasized the desirability of deregulating PCs. As with business deregulation, PC deregulation has a number of benefits.
Also as with business deregulation, once a good thing starts to be too much of a good thing, it can become a bad thing.
Balance matters.
-----------------
Copyright and other stuff -- The great KJR link point
Wednesday, March 19, 2008
To lock or not to lock - it's a deeper question than you thought
3/17/2008
I had a plan.
Last week's column listed three factors to take into account in deciding how far you should open up or lock down desktop PCs: The company's size, how heavily it is regulated, and the role of the individual employee. Bigger, more heavily regulated companies tend to need more tightly controlled PCs. The same is true of employee roles that are more regimented and less flexible.
I'd planned to continue this week with three more factors. One was going to be company strategy. Specifically, companies that sell strongly commoditized products -- products whose only differentiation is price -- have to focus heavily on cost control, meaning lockdown makes sense.
So much for planning: On reflection, I don't buy it.
I don't care if your company manufactures cinder blocks, or buys and sells lentils. It doesn't matter if the product itself is a commodity. Any company that wants to enjoy continued success needs to be on a constant lookout for new and better ways of getting things done.
There are two ways to go about finding these improvements. One is top-down planning. The other is bottom-up initiative. Since the business case for opening up PCs is built on the importance of bottom-up initiative, this is a subject we need to explore in depth.
Top-down planning has the advantage over bottom-up initiative when it comes to engineering elegance. Since the only way to optimize the whole is to sub-optimize the parts, business leaders should engineer the corporation from the top down, according to a carefully rendered program of progressive decomposition -- from core process to sub-processes to sub-sub-processes to activities to tasks to procedures, all carefully orchestrated and controlled.
It's the organization as machine. The gears mesh, the shafts turn, the subassemblies integrate, and everything hums. IT locks down the desktops because any variation from the grand design can only optimize a part at the expense of the whole.
Now imagine you're an employee who performs actual, for example, work. You know how the work gets done because you do it every day. You see an opportunity -- a way to do it better.
Which is too bad, because better people than you have already designed the whole company. There's no room for bottom-up initiative. How could there be? Change anywhere could unbalance the whole machine.
Sure sounds convincing, doesn't it? Well, no, it doesn't. Company processes aren't as carefully engineered as all that. They aren't perfectly optimized from a global, top-down perspective.
The situation is messier than that.
In a typical company, core processes ... the processes that form the heart of the business ... are well-engineered and well supported by the company's enterprise systems. It's hard to escape this conclusion because by definition, a company's core processes are what give it a competitive advantage. That being the case, they will have received the most attention, brainpower, and investment.
Move away from the core processes and you typically find solutions that are more ad hoc in nature. That makes sense. Company leaders should invest more time and attention in competitive differentiators than in business responsibilities that support business responsibilities that support business responsibilities that support competitive differentiators.
So we'd expect to find more opportunities for bottom-up innovation in non-core areas of responsibility than in core processes. This logic dictates a policy that locks down most rigidly the PCs of employees who play primary roles in core and near-core business functions and processes. The PCs of employees whose responsibilities are farther away from the core would be more open.
This makes for a neat, tidy little business paradigm, not too different from Geoffrey Moore's "Keep the core and outsource the rest."
Don't trust tidy little business paradigms. Too often they are on the wrong side of the line that separates the simple from the simplistic.
Here's one of the nasty little conundrums (conundra?) that get in the way. Imagine your company's core and supporting processes really are carefully engineered and perfectly balanced. If that's the case, then in addition to perfect optimization, the company will have achieved perfect stagnation and stasis.
Look at any large organization that's optimized from the top down and you'll find it almost has to discourage front-line innovation. How do you innovate in a world where, when Manufacturing sneezes, Marketing has to say "gesundheit"?
The price to be paid for tight integration is rigidity, and a powerful resistance to change. Today's efficiency almost guarantees tomorrow's obsolescence.
On the other hand, advocating inefficiency and poor business integration just doesn't sit very well.
Do you still think desktop policy is a simple matter?
Think again.
I had a plan.
Last week's column listed three factors to take into account in deciding how far you should open up or lock down desktop PCs: The company's size, how heavily it is regulated, and the role of the individual employee. Bigger, more heavily regulated companies tend to need more tightly controlled PCs. The same is true of employee roles that are more regimented and less flexible.
I'd planned to continue this week with three more factors. One was going to be company strategy. Specifically, companies that sell strongly commoditized products -- products whose only differentiation is price -- have to focus heavily on cost control, meaning lockdown makes sense.
So much for planning: On reflection, I don't buy it.
I don't care if your company manufactures cinder blocks, or buys and sells lentils. It doesn't matter if the product itself is a commodity. Any company that wants to enjoy continued success needs to be on a constant lookout for new and better ways of getting things done.
There are two ways to go about finding these improvements. One is top-down planning. The other is bottom-up initiative. Since the business case for opening up PCs is built on the importance of bottom-up initiative, this is a subject we need to explore in depth.
Top-down planning has the advantage over bottom-up initiative when it comes to engineering elegance. Since the only way to optimize the whole is to sub-optimize the parts, business leaders should engineer the corporation from the top down, according to a carefully rendered program of progressive decomposition -- from core process to sub-processes to sub-sub-processes to activities to tasks to procedures, all carefully orchestrated and controlled.
It's the organization as machine. The gears mesh, the shafts turn, the subassemblies integrate, and everything hums. IT locks down the desktops because any variation from the grand design can only optimize a part at the expense of the whole.
Now imagine you're an employee who performs actual, for example, work. You know how the work gets done because you do it every day. You see an opportunity -- a way to do it better.
Which is too bad, because better people than you have already designed the whole company. There's no room for bottom-up initiative. How could there be? Change anywhere could unbalance the whole machine.
Sure sounds convincing, doesn't it? Well, no, it doesn't. Company processes aren't as carefully engineered as all that. They aren't perfectly optimized from a global, top-down perspective.
The situation is messier than that.
In a typical company, core processes ... the processes that form the heart of the business ... are well-engineered and well supported by the company's enterprise systems. It's hard to escape this conclusion because by definition, a company's core processes are what give it a competitive advantage. That being the case, they will have received the most attention, brainpower, and investment.
Move away from the core processes and you typically find solutions that are more ad hoc in nature. That makes sense. Company leaders should invest more time and attention in competitive differentiators than in business responsibilities that support business responsibilities that support business responsibilities that support competitive differentiators.
So we'd expect to find more opportunities for bottom-up innovation in non-core areas of responsibility than in core processes. This logic dictates a policy that locks down most rigidly the PCs of employees who play primary roles in core and near-core business functions and processes. The PCs of employees whose responsibilities are farther away from the core would be more open.
This makes for a neat, tidy little business paradigm, not too different from Geoffrey Moore's "Keep the core and outsource the rest."
Don't trust tidy little business paradigms. Too often they are on the wrong side of the line that separates the simple from the simplistic.
Here's one of the nasty little conundrums (conundra?) that get in the way. Imagine your company's core and supporting processes really are carefully engineered and perfectly balanced. If that's the case, then in addition to perfect optimization, the company will have achieved perfect stagnation and stasis.
Look at any large organization that's optimized from the top down and you'll find it almost has to discourage front-line innovation. How do you innovate in a world where, when Manufacturing sneezes, Marketing has to say "gesundheit"?
The price to be paid for tight integration is rigidity, and a powerful resistance to change. Today's efficiency almost guarantees tomorrow's obsolescence.
On the other hand, advocating inefficiency and poor business integration just doesn't sit very well.
Do you still think desktop policy is a simple matter?
Think again.
-----------------
Copyright and other stuff -- The great KJR link point
Monday, March 17, 2008
Deciding how far to open the portal door
3/10/2008
What is it about vitamins?
When I was a kid they were chewable. Then I grew up and they were small, coated, and easily swallowed.
Now they make me feel like Mr. Ed: They're the size of horse pills, and if (when) they get stuck on the way down I taste alfalfa, or maybe straw.
Speaking of things that are hard to swallow, correspondent Mark Sowash made me aware that, since at least last October, Gartner has been predicting increased employee ownership of PCs (Ready or not, here comes user PC choice Computerworld 10/15/2007).
There is, of course, a difference between prediction and advocacy. Still, fair's fair -- Gartner got there first (ouch!) and I agree (the horror!).
The Computerworld article describes a 250-employee consulting company that's giving employee PC ownership a try.
It isn't going to be a free-for-all. The company is establishing standards for all PCs that connect to the corporate network, especially for security. It will scan devices for compliance before they connect. It's moving its enterprise applications to web-based access to keep enterprise data in the data center.
Sounds well-thought-out and workable to me.
Following last week's column on this subject (Getting to 21st century IT Keep the Joint Running 3/3/2008) I added two posts on Advice Line, the question-and-answer blog I do for InfoWorld (Can virtualization resolve the IT/end-user disconnect? 2/29/2008 and Getting to 21st century IT - User-owned PCs? 3/4/2008), asking for comments. The response was enthusiastic, perceptive, argumentative at times, and in all respects worthwhile.
I was struck by something: The positions taken were generally rooted in a hidden assumption about the nature of the workplace and employee. Those advocating employee ownership, for example, tended to be travelers or knowledge workers who are expected to creatively solve problems for their employers. Many of those who rejected the idea (and the idea of significantly loosened controls) support production workers with well-defined responsibilities that are entirely supported by the company's enterprise applications.
The more I think about the subject the more I'm convinced the right answer isn't yes or no. It's "it depends." This is, in retrospect, obvious. It's also woefully incomplete, because the moment you say the words, you have to then explain what "it" depends on.
We'll start the ball rolling this week with three factors: size, role, and regulation.
Size: Small companies tend to succeed through individual initiative, employing generalists who understand a broad swath of what the company does. Most "business process" happens inside one employee's head.
As companies grow they gain economies of scale. To get them, they have to standardize what was idiosyncratic, whether the subject is business process, HR policy or PC configurations. Employee roles specialize, and what used to happen in one person's head now happens through defined workflows.
It's a sad trade-off: With success comes increasing bureaucracy, because the alternative is having costs increase as fast as revenue, or even faster.
Role: Some jobs are defined by their lack of clear definition. While the desired outcome might be clear, the means for achieving it is not. The list might include sales, marketing, consulting, IT developer (yes, IT developer) and varying kinds of analyst.
If you can't predict what someone will have to do to get the job done it seems futile to lock down a specific toolkit and say, "that's all you need."
Other jobs are rigidly defined and narrowly focused. Call center agents come to mind. While they might, and often are called on to be flexible in how they converse with callers, when the time comes to pull data out of the company's systems and put new data in, you want every agent to use the exact same tools in the exact same way.
Regulation: Some businesses are more highly regulated than others. This is neither bad nor good (I remember the pre-environmental-regulation United States and like what we have now much better). It's a fact.
Another fact: Regulators care about compliance and only compliance. If compliance means a reduced ability to innovate, too bad. HIPAA regulators care about protecting patient data. The impact on creativity elsewhere in the company isn't their concern.
The Big Finish: The smaller the company, the broader and fuzzier the role, and the less regulated the industry, the more likely it is you can open things up.
The really tough challenge is figuring out what you can do, if you're big and highly regulated, to provide as much empowerment as possible. After all, the people who run big companies rarely want to preside over bureaucracies.
They just need an alternative.
What is it about vitamins?
When I was a kid they were chewable. Then I grew up and they were small, coated, and easily swallowed.
Now they make me feel like Mr. Ed: They're the size of horse pills, and if (when) they get stuck on the way down I taste alfalfa, or maybe straw.
Speaking of things that are hard to swallow, correspondent Mark Sowash made me aware that, since at least last October, Gartner has been predicting increased employee ownership of PCs (Ready or not, here comes user PC choice Computerworld 10/15/2007).
There is, of course, a difference between prediction and advocacy. Still, fair's fair -- Gartner got there first (ouch!) and I agree (the horror!).
The Computerworld article describes a 250-employee consulting company that's giving employee PC ownership a try.
It isn't going to be a free-for-all. The company is establishing standards for all PCs that connect to the corporate network, especially for security. It will scan devices for compliance before they connect. It's moving its enterprise applications to web-based access to keep enterprise data in the data center.
Sounds well-thought-out and workable to me.
Following last week's column on this subject (Getting to 21st century IT Keep the Joint Running 3/3/2008) I added two posts on Advice Line, the question-and-answer blog I do for InfoWorld (Can virtualization resolve the IT/end-user disconnect? 2/29/2008 and Getting to 21st century IT - User-owned PCs? 3/4/2008), asking for comments. The response was enthusiastic, perceptive, argumentative at times, and in all respects worthwhile.
I was struck by something: The positions taken were generally rooted in a hidden assumption about the nature of the workplace and employee. Those advocating employee ownership, for example, tended to be travelers or knowledge workers who are expected to creatively solve problems for their employers. Many of those who rejected the idea (and the idea of significantly loosened controls) support production workers with well-defined responsibilities that are entirely supported by the company's enterprise applications.
The more I think about the subject the more I'm convinced the right answer isn't yes or no. It's "it depends." This is, in retrospect, obvious. It's also woefully incomplete, because the moment you say the words, you have to then explain what "it" depends on.
We'll start the ball rolling this week with three factors: size, role, and regulation.
Size: Small companies tend to succeed through individual initiative, employing generalists who understand a broad swath of what the company does. Most "business process" happens inside one employee's head.
As companies grow they gain economies of scale. To get them, they have to standardize what was idiosyncratic, whether the subject is business process, HR policy or PC configurations. Employee roles specialize, and what used to happen in one person's head now happens through defined workflows.
It's a sad trade-off: With success comes increasing bureaucracy, because the alternative is having costs increase as fast as revenue, or even faster.
Role: Some jobs are defined by their lack of clear definition. While the desired outcome might be clear, the means for achieving it is not. The list might include sales, marketing, consulting, IT developer (yes, IT developer) and varying kinds of analyst.
If you can't predict what someone will have to do to get the job done it seems futile to lock down a specific toolkit and say, "that's all you need."
Other jobs are rigidly defined and narrowly focused. Call center agents come to mind. While they might, and often are called on to be flexible in how they converse with callers, when the time comes to pull data out of the company's systems and put new data in, you want every agent to use the exact same tools in the exact same way.
Regulation: Some businesses are more highly regulated than others. This is neither bad nor good (I remember the pre-environmental-regulation United States and like what we have now much better). It's a fact.
Another fact: Regulators care about compliance and only compliance. If compliance means a reduced ability to innovate, too bad. HIPAA regulators care about protecting patient data. The impact on creativity elsewhere in the company isn't their concern.
The Big Finish: The smaller the company, the broader and fuzzier the role, and the less regulated the industry, the more likely it is you can open things up.
The really tough challenge is figuring out what you can do, if you're big and highly regulated, to provide as much empowerment as possible. After all, the people who run big companies rarely want to preside over bureaucracies.
They just need an alternative.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, March 4, 2008
Getting to 21st century IT
3/3/2008
When is a computer not a computer?
Answer: When it's a portal to an entire universe, as I pointed out last week with perhaps-excessive lyricism. Lyrical or not, quite a few correspondents agreed with the column's core arguments:
Many, misreading last week's column as advocacy of a free-for-all in business computing, were horrified.
My point was something different: This, like it or not, is the situation. IT needs to figure out how to adapt, instead of establishing policies and procedures predicated on a world that no longer exists.
Look, for example, at an increasingly common class of employee -- the traveler. Few among us still entertain the notion that this is a cushy, glamorous existence. Travel delays, increasingly cramped airline seating, the need to schlep one's office and wardrobe along, and the rigors of threat levels eternally Orange combine to make business travel an annoying lifestyle at best.
Add to this the typical corporate no-personal-use computing policy. In practical terms it means no ability to answer personal e-mail for days at a time; no right to use the Internet for non-business purposes, even after business hours; no right to download music and add it to an MP3 player to help pass the time during the next cross-country flight.
In many companies, it appears corporate IT expects travelers to bring two laptops along -- one personal, the other corporate. Very nice.
Here's one more, related point: Many IT end-user support organizations are trapped in the "Whiteout-on-a-screen" mentality while many of the alleged Whiteout users routinely participate in (for example) on-line gaming environments with sophisticated interfaces they nonchalantly figure out on their own, without thinking much of it.
This is the challenge. The question is what to do about it.
Correspondent Richard Resnick provided the most extreme suggestion: No corporate-owned PCs at all. Let employees buy their own -- whatever they think they need to do their jobs. It's Nicholas Carr's vision in reverse: Only central IT remains. Employees take over ownership of the periphery, including responsibility for their own PC support.
It's an intriguing alternative, and one not easily envisioned. Certainly, the nature of the protections IT would institute would be very different given the change in boundary. I leave the specifics as an exercise for the reader.
Another correspondent, Will Pearce, provided a less radical alternative: Virtualize. Give end-users two virtual machines.
IT has valid concerns about having to support systems on which end-users have installed unapproved software, so one virtual machine would be buttoned-down, corporate, protected, fully supported, and strongly connected.
End-users and business managers, on the other hand, frequently discover useful software tools that are not on IT's list of supported applications. Enter the Sandbox -- a place end-users can install and use business-focused applications IT doesn't and doesn't need to support. If they work without creating conflicts with other applications, more power to everyone, and IT might even add them to the supported list.
If they don't ... it's the Sandbox. All the user has to do is switch over to the corporate virtual machine to continue working. All IT has to do is to restore the standard Sandbox virtual machine.
I'd add a third virtual machine as well. It would be open, personal, still reasonably protected ... but unsupported beyond restoring the virtual machine, and kept outside the corporate firewall. Travelers and other employees in the growing population of those who donate personal time to their employers would be able to use their personal virtual machine to take care of personal business without impinging on corporate IT.
Even if you ignore the issues discussed this week and last, virtualization would appear to provide an easier-to-administer alternative to maintaining standard images for restoring hashed-up systems. It certainly seems like a workable technological core for handling the challenges discussed last week and here.
End-user ownership of the periphery is a fascinating long-shot. Virtualization is a promising but unproven possibility. Entirely different alternatives might prove superior for supporting the 21st century workforce.
Underneath the specific solutions is the contrast between two corporate attitudes. One considers employees a necessary evil -- unavoidable, but suspect; untrustworthy entities from which the corporation must be protected. The other recognizes employees as the source of all success.
IT's response to the 21st century workforce depends on which sort of employee companies think they have.
So, as it happens, does every company's long-term financial success.
When is a computer not a computer?
Answer: When it's a portal to an entire universe, as I pointed out last week with perhaps-excessive lyricism. Lyrical or not, quite a few correspondents agreed with the column's core arguments:
- When using their home computers, end-users experience a vast array of possibilities, but at the office they operate in a very constrained space; and
- Increasingly, "work/life balance" is giving way to "live your life wherever you are."
Many, misreading last week's column as advocacy of a free-for-all in business computing, were horrified.
My point was something different: This, like it or not, is the situation. IT needs to figure out how to adapt, instead of establishing policies and procedures predicated on a world that no longer exists.
Look, for example, at an increasingly common class of employee -- the traveler. Few among us still entertain the notion that this is a cushy, glamorous existence. Travel delays, increasingly cramped airline seating, the need to schlep one's office and wardrobe along, and the rigors of threat levels eternally Orange combine to make business travel an annoying lifestyle at best.
Add to this the typical corporate no-personal-use computing policy. In practical terms it means no ability to answer personal e-mail for days at a time; no right to use the Internet for non-business purposes, even after business hours; no right to download music and add it to an MP3 player to help pass the time during the next cross-country flight.
In many companies, it appears corporate IT expects travelers to bring two laptops along -- one personal, the other corporate. Very nice.
Here's one more, related point: Many IT end-user support organizations are trapped in the "Whiteout-on-a-screen" mentality while many of the alleged Whiteout users routinely participate in (for example) on-line gaming environments with sophisticated interfaces they nonchalantly figure out on their own, without thinking much of it.
This is the challenge. The question is what to do about it.
Correspondent Richard Resnick provided the most extreme suggestion: No corporate-owned PCs at all. Let employees buy their own -- whatever they think they need to do their jobs. It's Nicholas Carr's vision in reverse: Only central IT remains. Employees take over ownership of the periphery, including responsibility for their own PC support.
It's an intriguing alternative, and one not easily envisioned. Certainly, the nature of the protections IT would institute would be very different given the change in boundary. I leave the specifics as an exercise for the reader.
Another correspondent, Will Pearce, provided a less radical alternative: Virtualize. Give end-users two virtual machines.
IT has valid concerns about having to support systems on which end-users have installed unapproved software, so one virtual machine would be buttoned-down, corporate, protected, fully supported, and strongly connected.
End-users and business managers, on the other hand, frequently discover useful software tools that are not on IT's list of supported applications. Enter the Sandbox -- a place end-users can install and use business-focused applications IT doesn't and doesn't need to support. If they work without creating conflicts with other applications, more power to everyone, and IT might even add them to the supported list.
If they don't ... it's the Sandbox. All the user has to do is switch over to the corporate virtual machine to continue working. All IT has to do is to restore the standard Sandbox virtual machine.
I'd add a third virtual machine as well. It would be open, personal, still reasonably protected ... but unsupported beyond restoring the virtual machine, and kept outside the corporate firewall. Travelers and other employees in the growing population of those who donate personal time to their employers would be able to use their personal virtual machine to take care of personal business without impinging on corporate IT.
Even if you ignore the issues discussed this week and last, virtualization would appear to provide an easier-to-administer alternative to maintaining standard images for restoring hashed-up systems. It certainly seems like a workable technological core for handling the challenges discussed last week and here.
End-user ownership of the periphery is a fascinating long-shot. Virtualization is a promising but unproven possibility. Entirely different alternatives might prove superior for supporting the 21st century workforce.
Underneath the specific solutions is the contrast between two corporate attitudes. One considers employees a necessary evil -- unavoidable, but suspect; untrustworthy entities from which the corporation must be protected. The other recognizes employees as the source of all success.
IT's response to the 21st century workforce depends on which sort of employee companies think they have.
So, as it happens, does every company's long-term financial success.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, February 26, 2008
The portal
2/25/2008
In 1980, a 3278 green-screen terminal cost (as I recall) about $6,000, not including the mainframe it attached to.
Along came the PC. It cost half that, and was self-sufficient.
IT tried to keep them out. They put too much power in the hands of ignorant users and you couldn't do serious computing on them anyway. Yes, the IT authorities made both arguments, simultaneously, and didn't even blush.
PCs leaked in despite IT's opinion. Distributed computing leaked in too. The economics made them unavoidable. Various pundits claim otherwise, but they are comparing the costs of PCs and distributed computing with the competition-deflated costs of mainframe computing, not the pre-PC high-margin early-1980s price tag.
Fast-forward to now. You can buy a 150 gigabyte drive for less than $100. For another hundred bucks you can buy a USB external disk to back it up.
For 150 backed-up gigabytes, IT would charge $1,500 per year.
From my backup drive I can restore any file in five minutes. IT would take more than a day. Self-service? Forget it.
In 1980, IT completely locked down the 3278 terminal, by definition. IT now locks down the PC, not by definition but by choice. Meanwhile, at home, people install whatever they please, and in spite of what the doomsayers tell you, few run into insurmountable problems. Those who do sheepishly ask their teen-aged children to help them. Their teenagers give them the same eyeball rolls they get from the Help Desk staff at work, but much better service.
Nothing in this comparison is fair. Fair has nothing to do with it. My PC at home beckons, saying "Yes, you can do that too." My PC at work says, "No you can't." Your end-users experience that contrast every working day.
Preaching to them that "it's a business computer, to be used only for business purposes," isn't persuasive, because they know something we in IT often ignore: It isn't really a computer.
Oh, technically that's what it is, but technically doesn't matter. The PC is a portal to a universe of possibilities. While the word "cyberspace" has fallen out of use, the idea of cyberspace is alive, well, and built into the perception of everyone who looks at a screen while manipulating a keyboard and mouse.
It might be time ... past time ... for IT to look at its job in a new way.
Try this on for size: Imagine you ran IT as if it embraced this PC-as-portal perspective. As if IT's job was to manage one corner of that universe of possibilities.
What would you do differently?
Let's take it a step further. Let's look, not just at the PC but about work as a whole from the employee's point of view. That shouldn't be too hard. We in IT are employees too, when we aren't busy being IT professionals.
From the employee's point of view the job is, in addition to being a way to earn a living, a place for: social interaction; developing the self-esteem that comes from creating value and achieving important things; structuring time and staying occupied; exercising their brains and keeping them from becoming stale.
Few employees draw a hard boundary around their work life, keeping it psychologically distinct and independent of the rest of their life. They are the same people in the office as out of the office.
We in IT are stuck in a 1950s industrial view of the workplace. Much of the workforce is post-industrial in perspective. They don't "achieve work/life balance." They just live their lives, wherever they happen to be at the moment -- sometimes in the office, sometimes out of it.
In the office they research reports, create presentations, check their investment portfolios, answer business e-mail, answer personal e-mail, make business phone calls, answer personal phone calls.
Out of the office they think about the reports, edit the presentations, check their investment portfolios, answer business e-mail, answer personal e-mail, make business phone calls, and answer personal phone calls.
Employees live a significant part of their lives in the universe of possibilities they reach through their PCs, their Blackberries, the Treos, their iPhones.
The economic gap between self-sufficient computing and central IT that drove the PC revolution is back. The existential gulf separating IT's perception of work from the employee perception of work is new, and wider. We in IT had better figure it out, or business users will figure it out without us.
Because for us, a PC is an expensive, hard-to-support business resource. But for them it's a portal to an entire universe they can buy at Costco for a few hundred bucks.
In 1980, a 3278 green-screen terminal cost (as I recall) about $6,000, not including the mainframe it attached to.
Along came the PC. It cost half that, and was self-sufficient.
IT tried to keep them out. They put too much power in the hands of ignorant users and you couldn't do serious computing on them anyway. Yes, the IT authorities made both arguments, simultaneously, and didn't even blush.
PCs leaked in despite IT's opinion. Distributed computing leaked in too. The economics made them unavoidable. Various pundits claim otherwise, but they are comparing the costs of PCs and distributed computing with the competition-deflated costs of mainframe computing, not the pre-PC high-margin early-1980s price tag.
Fast-forward to now. You can buy a 150 gigabyte drive for less than $100. For another hundred bucks you can buy a USB external disk to back it up.
For 150 backed-up gigabytes, IT would charge $1,500 per year.
From my backup drive I can restore any file in five minutes. IT would take more than a day. Self-service? Forget it.
In 1980, IT completely locked down the 3278 terminal, by definition. IT now locks down the PC, not by definition but by choice. Meanwhile, at home, people install whatever they please, and in spite of what the doomsayers tell you, few run into insurmountable problems. Those who do sheepishly ask their teen-aged children to help them. Their teenagers give them the same eyeball rolls they get from the Help Desk staff at work, but much better service.
Nothing in this comparison is fair. Fair has nothing to do with it. My PC at home beckons, saying "Yes, you can do that too." My PC at work says, "No you can't." Your end-users experience that contrast every working day.
Preaching to them that "it's a business computer, to be used only for business purposes," isn't persuasive, because they know something we in IT often ignore: It isn't really a computer.
Oh, technically that's what it is, but technically doesn't matter. The PC is a portal to a universe of possibilities. While the word "cyberspace" has fallen out of use, the idea of cyberspace is alive, well, and built into the perception of everyone who looks at a screen while manipulating a keyboard and mouse.
It might be time ... past time ... for IT to look at its job in a new way.
Try this on for size: Imagine you ran IT as if it embraced this PC-as-portal perspective. As if IT's job was to manage one corner of that universe of possibilities.
What would you do differently?
Let's take it a step further. Let's look, not just at the PC but about work as a whole from the employee's point of view. That shouldn't be too hard. We in IT are employees too, when we aren't busy being IT professionals.
From the employee's point of view the job is, in addition to being a way to earn a living, a place for: social interaction; developing the self-esteem that comes from creating value and achieving important things; structuring time and staying occupied; exercising their brains and keeping them from becoming stale.
Few employees draw a hard boundary around their work life, keeping it psychologically distinct and independent of the rest of their life. They are the same people in the office as out of the office.
We in IT are stuck in a 1950s industrial view of the workplace. Much of the workforce is post-industrial in perspective. They don't "achieve work/life balance." They just live their lives, wherever they happen to be at the moment -- sometimes in the office, sometimes out of it.
In the office they research reports, create presentations, check their investment portfolios, answer business e-mail, answer personal e-mail, make business phone calls, answer personal phone calls.
Out of the office they think about the reports, edit the presentations, check their investment portfolios, answer business e-mail, answer personal e-mail, make business phone calls, and answer personal phone calls.
Employees live a significant part of their lives in the universe of possibilities they reach through their PCs, their Blackberries, the Treos, their iPhones.
The economic gap between self-sufficient computing and central IT that drove the PC revolution is back. The existential gulf separating IT's perception of work from the employee perception of work is new, and wider. We in IT had better figure it out, or business users will figure it out without us.
Because for us, a PC is an expensive, hard-to-support business resource. But for them it's a portal to an entire universe they can buy at Costco for a few hundred bucks.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, February 19, 2008
Capability Maturity Model revisited
2/18/2008
I wrote harsh words about the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) (The connection between leadership and process in IT Keep the Joint Running 1/14/2008).
Nobody wrote to disagree. Not exactly. Hillel Glazer, an SEI insider, politely informed me that I was hopelessly out of date: SEI abandoned CMM in 2001 in favor of Capability Maturity Model Integration (CMMI). He agreed to an interview to explain the situation. Mike Konrad, one of CMMI's authors, reviewed Hillel's answers and wrote me independently to endorse them.
Bob: SEI describes CMMI as a general-purpose process framework that can be used to create just about any sort of business process -- not just software methodologies. Do we need yet another process methodology, given that we already have: Lean, Six Sigma, Lean Six Sigma, Theory of Constraints, and Reengineering?
Hillel: To be more precise, "CMMI-DEV" is not for creating business processes or for creating (developing) products, but for improving the business processes of product and service development. CMMI assumes a given organization already has business processes and desires to improve them. What happens all too often is organizations are compelled to use CMMI but start out not having/knowing their processes and so CMMI becomes both how they define their processes as well as how they improve them. It's a fundamental -- and widely held -- misunderstanding of CMMI.
Bob: In his 2005 interview, Capers Jones was openly dismissive of Agile and similar adaptive, iterative methodologies. With CMMI, has SEI softened its stance?
Hillel: Capers Jones is not a reviewer or contributor to CMMI, and I wouldn't say SEI folks and Capers Jones see eye to eye on many things.
When CMMI was being written, reviewers were criticizing SEI for making it so "waterfall" centric. The authors were genuinely dumbfounded as to what it is in the model that gave that "anti-iteration" connotation. CMMI is 100% agnostic as to the product development life cycle an organization chooses to use, and always has been. Also, the SEI has created a team-oriented development method called "Team Software Process" (TSP) which has been demonstrated as being very agile-oriented.
Bob: Does any of this really matter to bread-and-butter IT shops? Most companies don't develop -- they integrate and configure purchased applications. The packaged methodologies, waterfall or iterative, weren't designed for this world. Does CMMI offer something useful for it, or is it also intended for new development?
Hillel: Right now, ITIL probably provides more value than CMMI to pure-play IT shops. However, stay tuned, there's another CMMI in the works for "services" organizations that goes beyond a static library of management and service workflows and offers a continuous improvement mechanism to companies providing services -- IT or otherwise.
Bob: I've recommended culture change as the first step in implementing a more process-driven approach in any organization -- to create a "culture of process" -- and to make sure process owners are fully educated in process management. Do you agree? If not, how do you recommend starting down the CMMI path?
Hillel: I completely agree. When working with companies that do need a culture shift, the first thing I get them to internalize are the CMMI's "generic practices" which provide the process acculturation so many organizations lack.
In many cases, no matter how much power they've been given, you can't start with the CIO, you must start with the CEO. The CEO needs to see the business value of being process-oriented. Otherwise, the CIO will be placed in an untenable position at the business level.
Bob: Anything else?
Hillel: What's most often misunderstood about this is that "CMMI is a model, not a standard." CMMI contains no processes or procedures of its own, and is not a thing that can be complied with. It's a fundamental shift in expectation and experience of most CMMI users -- who are used to complying with standards. Wrapping one's head around and being able to apply a model takes a whole different set of aptitudes than complying with a standard.
We hear "just tell me what to do" all the time. Combine that with the impatience (read: short attention span) and lack of process culture among too many executives -- a topic you regularly rail against -- and you have a recipe for process disaster.
Bob: Last question: Do you agree Keep the Joint Running is the most insightful commentary in the IT industry? Or would you rather have me twist your responses in creative ways that make you appear to be the biggest schlemiel in the trade?
Hillel: LOL!
Bob: Don't say I didn't warn you ...
I wrote harsh words about the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) (The connection between leadership and process in IT Keep the Joint Running 1/14/2008).
Nobody wrote to disagree. Not exactly. Hillel Glazer, an SEI insider, politely informed me that I was hopelessly out of date: SEI abandoned CMM in 2001 in favor of Capability Maturity Model Integration (CMMI). He agreed to an interview to explain the situation. Mike Konrad, one of CMMI's authors, reviewed Hillel's answers and wrote me independently to endorse them.
Bob: SEI describes CMMI as a general-purpose process framework that can be used to create just about any sort of business process -- not just software methodologies. Do we need yet another process methodology, given that we already have: Lean, Six Sigma, Lean Six Sigma, Theory of Constraints, and Reengineering?
Hillel: To be more precise, "CMMI-DEV" is not for creating business processes or for creating (developing) products, but for improving the business processes of product and service development. CMMI assumes a given organization already has business processes and desires to improve them. What happens all too often is organizations are compelled to use CMMI but start out not having/knowing their processes and so CMMI becomes both how they define their processes as well as how they improve them. It's a fundamental -- and widely held -- misunderstanding of CMMI.
Bob: In his 2005 interview, Capers Jones was openly dismissive of Agile and similar adaptive, iterative methodologies. With CMMI, has SEI softened its stance?
Hillel: Capers Jones is not a reviewer or contributor to CMMI, and I wouldn't say SEI folks and Capers Jones see eye to eye on many things.
When CMMI was being written, reviewers were criticizing SEI for making it so "waterfall" centric. The authors were genuinely dumbfounded as to what it is in the model that gave that "anti-iteration" connotation. CMMI is 100% agnostic as to the product development life cycle an organization chooses to use, and always has been. Also, the SEI has created a team-oriented development method called "Team Software Process" (TSP) which has been demonstrated as being very agile-oriented.
Bob: Does any of this really matter to bread-and-butter IT shops? Most companies don't develop -- they integrate and configure purchased applications. The packaged methodologies, waterfall or iterative, weren't designed for this world. Does CMMI offer something useful for it, or is it also intended for new development?
Hillel: Right now, ITIL probably provides more value than CMMI to pure-play IT shops. However, stay tuned, there's another CMMI in the works for "services" organizations that goes beyond a static library of management and service workflows and offers a continuous improvement mechanism to companies providing services -- IT or otherwise.
Bob: I've recommended culture change as the first step in implementing a more process-driven approach in any organization -- to create a "culture of process" -- and to make sure process owners are fully educated in process management. Do you agree? If not, how do you recommend starting down the CMMI path?
Hillel: I completely agree. When working with companies that do need a culture shift, the first thing I get them to internalize are the CMMI's "generic practices" which provide the process acculturation so many organizations lack.
In many cases, no matter how much power they've been given, you can't start with the CIO, you must start with the CEO. The CEO needs to see the business value of being process-oriented. Otherwise, the CIO will be placed in an untenable position at the business level.
Bob: Anything else?
Hillel: What's most often misunderstood about this is that "CMMI is a model, not a standard." CMMI contains no processes or procedures of its own, and is not a thing that can be complied with. It's a fundamental shift in expectation and experience of most CMMI users -- who are used to complying with standards. Wrapping one's head around and being able to apply a model takes a whole different set of aptitudes than complying with a standard.
We hear "just tell me what to do" all the time. Combine that with the impatience (read: short attention span) and lack of process culture among too many executives -- a topic you regularly rail against -- and you have a recipe for process disaster.
Bob: Last question: Do you agree Keep the Joint Running is the most insightful commentary in the IT industry? Or would you rather have me twist your responses in creative ways that make you appear to be the biggest schlemiel in the trade?
Hillel: LOL!
Bob: Don't say I didn't warn you ...
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, February 12, 2008
Carr-toonish engineering
2/11/2008
If someone does something that's patently ridiculous, but manages to draw enough attention that it generates a lot of discussion, has that person performed a valuable service or just wasted our time?
But enough about Paris Hilton, Kiefer Sutherland and Lindsay Lohan. In our own industry we can ask a similar question about Nicholas Carr, who, as mentioned last week, has predicted that the "technical aspect of IT" (which in Carr's world is IT infrastructure management) will move to the Internet, which will become the CPU-cycle-provisioning equivalent of an electrical power plant.
With the technical part gone, handling the non-technical remainder (I bet you didn't know application design, development and integration are non-technical undertakings) won't require a separate in-house IT organization any more. Instead, they will become a mixture of Software as a Service (SaaS) applications and business-department-developed code that runs on the utility computing infrastructure.
Sometimes, fault-finding isn't the best way to evaluate a new idea. A superior alternative is to be helpful and positive -- to figure out how to make it work (for a historical example, see Inhaling network computers KJR, 1/13/1997.)
What will be required for IT to go away?
First of all, let's assume Carr isn't simply "predicting" the success of IT infrastructure outsourcing, as I contended last week -- that he's serious about utility computing in the electrical generation sense.
In the deregulated electrical power industry, generation companies pump 60-cycle current onto the grid, metering how much they provide. End-customers draw electricity off the grid. Their local provider acts as a broker, buying current from the low-cost provider and metering consumption.
This is, by the way, how you can buy wind-generated electricity if you prefer. You don't really get the exact electrons pushed onto the grid by a wind farm. You simply instruct your broker to buy enough of them to satisfy your consumption. The rest is just balancing the books.
For utility computing to work, we would need a similar metering and billing infrastructure. We'd need a lot more, too. For example:
Now, look ahead just far enough that you're at the end of any useful business planning horizon. You'll reach a very different conclusion.
If someone does something that's patently ridiculous, but manages to draw enough attention that it generates a lot of discussion, has that person performed a valuable service or just wasted our time?
But enough about Paris Hilton, Kiefer Sutherland and Lindsay Lohan. In our own industry we can ask a similar question about Nicholas Carr, who, as mentioned last week, has predicted that the "technical aspect of IT" (which in Carr's world is IT infrastructure management) will move to the Internet, which will become the CPU-cycle-provisioning equivalent of an electrical power plant.
With the technical part gone, handling the non-technical remainder (I bet you didn't know application design, development and integration are non-technical undertakings) won't require a separate in-house IT organization any more. Instead, they will become a mixture of Software as a Service (SaaS) applications and business-department-developed code that runs on the utility computing infrastructure.
Sometimes, fault-finding isn't the best way to evaluate a new idea. A superior alternative is to be helpful and positive -- to figure out how to make it work (for a historical example, see Inhaling network computers KJR, 1/13/1997.)
What will be required for IT to go away?
First of all, let's assume Carr isn't simply "predicting" the success of IT infrastructure outsourcing, as I contended last week -- that he's serious about utility computing in the electrical generation sense.
In the deregulated electrical power industry, generation companies pump 60-cycle current onto the grid, metering how much they provide. End-customers draw electricity off the grid. Their local provider acts as a broker, buying current from the low-cost provider and metering consumption.
This is, by the way, how you can buy wind-generated electricity if you prefer. You don't really get the exact electrons pushed onto the grid by a wind farm. You simply instruct your broker to buy enough of them to satisfy your consumption. The rest is just balancing the books.
For utility computing to work, we would need a similar metering and billing infrastructure. We'd need a lot more, too. For example:
- Web 3.0: We will need a grid computing architecture that runs applications wherever CPU cycles happen to be cheapest (with suitable metering and billing -- see above).
- Virtualization: This will have to be perfect, so that the CPU cycles you buy can run your applications no matter what operating system they were written for.
- Quality of Service: Different applications need different levels of performance. Buyers will need a way to specify how fast their cycles have to be, and without the help of those pesky engineers who would be housed in an IT department if it hadn't been disbanded.
- AI-based data design: With professional, centralized IT evaporated into the business, which will be building whatever custom applications remain, there will no longer be an organizational home for data designers. The only alternative is technology smart enough to handle this little engineering chore.
- Automated, self-tuning pre-fetch: Last week's column demonstrated the impact of latency in the communications channel on linked SaaS-supplied systems -- the speed of light slows table joins to a crawl.
This is fixable, so long as systems are smart enough to automatically pre-fetch records prior to needing them. Every SaaS vendor will have to provide this facility automatically, since businesses will no longer employ engineers able to manually performance-tune system linkages.
- New security paradigm: Sorry about the use of "paradigm." It fits here. You'll be running all of your applications on public infrastructure, on the wrong side of the firewall (which -- good news! -- you'll no longer need). Think it will be hard for someone with ingenuity to plant a Trojan that monitors the cycles and siphons off every business secret you no longer have?
- AI-based data warehouse design: Let's assume for the sake of argument that the Carr-envisioned future happens as he predicts. You will still want to mine all of your data, in spite of it being schmeared out across the SaaS landscape.
I see two choices. The first, almost unimaginable, is an efficient, distributed, virtual data warehouse, reminiscent of the sea shell collection Steven Wright keeps scattered on beaches all over the world.
The alternative is the same data warehouse technology we've grown accustomed to. Except we don't have IT anymore, so we'll need an AI design technology to pull it together for us, performance optimized and ready for analysis.
Now, look ahead just far enough that you're at the end of any useful business planning horizon. You'll reach a very different conclusion.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, February 5, 2008
Carr-ied away
2/4/2008
Nicholas Carr has a new theory -- that internal IT is reaching the end of the line, because information technology will follow the same commoditization curve that electrical utilities followed a century ago.
Okay, it isn't really a new theory, although from the attention Carr is getting for his new book, which should have been titled The Joys of Griddish but instead is called The Big Switch: Rewiring the World, from Edison to Google (W. W. Norton, 2008), you'd think he had come up with it all by himself.
Carr, you'll recall, previously theorized that IT doesn't matter (We ain't there quite yet Keep the Joint Running 6/16/2003). His reasoning: Every business has access to the same information technology, so IT can't provide a sustainable strategic advantage.
That his old theory was fatally flawed is easily demonstrated: Every business has access to the same everything as every other business -- the same technology, ideas, people, processes, capital, real estate, and silly articles published in the Harvard Business Review because their authors were once on its editorial staff.
Were we to accept Carr's past logic and apply it equally to all subjects, we would despairingly conclude that nothing matters. Now, not content with turning us all into depressed nihilists, Carr has discovered (and we should be pleased for him) the Internet and the possibility of outsourcing all of the computing cycles of every business to it.
What Carr has visionarily discovered, while tossing in terms like grid and utility computing to prove he is Fully Buzzword Compliant, is IT infrastructure outsourcing, a mere three decades after it began. Meanwhile, many very large corporations that outsourced their IT infrastructure have found that economies of scale reach a point of diminishing returns -- enterprises reach a size where running their own data center costs less and provides more value than contracting with an outsourcer.
But never mind this little quibble. After all, many businesses aren't that big and data center outsourcing does make sense for them. It's nothing new and makes no difference. It's business as usual right now, and companies still need an IT organization, because ...
Applications and the information they process are where the IT rubber meets the business road. Computer programs are not indistinguishable from one another. The information in the data repositories they control is unique, valuable, and (assuming corporations are careful about information security) private.
Carr hasn't entirely ignored this reality in "his" theory of utility computing. He merely waves it off as trivial -- something easily solved through a combination of Software as a Service (SaaS, which if you've been asleep for awhile means hosted solutions) and ... here's an exact quote ... "the ability to write your own code but use utility suppliers to run it and to store it. Companies will continue to have the ability to write proprietary code and to run it as a service to get the efficiencies and the flexibility it provides."
With unparalleled perspicuity, Carr has figured out that companies can write their own code and then run it in an outsourced data center. Hokey smokes!
Carr's New Insight is that responsibility for applications will move "into the business" which is why IT will eventually go away. He endorses the notion that businesses can easily integrate disparate SaaS-provided applications and databases across the Internet using a few easy-to-use interfaces.
What nonsense. Most internal IT organizations long ago changed their focus. They seldom develop. Mostly they configure and integrate purchased applications.
Nothing about this is easy. Integrating multiple applications and their databases takes complex engineering, not facile hand-waving. Moving responsibility "into the business" means nothing more than managing multiple, smaller, poorly cooperating IT departments instead of single, larger centralized ones. Ho hum.
Nor can integrating multiple SaaS systems work in a high-volume production environment. That's because of a concept network engineers but not self-appointed "experts" understand: latency.
Imagine a financial services company. Customer management is SaaS in California. loan operations is SaaS in Massachusetts. You have to update 10 million customer accounts every day with interest computations. The minimum latency imposed by the laws of physics on an ordinary two-table join adds more than 45 hours to this little batch run.
Well-integrated computing environments come from serious engineering. Phrases like utility computing and grid might obscure this fact behind a fog of vagueness. They don't eliminate it.
I have my own vision for the future of IT. In it, only people who have written code, designed databases, administered servers or engineered networks at some time in their careers will get to write about IT's past, present and future.
The rest can include themselves out.
Nicholas Carr has a new theory -- that internal IT is reaching the end of the line, because information technology will follow the same commoditization curve that electrical utilities followed a century ago.
Okay, it isn't really a new theory, although from the attention Carr is getting for his new book, which should have been titled The Joys of Griddish but instead is called The Big Switch: Rewiring the World, from Edison to Google (W. W. Norton, 2008), you'd think he had come up with it all by himself.
Carr, you'll recall, previously theorized that IT doesn't matter (We ain't there quite yet Keep the Joint Running 6/16/2003). His reasoning: Every business has access to the same information technology, so IT can't provide a sustainable strategic advantage.
That his old theory was fatally flawed is easily demonstrated: Every business has access to the same everything as every other business -- the same technology, ideas, people, processes, capital, real estate, and silly articles published in the Harvard Business Review because their authors were once on its editorial staff.
Were we to accept Carr's past logic and apply it equally to all subjects, we would despairingly conclude that nothing matters. Now, not content with turning us all into depressed nihilists, Carr has discovered (and we should be pleased for him) the Internet and the possibility of outsourcing all of the computing cycles of every business to it.
What Carr has visionarily discovered, while tossing in terms like grid and utility computing to prove he is Fully Buzzword Compliant, is IT infrastructure outsourcing, a mere three decades after it began. Meanwhile, many very large corporations that outsourced their IT infrastructure have found that economies of scale reach a point of diminishing returns -- enterprises reach a size where running their own data center costs less and provides more value than contracting with an outsourcer.
But never mind this little quibble. After all, many businesses aren't that big and data center outsourcing does make sense for them. It's nothing new and makes no difference. It's business as usual right now, and companies still need an IT organization, because ...
Applications and the information they process are where the IT rubber meets the business road. Computer programs are not indistinguishable from one another. The information in the data repositories they control is unique, valuable, and (assuming corporations are careful about information security) private.
Carr hasn't entirely ignored this reality in "his" theory of utility computing. He merely waves it off as trivial -- something easily solved through a combination of Software as a Service (SaaS, which if you've been asleep for awhile means hosted solutions) and ... here's an exact quote ... "the ability to write your own code but use utility suppliers to run it and to store it. Companies will continue to have the ability to write proprietary code and to run it as a service to get the efficiencies and the flexibility it provides."
With unparalleled perspicuity, Carr has figured out that companies can write their own code and then run it in an outsourced data center. Hokey smokes!
Carr's New Insight is that responsibility for applications will move "into the business" which is why IT will eventually go away. He endorses the notion that businesses can easily integrate disparate SaaS-provided applications and databases across the Internet using a few easy-to-use interfaces.
What nonsense. Most internal IT organizations long ago changed their focus. They seldom develop. Mostly they configure and integrate purchased applications.
Nothing about this is easy. Integrating multiple applications and their databases takes complex engineering, not facile hand-waving. Moving responsibility "into the business" means nothing more than managing multiple, smaller, poorly cooperating IT departments instead of single, larger centralized ones. Ho hum.
Nor can integrating multiple SaaS systems work in a high-volume production environment. That's because of a concept network engineers but not self-appointed "experts" understand: latency.
Imagine a financial services company. Customer management is SaaS in California. loan operations is SaaS in Massachusetts. You have to update 10 million customer accounts every day with interest computations. The minimum latency imposed by the laws of physics on an ordinary two-table join adds more than 45 hours to this little batch run.
Well-integrated computing environments come from serious engineering. Phrases like utility computing and grid might obscure this fact behind a fog of vagueness. They don't eliminate it.
I have my own vision for the future of IT. In it, only people who have written code, designed databases, administered servers or engineered networks at some time in their careers will get to write about IT's past, present and future.
The rest can include themselves out.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, January 29, 2008
Run, IT, run ... but not as a business
1/28/2008
Nitpicking is fun, but pragmatism pays the bills.
Last week's column, which deconstructed the notion that CIOs should run IT as a business, was fun, but it might have been more self-indulgent than useful.
The column, if you missed it, listed eleven definitions of "business" and demonstrated that none of them makes sense as a basis for running an IT department. But running IT like a business doesn't require you to define it as one, Louis Sullivan's dictum that "form follows function" notwithstanding.
After you've finished singing, dancing and playing the tuba, running IT like a business means negotiating "service level agreements" (SLAs) for what you do and instituting a system of charge-backs to the rest of the business to pay for it.
Negotiated SLAs are contracts between IT and the departments IT serves, and are just plain silly.
Contracts are how businesses manage relationships with their customers, so if you are to run IT as a business, this is what you must do.
Which brings up the question, what happens if you fail to live up to one of your negotiated SLAs? In business, this would result in financial penalties, withheld payments, binding arbitration, or lawsuits.
Just how stupid would a business look if Manufacturing took IT to court for failing to live up to an SLA? This isn't an easy question to answer because "stupid" isn't easily quantified, nor is there a unit of measure for it. If stupid was electricity and we measured it in volts, I'm pretty sure this would reach Taser levels.
Charge-backs, in contrast to SLAs, do have one thing going for them -- they vastly simplify IT governance. If, for example, Marketing wants to re-plumb the company website with a content management system (CMS), you have no worries. Marketing signs up for the cost and charge-backs give you the budget you need. You hire staff, engage contractors or bring in a systems integrator and everybody is happy.
Not really. What really happens is that your staff based its CMS recommendation on what would integrate best with the rest of your technical architecture, scale without major reconfiguration, and allow granular administration to avoid opening interesting holes in your information security.
The Marketing Director, being a prudent steward of her departmental budget, obtains three competitive bids. All are lower than your estimate.
Of course they are. Because your staff failed to run IT like a business. They are running IT like a department, responsible for managing the company's information assets. And so you lose the Marketing Department's business to a competitor.
It isn't the Marketing Director's fault. IT isn't alone in this nonsense. If IT is to be run as a business, so is every other shared service department in the enterprise, Marketing included. Marketing doesn't want to lose the Dental Accessories business unit's account to an outside agency, so it has to keep its costs as low as possible.
And the race to the bottom continues.
CEOs who organize the enterprise so its shared services departments act as independent businesses have forgotten a basic engineering principle ... that optimizing the parts sub-optimizes the whole and vice versa ("Optimizing the organization Keep the Joint Running 10/27/2003).
Specifically, the company's shared services organizations, when run as businesses, lose their authority to preserve the integrity of essential resources. In the case of IT it's the information architecture. In the case of Marketing it's the corporate image and the meaning of the brand. In the case of Human Resources it's the policies that protect employees from bad managers while allowing managers to deal with non-performing employees without the risk of ending up in court.
And so on.
No question, the idea is seductive. CEOs, for understandable reasons, are likely to have a strong faith in the power of markets to regulate themselves efficiently without the need for outside controls or guidance. That being the case, turning the enterprise into a marketplace sure seems easier than the hard work of instituting the governance processes, difficult choices and consensus building that are otherwise required. As is so often the case, trying to avoid hard work doesn't lead to brilliant results.
Marketplaces don't require all of this because they don't have a purpose. They are simply spaces where entities that do have purpose interact in complex ways.
Companies have a purpose. Marketplaces don't. Turning a company into a marketplace misses this essential difference.
In the end, running IT as a business ... and the enterprise as a marketplace ... is an attempt to avoid the need for governance processes, difficult choices and consensus building.
Another name for these activities is leadership. Done right it's hard work.
Nitpicking is fun, but pragmatism pays the bills.
Last week's column, which deconstructed the notion that CIOs should run IT as a business, was fun, but it might have been more self-indulgent than useful.
The column, if you missed it, listed eleven definitions of "business" and demonstrated that none of them makes sense as a basis for running an IT department. But running IT like a business doesn't require you to define it as one, Louis Sullivan's dictum that "form follows function" notwithstanding.
After you've finished singing, dancing and playing the tuba, running IT like a business means negotiating "service level agreements" (SLAs) for what you do and instituting a system of charge-backs to the rest of the business to pay for it.
Negotiated SLAs are contracts between IT and the departments IT serves, and are just plain silly.
Contracts are how businesses manage relationships with their customers, so if you are to run IT as a business, this is what you must do.
Which brings up the question, what happens if you fail to live up to one of your negotiated SLAs? In business, this would result in financial penalties, withheld payments, binding arbitration, or lawsuits.
Just how stupid would a business look if Manufacturing took IT to court for failing to live up to an SLA? This isn't an easy question to answer because "stupid" isn't easily quantified, nor is there a unit of measure for it. If stupid was electricity and we measured it in volts, I'm pretty sure this would reach Taser levels.
Charge-backs, in contrast to SLAs, do have one thing going for them -- they vastly simplify IT governance. If, for example, Marketing wants to re-plumb the company website with a content management system (CMS), you have no worries. Marketing signs up for the cost and charge-backs give you the budget you need. You hire staff, engage contractors or bring in a systems integrator and everybody is happy.
Not really. What really happens is that your staff based its CMS recommendation on what would integrate best with the rest of your technical architecture, scale without major reconfiguration, and allow granular administration to avoid opening interesting holes in your information security.
The Marketing Director, being a prudent steward of her departmental budget, obtains three competitive bids. All are lower than your estimate.
Of course they are. Because your staff failed to run IT like a business. They are running IT like a department, responsible for managing the company's information assets. And so you lose the Marketing Department's business to a competitor.
It isn't the Marketing Director's fault. IT isn't alone in this nonsense. If IT is to be run as a business, so is every other shared service department in the enterprise, Marketing included. Marketing doesn't want to lose the Dental Accessories business unit's account to an outside agency, so it has to keep its costs as low as possible.
And the race to the bottom continues.
CEOs who organize the enterprise so its shared services departments act as independent businesses have forgotten a basic engineering principle ... that optimizing the parts sub-optimizes the whole and vice versa ("Optimizing the organization Keep the Joint Running 10/27/2003).
Specifically, the company's shared services organizations, when run as businesses, lose their authority to preserve the integrity of essential resources. In the case of IT it's the information architecture. In the case of Marketing it's the corporate image and the meaning of the brand. In the case of Human Resources it's the policies that protect employees from bad managers while allowing managers to deal with non-performing employees without the risk of ending up in court.
And so on.
No question, the idea is seductive. CEOs, for understandable reasons, are likely to have a strong faith in the power of markets to regulate themselves efficiently without the need for outside controls or guidance. That being the case, turning the enterprise into a marketplace sure seems easier than the hard work of instituting the governance processes, difficult choices and consensus building that are otherwise required. As is so often the case, trying to avoid hard work doesn't lead to brilliant results.
Marketplaces don't require all of this because they don't have a purpose. They are simply spaces where entities that do have purpose interact in complex ways.
Companies have a purpose. Marketplaces don't. Turning a company into a marketplace misses this essential difference.
In the end, running IT as a business ... and the enterprise as a marketplace ... is an attempt to avoid the need for governance processes, difficult choices and consensus building.
Another name for these activities is leadership. Done right it's hard work.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, January 22, 2008
Running IT like a whatchamacallit
1/21/2008
CIOs are, according to many in the business punditocracy, supposed to run IT as a business. Yet in spite of all of the ink smeared on crushed trees advocating this thought process (not to mention the miniscule magnetic domains that have given up their freedom to store it) I've yet to see anyone define what they mean by "business."
It might seem too obvious to bother with. We all know what a business is, don't we?
That's the problem with this sort of thing: We all do know what a business is, only we don't all know what one is in the same way. Depending on the situation and who is doing the talking, businesses can be:
When a CIO is supposed to run IT as a business, which definitions are supposed to be part of the formula?
Certainly not Definition #1. If you work in IT you might like it, as it makes Definition #7 a more enduring possibility. But even ignoring the pundits who also recommend disbanding internal IT in favor of outsourcing, self-perpetuation isn't something you can sell to a board of directors.
Which also means you can scratch Definition #7 off the list.
Definition #2 is a certainty. In its simplest form, IT's mission is to provide working information technology to the business. This, or something like it, is IT's mission whether you run it as a business, a department, or a hobby, so scratch Definition #2 off the list as well. The same logic applies to Definitions #6, #8 and #9.
Definition #3 is a distinct possibility. Never mind a mission. A Definition #3 IT business would deliver products and services to internal customers in exchange for money, through the magic of transfer pricing (the practice formerly known as charge-backs).
Except that it doesn't work that way. When companies engage in transfer pricing they put controls in place to make sure internal departments break even exactly. If they didn't, the business as a whole would be an ecology (Definition #5, as are most companies that engage in transfer pricing anyway). Scratch this one off, too, and Definition #4 for the same reason.
Definition #5 is a good representation of a marketplace as well as a jungle, and in fact, marketplaces are near-perfect parallels to ecologies. It's bad enough when a CEO turns a whole enterprise into an ecology. Another description of this sort of environment is "political quagmire." One presumes "run IT as a political quagmire" isn't what the pundits have in mind.
Definitions #10 and #11 make no sense either. It might be fun to sell shares in IT to various business executives and might even lead to beneficial results, in much the way the Green Bay Packers benefit from having 125,000 fans as the shareholders who collectively own the team.
Somehow I just don't see it working very well in practice.
So there you have it. Eleven different definitions of "business" and not one of them makes any sense for IT. Which leads to a question: If IT isn't a business by any reasonable definition of the term, what might it mean to run it like one?
I'm left without an answer, and with only one possible conclusion -- that I don't know what the pundits are talking about.
I suspect that's something they and I have in common.
CIOs are, according to many in the business punditocracy, supposed to run IT as a business. Yet in spite of all of the ink smeared on crushed trees advocating this thought process (not to mention the miniscule magnetic domains that have given up their freedom to store it) I've yet to see anyone define what they mean by "business."
It might seem too obvious to bother with. We all know what a business is, don't we?
That's the problem with this sort of thing: We all do know what a business is, only we don't all know what one is in the same way. Depending on the situation and who is doing the talking, businesses can be:
- Non-human, amoral organisms that have an existence independent of the people who make them up, and which, like any other organisms, consider self-perpetuation their first and most important goal.
- Mission-driven entities that exist to provide goods and services that have value to someone.
- Product generators that exist to deliver items for which customers will pay more money than was needed to provide them.
- Profit generators that exist to deliver a stream of money to their actively-involved owners.
- Ecologies -- environments in which individuals compete, and sometimes collaborate to obtain resources.
- Assemblages of processes that connect to transform inputs into outputs.
- Places of employment that exchange work assignments for money and non-cash compensation.
- Social fabrics that provide a space for people to interact and form connections.
- Personal "force multipliers" that increase an individual's ability to achieve goals.
- Opportunities for investment, to deliver a lump of cash to a passively involved shareholder.
- Commodities to be bought, sold, aggregated or dispersed for profit.
When a CIO is supposed to run IT as a business, which definitions are supposed to be part of the formula?
Certainly not Definition #1. If you work in IT you might like it, as it makes Definition #7 a more enduring possibility. But even ignoring the pundits who also recommend disbanding internal IT in favor of outsourcing, self-perpetuation isn't something you can sell to a board of directors.
Which also means you can scratch Definition #7 off the list.
Definition #2 is a certainty. In its simplest form, IT's mission is to provide working information technology to the business. This, or something like it, is IT's mission whether you run it as a business, a department, or a hobby, so scratch Definition #2 off the list as well. The same logic applies to Definitions #6, #8 and #9.
Definition #3 is a distinct possibility. Never mind a mission. A Definition #3 IT business would deliver products and services to internal customers in exchange for money, through the magic of transfer pricing (the practice formerly known as charge-backs).
Except that it doesn't work that way. When companies engage in transfer pricing they put controls in place to make sure internal departments break even exactly. If they didn't, the business as a whole would be an ecology (Definition #5, as are most companies that engage in transfer pricing anyway). Scratch this one off, too, and Definition #4 for the same reason.
Definition #5 is a good representation of a marketplace as well as a jungle, and in fact, marketplaces are near-perfect parallels to ecologies. It's bad enough when a CEO turns a whole enterprise into an ecology. Another description of this sort of environment is "political quagmire." One presumes "run IT as a political quagmire" isn't what the pundits have in mind.
Definitions #10 and #11 make no sense either. It might be fun to sell shares in IT to various business executives and might even lead to beneficial results, in much the way the Green Bay Packers benefit from having 125,000 fans as the shareholders who collectively own the team.
Somehow I just don't see it working very well in practice.
So there you have it. Eleven different definitions of "business" and not one of them makes any sense for IT. Which leads to a question: If IT isn't a business by any reasonable definition of the term, what might it mean to run it like one?
I'm left without an answer, and with only one possible conclusion -- that I don't know what the pundits are talking about.
I suspect that's something they and I have in common.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, January 15, 2008
The connection between leadership and process in IT
1/14/2008
Business is the land of the panacea, and IT is its capital. Sensible people ... people who would never ask, "What do you think -- should I take tetracycline, Vitamin D, or have surgery?" before undergoing the minor inconvenience of a medical diagnosis to determine (a) if they are ill; and (b) if so, with what ... ask whether they should undertake CMM, ITIL or COBiT without first having any idea of what is and isn't working well.
Let's dispose of something right now: Ignore CMM (the Software Engineering Institute's Capability Maturity Model).
That, more or less, is the advice given by Capers Jones, one of CMM's strongest advocates.
CMM is waterfall application development methodology taken off a cliff. (Come to think of it, waterfalls always go off a cliff, by definition. Oh, never mind.) Had everyone followed CMM, the World Wide Web would never have happened. By the time the first few thousand websites had been deployed ... with maybe one tenth the content and functionality of the ones that actually happened ... everyone would have lost interest.
According to Capers Jones, CMM is essential for just about any run-of-the-mill IT shop that employs more than 1,000 developers and undertakes 10,000+ function point projects. He has solid evidence that this is the case.
So if you lead more than a thousand developers, it's just barely possible that you really do need CMM. Probably not, though, because even if you do, you rarely have a reason to charter a 10,000+ function point development project, for two reasons.
The first: You're almost always better off chunking your projects down into a succession of small projects instead. Risk goes down, success is more reliable, and business value happens faster. And, (he said, never passing up an opportunity to plug his books and seminars) you can employ the Bare Bones methodology instead of something bulkier.
The second: Most business IT groups spend the majority of their applications effort integrating, configuring, maintaining and upgrading commercial software packages rather than developing from scratch. The square peg of development methodologies has limited relevance when it comes to the round hole of integration and configuration, despite decades of attempts to pound one into the other.
But I digress.
Four major factors determine the success of any IT organization: Business alignment, process maturity, technical architecture, and human performance.
Which of the four is most important? Human performance, without a doubt. As mentioned here in recent columns, the proof is easy, and geometrical in its rigor: Great employees routinely overcome bad or non-existent process, ineffective leadership and governance, and messy technical architecture. Bad employees just as routinely cause even the best process designs to fail while turning elegant architecture into a tangle of spaghetti, and efficient governance into meaningless committee meetings as projects become eternal.
Bad employees don't routinely fail in the face of excellent leadership for the simple reason that excellent leaders hire bad employees less often, and when they do either coach them to success, reassign them to more suitable roles, or terminate them. Strong leaders don't tolerate weak employees.
That doesn't stop us (us being IT Catalysts, my consulting company) from advising clients on how to make their processes more effective. Far from it. One of the questions we often ask struggling managers is how (but really whether) they know if the processes they're responsible for are healthy.
Am I speaking out of both sides of my mouth?
Not at all. Here's the distinction: Effective leaders place their emphasis on people. Effective managers insist on delivery, and recognize the importance of process in achieving that end.
If you are responsible for a business function you have to be effective at both leadership and management, and they aren't independent topics.
Effective management depends on effective leadership for all the reasons enumerated here over the past few weeks and summarized above: Effective leadership puts motivated employees with the right skills, attitude and focus in the right roles, allowing processes to be effective.
Effective leadership is equally dependent on effective management, although the reason is more subtle: Because effective managers know how to monitor and manage processes, they can know what's going on without having to micromanage.
One other reason for the dependency: If you are in charge of a business function, you have to know how to manage first, because results ... process outputs ... are what you're paid for.
Fail to deliver them and your own manager might insist you spend less time leading and more time closely supervising the work.
Business is the land of the panacea, and IT is its capital. Sensible people ... people who would never ask, "What do you think -- should I take tetracycline, Vitamin D, or have surgery?" before undergoing the minor inconvenience of a medical diagnosis to determine (a) if they are ill; and (b) if so, with what ... ask whether they should undertake CMM, ITIL or COBiT without first having any idea of what is and isn't working well.
Let's dispose of something right now: Ignore CMM (the Software Engineering Institute's Capability Maturity Model).
That, more or less, is the advice given by Capers Jones, one of CMM's strongest advocates.
CMM is waterfall application development methodology taken off a cliff. (Come to think of it, waterfalls always go off a cliff, by definition. Oh, never mind.) Had everyone followed CMM, the World Wide Web would never have happened. By the time the first few thousand websites had been deployed ... with maybe one tenth the content and functionality of the ones that actually happened ... everyone would have lost interest.
According to Capers Jones, CMM is essential for just about any run-of-the-mill IT shop that employs more than 1,000 developers and undertakes 10,000+ function point projects. He has solid evidence that this is the case.
So if you lead more than a thousand developers, it's just barely possible that you really do need CMM. Probably not, though, because even if you do, you rarely have a reason to charter a 10,000+ function point development project, for two reasons.
The first: You're almost always better off chunking your projects down into a succession of small projects instead. Risk goes down, success is more reliable, and business value happens faster. And, (he said, never passing up an opportunity to plug his books and seminars) you can employ the Bare Bones methodology instead of something bulkier.
The second: Most business IT groups spend the majority of their applications effort integrating, configuring, maintaining and upgrading commercial software packages rather than developing from scratch. The square peg of development methodologies has limited relevance when it comes to the round hole of integration and configuration, despite decades of attempts to pound one into the other.
But I digress.
Four major factors determine the success of any IT organization: Business alignment, process maturity, technical architecture, and human performance.
Which of the four is most important? Human performance, without a doubt. As mentioned here in recent columns, the proof is easy, and geometrical in its rigor: Great employees routinely overcome bad or non-existent process, ineffective leadership and governance, and messy technical architecture. Bad employees just as routinely cause even the best process designs to fail while turning elegant architecture into a tangle of spaghetti, and efficient governance into meaningless committee meetings as projects become eternal.
Bad employees don't routinely fail in the face of excellent leadership for the simple reason that excellent leaders hire bad employees less often, and when they do either coach them to success, reassign them to more suitable roles, or terminate them. Strong leaders don't tolerate weak employees.
That doesn't stop us (us being IT Catalysts, my consulting company) from advising clients on how to make their processes more effective. Far from it. One of the questions we often ask struggling managers is how (but really whether) they know if the processes they're responsible for are healthy.
Am I speaking out of both sides of my mouth?
Not at all. Here's the distinction: Effective leaders place their emphasis on people. Effective managers insist on delivery, and recognize the importance of process in achieving that end.
If you are responsible for a business function you have to be effective at both leadership and management, and they aren't independent topics.
Effective management depends on effective leadership for all the reasons enumerated here over the past few weeks and summarized above: Effective leadership puts motivated employees with the right skills, attitude and focus in the right roles, allowing processes to be effective.
Effective leadership is equally dependent on effective management, although the reason is more subtle: Because effective managers know how to monitor and manage processes, they can know what's going on without having to micromanage.
One other reason for the dependency: If you are in charge of a business function, you have to know how to manage first, because results ... process outputs ... are what you're paid for.
Fail to deliver them and your own manager might insist you spend less time leading and more time closely supervising the work.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, January 8, 2008
A contrarian view of process
1/7/2008
Process has dominated the consulting world, at least since Michael Hammer and James Champy published Reengineering the Corporation in 1994.
Keep the Joint Running and its InfoWorld predecessor, Survival Guide, have been contrarian about process for nearly as long.
The process perspective isn't wrong. It is, however, subordinate to other, more important perspectives. As evidence:
Process has dominated the consulting world, at least since Michael Hammer and James Champy published Reengineering the Corporation in 1994.
Keep the Joint Running and its InfoWorld predecessor, Survival Guide, have been contrarian about process for nearly as long.
The process perspective isn't wrong. It is, however, subordinate to other, more important perspectives. As evidence:
- Jim Collins' Good to Great (2001) isolated five factors common to the high-performance companies he and his team analyzed. Process improvement or reengineering initiatives weren't among them. High-quality leadership, a culture of discipline, and strategic focus were.
- William Joyce, Nitin Nohria, and Bruce Roberson published the results of their "Evergreen Project" in What Really Works (2004). Their formulation is a bit more complicated than Collins', but similar in most respects. Their evidence was, if anything, more compelling.
Over the ten years examined in the study, companies that followed the "formula" increased sales by 415 percent and operating income by 326 percent. Companies that didn't increased sales by just 83 percent and operating income by 22 percent. - Regular correspondent Noah Wollner pointed me to an older study by John Kotter and James Heskitt. Titled Corporate Culture and Performance (1992), it contrasted companies that fostered a "performance enhancing culture" with others that didn't. Defined as promoting risk taking and innovation, being receptive to change, valuing entrepreneurship, and encouraging mutual support in identifying and solving problems, the impact was, to say the least, significant:
Over an eleven year span, organizations with performance-enhancing cultures experienced 682 percent revenue growth and 746 percent net income growth. Those that didn't grew revenue by only 166 percent and net income by just 1 percent over the same period of time. - And, as mentioned [in] my last column, every time anyone looks at what drives customer satisfaction, employee attitude is the most important underlying factor.
So far as I can tell, there is no reliable published evidence, other than the anecdotal, that process change is a primary driver of business success.
Does this mean process has no value in a modern corporation? That would be a false inference. The question isn't whether process matters. The question is how it matters.
Those who view companies as collections of processes end up looking at companies as mechanisms -- collections of gears, cogs, buttons, and wheels. From this perspective, employees occupy some but not all roles in a process. Done right, everyone is replaceable, and when replaced, nothing changes.
Those who view companies as collections of people end up in a different place. For us, businesses are, first and foremost, societies. While not the lead story, process still has important roles to play.
First, process encourages consistency where consistency matters -- usually when the company has to produce a large number of very similar items; sometimes when failing to undertake work in a very specific way can lead to dangerous situations or legal liability.
Second, having well-defined processes lets employees focus on getting work done instead of on figuring out how to do it. Just as important, well-defined processes (and procedures) make collaboration easier because everyone involved shares a common understanding of how we do things around here.
And finally, well-defined processes create a framework for constant, steady improvement ("continuous improvement" is the now-cliched, preferred buzz-phrase). Without a well-defined process to provide a baseline, the enterprise has to constantly start over -- the getting-work-done equivalent of software that never progresses beyond the alpha-testing release.
In human-centered enterprises, process also has clear boundaries. The most important is this: Everyone understands that the business exists to take care of customers; that taking care of customers is something employees do; and that employees rely on trustworthy processes to help them do it, when the processes fit the situation.
When a company's processes don't fit the situation, the company has to make a choice. It can, with complete validity, decide that what the customer wants isn't something the company does. If you run a travel agency and a customer wants you to replace a broken axle in the family minivan, "Sorry but we don't do that," is a reasonable response.
"We haven't done that before, but we'll figure out a way to do it for you," is often an even more reasonable response: The company can decide that when its standard processes don't fit a customer's request, the customer has just revealed an opportunity, or something that should be fixed.
Companies that only do what they do eventually do too much of what customers don't need any more. Those that figure out how to handle unexpected requests, on the other hand, sometimes find whole new profitable lines of business in the process.
As it were.
-----------------
Copyright and other stuff -- The great KJR link point
Friday, December 28, 2007
A holiday card to the industry - 2007
12/24/2007
People, process, and technology.
It's a simple formula that describes what makes any business operate. For decades, those who shape business thinking have ranked them as follows:
It can't be. No matter how well-designed its processes and how superior its technology, a business with disaffected, unmotivated, apathetic employees ... led poorly by definition ... will fail.
Nothing can overcome the wrong people.
Great employees, in contrast, will get the job done whether there is a process in place or not, let alone whether it's a good process. They will get the job done with substandard technology. They will get it done, even when company management puts barrier after barrier in their path.
Business consultants call these employees "heroes." Succeeding through heroics isn't supposed to be good business.
And it isn't, because relying on heroism is like relying on luck. Eventually, luck runs out. Eventually, too, heroes fail to beat the odds that are stacked against them.
Many in business, when they use the term "hero," do not mean it as a compliment. This makes no sense. Men and women succeed through heroics because they must, not because they choose to: With better processes, technology, leadership and support, extraordinary effort might be less necessary. Until then it's the source of business success.
Great employees succeed no matter what. Bad employees fail no matter what. Most employees create superior results with the right leadership but don't insist on it: Badly led, they become apathetic losers.
With the right leadership most employees succeed. Without it most employees don't. It's true of leaders but not of technology or process.
Then there are customers. It's a rare business that succeeds without them. Supposedly, they no longer feel any loyalty.
So let's look at baseball. Some teams have fanatically loyal fans -- teams like the Boston Red Sox and New York Yankees, who have been known to win from time to time, but also teams like the Chicago Cubs, who, if they fail to win the World Series next year will have achieved a full century without one.
Something these teams have in common: They have never threatened to leave for economically warmer climes or better stadia. They have, instead, maintained a steady, warm bond with their fans, who enthusiastically return the favor.
Some businesses that are not baseball teams also sustain loyal customers. Once upon a time there was, for example, the Green Mill, a "three/two" joint (that is, it served weak beer) on the corner of Grand and Hamline in St. Paul.
The Mill was the center of my social life. It was more than that -- it was the center of a community. Less sanitary than Cheers (but then, isn't any worthwhile bar when you're young?) it was the place everybody knew my name.
Everyone knew Galvin's name as well. I recall an occasion when Galvin cashed a check at the Mill. Bikko, who tended bar at this fine establishment (and was known to buy a round from time to time), asked if the address on the check was correct. Galvin affirmed that this was so.
Bikko took a second look. "Hey, this is our address!" he said. Galvin affirmed that this was so as well.
"Makes sense to me," Bikko remarked as he handed Galvin two tens and a five.
The Green Mill is now a classy, faux-potted-plant-laden chain of gourmet Italian restaurants. It has strong process that creates great product -- Chicago-style deep dish pizza and gourmet beer. But nobody knows my name, nor wants to.
I might go there for a meal once every year or two.
The Green Mill of my youth didn't become a community through process or technology. It didn't do so through product quality either: The beer was thin and the pizza was, so far as we could tell, cardboard covered with cheese.
I was there every night. It was home, because Bikko behind the bar and Schultzy at the tables were our hosts and our friends.
If it matters, research confirms that customer loyalty comes from loyal, committed, enthusiastic employees more than it comes from any other factor, and that business success comes from loyal customers more than it comes from any other single factor.
The research isn't really necessary, of course -- all that's needed is a moment's reflection.
It isn't the technology. It isn't the processes. It isn't even the products.
It is, happily enough, the people.
People, process, and technology.
It's a simple formula that describes what makes any business operate. For decades, those who shape business thinking have ranked them as follows:
- Businesses are collections of processes.
- Businesses hire people to perform roles in those processes.
- Businesses use technology to automate processes or process steps.
It can't be. No matter how well-designed its processes and how superior its technology, a business with disaffected, unmotivated, apathetic employees ... led poorly by definition ... will fail.
Nothing can overcome the wrong people.
Great employees, in contrast, will get the job done whether there is a process in place or not, let alone whether it's a good process. They will get the job done with substandard technology. They will get it done, even when company management puts barrier after barrier in their path.
Business consultants call these employees "heroes." Succeeding through heroics isn't supposed to be good business.
And it isn't, because relying on heroism is like relying on luck. Eventually, luck runs out. Eventually, too, heroes fail to beat the odds that are stacked against them.
Many in business, when they use the term "hero," do not mean it as a compliment. This makes no sense. Men and women succeed through heroics because they must, not because they choose to: With better processes, technology, leadership and support, extraordinary effort might be less necessary. Until then it's the source of business success.
Great employees succeed no matter what. Bad employees fail no matter what. Most employees create superior results with the right leadership but don't insist on it: Badly led, they become apathetic losers.
With the right leadership most employees succeed. Without it most employees don't. It's true of leaders but not of technology or process.
Then there are customers. It's a rare business that succeeds without them. Supposedly, they no longer feel any loyalty.
So let's look at baseball. Some teams have fanatically loyal fans -- teams like the Boston Red Sox and New York Yankees, who have been known to win from time to time, but also teams like the Chicago Cubs, who, if they fail to win the World Series next year will have achieved a full century without one.
Something these teams have in common: They have never threatened to leave for economically warmer climes or better stadia. They have, instead, maintained a steady, warm bond with their fans, who enthusiastically return the favor.
Some businesses that are not baseball teams also sustain loyal customers. Once upon a time there was, for example, the Green Mill, a "three/two" joint (that is, it served weak beer) on the corner of Grand and Hamline in St. Paul.
The Mill was the center of my social life. It was more than that -- it was the center of a community. Less sanitary than Cheers (but then, isn't any worthwhile bar when you're young?) it was the place everybody knew my name.
Everyone knew Galvin's name as well. I recall an occasion when Galvin cashed a check at the Mill. Bikko, who tended bar at this fine establishment (and was known to buy a round from time to time), asked if the address on the check was correct. Galvin affirmed that this was so.
Bikko took a second look. "Hey, this is our address!" he said. Galvin affirmed that this was so as well.
"Makes sense to me," Bikko remarked as he handed Galvin two tens and a five.
The Green Mill is now a classy, faux-potted-plant-laden chain of gourmet Italian restaurants. It has strong process that creates great product -- Chicago-style deep dish pizza and gourmet beer. But nobody knows my name, nor wants to.
I might go there for a meal once every year or two.
The Green Mill of my youth didn't become a community through process or technology. It didn't do so through product quality either: The beer was thin and the pizza was, so far as we could tell, cardboard covered with cheese.
I was there every night. It was home, because Bikko behind the bar and Schultzy at the tables were our hosts and our friends.
If it matters, research confirms that customer loyalty comes from loyal, committed, enthusiastic employees more than it comes from any other factor, and that business success comes from loyal customers more than it comes from any other single factor.
The research isn't really necessary, of course -- all that's needed is a moment's reflection.
It isn't the technology. It isn't the processes. It isn't even the products.
It is, happily enough, the people.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, December 18, 2007
[Yet] Another helpless desk
12/17/2007
In the beginning was Deming.
Deming introduced measurement to industry in the 1950s. A statistician, he relied on sophisticated multivariate techniques. He encouraged those who didn't understand sampling theory, analysis of variance and multiple regression to stay away and let the experts handle the data collection and math.
American industry ignored Deming and his theories -- I can't help but suspect America's enduring cultural distrust of the intellectual -- but Japan did not, turning itself from a defeated military power to a fierce economic superpower in the process.
As a culture we are nothing if not adaptable, and so "metrics" happened in (to?) America. Sadly, we aren't so adaptable that we were willing to actually learn, for example, statistics.
Which might explain why most of the metrics stories I hear are horror stories, not successes.
I'll be the first to admit to flaws in my sample. I'm sure it is non-stationary, biased, suffers from heteroskedasticity and perhaps the heartbreak of psoriasis as well. I'm nonetheless confident in this conclusion: Call centers are the most mis-measured function in business, and IT Service Desks are the most mis-measured type of call center. Which brings us to this week's anonymously provided tale of woe:
The culprit here is clear: Simplemindedness.
A Help Desk is neither simple nor solitary. It's one part of a system that should: Work on what's most important first; resolve incidents quickly; and prevent recurrences.
Assessing the system's outputs isn't all that challenging. Assessing the engineers and technicians who create the outputs is tougher.
They have to resolve what they can, properly refer what they can't, accurately document their work, and escalate underlying systemic defects. That requires: Intelligence, judgment, technical skill, diligence, and collaboration. It's a multivariate situation.
Just ask Deming.
In the beginning was Deming.
Deming introduced measurement to industry in the 1950s. A statistician, he relied on sophisticated multivariate techniques. He encouraged those who didn't understand sampling theory, analysis of variance and multiple regression to stay away and let the experts handle the data collection and math.
American industry ignored Deming and his theories -- I can't help but suspect America's enduring cultural distrust of the intellectual -- but Japan did not, turning itself from a defeated military power to a fierce economic superpower in the process.
As a culture we are nothing if not adaptable, and so "metrics" happened in (to?) America. Sadly, we aren't so adaptable that we were willing to actually learn, for example, statistics.
Which might explain why most of the metrics stories I hear are horror stories, not successes.
I'll be the first to admit to flaws in my sample. I'm sure it is non-stationary, biased, suffers from heteroskedasticity and perhaps the heartbreak of psoriasis as well. I'm nonetheless confident in this conclusion: Call centers are the most mis-measured function in business, and IT Service Desks are the most mis-measured type of call center. Which brings us to this week's anonymously provided tale of woe:
At the Help Desk where I currently work, they like to measure First Call Resolve (FCR).
What I am finding out from longtime tech support people is they like to game the metrics. Here's how it works:
First, the system defaults every call to Resolved whether it really is or not.
If a user never calls back to say "That didn't fix it", you get a freebie. If, on the other hand, the user does call back to say, "Yep, that fixed it," and the tech on the line documents the call in the system notes, you just lost an FCR. Why? Because you weren't the LAST person to talk to the user. Yep, the last person to talk to the user on a call gets the FCR. It's as if the relief pitcher who comes in with two outs in the ninth, a five-run lead and the bases empty gets credit for the win.
So potentially someone else could make you look bad, just by creating the last entry in a call log. And after five days, a ticket goes from Resolved to Closed and there's nothing you can do about it.
You always open a ticket on a new call, find out what the issue is, then decide if it's your queue or not. If not, you transfer it. However, the queue you transfer to will never get an FCR on that call even if they solve it immediately. Why? Two people have talked to the user, that's why.
Some tech guys get around that by opening up their own ticket and documenting it for an FCR, leaving your ticket out to hang. And that can ding YOU just as badly since it's been presumed you abandoned it. If you get a call where no one handles it but they actually need to call outside of tech support to, say, Financial Ops, you document it but those calls are not counted as FCR. They are deducted from your score.
Strangely enough, some of us were talking about this the other day -- about how to increase FCR legitimately. Some of them had researched suspicious FCR standings (which are posted for individuals) and found that some of the lumps were posting gratuitous FCR calls (in other words, fake calls). You could tell by the shortness of the ticket and the vague incorrect answers that were in the notes.
The best way to find the lumps? Not the FCR metrics -- they're worthless. Instead, just ask the other techs. Most tech people are fairly honest in appraising their fellow co-workers. It's not that we don't like them. It's idiotic management playing games with our stats.
So, like the plaque says, "Be careful what you measure. You'll get it.
The culprit here is clear: Simplemindedness.
A Help Desk is neither simple nor solitary. It's one part of a system that should: Work on what's most important first; resolve incidents quickly; and prevent recurrences.
Assessing the system's outputs isn't all that challenging. Assessing the engineers and technicians who create the outputs is tougher.
They have to resolve what they can, properly refer what they can't, accurately document their work, and escalate underlying systemic defects. That requires: Intelligence, judgment, technical skill, diligence, and collaboration. It's a multivariate situation.
Just ask Deming.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, December 11, 2007
Once in awhile it's done right
12/10/2007
Asked if the study of creation could provide any insights as to the nature of its Creator, the great biologist J. B. S. Haldane replied that clearly the Creator has " ... an inordinate fondness for beetles."
Coleopterans account for about a quarter of all animal species on this earth. Mammals, in contrast, contribute about a quarter of a percent of all species. Don't feel bad. By other measures I'm sure we human beings are more important.
Humans dominate all other species (except, perhaps, for some viruses and bacteria, along with ants, spiders and the aforementioned beetles) because of our ability to think: To make tools, to plan, to transfer skills and knowledge to our progeny.
That's how humans dominate other species. Individual humans dominate other humans through their social skills. These two facts explain most of human history: We win through intelligence. I win through what Daniel Goleman calls "emotional intelligence."
This is why most businesses fail to learn from their successes, as explained in detail in the last several editions of Keep the Joint Running: Learning from success is good for the company but not necessarily for those who run the company.
Emotional intelligence is a vital quality for effective leaders. The problem arises when they decide to value emotional intelligence more than tangible skills, knowledge and logical decision-making in the organizations they lead. It's how organizations start down the sad path to what my business partner calls "mediocracy."
It needn't be so. As evidence I submit this tale from a regular KJR correspondent:
Asked if the study of creation could provide any insights as to the nature of its Creator, the great biologist J. B. S. Haldane replied that clearly the Creator has " ... an inordinate fondness for beetles."
Coleopterans account for about a quarter of all animal species on this earth. Mammals, in contrast, contribute about a quarter of a percent of all species. Don't feel bad. By other measures I'm sure we human beings are more important.
Humans dominate all other species (except, perhaps, for some viruses and bacteria, along with ants, spiders and the aforementioned beetles) because of our ability to think: To make tools, to plan, to transfer skills and knowledge to our progeny.
That's how humans dominate other species. Individual humans dominate other humans through their social skills. These two facts explain most of human history: We win through intelligence. I win through what Daniel Goleman calls "emotional intelligence."
This is why most businesses fail to learn from their successes, as explained in detail in the last several editions of Keep the Joint Running: Learning from success is good for the company but not necessarily for those who run the company.
Emotional intelligence is a vital quality for effective leaders. The problem arises when they decide to value emotional intelligence more than tangible skills, knowledge and logical decision-making in the organizations they lead. It's how organizations start down the sad path to what my business partner calls "mediocracy."
It needn't be so. As evidence I submit this tale from a regular KJR correspondent:
I recently finished a six month job rotation as manager of our Service Desk (formerly "Helpless Desk" according to our users).
The prior manager measured performance on a strict count of tickets handled, weighted by priority. Since we can't reward by dollars (union shop), we use perks like window cubes, preferred schedules, and first choice on vacations as incentives.
The top performer for the 13 quarters prior to my arrival was an individual who I really didn't see doing anything. The quarter ended and he was again the top man. I decided to find his secret to success in an effort to raise everyone else's game. So I started analyzing his tickets.
His method was simple. Every single call he took was labeled Critical. If he took a ticket originally handled by someone else, he upgraded it. If he got repeat calls from the same user with the same problem, each was a new ticket. He closed out every ticket within two hours, regardless of whether the problem was handled or not. We measured volume, so he delivered volume.
However, when he trained someone new, he always preached completion, follow-up, and thorough documentation -- in short, how the job really should be done. He gamed the metric both ways (boost my numbers, lower your numbers). And we rewarded him for it.
I changed the rules and the measures. Those answering the phones started with the question "Is this a problem we have worked on before?" and reopened the old ticket instead of writing a new one. They wrote all tickets and graded their priority. They assigned the tickets and those handling them did not have authority to change the priority. I measured who got things fixed "once and for all" rather than incident volume.
Lo and behold, the top performer fell immediately into the bottom 10%. In the next quarterly survey of our effectiveness, users rated service 20% higher than ever previously. I was offered the position permanently (and declined it).
Our "top" performer left due to "absenteeism problems."
I left my successor a plaque that read "Be careful what you measure. You'll get it." (It's from one of your columns on metrics -- credit where it's due.)
My successor went even further. He rewards the people who identify patterns of problems and solve them, for individual recognition. He did away with the perk system in preference to a team system. His metrics are number of tickets, number of reopens, time from receipt of call to start of work, and customer satisfaction.
He also tracks the number of calls received to prevent gaming the first number by not writing tickets. The desk is way up in satisfaction, and he definitely is on the right track.
Oh, and he still uses the manual written by the former top performer to train people.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, December 4, 2007
Learning in the wrong direction
12/3/2007
Can an organization learn?
In response to the last two columns, which talked about the barriers to organizational learning and how to overcome them, a subscriber challenged me on this point. Learning, he said, is something people do, not organizations.
I agree, organizations aren't just people, only bigger. As has been pointed out in KJR more than once, they're a different type of creature than human beings, with different motivations and patterns of behavior (see What corporations and spleens have in common Keep the Joint Running 5/5/2003).
Can organizations learn? As is usually the case, the answer depends on how you define "learn." Since my scientific training is in sociobiology, I define it operationally: To learn is to change behavior in an adaptive way based on experience.
If that's the definition, the answer is an unequivocal "yes" -- organizations do change their behavior based on what they experience. They learn through changes in the behavior of their executives, managers and staff, just as animals learn through changes in the behavior of individual neurons. The difference: Executives, managers and staff can prevent the organization from learning if it isn't in their best interests.
To illustrate the point, here is a case study, sent in by a subscriber who really, really needs to remain anonymous:
The company I worked for had several divisions. I was a member of the smallest and we were led by a rogue Product Manager who thought we should write software the clients loved and could understand intuitively.
So we sat with clients, visited their offices to watch them work, etc. Our software won design awards, gained more than 50% market share in its space, and our engineers got standing ovations at user conferences.
At our annual company meeting the CFO would go over "the numbers" broken out by division which was fine when our division was tiny but as we grew people began to realize that we generated several times as much revenue per person as the other division -- we had 1/10 the total resources generating 1/3 the quarterly revenue.
Then it got childish. The "numbers" were no longer broken out by division. There was grumbling about special people making more money in "that" division when everyone was working "hard." The divisional portion of the yearly bonus was discontinued in favor of an overall company performance bonus.
But lo and behold, the success continued. At the peak a division containing 1/10 of all resources serviced 40% of all clients, and generated more than half the new software sales revenue vs. all other divisions combined. That factor of 10 revenue generation ratio was just too much and we soon found our core members redeployed to other projects, new mandates to use code libraries and architecture based on the other divisions' products, etc.
The moral of the story is that we succeeded for the customer for awhile, as evidenced by our developer-to-customer-support ratio (2 to 1) vs the other divisions (1 to 4) and support-to-customer ratio (1 per 700 vs 1 per 40).
But we failed in the long run because we couldn't bring the rest of the company along. Our success generated jealousy and animosity in the VP level office suites and since we were so small (1/10 the VP's) politically we never stood a chance. Once the high and mighty hit on the excuse above we got squashed like a bug.
The company was sold a few years later to a large software accumulator and is now being milked for its support fees. Which as you notice is great when you have a buggy, hard to use product with proprietary data and you charge high support and maintenance fees. But when customers don't need support because their old version works just fine that model breaks down.
The end result was the mass exodus of the best and brightest and now only a handful of the original group remain. All of us are now seeking to recapture that 5-6 year golden era before we were told to do less well so as not to offend our co-workers.
Truth is definitely weirder than fiction.
If this were fiction -- say, an episode of House -- we'd put these symptoms on a whiteboard and figure out what disease explains them all. My diagnosis: Weak leadership.
A strong CEO would have created an environment that recognized and emulated success, building it into the corporation's structure, compensation, and culture. A strong CEO would have recognized that in business, "fair" doesn't mean equality. It means meritocracy.
This CEO opted for "mediocracy" instead.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, November 27, 2007
Creating a learning organization
11/26/2007
Last week's column set some readers' teeth on edge (Why Johnny Corporation can't learn, Keep the Joint Running, 11/19/2007). The issue was its negative tone.
The column explained why corporations rarely learn from their mistakes and even more rarely learn from their successes. "Don't bring us problems -- bring us solutions," was the gist of the complaints.
Fair enough, so long as we all agree that unless you understand the underlying dynamics of a problem you're unlikely to find a solution.
Solutions to these two problems are especially tough to implement because doing so calls for challenging some very popular business beliefs and practices. In particular, companies that truly want to be "learning organizations" will have to thoroughly and deeply re-think their approach to accountability, to metrics, and to compensation.
The first, and possibly most important step you can take is to give up one of the most cherished notions in American pop business culture -- the need to hold people accountable. KJR has covered this subject before (see The dark side of accountability, 11/3/2003).
Among the many disadvantages of a hold-people-accountable business culture is that it pretty much guarantees that anyone associated with a mistake will do everything possible to hide it -- to sweep it under the rug, bury it in a quarry, or put sawdust in the crankcase and call it a mint-condition classic.
Or, if there's no way to hide the mistake, they'll find some poor schnook to serve as a scapegoat. Root cause analysis? The root cause is that this schnook here caused the problem.
Think anyone will admit to a mistake under these circumstances? Of course not.
So Lesson One in creating a learning organization is to create a culture of responsibility. That means consistently praising everyone who identifies mistakes and takes the lead in fixing them, without ever paying the least bit of attention to who made the mistake in the first place.
The next place to look is metrics. Last week's column pointed out that when your metrics define failure as success and vice versa, they guarantee you'll repeat and extend your mistakes because you always get what you measure.
The best metrics assess your progress toward real, meaningful goals. They aren't proxies or indexes, and they don't assess intermediate results.
To illustrate, imagine three police departments. The first measures success by the ratio of arrests it makes to crimes committed. The crime rate goes up, not down, because the city's peace officers are insufficiently concerned about determining who actually committed each crime, and even less concerned about making sure the evidence they present isn't thrown out because of irregularities.
The second police department, headed by wiser leaders, measures the ratio of convictions to crimes. Much better. For the most part, its officers take care to arrest only those who seem to be guilty.
Much better, but still not as good as the third police department, which measures its success in terms of overall public safety.
Which is why Lesson Two in creating a learning organization is to choose your goals wisely and measure them carefully. Doing so points you in the right direction and makes sure you know success and failure when you see them.
Lesson Three is simply stated but difficult to put into practice: Align compensation. It's particularly important if you want to learn from success.
This isn't a matter of rewards and motivation, because compensation, properly understood, isn't about rewards and motivation. It's about the most tangible form of communication a company has -- what it pays for. To understand this point, compare these two phrases: "Here's what we want you to do," and "Here's what we're paying you to do."
The latter packs a much stronger punch, don't you think?
Aligning compensation means defining acceptable performance as delivering results and strong performance as delivering repeatable results. Exceptional performance? That means repeating the results of others, not having them repeat yours.
Whether the subject is reusable software modules, successful business practices, or borrowing another employee's PowerPoint deck, if you want a company that learns from its successes you had better provide the highest compensation to those employees who find those successes and learn from them.
Even this is dangerous, by the way. Because if you aren't careful you'll stifle innovation along the way.
It has to be that way. Learning from success means you don't reinvent the wheel.
Innovation means you do.
-----------------
Copyright and other stuff -- The great KJR link point
Last week's column set some readers' teeth on edge (Why Johnny Corporation can't learn, Keep the Joint Running, 11/19/2007). The issue was its negative tone.
The column explained why corporations rarely learn from their mistakes and even more rarely learn from their successes. "Don't bring us problems -- bring us solutions," was the gist of the complaints.
Fair enough, so long as we all agree that unless you understand the underlying dynamics of a problem you're unlikely to find a solution.
Solutions to these two problems are especially tough to implement because doing so calls for challenging some very popular business beliefs and practices. In particular, companies that truly want to be "learning organizations" will have to thoroughly and deeply re-think their approach to accountability, to metrics, and to compensation.
The first, and possibly most important step you can take is to give up one of the most cherished notions in American pop business culture -- the need to hold people accountable. KJR has covered this subject before (see The dark side of accountability, 11/3/2003).
Among the many disadvantages of a hold-people-accountable business culture is that it pretty much guarantees that anyone associated with a mistake will do everything possible to hide it -- to sweep it under the rug, bury it in a quarry, or put sawdust in the crankcase and call it a mint-condition classic.
Or, if there's no way to hide the mistake, they'll find some poor schnook to serve as a scapegoat. Root cause analysis? The root cause is that this schnook here caused the problem.
Think anyone will admit to a mistake under these circumstances? Of course not.
So Lesson One in creating a learning organization is to create a culture of responsibility. That means consistently praising everyone who identifies mistakes and takes the lead in fixing them, without ever paying the least bit of attention to who made the mistake in the first place.
The next place to look is metrics. Last week's column pointed out that when your metrics define failure as success and vice versa, they guarantee you'll repeat and extend your mistakes because you always get what you measure.
The best metrics assess your progress toward real, meaningful goals. They aren't proxies or indexes, and they don't assess intermediate results.
To illustrate, imagine three police departments. The first measures success by the ratio of arrests it makes to crimes committed. The crime rate goes up, not down, because the city's peace officers are insufficiently concerned about determining who actually committed each crime, and even less concerned about making sure the evidence they present isn't thrown out because of irregularities.
The second police department, headed by wiser leaders, measures the ratio of convictions to crimes. Much better. For the most part, its officers take care to arrest only those who seem to be guilty.
Much better, but still not as good as the third police department, which measures its success in terms of overall public safety.
Which is why Lesson Two in creating a learning organization is to choose your goals wisely and measure them carefully. Doing so points you in the right direction and makes sure you know success and failure when you see them.
Lesson Three is simply stated but difficult to put into practice: Align compensation. It's particularly important if you want to learn from success.
This isn't a matter of rewards and motivation, because compensation, properly understood, isn't about rewards and motivation. It's about the most tangible form of communication a company has -- what it pays for. To understand this point, compare these two phrases: "Here's what we want you to do," and "Here's what we're paying you to do."
The latter packs a much stronger punch, don't you think?
Aligning compensation means defining acceptable performance as delivering results and strong performance as delivering repeatable results. Exceptional performance? That means repeating the results of others, not having them repeat yours.
Whether the subject is reusable software modules, successful business practices, or borrowing another employee's PowerPoint deck, if you want a company that learns from its successes you had better provide the highest compensation to those employees who find those successes and learn from them.
Even this is dangerous, by the way. Because if you aren't careful you'll stifle innovation along the way.
It has to be that way. Learning from success means you don't reinvent the wheel.
Innovation means you do.
-----------------
Copyright and other stuff -- The great KJR link point
Subscribe to:
Posts (Atom)