Startups, Big and Small

Over the course of my career, I have had significant experience with small startups and large corporations. In addition, I have read extensively about the evolution of businesses, both in a positive direction and unfortunately in a trend towards obsolescence. I would not pretend to have any secret formula for what makes a company successful. But I wish to share certain observations that I think most of us intuitively know, even if we do not openly express them.

A fresh startup has many positives and negatives.  Let’s start with the negatives — no money. Obviously, this is a generalization. There are startups that branch off of successful projects and/or large companies and already have significant funds in the bank. These types of startups usually already have a technology in hand which has been tested and even proven to an extent. Therefore, although classified as startups, these really are much more equivalent to branches off of a well rooted tree. Such startups can be far more flexible while maintaining minimal risk.

The startups with no money are the ones that involve a lot of risk on the part of the founders, a lot of loans from friends and families and a lot of work to get that first major investor interested. Of course, all of this is in parallel to developing a real product that will ultimately have to be marketable and generate a significant return on investment. There are many people who so believe in their product that they sell their homes for the startup money they need. You occasionally hear about such companies, and the innovators who created the startup get interviewed by all of the tech news groups. But for each such success, there are hundreds, if not thousands of people who lose it all.

In many ways, the only way you can survive such an experience is to share the frontier mindset that is required whenever a group of people come to a new and unexplored land and call it home. I have said many times that I personally lack the startup spirit. I am extremely conservative in financial terms, and limit myself to offering my consulting services to those who have created their own startups. I often offer these services for free if I believe in the product, without any expectation of future remuneration. This harks back to the socialist in me — as long as I have a roof over my head, food on my table and smiling children and wife, I have it all. So the least I can do is to share my good fortune. Unless it’s Microsoft — then I would charge an arm and a leg. I’m a socialist — I’m not crazy.

The excitement of working on a fresh startup is tremendous. Everything is a blank slate. Even the formal administrative structure of the company is often not laid out. If you have an idea, you’re free to explore it. As long as everyone is focused on making the startup a success, there is tremendous freedom for people to express their ideas and imagination. One only needs to read the newspaper to see how many innovative ideas are coming out of the startup community. This dwarfs the number of innovations that come out of some very well-established major companies.

Interestingly, within the older established business community, the smart companies try to create a startup mindset, at least within a certain part of their workforce. Whether it is a day a week that you are given to focus on personal ideas, or an incentive program to use your free time [as little as there is] to try and develop ideas that may or may not be of value to the major company, it is critical to preserve that pioneering spirit. Without this mindset, our technological world would never have a lot of the features that are sometimes transformative.

In my previous place of employment, I walked into an environment where there effectively was almost no software available that specifically answered the needs of the company. My focus was primarily on developing clinical tools in order to document the entire medical interaction with the patients, but also administrative and statistics tools to be able to track performance and identify possible inherent failures in the system. I had the freedom to build anything I wanted to and to constantly test new ideas, benefiting from near immediate feedback from the staff of users. This was nothing less than a programmer’s dreamworld. Since I was one of the users of the software I developed, I immediately saw the weaknesses and strengths in what I had put down on the screen. Sometimes within minutes, I would correct certain problems. Sometimes within minutes, I would add a feature.

No meetings, no boards, no fighting between doctors who understand nothing about technology and technicians who have nothing but contempt for doctors who claim to be “scientists” but often don’t understand the first thing about basic computing. I flourished in this environment. The software flourished in this environment. One of my crowning jewels was a piece of software that allows a branch director to track one by one  every single patient in a clinic. Any piece of information that has somehow made it to the computer is available via a single click..

Unfortunately, not all is gravy. I have also had the experience of working with major organizations that are extremely set in their ways. No one can argue with success. The companies I speak of are all financially successful companies and therefore can easily argue that there is no need to make a major investment in upgrading their computer resources. I on the other hand fundamentally believe that stagnation is the beginning of desolation. There is simply too much going on in most spheres, but especially in medicine, not to have a dedicated in-house team that is focused on constant improvements to the IT infrastructure. Some large companies are at times terrified to touch their own code. The original programmers may no longer be around, and new changes that occasionally lead to new bugs can bring a working system to a screaming halt. This creates an incredibly frustrating environment whereby everything works, but little gets updated, unless one is talking about critical new code.

I will give one simple example. One of the innovations that I greatly succeeded with, in my previous place of employment, was a total integration of a PACs (which is an X-ray and document management) system into the electronic medical record. With a single click to open a particular patient’s chart, every piece of digital information available was there on the single page being viewed. If you wanted to see the patient’s x-rays, both new and old, a single click. If you wanted to see the patient’s previous CBC results, a couple of clicks.

In old monolithic EMR software, building bridges to new software (like a PACs) can be almost impossible. Modifying the interface of the old software can have a cascading effect that ends up ruining some apparently unrelated piece of software. So, CIOs and CEOs managing large old systems are very hesitant even for the most brilliant programmer to touch anything. This is hardly the ideal situation for a young and innovative minded programmer.

My system also incorporated a special set of functionalities that made it possible to share everything that happened in the clinic with both the patient [whose fundamental right it is to have access to this information] as well as with the family doctor of the patient. There were many times when the family physicians (from the HMO) would call while the patient was in the clinic to suggest alterations in management. This type of totally open access to authorized individuals was so unique a feature that I was approached by two separate hospitals asking how they could incorporate such a tool. Such openness of the data simply did not exist in the hospitals’ monolithic systems.

One specific experience with a major hospital taught me the fundamental difference between working in a startup environment versus trying to update a well-established, hardened bureaucracy. At one point, I presented myself to one of the Israeli hospitals, initially offering my services for free. All I wanted to do was to spend time with the doctors on the floors, and as physician to physician, learn their frustrations and try to come to an understanding as to what kinds of tools would be most helpful to them. When I presented this idea to the head of the IT department, he was very excited and saw tremendous potential. When I then met with the department sub-managers, the anxiety and distrust was palpable. They were convinced even before meeting me that I would be this type of flash in the pan developer that would try to come in and upset their ecosystem.

I tried to explain to these sub-managers that physicians had expressed significant dissatisfaction with features of their system. I tried to do this in as kind a way as possible. But it was to no avail. By the end of the conversation, it was blatantly clear that they had no interest in hearing my ideas no matter how much positive potential they had. This happened a couple more times and I finally accepted the fact that hardened bureaucracy is almost impossible to break through. The only hope is when the IT department  must completely rewrite a system to accommodate a whole new set of technologies. It is at that point that one stands a chance of introducing new ideas and new technologies. But in practice, I realized that I would never be given the freedom to do the many things I had already done in my previous place of employment.

Established companies have many benefits. If they are successful, they have the funds to explore new fields of research that won’t necessarily justify themselves in terms of ROI. More so, there will already be a great deal of previous research that can form the foundation of your own work. Development labs will already exist along with the technicians to make it possible to complete projects in a fraction of the time that it would take an individual to do so. All of these things are very critical and can definitely contribute to the speedier implementation of new technologies. The trick is to combine the best of both worlds in order to find the best possible solution.

Thanks for listening.

About the Author
Dr. Nahum Kovalski received his bachelor's of science in computer science and his medical degree in Canada. He came to Israel in 1991 and married his wife of 22 years in 1992. He has 3 amazing children and has lived in Jerusalem since making Aliyah. Dr. Kovalski was with TEREM Emergency Medical Services for 21 years until June of 2014, and is now a private consultant on medicine and technology.