Second-order consequences

Philip Morgan

I'm following up on this article I shared previously, which does a lot to explain the value of vertical specialization: want you to be able to follow along with this even if you haven't read the article, so let's start with a brief synopsis:Atul Gawande, famous for several books including The Checklist Manifesto, writes about the effect electronic medical records software like Epic has had on an important facet of medical practice: the face-to-face human interaction between practitioners and patients. He teases out first and second-order consequences--intended and unintended--of the cognitive load that systems like Epic add to both doctor-patient interactions and other aspects of practicing medicine.Let's start with the second-order consequences, because these are the most exciting and likely to piss you off. ;-)First-order consequences are the ones you intend. The ones you're designing for.If you're Facebook, those consequences are "more connection" or whatever that really means. I guess "more eyeballs to show ads to", right?Second-order consequences are the consequences of the first-order consequences.If you're Facebook, they're hate groups getting their message amplified, elections getting manipulated, and negative psychological effects for your most engaged users.If you're Epic (the dominant electronic medical record software platform and the one Atul Gawande talks a fair bit about in the abovelinked article), the first-order consequences are centralized, standardized medical records.As a developer, you can help a client get the first-order consequences they want from custom software without knowing their business very much. You just need to be good at extracting the right information from them and turning that into good software. You can even charge them for this because not enough of your peers have specialized vertically and therefore your competition is just as inefficient as you are at getting up to speed on your clients' business. Yes, I know that's blunt, but what else can I call the cost of coming up to speed on your client's business except inefficiency? You probably can't be 100% to to speed on their specific business, but you sure as hell can understand the type of business they run, and that understanding can be a competitive advantage for you.Sideline: you know how popular "roadmapping" is these days? You know how one of the selling points is that you can charge for it because the discovery is valuable? That's all fine, but what if you could look a prospect in the eyes and say something like this:I think you should talk to a few of our competitors before you decide. One of the things you'll hear from a few of them is they want to do something called roadmapping. That's where they'll ask you a bunch of questions about your business and what you want to do with this software. They'll charge you for it. We used to do that too until we worked with multiple clients a lot like you, and we've found that with that body of learning behind us, we can come up to speed incredibly quickly on your project. As you speak with our competitors, just know that we won't charge you for that kind of on-the-job learning.Maybe you have it already, but if not... can you imagine having that kind of confidence in an interaction with a prospect? The kind that takes your competitor's strength and reframes it into a weakness with a few carefully-chosen words.Anyway, back to the main point here.When you get to the second-order consequences, that's where you as a specialized developer are in a potentially great position to advise your client on the second-order consequences of the software they want to build.They probably don't have a clue what these consequences will be.You, on the other hand, are well-positioned to predict, understand, explain, and design around these kind of consequences.So as you think about that Atul Gawande article, notice how much of the pain the actual users of the software are feeling comes from second-order consequences.-P