One of my favorite writers (and future podcast guests, if I decide to persist in my outreach to him), Matt Levine, published an interesting bit recently that highlights second-order consequences of custom software.
Second-order consequences are the kind of stuff specialized consultants can warn their clients about, thereby creating value for those clients.
Here’s an excerpt from this piece, which is well worth a full read: https://www.bloomberg.com/opinion/articles/2018-11-21/now-you-can-foreclose-on-your-neighbor
Dakin Campbell at Business Insider has a story about the evolution of Marquee, Goldman Sachs Group Inc.’s, basically, technology product. Goldman has long had a pretty good platform—called SecDB—for keeping track of its positions, analyzing and pricing trades, managing risks, and generally being the technological underpinning of a big trading operation. (Disclosure: I used to work there, and remain fond of SecDB.) Having this system when others didn’t was a competitive advantage, but at some point Goldman realized that having it and sharing it with customers could also be an advantage: You could sell it to them, maybe, but also if you get them locked into your ecosystem then they will be more inclined to do more trades with you.
You’ve got this internal software tool. It’s a competitive advantage.
Why not develop it a bit further and make it available to your clients to extend that competitive advantage?
So far so good.
They restructured the platform’s underlying technology into a robust library of fully documented application-programming interfaces, or APIs, and snippets of code that make it easier for developers, both internal and external, to build new products on top of Goldman’s tech. Clients can now execute trades, examine portfolios, and design bespoke products via browser, desktop application or API.
Awesome! First-order design goals and first-order effects of those design goals are getting achieved. High-fives all around!
But inside Goldman Sachs, the outlook was less rosy. Engineers were stretched thin. Colleagues weren’t selling it to clients as they should, worried about rushing out a half-baked product or sharing contacts with other areas of the bank, according to current and former executives. Some openly chafed against giving away the firm’s secret sauce. And most worryingly, customers weren’t embracing it to execute trades.
Hmmm…. second-order consequences are starting to complicate things.
It gets worse…
…you can see why the sales force might be skeptical. If it gets traction, it is not just a product that the clients can use; it is also a way for the clients to interact with the bank—a way that does not involve calling up their salespeople all the time to get pricing on bonds or to buy and sell bonds, and that replaces those phone calls with API calls. If the sales force pitches this to their clients and it is bad, it weakens their relationship. If it is really good, though, it might replace that relationship entirely.
There we have the killer second-order consequence, which shows up in the form of badly misaligned incentives.
Part of the value of custom software is the software itself, but most of its value comes from how it works in the context of a human system.
When you specialize vertically, you start to gain expertise in the human/business/cultural context that your custom software operates within.
This expertise, as much or perhaps more than your technical skill with code, is where your value as a consultant comes from.