I just had a meeting today with some healthcare managers and MDs at a hospital. We were discussing about how to manage innovation at the center, and at some point of the discussion someone raised the issue that it was not in the best interest of the hospital to distract physicians with innovation, because they already had a huge workload… Assistance, research, teaching… Adding an innovation dimension to their activities was certainly too much… (or so he said).
Well, this concern is a by-product of how people usually see innovation. They figure innovation is a task, a job, a workload. And innovation is not a task, it is an attitude. And if you are a healthcare manager, it is important that you have a clear understanding of this.
Bear in mind, I am talking about innovation, that is, in Peter Drucker words, identifying change that creates a new dimension of performance, and not about entrepreneurship, which is something that obviously generates a great deal of effort on anyone willing to launch a start-up.
The output of innovation, or at least its first step, is detecting needs, identifying opportunities, imagining solutions. And healthcare professionals are in a position where they can identify needs first-hand. And this does not consume time, it just reflects a state of mind, an attitude of permanently questioning why are we doing the things we are doing.
I usually say the best ideas come from upset physicians. Behind an angry physician there is usually an opportunity. It works like this: A physician finds something he hates, he gets upset and then, all of a sudden, he identifies how to solve this problem, generating an interesting idea. We all know that an idea is not necessarily an opportunity, but it is a start. The best ideas I see are the solution of an identified problem, and not a solution in search of a problem to solve.
Subscribe to:
Post Comments (Atom)
1 comments:
A famous hacker (Eric Raymond) said one time: Every good work of software starts by scratching a developer's personal itch.
Change "work of software" by "medical innovation" and developer by "doctor or patient" (or even better a doctor that becomes a patient at some point) and this principle will be applicable to medical innovations.
In other words: "To solve an interesting problem, start by finding a problem that is interesting to you."
Hackers are everywhere (not only around computers). I have found a few of then with a stethoscope over his neck and a white coat.
How to become a "hacker" (innovative mind)?. Eric Raymond has again an answer (How to become a hacker?). Just believe in this principles:
1. The world is full of fascinating problems waiting to be solved.
2. No problem should ever have to be solved twice.
3. Boredom and drudgery are evil.
4. Freedom is good.
5. Attitude is no substitute for competence.
In its book "Cathedral and bazaar" he gives a set of rules for a innovative (hacker) organization:
1. Every good work of software starts by scratching a developer's personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. ``Plan to throw one away; you will, anyhow.''
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
9. Smart data structures and dumb code works a lot better than the other way around.
10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.''
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
17. A security system is only as secure as its secret. Beware of pseudo-secrets.
18. To solve an interesting problem, start by finding a problem that is interesting to you.
19: Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
Post a Comment