Joel on Software is one of the websites that I occasionally read. Joel writes well about technology and business — and his foreward to Rick Chapman's new book is compelling, and relevant to medicine. Joel's argument is that developers should run software companies because the "get it" in ways that non-developers simply wouldn't or couldn't .. and so will avoid the mistakes that the "non-geeks" would make.
I'll make the same statement for medicine — and even IT in medicine:
a) Medicine is not "just a business." As I mentioned last April, there is more to what we do than make money. If we really are here to enhance the quality of the lives of others — then our leaders must have the same core beliefs as we do. Making money is scondary – providing our services is primary. Yes, we need to pay the morgage – and the salaries of the nurses, and the phone bill, etc … so … yes, we need good business skills. But good business skills are not enough. In healthcare, there needs to be a passion. Yes .. healthcare is not unique .. and there are many professions that share similar qualities: education, some legal services, clergy … ? journalism?
b) Decisions in healthcare technology can't be made by mainstream IT managers without experience in healthcare. Why not? For the same reason that Joel asserts that programmers should run software companies. One shouldn't have want to have to explain to an IT executive what a CBC is … nor should one have to explan the difference between Java and Javascript. "duh" says the physician/nurse/PA … "duh" says the geek … but who knows both? Sadly, there are rather few.
My neighbor is a manager for a big company that makes steam turbines for the Navy. He manages a team of workers, and … for the most part … he really understands what the workers are doing. He tells me that he would have a hard time managing them if he didn't quite get what they were doing.
Managers of software developers have a much tougher time. They can't always know the details of the work that the workers are doing .. since technology is moving so fast that the workers will nearly alwasy know more about the technology than than the managers do.
? or do they? Shouldn't a good manager keep up on this? Just as a good physician will always keep up on the most recent research? If web develoeprs start using Flash rather than DHTML .. shouldn't the manager learn about flash too?
I’ve always believed that IT cannot really stand on its own.
I would say that managers of software companies that have a tough time managing because the technology is moving to quickly are failing not because the technology is moving too quickly, but that their lack of understand has made them the puppets of the people in their charge.
One of the hallmarks of poorly managed IT shops is lots of different technologies, each doing the same thing. A good IT manager is hard to come by because they have to have the technical skills to pick the right technology in the first place and the business skills to stick with things that work, not matter what the latest technology buzzwords are.
Actually, I think this is a multipart faceted problem.
First there are always field experts. There are also various levels of field experts. And everyone usually has one area of expertise. The key here is sharing the information of one’s expertise with another. Having the technologist and medical practicioner both step out of jargon land and communicate with the other party. Then both can contribute and together make a viable decision. IMHO, it is the technologist’s responsibility to learn the business practice of the place they work.
As for having individual managers, maintain knowledge on the latest and greatest technology upcomings, wouldn’t it be better for organizations to have a position or group for technology architects. That role would evaluate the newer technologies, keep abreast, and evaluate vendor solutions in comparison with long term goals. The role would also be responsible for disseminating information when an applicable technology arises. This way one or two people are responsible for keeping abreast of the latest technology, communicating the newer technology, and implementing it in a planned manner. Imagine a standardized infastructure.
Take this example with flash, before the web developer starts developing with the latest and greatest bells and whistles. The Architect could do an evaluation, looking at the dispersion of flash installs, see if using the new requirement requires a new download for the user’s of the website. See if there are any changes to the infrastructure needed to use this new technology. Compare if this technology plan is applicable for the corporate infrastructure goal. Then if deemed useful, the architect would develop a plan of implementation with the global needs of the enterprise in mind.
Or would you rather have one developer deciding that activex controls and vbscript are the greatest thing, and let’s implement those? Another developer thinking that applets are the way to go, and implement these. Another developer deciding on flash. See the problem here, (besides going off to technological jargon). An architect role or team would bring standardization to an organization’s infastructure.