Why an advisor should write code
Advice about technology is better when the advisor has had to make the thing work. Not all of it, and not for every client.
Amogh Suman
I advise banks, insurers and fintechs on what to build, and I build some of it myself. It is fair to ask why someone in advisory spends time writing code. The short answer is that it makes the advice better, and the reasons are specific.
What building teaches that reading does not
A slide can say that a model will classify customer complaints, that a dashboard will show demand by district, or that a voice assistant will work in five languages. Each of those sentences hides a long list of decisions. Where does the data come from? What happens when it is missing? Who checks the output, and how long does that take? What does it cost to run every month?
You can learn the questions from reading. You learn which ones matter only by hitting them. Once you have spent a weekend discovering that the hard part of a dashboard is agreeing on one definition of a number, you stop treating "build a dashboard" as a line item.
Three things that change
Estimates get honest. When you have built something similar, you know which parts are quick and which are slow. The slow parts are rarely the model or the interface. They are data access, edge cases, security reviews and the conversations needed to agree what "done" means.
Recommendations get smaller. Advisors who have never built tend to recommend platforms. Advisors who have built tend to recommend a narrow first version that proves one thing. The second approach is cheaper and fails faster, which is the point.
Vendor conversations change. It is much harder for a vendor to wave away a question when the person asking it has built a rough version of the same feature. Clients notice that.
The value is not that I can write the code. It is that I know which questions the code will force someone to answer.
Where the line is
Writing code does not mean building everything for a client. Advisory and delivery are different jobs, and mixing them badly creates two problems: the advisor stops being neutral about what to build, and the client ends up depending on software nobody is set up to maintain.
A sensible rule is to build to learn and to show, and to hand over the real build to a team that will own it. A prototype that makes a decision concrete is worth building. A production system that a bank will run for years should be built by people who will be there for years.
What advisors who do not build get wrong
The most common mistake is to treat technology choices as procurement choices: pick the vendor, sign the contract, move on. The hard work starts after the contract, in the details of data, process and people that no vendor controls. Advisors who have built something tend to spend their time there, which is where clients need them.
I will keep building on the side. The projects on this site are the evidence: some are useful, some are experiments, all of them have made me a more careful advisor.