Resolving the Clinicoproduct Divide, Part 2
Setting up the right clinicians for success at development work
If you read Part 1 of Resolving the Clinicoproduct Divide, then perhaps you are slightly more convinced that the best pattern for clinicians contributing to development work is to ultimately put them on development teams (Step 1). You’ve accepted that the potential benefit of higher quality, faster development outweighs the costs of paying clinician salaries for non-clinical work. Now in Part 2, let’s flesh out some tactical details: How to select the right clinicians for development work and then what to do to set everyone up for success. If we do this right, what was once a yawning chasm of frustration, miscommunication and distrust can evolve into a gentle glen.
Step 2: Select clinicians for product work based on empathy & curiosity
In Tony Fadell’s book, Build (Schutzblog top pick of 2024), he contends that the superpower of great product people is empathy – the ability to immerse oneself in the feelings and experience of another. Funnily enough, it turns out that the superpower of great clinicians is… empathy. Very quickly in clinical training we learn that there are many ways to approach a given clinical problem. It is only through empathetic curiosity that you can craft a clinical plan that meets the goals, values and lifestyles of individual patients. As famous New Jerseyan Albert Einstein once said, “If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
Take the common cough. Think about the last time you sought medical care for a cough. Already you are concerned about something if you are going to risk interacting with the medical system. So what exactly are you concerned about with your cough? It turns out there are 5 non-mutually exclusive reasons to present with cough:
Coughing hurts and/or is embarrassing during the day and you want it to stop
Coughing is interrupting your sleep
Should you alter your plans to not get someone else sick (vacation/baby/grandparent)?
Is it a more serious infection that requires antibiotics?
Is it cancer?
Now, put yourself in the role of a clinician, trained to diagnose and treat this cough. If you are unaware of this individual patient’s concern about the cough, you might walk in and tell them it isn’t cancer and send them on their way, even more nervous than before. Or you might prepare for a fight about antibiotics that they don’t want to have. Or worse yet, you might chastise them for wasting your precious time and neglect to help them sleep. I’ve seen it all. Only through empathy and curiosity are you able to apply your clinical knowledge to help this patient, at this moment. Over time, very few of you might realize there are subsets of patients with different cough-related “jobs to be done” and develop a standard approach based on concern. And this is the exact pattern of behavior that makes for excellent product development.
The ability to fully understand a problem and refrain from jumping to solutions comes from humility and empathy, and the desire to skip that part and rush to a solution is some mix of ego, impatience, and ignorance. And therein lies your selection criteria: Clinicians with excellent domain knowledge, empathy, humility and curiosity. There are ways to screen for empathy, such as behavioral interviewing, the ultimate version of which includes Soma Lab (in which I have invested). An earlier post suggested that you choose your “most averagest clinicians for development” which probably needs some clarification. Once you’ve found your empathetic, curious and technically skilled candidates, choose clinicians that solve clinical problems the way in which you’d like to see scaled across the organization. If you choose your idiosyncratic superheroes to do your development work, they are going to create things that no one else can use.
Step 3: Reinforce empathy and curiosity through culture
If you have made it this far, then you have selected empathetic clinicians and committed to put them on development teams. Now you have to continuously create a development culture that reinforces empathy and curiosity amongst all team members, lest you return to the ugly status quo from which you are currently trying to escape. You must avoid the expertise trap.
But wait, isn’t clinical expertise exactly what you want from clinicians? Yes and no. The expertise trap, in which any creator can fall, is to value domain knowledge to the exclusion of the other core ingredients for development work: curiosity, empathy and creativity in responding to user/customer feedback. Putting anyone, especially “already uncomfortable with this agile stuff” clinicians, in an expert role, subjects them to stereotype threat, the belief that their performance is representative of a group (all clinicians). This belief of representation has been demonstrated to decrease performance due to risk aversion and defensiveness, the opposite of curiosity and empathy.
To avoid the expertise trap, praise and reward curiosity, learning, humility, incorporation of feedback and progress toward results over time, basically the tenets of agility. Given the number of technical domains required to build a clinical service (clinical, ops, technology, real estate, compliance, etc.), encourage everyone on your team to share knowledge freely and explain from first principles. Your best people probably already do this, deftly unpacking tightly-hed beliefs in a psychologically safe environment. This free sharing of information will build skills, confidence, capability, resilience and camaraderie in your development teams. It allows your organization to honor and respect your experts without having them defend themselves. If you hear of anyone hoarding knowledge or pulling rank, consider that a blaring klaxon for managerial intervention. It takes constant leadership effort to walk the balance of respecting your clinicians’ expertise without treating them like experts, but the flywheel of speed and quality that follows will quickly pay back your efforts.
Step 4: Train in the disciplines of development
When I started as a newly minted doc merged with the technical team at Iora, I was clearly a nerd by virtue of playing video games since the 80s, but knew very little about modern software development. So I sat there and wrote down every word I did not understand during meetings. Fortunately our CTO and Head of Product were kind enough to sit with me and painstakingly explain everything that was going on. Everyday the lists got longer until one day they started to get shorter. Going even further, our VP of Tech pushed for my formal Scrum training in Product Ownership at a cost of roughly 3 days and a few thousand dollars. Holy shit, what an ROI. So, my advice to everyone is: You have these really smart clinicians, teach them the language of software and service development, of agile, of theory of constraints and PAY TO TRAIN THEM to do the work. Don’t let them just wing it, because the formality of agile development will reinforce the discipline on your existing teams. Discipline always flags, new energy is needed to renew commitment. Go further, introduce interdisciplinary journal clubs, etc. In the wise words of Abe Lincoln, the well known spouse of a famed Jersey shore vacationer, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”
Step 5: Hold clinicians accountable
Ok, we are almost there. Now you’ve committed to bring the right clinicians on the team, structured your culture for empathy and curiosity, and trained them in agile development. Next you have to do the most challenging part: Hold clinicians accountable. Clinicians have a strained relationship with accountability. Given the chaotic complexity of caring for humans, we have a tendency to shirk accountability for outcomes. We hold ourselves very accountable for effort and process fidelity (we did everything we could) but actually ensuring the right good thing happens? That is still outside of our control. Furthermore, in the clinical world, “a bad thing not happening” or “doing no harm” is a respectable and often sufficient outcome. As such, in the world of development you may find that we get real squirrely about being held accountable for results.
You will benefit from understanding this context so that you can embrace this behavior for what it is, a desire to succeed/avoid failure, rather than the refusal to take responsibility. Agile methods such as Scrum are helpful because they already include mechanisms of team accountability through work visibility, acceptance criteria, and definitions of done. The retrospective is an incredibly useful tool for accountability, as it is a regular, team-led examination of ongoing work processes with a commitment to iteratively improve. When you combine this discipline with your own success at organizational goal setting, you will have a series of results to which you can hold your teams accountable. Be firm but gentle and your clinicians will come along and come to love accountability. Believe in your team, yourself, the power of feedback and iteration. You will do much more for the world if you aim and miss than if you never aim at all.
So, you now have a step by step guide on how to select and incorporate clinicians onto your development teams. If you do this correctly, this should leave you with two new problems that we will address next time, as the solutions are intertwined. First, what do you do with all the other clinicians (whether employed or customers), the ones that deliver the actual care, that nevertheless “want in” on development processes? Second, now that your development teams are humming along, they are going to quickly overwhelm your front line teams’ ability to absorb and incorporate changes. More on that next time!