Why Technology Leaders Need to Understand Business Before Choosing a Tech Stack
The strongest architecture decisions start with business questions, not framework debates. Here is the order I work in.
Early in my career I thought the hardest part of building software was picking the right technology. Twenty years later I think almost the opposite. The stack is usually the last thing I decide, not the first, and the times I have watched it go badly almost always trace back to someone choosing the technology before anyone really understood the business.
A stack is a means to an end. The end is a product people actually use, or an operation that runs more smoothly, or a team that can ship without drama. Start from the technology and you optimize for the tool. Start from the business and you optimize for the thing that pays for all of it.
What understanding the business actually means
It is less glamorous than it sounds. It means sitting with the people who will use the thing and watching how they actually work, not how they say they work in a meeting. It means asking what happens if it is slow, or wrong, or down for an hour on a Saturday. It means knowing who is on call a year from now, after the launch excitement has worn off, and whether they will understand what they inherited.
Most of the expensive mistakes I have seen were not bad code. They were good code, written carefully, solving a problem nobody had bothered to define properly first.
The pull toward the exciting choice
There is a strong gravity in engineering toward the interesting decision. The new framework someone read about that week. The architecture that would be perfect for a company ten times your size. It feels like progress. Then it ships, the people maintaining it do not have the context, and every change after that gets a little slower and a little scarier.
The technology that ages well is rarely the most advanced one in the room. It is the one the team can run confidently at the size you will realistically be, not the size you are daydreaming about.
Get the order right
Business problem first. Then the real constraints: the people, what they can maintain, what it costs as it grows. The technology comes after all of that, and by then the choice is usually obvious and easy to defend to both the engineers and the people writing the cheques. Do it in the other order and you spend the next two years explaining a decision that never had a good reason behind it.
Written by Ronald Patrick G. Wenceslao — Engineering & Technology Leader. Open to leadership, advisory, and AI-enabled operations conversations.