Friday, March 11, 2005

Bright People, Redux

The other day, I wrote a quick entry for this blog on the subject of bright people in general and the Ideo Corporation in particular. I said that I was impressed by bright people. That's true; I am. But that wasn't actually what I meant to say. Somehow, in writing the piece, I wandered completely off the reservation and into the weeds. So, let me try it again.

What impressed me about the Ideo people, as well as people like them, is what they do with their intelligence, and the way that they do it.

I am mightily impressed by people who do not accept the world as it is, and work to improve it. I admit that when I say that, I am not talking about the social scientists and humanitarians, who seek to improve the condition of the people of the world. They're pretty amazing, too, because they plug on and plug on in spite of all of the travails that the world and its people can throw at them. When humanitarian agencies announced that they were restricting or terminating operations in Iraq because their people were getting killed, I thought 'But how can they do that? Can they do that? They can't do that!' When of course they can. Being a humanitarian may mean being a special kind of stupid -- the kind of stupidity that soldiers on when others would have just given up, and by soldiering on achieves an improvement in life, even if just for one person, one town, one people -- but it doesn't mean being dumb, throwing yourself into the fire when there isn't a good reason for it. Of course they can withdraw when they see the need to do so. If anyone has earned the right, they have.

But the improvement that I am thinking about in relationship to the Ideo people is improvement in the way that things work and processes function. It is improvement in the design of the things, the execution of the processes, so that when they are put together what you end up with is a transition from a series of disjointed, not-quite-focused efforts to one of fluid grace and maximal impact. (I know: they don't do it because in childhood they swore a mighty oath to rid the world of graceless systems and malformed products. They do it because someone is paying them to do it. So they're intellectual mercenaries. Fine. I can live with that. )

Who do they do it for?

Come help us see if our method for delivery of medical services can be improved, one group said. Sure. Lets start with the easy question: what does improvement mean, there? Cheaper? Faster? Better documented? More likely to result in payment from insurers? More pleasant for the participants? Less likely to result in litigation? You can see the heads in the meeting room nodding. Yes, yes, all of that. Okay, what one is most important? Or what two, or three? If you have to make a tradeoff, what goes up and what comes down? And that’s just the first part of the process that you go through in the improvement of a function, of a process. And you've got to got to got to get that part right, else when you are done, and you stand smiling next to the result -- see? we gave you what you asked for! -- and notice that the customers' smiles are a little bit forced, a little bit off, and you start to get that oh-no feeling in the pit of your stomach -- you realize that the first part wasn't done well enough. And you've just spent a whole bunch of effort for nothing. Maybe its because you didn't ask the right questions, or didn't listen hard enough, or the customer misled you, or the customer changed their mind along the way, but for whatever reason, the improvement process failed.

Those don't get written up in the glossy brochure, of course.

But say you get through that phase unscathed. You've got a reasonably good lock on what the customer wants. Then the real fun starts, because then you get to do the analysis of where they are now, and what it would take to get them to where they want to be. What has to go; what has to change; what has to be created. How will the new state look, how will it feel. What will the effect be of the changes to the systems that interact with the changed ones (thats a killer; sometimes you know all of them, but usually, you don't. And either does the customer) and what do you have to do to make that connection seamless? This is a tedious and agonizing process, a blend of rigorous analysis and whimsical fancy. It can be exhilarating, and it can drain your brain. Sometimes, at the same time.

It's particularly helpful, I would think, if you can see the process flow. But that's just a guess.

And if you are successful, giving the customer not only what they wanted, but possibly more than that, possibly you give them what they need, even if they didn't know that they needed it, then you become a successful innovator, a successful process improver. And that’s what I think Ideo is. They do it with bright people, and -- I'd like to think -- they do it with good internal systems, good methods of wringing out the good ideas from one project and recycling them, extracting the core concepts, the ones that are needed for every successful project. And they marry them to the unique concepts for this project, so that they have good structure and good nuances, and when you put them together, you get a good project.

It doesn't always happen this way. Why? Because its hard.

I know of one effort that an organization made to try to create a process to successfully move work from customer sites into their own site. This means that when the customer hands over the check and says Okay, you guys run our computer systems from now on, that you can not only do it, but do it better and cheaper than they could (else they won't see it as a benefit, and you won't make any money on the deal). So this effort, the Standard Transition, was supposed to put together all of the questions that people ask -- sometimes, much later, slapping themselves on the head and saying Damn, we shoulda asked...-- about how the systems run now. Who runs them, how, when, why, under what conditions, with what output, and what do they do now when it doesn't work, and should we do the same thing. They spent a great deal of time, trying to come up with this Standard Method, and to their credit, they documented a hell of a lot of things, many of which were things that you probably would have thought of, and some were things that you might only think of if you got burned by it, last time you did a transition. And they put them in, as Dilbert would put it, a big honkin' binder.

Is it slim, slender, graceful? Is it easily used, adapts easy to different environments, adds noticeable value to the process?

Well....no. That’s a lot to ask of a big honkin' binder. But its better than nothing. And that’s where most efforts stop, because it takes a hell of a lot of effort to get even to that point. But then to take that output, that painfully created and documented output, and use it for the next project, and not only do that next project but along the way smooth out the rough edges of the standard method...and to do that again and again .... well, that’s pretty impressive.

Heard a story years ago, and though I don't know if it is true, I'd like to think it is. The story is that Bill Bradley, when he was a professional basketball player, would go to the court at night and practice taking shots from every part of the court. Again, and again, and again -- until he could reliably, almost without thinking, sink the ball from any spot on the court. That’s taking that big honkin' binder out for every project, walking through it for every project, and smoothing it with every project. Sometimes adding things back in that were taken out. Sometimes adding new material in. But always improving, always getting better.

Is that Ideo? I hope so. Because I do dearly love that image -- the idea that somewhere, there are people who do that.

Bright people.

No comments: