Introduction
“I have spent more than a decade building, leading, and delivering software products used by millions of users and enterprises in Fortune 500 environments. One thing I have learned is that building software is no longer the hardest part. Technology today has made writing code easier than ever. What is still hard to find is strong judgment, and weak judgment is one of the most underrated reasons technology projects fail.”
– Premuditha Perera
Many technology problems are first discussed as delivery problems.
The team is slow. The release is late. The system is unstable. The cost is too high. The quality is dropping. The business has lost confidence. Sometimes those are real delivery problems. But many times, they are not the first problems. They are the visible results of earlier decisions.
A decision to rush without enough clarity. A decision to use the wrong tool because it was familiar. A decision to build something more complex than the business needed. A decision to avoid a difficult trade-off until it became expensive.
From the outside, it may look like the project failed at build. In reality, it often failed much earlier. It failed at judgment.
Building is easier than deciding well
Today, software development knowledge is not rare.
Most technical problems have already been discussed, documented, solved, and explained somewhere. Teams now have better frameworks, cloud platforms, infrastructure, developer tools, and AI-assisted coding support than ever before.
Writing code, finding examples, setting up infrastructure, and even generating code have all become easier. But deciding what should be built, why it should be built, how far it should go, what trade-offs are acceptable, and what should not be built at all, that is still difficult.
That is where many projects struggle. A system can survive bugs, refactoring, and even some imperfect technical decisions. But it cannot survive for long when important decisions are made without enough judgment.
Familiar tools are not always the right tools
One common mistake is using the same familiar technology stack to solve every problem.
This happens more often than people admit. A team becomes comfortable with a certain language, framework, cloud service, database, or architecture style. Over time, that becomes the default answer for every new problem. The problem is not that the stack is bad. In many cases, it may be a perfectly good stack. The problem is that the decision is no longer based on what the business actually needs. It is based on what the team already knows how to deliver.
A customer should get the most optimal solution for the value they are paying. Not a suboptimal solution shaped by the limits of the team’s comfort zone.
Of course, familiarity matters. A team should not randomly choose new technology just to look modern. That can create even more risk. A familiar stack can be the right answer when it fits the problem, the team, the timeline, and the long-term support model. But every serious technology decision should ask a few basic questions:
- Is this the right tool for this specific problem?
A technology choice should be based on the problem in front of the business, not only on what the team has used before.
- Will this help the business move forward?
The solution should support a real business outcome, not just satisfy a technical preference.
- Can this be supported by the team over time?
A good decision is not only about building the first version. It is also about maintaining, improving, and operating the system after launch.
- Are we choosing this because it is right, or because it is familiar?
Familiarity is useful, but it should not quietly become the main reason behind every technical decision.
Good judgment is knowing when to use what the team already knows, when to stretch beyond it, and when to keep things simple.
Technology should multiply the business
Another mistake is thinking that the best technology solution is always the most advanced one. It is not.
Many teams are naturally drawn to sophisticated solutions. Complex architecture. New tools. Distributed systems. Event-driven everything. AI everywhere. Heavy automation. Perfect abstractions. Sometimes those things are needed. Many times, they are not.
Technology should be a multiplier for the business. It should help the business move faster, serve customers better, reduce operational pain, improve reliability, increase visibility, or create new capability.
If the technology does not support a real business milestone, it may be impressive, but it may not be useful. This is where balance matters. The right solution is not always the simplest solution. It is also not always the most advanced solution.
The right solution fits the business context, the team, the risk, the budget, the timeline, and the future direction. That requires judgment.
Trade-offs are where leadership shows up
Every technology decision has a trade-off.
Moving faster may increase technical risk. Designing for flexibility may add complexity. Optimizing for low cost today may create higher cost later. Over-investing too early may slow the business before it has proved the need. There is no perfect answer that works everywhere.
This is why technology leadership cannot be reduced to knowing patterns, frameworks, or best practices. Those are useful, but they are not enough. Real leadership is knowing how to make the right trade-off for the situation in front of you.
Sometimes the right decision is to build quickly. Sometimes it is to slow down and fix the foundation. Sometimes it is to use boring technology. Sometimes it is to invest in a more scalable approach. Sometimes the right decision is to say no.
And sometimes the most valuable decision is to not build something at all.
More development does not fix weak judgment
When a project is struggling, the first reaction is often to add more people.
More developers. More meetings. More process. More delivery pressure. But if the real problem is weak judgment, more execution does not solve it. It usually makes the problem bigger.
More people can build more things. But without clear direction, they can also create more inconsistency, more rework, more technical debt, and more confusion. Speed without direction is dangerous.
A team can be busy every week and still move the system in the wrong direction. This is why the most important question is not always, “How fast can we build?” Sometimes the better question is, “Are we building the right thing, in the right way, for the right reason?”
Technology and business must move together
Technology should not live separately from the business.
A technical decision is also a business decision when it affects cost, timelines, operations, customer experience, compliance, support, or future growth. This is where many gaps start to appear. Business teams may ask for outcomes without fully understanding the technical consequences. Technical teams may make decisions without fully understanding the business pressure. Product teams may focus on visible features while hidden complexity grows underneath.
Most of the time, this does not happen because people are careless. People are usually trying to do the right thing from where they stand. The problem is that someone has to connect these views. Someone has to understand the business goal, the technical reality, the delivery pressure, and the long-term system impact. That connection is where good judgment becomes valuable.
Good judgment helps answer questions like:
- What is the business really trying to achieve here?
The requested feature is not always the real need. Sometimes the real need is operational efficiency, better visibility, lower risk, or faster decision-making.
- What level of solution is enough for this stage?
Not every problem needs the most sophisticated answer on day one. The right level of investment depends on where the business is and what it needs next.
- What are we making easier, and what are we making harder?
Every decision improves something and usually makes something else more difficult. Good judgment makes that trade-off visible before it becomes expensive.
The real cost of weak judgment
Weak judgment does not always create immediate failure. That is what makes it dangerous.
A poor decision can still produce a working feature. A rushed shortcut can still pass testing. A familiar technology choice can still deliver the first version. An over-engineered solution can still look impressive in a meeting. But over time, the cost appears. The system becomes harder to change. Delivery becomes slower. Teams lose confidence. Every new feature takes longer than expected. Simple requests become complex. Nobody knows why certain decisions were made.
The business starts depending on a system that is becoming harder to guide. By the time the problem becomes visible, it is no longer one decision. It is a long chain of decisions. That is why judgment matters so much. It shapes not only what gets built, but also what the business will have to live with later.
Why this matters to Rootstone
This is one of the beliefs behind Rootstone. Not because the world needs another company that can write code. There are plenty of those. Rootstone is built around a different belief: serious technology work needs judgment before movement, direction before speed, and ownership beyond delivery.
The goal is not to build the most complex solution, use the newest technology, or move fast for the sake of movement. The goal is to make technology work for the business, with the right decisions, the right trade-offs, and the right level of ownership.
Because in the end, technology rarely fails only at build. More often, it fails much earlier.
It fails at judgment.
