Most organizations carry a quiet gap between what is technically possible and what is commercially worthwhile. Engineers tend to optimize for correctness, performance and clean architecture; business leaders tend to optimize for return, timing and risk. When those two groups never really talk, investments drift away from value, projects ship features nobody asked for, and good technical work fails to register as a business result. I have watched this happen, and for years I was on one side of it.
I started as a systems engineer. My instinct was always to ask whether something could be built well. It took an MBA, and a fair amount of being wrong, before I learned to ask first whether it should be built at all, and what it was worth to the organization. This article is about that bridge between the engineer's question and the manager's question, told from my own path rather than from a list of accomplishments. Where I make a general claim about why transformations succeed or fail, I cite the research that supports it.
Why the Gap Persists
The role of technology in organizations has changed faster than the way we train the people who lead it. IT used to be a support function; today it sits close to strategy, customer experience and how an institution actually runs. Yet the two educations that produce technology leaders still point in opposite directions. An engineering degree teaches you to make systems work. A business degree teaches you to decide what is worth doing with limited money and time. Few people are formally taught both, which is precisely why the gap survives.
The cost of that gap is documented. BCG's study of roughly 900 digital transformations found that only about 30% met or exceeded their targets and produced lasting change, while a quarter delivered almost no value at all. The decisive differences BCG identified are not mainly technical: strategy, leadership and talent sit at the top of the list. In other words, the failures are usually not failures of engineering. They are failures of judgment about what to build and how to carry the organization with you.
- First question: can we build it well?
- Pride in elegant architecture and clean code
- Options ranked by technical feasibility
- Timelines driven by development complexity
- Success felt like uptime, performance, no defects
- First question: is it worth doing, and to whom?
- Attention to return, cost of delay and opportunity cost
- Options ranked by value and strategic fit
- Timelines driven by when the value is needed
- Success measured by the outcome the work produced
Neither column is wrong. The mistake I made for years was treating the left column as the whole job. A perfectly engineered system that solves a low-priority problem is still a poor use of an organization's money, and learning to feel that as a real cost was the hardest part of the transition. The point is not to abandon the engineer's standards but to add a second filter in front of them.
What the Engineering Mindset Gets Right, and Where It Stops
An engineering education is an unusually good foundation for this work, and I would not trade mine. Systems thinking, decomposition, the habit of testing assumptions against reality, the discipline of making something actually work under load: these transfer directly to running technology in an organization. When a vendor demo glosses over how a system behaves at scale, the engineer in the room is the one who asks the uncomfortable question.
What the training did not give me was a vocabulary for value. I could tell you that one architecture was more maintainable than another; I could not always tell you which one the institution should pay for given everything else competing for the same budget. I could estimate effort; I struggled to estimate worth. That blind spot is common among technical people, and it is exactly where business education earns its place.
What the MBA Actually Changed
People sometimes assume an MBA is about jargon and slide decks. For me the useful part was much plainer: a set of tools for reasoning about scarce resources and human behavior. Three shifts stand out.
The first was financial literacy applied to technology. Concepts such as total cost of ownership, payback period and opportunity cost gave me a way to compare a technical choice against a non-technical alternative on the same terms. The right answer is sometimes not to build anything.
The second was taking people seriously as part of the system. McKinsey's research on transformations is blunt about this: fewer than 30% of digital transformations succeed, and the practices that separate the winners are organizational, not technical. Their data shows that simply defining clear roles so employees are prepared for the new way of working makes a company about 3.8 times more likely to succeed. As an engineer I had treated adoption as someone else's problem. It is the problem.
The third was learning to translate. A board does not want to hear about the data model; it wants to know what a decision costs, what it returns and what it risks. Engineers who can carry an idea across that boundary, in both directions, become disproportionately useful, and that translation work is most of what I do as a consultant now.
A note on frameworks: I am wary of acronyms that pretend to be discoveries. The thinking in this article is not a proprietary method; it leans on well-established work, including Prosci's ADKAR change-management research and the public findings of McKinsey and BCG on why transformations succeed or fail. What I add is the perspective of someone who crossed from the technical side to the business side and felt where the seams are.
What the Research Says About the Gap
I lean on outside data here on purpose, because the argument should not rest on my word alone. The figures below come from large, published studies, and each is sourced in the references.
Read together, these numbers tell one story. The constraint on technology value is rarely the technology. It is whether someone connected the build to a clear business purpose and then helped real people change how they work. That is the seam an engineer who has also studied business is unusually well placed to close.
How I Try to Decide Now
I do not run a secret framework, but I do force myself through the same questions before committing to a technology decision, in roughly this order.
What is the actual business question?
Before any architecture talk, I make the sponsor state the outcome in their own terms and how they would know it worked. If we cannot name the result, we are not ready to build.
What does it really cost?
Not just the licence or the sprint, but total cost of ownership over its life, plus the cost of the work we will not do because we chose this. The cheapest-looking option is often the most expensive.
What breaks, technically and on paper?
Technical debt, vendor lock-in and integration risk live in the same list as budget overrun and compliance exposure. Engineers and managers usually see different items, which is why the list has to be shared.
Will people adopt it?
This is the question I used to skip. Who has to change a habit, and what is in it for them? A technically excellent rollout with no adoption plan is a slow-motion failure.
How will we know it worked?
Pick the technical signals (performance, reliability) and the business signals (usage, time saved, cost avoided) before launch, not after, so success is something we measured rather than something we asserted.
Can it carry the next two years?
Decisions in education and mid-sized firms outlive their authors. I try to choose for the roadmap, not only for the demo, so today's convenient choice is not next year's migration project.
Where I See This Play Out
Two contexts shape my view. The first is the classroom. I teach systems and software subjects at Universidad Adventista Dominicana (UNAD), and the students who struggle most after graduation are rarely the weakest coders. They are the ones who never learned to explain why their work matters to anyone who does not code. I now build that translation skill into how I teach, because the market rewards it.
The second is consulting. I advise mid-sized companies in the Dominican Republic on digital transformation, and most of that work is bound by confidentiality, so I will not attach names or invented numbers to it. What I can say plainly, and what the research above backs up, is that the projects that go wrong almost never go wrong for technical reasons. They go wrong because the technical plan and the business intent were never the same plan.
The pattern I see most: a capable technical team delivers exactly what was specified, and the initiative still stalls, because no one owned the business case or prepared the people who had to live with the change. The fix is rarely more engineering. It is putting the business question and the human question on the table at the start, next to the technical one.
The Honest Downsides
Crossing between the two worlds is not free, and I would be dishonest to present it as pure gain. There are real costs, and naming them is part of doing it well.
Over-analysis: Once you can see both the technical and the commercial implications of a choice, you can talk yourself out of almost anything. My own failure mode is deliberating past the point where a decision was good enough. Seeing more angles only helps if you still decide on time.
You become the translator, for better and worse
Sitting between technical teams and leadership means a lot of conversations route through you. That influence is real, but so is the load, and it is easy to become a bottleneck. The goal is to build shared understanding between the two sides, not to make yourself permanently indispensable as the only interpreter.
Depth fades if you neglect it
The honest risk of breadth is shallowness. Business reading is no substitute for staying close enough to the technology to know when an estimate is fantasy. I have to defend time for hands-on work, or the engineering half of the judgment quietly erodes.
If You Are an Engineer Considering This Path
People ask me whether they should pursue business training, and my honest answer is that it depends on what you want to do, not on prestige. You do not need a degree to start; you need to start asking a different set of questions about your own work. A few that helped me:
- Put a number on value, not just effort. For your next feature, try to estimate what it is worth to the organization, not only how long it takes. The discomfort of that exercise is the lesson.
- Learn the basics of money. Total cost of ownership, payback period and opportunity cost are not difficult, and they change how you argue for technical work.
- Treat adoption as engineering. Who has to change a habit for your work to matter, and what makes that easy for them? Design for that as deliberately as you design the system.
- Practice translation. Explain your current project to a non-technical friend in two minutes, in terms of what it costs, returns and risks. If you cannot, that is the skill to build first.
Why This Matters More Now
The demand for people who can hold both views is rising, not because of any one technology but because more decisions now sit on the boundary. AI and cloud choices have large cost and risk consequences that are invisible unless you understand both the engineering and the economics. Regulation around data and security keeps adding constraints that are simultaneously technical and operational. And boards increasingly expect technology risk to be explained in business language. None of that rewards pure specialists on either side.
I do not think the answer is that everyone needs an MBA. The answer is that the gap between building and deciding is where value leaks out of technology projects, and the people who can stand in that gap and speak both languages will keep being worth a great deal to the organizations that employ them.
Conclusion
If I could give my younger, engineer-only self one piece of advice, it would be this: the question "can we build it well?" is necessary but not sufficient. The harder and more valuable question is "should we, and what is it worth to the people who will live with it?" Learning to ask both, in that order, is what the move from engineering to business actually taught me.
The value of bridging the two sides is not that it makes you smarter than either specialist. It is that most of the failures in technology projects happen in the empty space between them, and someone has to stand there. The research is consistent on this point: transformations fail for organizational and human reasons far more often than technical ones, and the practices that fix them are about clarity of purpose, defined roles and disciplined change management.
Key takeaway: An engineer who learns the language of value, and a manager who respects how things are actually built, are describing the same useful person from two directions. That person is rarely the smartest in either room, but is often the reason the work pays off.
References and Further Reading
- McKinsey & Company. "Unlocking success in digital transformations." Research finding that fewer than 30% of digital transformations succeed and that clearly defined roles make companies about 3.8x more likely to succeed. mckinsey.com
- Boston Consulting Group (2020). "Flipping the Odds of Digital Transformation Success." Study of ~900 transformations: ~30% meet or exceed targets; firms that get six success factors right report a 21% EBIT gain versus 10%. bcg.com
- Prosci. "The Correlation Between Change Management and Project Success." Initiatives with excellent change management are 7x more likely to meet objectives (88% meet or exceed goals vs 13% with poor change management). prosci.com
- Prosci. "Why Change Management Is Important," summarizing the ADKAR model and the people side of change. prosci.com
- Kotter, J. P. (2012). Leading Change. Harvard Business Review Press. Foundational work on why organizational change efforts stall.
Research note: The statistics in this article come from public research by McKinsey, BCG and Prosci, each linked above; please treat those organizations, not me, as the source for the numbers. Everything written in the first person is my own experience as a systems engineer who later earned an MBA and now teaches at UNAD and consults on digital transformation in the Dominican Republic. Client work is bound by confidentiality, so I describe patterns rather than naming organizations or attaching specific figures to projects I cannot disclose.