Job 0: PhyzBiz
My first job as a software developer was an internship while I was in my Sophomore and Junior years at Carnegie Mellon. I had originally been working on campus in the Civil Engineering department, and a professor there connected me with some friends of his who were launching a startup a few blocks off campus. My wife — we got married during Spring Break of my sophomore year — also worked there as their technical writer.
The central idea of PhyzBiz was to become the go-to solution for digitizing medical office practice management. In some of the initial discussions, we wanted to install touch screens (more than half a decade before the iPhone became the first touch screen with wide adoption) at medical offices that patients would use for registration and scheduling, replacing the clipboards, pen, and paper that remain ubiquitous to this day.
The software was a traditional client-server application (NOT a web application) developed using PowerBuilder against an Oracle database. Our deployment strategy was that each medical office would have their own server — running Oracle — where all their data would be stored, and our software would be installed on any computer in the office, including touch screen terminals for patients to use in the waiting room.
The company hired, IIRC, about fifteen people total during its year of existence. We had several network/database/sysadmin engineers, myself and two other software engineers, a graphic designer, a technical writer (my wife), a project manager, a single person who handled HR, accounting, payroll, and most anything else that could fit into that umbrella, and a team of Chief Something Officers. The two founders of the company were CEO and CFO. We had a Chief Medical Officer (who I don’t believe I ever met or saw in the office) who was a working physician whose office was supposed to be our first beta customer, a Chief Operating Officer who had worked as an office manager at various medical practices and was kind of the closest thing we had to a Product Manager, and the CTO.
As I alluded to, the company lasted for about a year before running out of money. We had some components of the product that basically worked — our one beta test office was using the software in a limited fashion, I believe — but, in retrospect, we tackled too broad of a scope for the resources we had, and don’t believe we were close to having a product to sell at scale. Rather than focusing on one part of the medical practice, we were trying to do a product that did everything — scheduling, medical records, insurance, billing, patient registration, etc. — and don’t know that any of it was particularly great.
That being said, for at least the next decade, I would find myself trying to catch a peak at systems being used at doctors’ offices I visited, and found their systems to be behind what we had envisioned at this job. Even today, where technology has opened up so many tools to allow for fully digital workflows, I still find that I need to fill out and sign a sheaf of paper forms before any doctor visit, often repeating much of the same information on several, if not all, pages. (OneMedical is a striking counter example.)
1: Lessons I'm still learning
As an high achiever throughout school, my entire life up to this point had trained me to believe that the path to success was to follow directions, and do what I was told. To get an A, you just had to check all the right boxes and get things done. Deadlines were always realistic based on hundreds of students over decades doing the exact same projects for the same teachers (and even professors) over and over again. Perfection was possible because you weren’t doing anything new. At this internship, I was slow to realize — and think I only really realized it long after the company was done — that my boss didn’t want to tell me what to do every day. They didn’t have time, and didn’t necessarily even know themselves. Especially when a company is trying to build something that has never been built before, employees need to take the initiative to define the roadmap (and also need to havethe freedom to act with that initiative).
As I mentioned above, I think one of the main reasons this company failed after a year (and there were definitely other contributing factors) was that the company failed to define a clear and achievable MVP. This has become pretty much the de facto rule of an early stage startup, so I won’t go into this part in too much detail. There was a separate example where our CTO told us that our most experienced engineer needed to isolate himself for a while to work on a “major new feature”. I seem to recall two or three weeks with this engineer locked away in a separate office, working on something that was BIG. When he finally came out, all he had done was add a slider to the bottom of our app that would zoom the screen in and out for accessibility reasons. With how much basic functionality our application was missing at the time, this has always seemed like a big miss in prioritization.