Why an MBA?.md

An MBA is typically how an engineer announces they are leaving the codebase behind to pursue a management-related career. My experience did the opposite. I finished my degree and went deeper into building software.

Stepping away from technical leverage

People often ask why a software engineer pursues a business degree. I wanted to force my own growth by stepping into rooms where my technical background offered zero leverage.

Engineering teams reward the person who can produce the most efficient technical solution. A cohort of professionals from finance, healthcare, and the military operates on entirely different metrics. To succeed there, you have to raise a point and defend a position with stakeholders who do not share your vocabulary. The code cannot defend you. I needed to learn how to build consensus and drive decisions relying entirely on the strength of the business case.

This approach was established early on. My undergraduate degree was in management information systems at Sacramento State, a program built on the premise that business drives technology. It was actually there, while building my first tax calculator, that I discovered my passion for software development. The MBA took that foundational principle and turned it into an operational discipline.

Detaching from the system

Engineering trains you to find the objective answer. The test passes or fails. The profiler names the slow function. Arguments have clear, mathematical exits. Business realities lack that comfort. Throughout the program, I evaluated dozens of case studies, diagnosing organizational failures and analyzing strategic pivots within active companies. Analyzing these scenarios alongside professionals from diverse sectors exposed something I had not expected. Technical accuracy buys you nothing if you cannot connect it to the operational metrics those stakeholders actually care about. You have to work through situations where incomplete information is the default state and nobody agrees on the underlying facts.

That process shifts how an engineer thinks. The natural engineering reflex is to build. We see a challenge, we build a system, and we ship a product. That exact instinct frequently leads to severe overengineering, creating complex architecture for problems that require process changes rather than code. Business training forces a complete detachment from the technical system to focus exclusively on the core problem. It creates the discipline to look at a project scope and recognize that the most effective technical decision is often solving the issue through operational refinement rather than writing another line of code.

Designing organizational architecture

The program provided an immediate environment to apply this discipline. When my team was tasked with modernizing the Sacramento Entrepreneurship Academy (SEA), an institution that has developed regional founders for decades, the work began at the technical level. I wrote the code to revamp their program timelines for visual clarity and enhanced access to their digital portals.

Studying the management of innovation taught me that a modernized interface has limited impact if the organization itself remains siloed. The deeper infrastructure challenge was ecosystem alignment. Alongside the technical rollout, we initiated a strategic partnership between SEA and the Carlsen Center for Innovation and Entrepreneurship. We drew on the existing innovation hub in the Sacramento region to build a unified environment for future entrepreneurs. We aligned the operational realities of two distinct institutions to build a stronger local ecosystem. The project proved the exact lesson the case studies were teaching in the abstract. The most valuable architecture you can design is an alignment between people, and the code simply exists to facilitate it.

Bridging the gap in government

In business school, “competitive advantage” is often used to describe a unique capability that allows an organization to outperform its rivals. In government and large-scale public infrastructure, that advantage is found in individuals who can bridge the gap between strategic intent and technical execution. A pure administrator can identify organizational bottlenecks but lacks the vocabulary to evaluate the technical debt, infrastructure limits, or execution reality required to clear them. A pure engineer can build a computationally flawless system that solves the wrong operational problem, failing entirely to integrate the new technology into the existing business model.

The disconnect between those two groups is where large-scale initiatives stall. Working within the state’s technology infrastructure requires understanding how to introduce modernization while balancing the massive, ongoing core operations of government. It is the capacity to walk into a room, diagnose a strategic organizational failure, align cross-functional stakeholders on a path forward, and then sit down and architect the precise solution required to fix it.

When I was selected to speak as the commencement speaker for 1,200 graduating business students, the moment marked a quiet shift. The College of Business was being represented by a software engineer. The degree did not pull me away from my technical roots. It gave me the framework to guarantee I am architecting the right systems to shape the future of California.

INSTITUTION PARTNERS