"You Don’t Have to be an Expert in Medicine to be a Good Designer in Healthcare"
Below is an article originally written by Henry Bayuzick, a Product Designer at PowerToFly Partner Flatiron Health, and published on October 4, 2018. Go to Flatiron Health's page on PowerToFly to see their open positions and learn more.
For a good part of my life, I wanted to do something in healthcare. There was always something so powerful about the idea of becoming a doctor and helping patients heal. There was only one problem: I didn't do well in biology and I didn't think I was was capable of going through the rigors of medical school. So when it came time to choose my career, I went with what I was good at: design.
Five years into my career, the opportunity to be a designer at Flatiron Health presented itself. It seemed like the perfect gig, an intersection between my interest in healthcare and what I was good at. I was nervous that my struggles in biology would quickly resurface making it hard for me to succeed at a healthcare company, but, one year later, I'm confidently able to say that you don't have to be an expert in medicine (or good at biology) to be a good designer in healthcare. Here's why.
Co-designing with experts enables clinically-accurate solutions
At Flatiron, subject-matter experts are embedded in every product team and include doctors, pharmacists, physician assistants, and more. On each project, gaining context begins by sitting down with the subject-matter expert(s) and learning relevant information. This means asking questions like, "What's the difference between clinical staging and pathologic staging?" or "Who is the person entering this information?". Their expertise enables me to better understand the varying clinical content (in this case staging and prognostic factors) determining the information hierarchy, relationships, ideal states and challenging problems.
But our partnership doesn't end there; instead, throughout the project, we collaborate on design solutions to ensure our mental models continue to align and the end experience is clinically accurate. For example, when physicians stage cancer, they also track prognostic factors such as biomarkers that better explain the disease. The workflow that we were redesigning collected prognostic factors as a one-time value, which, for a medical novice like me, seemed logical. However, in reality, prognostic factors change over time and how they are tracked is significant when determining future treatment. Collaborating with subject-matter experts revealed this difference, its importance and ways to improve it.
How you learn is more important than what you know
Nobody knows everything. Okay, so that's obvious, but really, even the oncologists who have been practicing medicine for longer than I have been alive don't know how everything works. To be clear, they know a lot, and it's incredible how much providers can store and recall, but at the end of the day, every individual has their own area of expertise. What this means is that at the beginning of each project, it doesn't matter how much I know or how much I don't know, instead what matters is how willing and able I am to learn. A lot has been written about beginner's mindset, and with each project at Flatiron, there's really no other option for me than to have a beginner's mindset. Recently, my team and I redesigned the workflow that physicians use to select treatment (much more difficult than it sounds). There was no pretending, I didn't know anything about chemotherapy regimens, but I did know how to learn. I researched treatment guidelines, asked oncologists about how they choose treatment, walked through real patient scenarios, and sketched diagrams of my understanding.
User research will likely reveal what you missed
Flatiron's not-so-secret key to success has been to embed clinical experts into all projects. Although we have the privilege to work with clinical experts on an almost daily basis, user research is still essential. Subject-matter experts help us understand clinical content and how workflows should be performed, but thorough user research reveals how people are actually using our software, the nuances between providers and clinics, and the creative workarounds. There is also simply no replacement for putting a design solution in front of the person who will ultimately be using it every day. Before working in the healthcare, I cut corners with user research, often making assumptions based on what I would do and using poor proxies, but designing healthcare products has forced me to improve my research skills. Over the course of a year, I have shadowed physicians and front-office staff, and conducted numerous remote research sessions with clinical users, such as sessions with chemotherapy nurses to understand how they calculate drug doses and use design solutions aimed at improving the safety of their workflow.
A few months ago, I was shadowing a physician when I felt a brief desire to go back to school so I could practice medicine. When I mentioned this idea to the doctor, he said, "Adding another doctor doesn't solve these problems, but redesigning our approach does." It was in this moment I realized the unique skills I was bringing to the table as a designer. Digitizing electronic health records didn't magically make healthcare better, in most cases it did the opposite by contributing to physician burnout. All along my desire to be a doctor was rooted in helping people get better, and although I was not a good biology student, being willing to learn, to co-design with experts, and to invest in becoming a better researcher has enabled me to do just that.
Why We Love Running Hackathons At Flatiron
Below is an article originally written by Sam Bail and Ovadia Harary at PowerToFly Partner Flatiron Health. Go to Flatiron Health's page on PowerToFly to see their open positions and learn more.
Hackathons have been a part of Flatiron Health since the company was founded in 2012. Our Chief Technology Officer (back then, Flatiron's second engineer) Gil Shklarski brought the concept with him from his previous stint at Facebook. For Flatiron, our quarterly hackathons are meant to be two days free of meetings or sprint commitments for the whole company, where employees form teams to work or "hack" on something that they are passionate about, but just haven't had the opportunity to work on. This could be exciting new product features, radical code cleanup ("dev happz" or, as Gil refers to it, "fixing s**t liberally"), cutting-edge data analyses or the occasional "gotcha" experiment from our security team. Each hackathon culminates in a live-demo session where participants have three minutes to present their projects in varying states ranging from "duct-taped together" to polished and ready to go into production, and then everyone at the company has the opportunity to vote on their favorite hacks in different categories.
Over the past few years, as Flatiron has grown, our hackathons have grown with it — from a handful of small hacks to a large, company-wide event spanning almost three days with over 40+ hacks presented at each final demo event. We have found these hackathons to be an important part of our company culture that have significantly shaped how we innovate and collaborate.
As we host our 16th hackathon this week, we wanted to share our top five reasons why we love running hackathons:
Hackathons encourage cross-functional collaboration
One of our favorite aspects of running and participating in hackathons is the ability to collaborate with people you usually don't get the chance to work with. Flatiron's hackathons may be different from those run by traditional tech companies, as we very much encourage non-engineers to participate — we firmly believe that bringing in different areas of expertise can be hugely beneficial. While teams at Flatiron already make up a number of different functions, including engineers, designers, quantitative scientists, and often oncologists and clinical staff, joining a hackathon team with an entirely different focus than your day-to-day is often eye opening, allowing you to see the work you do in a broader context. For example, we brought our informatics, clinical, data engineering, front-end development and marketing teams together to build a new trial finder for Fight CRC (read about it here). We love cross-functional collaboration so much that we introduced the "Best non-coding hack" as well as the "Best collaboration" award categories.
Hackathons allow anyone to innovate in anything
As customer commitments increase and the breadth of the company has grown to many different business lines, it's only natural to become focused solely on one's own responsibilities and near-term customer commitments. We encourage our employees to use the hackathon as way to step outside of their day-to-day role and use their creative juices to work on whatever problem they believe is worth solving. Most importantly, a hackathon provides an outlet for people to quickly spin up a minimum viable product or a demo to spur conversation without needing to talk in the abstract or request resources. We've seen amazing new products ship from our hackathon, and time and time again it is stimulated from a diverse group of functions and initiatives.
Hackathons help develop those "soft" skills
As has been written about by many successful engineers (most recently, here), we know that being a good software engineer doesn't just require good technical skills, but also what many usually call "soft skills" — the ability to collaborate, empathize, present and even sell an idea. Within a hackathon team, engineers often take on the role of product manager as well as project manager, where they have the chance to learn to radically prioritize different parts of the project (two days go by pretty quickly!), navigate disagreements on the team and give a compelling three-minute pitch. Especially for engineers who might often be heads down in code, hackathons are an amazing opportunity to step up and get themselves out there in a low-risk environment where everyone is in the same position of learning and possibly failing — see the next point!
Hackathons celebrate failures that can lead to even bigger successes
Some projects fail hard by the end of the hackathon, but these failures should be celebrated just as much as successes. Since our first hackathon, Gil has encouraged teams to keep Facebook's motto in mind: "What would you work on if you weren't afraid?" Celebrating failures also creates a culture in which teams are encouraged to stretch boundaries of what was thought possible, and in turn, successful projects often then yield larger rewards. However, creating this culture of intense innovation and experimentation requires an acceptance that some projects will fizzle out after two days for many different reasons. While these projects may not make it out to our customers, they still provide learnings. Spending two days learning that a product idea is not feasible, a new technology doesn't meet its promise, or that current infrastructure won't support a new use case, are all highly valuable and important learnings that will ultimately drive your engineering organization forward. At Flatiron, we encourage teams who have worked on failed projects to still present their demo at the end of a hackathon.
Hackathons improve upon the "20% time" concept
We love the concept of dedicating 20% of each person's time to working on side projects that spawn exciting new product lines — but let's be honest, especially in a growing company like ours, it's usually all hands on deck to push a new feature, fix a bug or carefully orchestrate changes that affect several teams. Dropping all these responsibilities one day a week to work on a passion project is simply not always possible. Hackathons give us two or three days of undisturbed time where we de-prioritize sprint work and staff engineers to keep the lights on, but otherwise really try to give everyone the opportunity to experiment, explore and collaborate. This focused burst of activity once per quarter is easier to schedule for the entire company; and since everyone participates, it's also easier to find people to collaborate with. There is also the added benefit of getting your idea immediately in front of the entire company and leadership team during the demo sessions. And just as with 20% time (which famously gave us Gmail), we have had several amazing hacks developed. One of our most successful product features — Document Search — was actually conceptualized and prototyped during a hackathon. Read more about it in this Fast Company article.
While hackathons may not be the answer for every company, Flatiron has found them to be incredibly valuable both to our culture and to our business. They have helped encourage cross-functional collaboration, allowed people to stretch themselves professionally, helped with soft skills development and much more.
Meet Flatiron Health
At Flatiron Health, their mission is to improve lives by learning from the experience of every cancer patient. Flatiron believes that learning from the experience of every cancer patient is an imperative — it is the key to accelerating research and continuing to improve the quality of care.
The talent and dedication of the people working at Flatiron makes everything that they do possible. If you're passionate about having an impact on accelerating cancer research and improving patient care, Flatiron would love to hear from you!
Click here to see all of their available opportunities, and don't forget to press "Follow"!
