The other day, a friend of mine wanted to use technology to automate some reports he needed to generate. I described to him the options he has: he can either put the time to find (and to learn to use) the right tool that empowers the non-technical person to create reports, spend money on a consultant who can whip the reports, or duct-tape something himself but understand the consequences of such a myopic solution (e.g. it gets very difficult to maintain the reports after they reach certain complexity, easy things are very easy but hard things are impossible, etc.). He asked me something that at first stunned me; he asked “why can’t this be done fast/cheaply and well?”

One of the most difficult things for non-technical people to understand is that technology solutions are expensive. Worse–many technology solutions that seem like they should be cheap are expensive. Essentially my friend came up against a classic problem of technology and software development: what is easy to describe/visualize is often very difficult to code up. For that reason, making technology that empowers business users is expensive because small changes in business requirements may lead to large changes to the software. We are therefore left with two poor options: to spend a lot of time/money up front building something that is flexible and operates on concepts familiar to the user (as opposed to some technical conventions), or to continue spending even more money building one-off solutions.

There are two dimensions that people usually care about: time and cost. Everything else (quality, flexibility, user experience) can be expressed in terms of these two dimensions. You can trade one off against the other but you can never lower both. In other words, there is no such thing as a free lunch.

At this point, I reflected on one point that I used to consider as counterarguments to the above: what about quality? Surely there must be some advantage to hiring a smarter software engineer, or one that understands the business user better.

True, there is an advantage, but it comes at a cost. Quality is nothing else but aninvestment in a solution that makes future changes (or troubleshooting) easier. It can manifest itself as code that is written more cleanly, adhering to accepted best practices (so that a future developer can understand the code easier and thus make changes faster), or more flexible (so that less code needs to be rewritten if the requirements change), or more user-friendly (it takes the users less time to use the tool). High quality code will cost you less in the long run, but it will cost you more today: you will have to hire an experienced developer, or a smarter one (one who has the gift of foresight), or have them spend more time (=money!) understanding the business so that the user experience is improved.

Many startups bias themselves toward time-to-market: getting something out today that works today. As those companies grow larger, technology becomes more convoluted (and thus harder to improve) because a lot depends on this poor quality code that the early technologists wrote to solve the problems of the day. Ultimately innovation is stifled because even the smallest changes become risky and nobody wants large system overhauls without a clear ROI, especially that what is already in place works.

This dead end is caused by two compounded factors: the business people have a myopicunderstanding of value and cost, and the technology people have a hard time assessingeither. So if you have a startup, ensure that your technology people can tell your business people how much something will cost, not today, but in its lifetime (this includes an assessment of a lifetime of a particular solution–nothing lasts forever!) and ensure that your business people can make decisions based on the long-term as well as the short-term view.

The right answer is somewhere in between. It would be dumb to spend a lot of money building extremely flexible solutions because fast time-to-market is crucial in a startup. But invest some money up front (by either hiring smart engineers and experienced engineers–you need both–or introducing governance) and build in guardrails that make it cheaper to make changes in the future.