The way software professionals approach the question of “how do you even go about working with a client to plan their software journey with you?” isn’t as far as you would think from how mental health professionals approach the question of “how do you even go about working with a client to plan their mental health journey with you?”
At a high level, both apply variations of the rules deeply embedded in any professional’s serious training: first you diagnose before taking action (in softwareland, that “diagnosing” is often called “discovery,” just to demonstrate that comparable concepts often have very different names.) You weigh different possibilities against each other. You plan before you act. Your plans take into account considerations both theoretical (what does the literature and our experience tell us is most likely to be the appropriate treatment here?) and practical (whose paying and what’s their budget?). And so forth. Indeed, one could even make the argument that this approach — thought and research before action, careful consideration, following time-proven standards, etc — is even the heart of what a professional is, in any profession and, in fact, it might even be the case that your humble-ish author of this analysis you’re reading wrote a book and runs a podcast on this very topic!
But today, let’s add an interesting twist to this observation: each profession develops largely independently from others, and thus have developed approaches idiosyncratic to that profession. It would be only a good thing, I’ll put forth, if one profession could learn from the best of other professions, because every profession has insights and best practices that it could teach others.
As one example, I’d argue that every profession and every professional out there ought to follow the example of the Medical profession and institute a version of the “First, do no harm,” the doctor’s ancient Hippocratic oath. However, we can omit first two words, “ὄμνυμι Ἀπόλλωνα”, “In the name of Apollo the Healer”, if we want to.
There’s one particular case where it might be particularly interesting to us to apply the learnings of one profession to another: using the software developer’s concept of “Waterfall” vs “Agile” approach to planning software to understand the two different ways Mental Health professionals approach can approach planning their mental health journey with a particular client.
Let’s summarize these two ways to approach software. “Waterfall” software development is the traditional way to build software. It centers around understanding the requirements of the client (with lots of details about how to research with them to get the requirements), building a plan (the technical plan defining what to build is called a “spec” in softwareland), and then going about building it. This is the method used since the dawn of time (1960-ish) to build software and it does follow common sense: figure out what you need, write a plan, then execute on the plan. Within waterfall development, there are lots of smart and subtle details—this is a time-tested methodology advocated by many smart people—like dividing the big plan into chunks and getting feedback after each chunk, and so forth.
But an interesting thing happened at the dawn of the century (by which I mean the 21st century, although my mind still connects “dawn of the century” to mean 1900, revealing the fact that I am not a Gen Z-er going around slaying it.) Various software developers and what we would today call “thought leaders” in the software world realized that Waterfall development is fundamentally broken: basically, no matter how good your spec is, no mater how detailed the plan is, no matter how much you talk to your client and perfectly capture what they ask for—when you follow the spec and build it, they are NEVER happy with it. And by “never,” I’m not exaggerating; I actually do mean “never.”
Why not? The key insight, publicly born in the early 21st century, was that: client needs change during the course of the journey together; that the plan in real life often doesn’t map to what they need; that what everyone thinks needs to be done because it really seems like it needs to be done often isn’t what needs to be done due to subtle underlying conditions and factors missed in the early diagnosis (see what I did there? slipping in medical terminology!).
So a new methodology was born, a methodology that was first called “Extreme Programming” but quickly rebranded as “Agile” software development, which basically says this: instead of focusing so much energy on the huge plan — because we recognize the huge plan is likely to be wrong in non-trivial ways or even if it’s right, it’s likely to need to change near immediately — what if instead, the software developers works very very very (three very-s! Maybe even four!) closely with the other stakeholders (various representatives of the client, the project managers, the marketing team, everyone interested!) to give constant feedback into what they’re doing, so–together–they can change plans in real-time.
What this looks like, in practice, is that Agile development pioneered a bunch of best practices for software developers. What if, instead of focusing on the big plan with every detail; we start with a very general roadmap; then we divide it into weekly or bi-weekly units (called “Sprints”), and we go week by week, and rethink everything at the end of each week/sprint. What if we also have daily meetings in which all stakeholders or their representatives meet every single morning to review the latest that was done, and get real-time (daily) feedback on it (that’s called the “daily stand-up.”) And so forth.
It’s important to note that Agile software development revolutionized the field of software development because it allowed software developers to literally move 10x as fast to build what the client actually needs. (Rather than wasting 6 months going in the wrong direction to get feedback, you waste 6 days!). There’s an argument to be made that Agile development is what led to software being able to conquer the world and Silicon Valley take over the economy and the future.
Now, let’s bring this parallel to the mental health professions.
Traditional diagnosis, planning, then treatment among mental health professionals roughly parallels “Waterfall” software development, with its focus on accurate diagnosis, a strong plan, and then the execution of that plan.
But imagine there was a concept that we could call “Agile mental health development” for lack of a better phrase, that instead did the following: Imagine it started with a very rough diagnosis, but then imagine the therapist or professional worked hand in hand very closely with the client in a near-real time way. Maybe daily meetings. Maybe weekly re-evaluations and re-diagnosis (Medical sprints!).
In the real world, this would fail before it starts for one reason: resources. “Sounds great, Morgan, but any therapist that treats non-trillionaires won’t have time for daily meetings, weekly re-evaluations, and this sort of intense focus.”
To which, I would respond: Maybe. What if there was a class of therapists and mental health professionals that could? One could be the highly paid doctors of the trillionaires (I wonder if Antilia, Mukesh Ambani’s 27 story home in Mumbai in which 600 servants live, probably spread across 6 servant bedrooms—I wonder if it includes a 24/7 ER just for the family?).
And for the rest of us… what if AI Therapy—an AI/LLM platform trained to be a world-class therapist, available 24/7 to any user with an Internet connection—could serve this sort of Agile role? Perhaps even if an AI Therapist were only 80% as good as the human therapist, but perhaps with the intense and constant feedback, constant communication, constantly being in deep contact with the client to understand him at a deep level, maybe those would very substantially overcompensate for it? Perhaps the future of all sorts of mental health support could be agile-style?
I don’t know the answer here, but just asking that question leads me to a very Silicon Valley style answer: let’s give it a shot and see. This is how innovation happens and how we advance as a civilization.
