Learning the Language of Business

Two lives

I was not stepping away from work into a quiet academic pause. I was living inside one of the more demanding periods of my professional life, leading cloud infrastructure and virtualization strategy at Yahoo while pursuing my MBA. The days had the density of two lives.

One life was full of infrastructure, cost models, data centers, engineering teams, cloud architecture, utilization, and transformation pressure. The other was full of classrooms, cases, frameworks, readings, group work, and conversations with people who did not all see the world through engineering eyes. It was not easy, but it was exactly the kind of difficulty I needed.

Engineers often believe we are practical because we build things that work. And we are practical, but sometimes narrowly so. We can become fluent in systems and still underdeveloped in markets, understand architecture and miss incentives, optimize performance and underestimate customer perception. We can build a strong platform and fail to explain why it matters to a buyer, a board, an investor, or an operating executive. Kellogg forced those questions into the room.

A case discussion did not begin with the architecture diagram. It began with the company. What market is it in, who is the customer, and what are the economics? What is the competitive position, what are the constraints, what is management trying to achieve, and what are the incentives? What should leadership do now, given incomplete information?

That last phrase mattered. Incomplete information.

In engineering, we try to create enough clarity for the system to behave, testing, measuring, debugging, and refining until the uncertainty becomes manageable. In business, leaders often have to act before clarity is complete. They decide in motion, with partial data, time pressure, conflicting incentives, and human uncertainty. A strategy is not a proof. It is a commitment under uncertainty, and that changed how I listened.

Before Kellogg, I might have looked at a leadership decision and judged it primarily by technical logic. Does the architecture make sense? Is the platform scalable, will the system perform, and are the engineering assumptions sound? Those questions still mattered, and they always will. But they were no longer enough.

A leader also asks a different set of questions. What capital is available, and what timing does the market allow? What does the customer understand, and what risk can the organization absorb? What incentives shape team behavior, what does the board need to see, and what will competitors do? What must be true for adoption to happen, and what trust must be earned before this system becomes usable?

These are not softer questions. They are system questions, describing the larger environment in which technology either becomes useful or remains stranded.

That was one of the most important shifts for me. I began to understand business not as a layer above technology, but as another system around it. Markets have architecture, capital has constraints, and organizations have incentives. Customers have fears, habits, language, and budgets, and leadership has rhythms, blind spots, and pressure. A technology strategy that ignores those realities is incomplete.

This realization did not weaken my respect for technical depth. It made technical depth more consequential.

If you understand the system deeply but cannot make its value legible to the institution, the system may never receive the support it needs. If you translate poorly, good technology may be ignored; if you exaggerate, trust is lost; if you translate precisely, leaders can make better decisions. That translation is part of building. It is not dilution. It is how technology becomes useful inside institutions.

What each discipline taught

Finance gave me one of the clearest examples. At Yahoo, infrastructure modernization had direct cost implications. Data centers, servers, utilization, automation, operations, energy, and capacity planning: these were engineering realities with financial consequences. Kellogg helped me make that connection more precise.

A server sitting idle became more than unused compute; it became deployed capital producing too little value. A slow provisioning process became more than operational friction; it became delayed opportunity. A fragmented platform became more than technical debt; it became a tax on speed, talent, and strategic flexibility. Finance gave language to what engineering could feel, and that language mattered in executive rooms.

When a technology leader can connect architecture to capital efficiency, the conversation changes. Infrastructure stops being a cost center buried in technical detail and becomes part of strategic resource allocation. The question is no longer only what the system costs. It becomes how the system changes the company’s ability to use capital, time, talent, and opportunity. That is a different conversation, and a more honest one.

Strategy gave me another kind of discipline. At Optena, I had lived the difficulty of being early. We had strong technical conviction about distributed computing, grid computing, virtualization, and infrastructure automation, and the direction was real. But the market language was still forming. Customers had pain, but not always the buying model or operating model to adopt what the architecture made possible.

At Kellogg, I could examine those experiences with more structure. Why do some innovations cross into adoption while others remain trapped? How do buyers perceive risk, how do categories form, and how does value migrate across an industry? How do incumbents respond, how do channels shape adoption, and how do customers learn what to buy? These were not theoretical questions to me. I had lived them.

In the classroom, they became less personal and more analytical, and that helped. Founders often experience market resistance emotionally, and business education can convert some of that emotion into understanding. It does not remove the difficulty, but it gives the mind a better map. I began to see timing more clearly.

Timing is not merely luck or calendar position. It is the convergence of many conditions: technology readiness, buyer pain, budget, organizational readiness, competitive pressure, ecosystem maturity, trust, and language. A market moves when enough of those conditions align, and a company building ahead of alignment must either find a narrow wedge of urgent pain or survive long enough for the market to catch up. That insight would become important later. At Kellogg, it was forming through reflection, discussion, and comparison.

Marketing also mattered more than I expected. Engineers sometimes reduce it to messaging, but at its best, marketing is disciplined empathy. It asks how customers see the world, what they value, what language they trust, what anxieties shape their decisions, and what problem they believe they are solving.

This was useful because I had spent much of my life building systems whose value was beneath the surface. Hidden value is powerful, but it must still be communicated. A platform that improves reliability, speed, cost, trust, or coordination often works behind the scenes, and if leaders cannot understand its value, they may underinvest until failure makes the value visible. That is a dangerous pattern. Business language can make hidden value visible before crisis.

This became one reason I took the MBA seriously. I did not want to become a technologist who complained that business people did not understand technology. I wanted to become someone who could make technology understandable without making it shallow. That distinction mattered: simplifying is not the same as dumbing down.

A good translation preserves the integrity of the idea while making its consequence visible to the person who must decide. The same technology has many meanings depending on who must act.

A builder who cannot move between those meanings becomes limited.

Organizational behavior gave me another kind of language. At first, many engineers underestimate this domain, because it can appear less concrete than finance or strategy. But after years in complex systems, I knew that organizations often fail less from lack of intelligence than from misalignment, fear, unclear incentives, poor communication, and weak trust.

I had seen this in factories, in startups, in large engineering organizations, and in cloud transformation. People do not resist change only because they are stubborn. They resist when the new system threatens control, identity, competence, status, rhythm, or trust. Teams protect local ownership because they are accountable for outcomes, leaders delay decisions because risks are unevenly distributed, and organizations say they want transformation while rewarding behaviors that preserve the old system.

Organizational behavior gave language to the human side of execution. It helped me see leadership less as command and more as context design.

A leader shapes incentives, communication, expectations, decision rights, operating rhythms, symbols, and trust. People act inside that context. If the context is poorly designed, even talented people struggle; if it is coherent, ordinary effort can become coordinated and powerful. This idea resonated deeply.

Machines have architectures, software has architectures, and organizations have architectures too. Some are explicit, and many are hidden. Leadership requires seeing and shaping both.

This connected directly to my experience at Yahoo. Cloud transformation was not only about virtualization, automation, storage, Hadoop, edge services, or platform infrastructure. It was also about internal trust. Would teams accept shared infrastructure, would finance believe the savings, and would product leaders trust the roadmap? Would operations teams feel they still had visibility and control, and would engineers see the platform as leverage rather than constraint?

Those questions were organizational architecture, and a cloud roadmap without that understanding would remain incomplete. Kellogg helped me name what I had been learning the hard way.

The same was true of capital. Engineers often think in terms of capability, but capital forces a reckoning with allocation. Every investment competes with another, every project consumes resources that could have gone elsewhere, and every strategic choice has a financial expression, even when people avoid saying so. This discipline was uncomfortable in a useful way.

Technology leaders can become too attached to what is possible. Capital asks what is worth doing now, not because imagination should be reduced, but because resources are finite and timing matters. A company cannot pursue every good idea. It has to choose, and choice is where strategy becomes real.

That lesson influenced how I later thought about product, venture creation, and enterprise AI. A powerful technology is not enough. The question becomes which problem is urgent enough, which buyer is ready enough, which operating model can absorb it, what risk must be reduced, what evidence will create trust, and what wedge allows adoption to begin. These are business questions, and they are also builder questions. The older I became, the less separation I saw between them.

Kellogg also gave me space to examine my own leadership style. I had intensity, systems curiosity, and a strong desire to build what came next. I could see patterns across domains and often moved quickly once I saw them. That strength could also become a weakness. Seeing a pattern is not the same as helping an organization move toward it.

A leader has to create shared understanding, translating enough of the future into the present so others can carry it. He has to know when to push and when to listen, and he has to understand that people do not adopt ideas only because the ideas are right. They adopt when the idea becomes connected to their reality, their incentives, their responsibilities, and their trust. That was humbling, and it changed how I thought about influence.

Influence is not performance, and it is not loud conviction. It is the ability to help others see consequence clearly enough to act. Sometimes that requires numbers, sometimes a story, sometimes patience, sometimes a prototype, sometimes a customer’s pain, sometimes a financial model, sometimes a risk analysis, and sometimes a quiet conversation with someone who will be affected by the change. A technologist who wants to lead must become fluent in these forms.

During those years, the learning loop was short. I was not storing ideas for later; I was using them. A finance concept could sharpen how I discussed infrastructure savings, a leadership discussion could help me understand resistance, and a strategy case could make me think more carefully about timing and competitive pressure. A marketing framework could help me describe value from the customer’s side, and an organizational behavior lens could explain why a technically sound plan was meeting internal friction. That is when education becomes powerful. It leaves the classroom and enters the next meeting.

By the end of my Kellogg period, I felt that my professional language had expanded. I was still a systems builder. I had not abandoned depth or become less technical. But I could move more fluidly between architecture and strategy, product and finance, engineering and organization, technology and market. I had gained translation, and that translation would become one of my most important capabilities.

Many technologists remain trapped because they can only speak to other technologists, and many business leaders remain limited because they cannot see the architecture beneath strategy. Some of the most valuable work happens between those worlds, where someone must understand enough of both to create alignment. Kellogg strengthened my ability to stand in that middle. It also sharpened my ambition.

Not ambition in the shallow sense, not title, money, or status. A deeper ambition: to build systems that mattered at the level of enterprise direction. I did not want technology to be treated as a support function. I wanted leaders to understand that architecture could change economics, platforms could change markets, data could change decisions, and infrastructure could change organizational speed. That conviction became stronger during the MBA.

I began to see that the technology leader of the future would need to be more than a technical expert. The world was becoming too integrated for narrow leadership, and the next kind of leader would need to understand systems, strategy, capital, governance, human behavior, and execution together. I did not yet have the full name for that archetype. But I was beginning to become it.

Kellogg was not the whole cause. It was one layer in a longer formation. The field, the lab, the factory, the city, Bell Labs, Oracle, Optena, Amitive, and Yahoo had already been teaching me, and Kellogg gave me language for what experience had been pressing into me. It helped convert instinct into articulation, and it helped connect my technical past with a broader leadership future. That is why this chapter belongs in the story. Not because a degree was added to my profile, but because a new lens entered my life.

Kellogg taught me that markets have their own architecture, that capital is a design constraint, that organizations behave according to incentives, stories, fear, and trust, that leadership is interpretation under uncertainty, that value must be communicated in the language of the decision-maker, and that the builder who cannot translate may remain trapped inside the workshop.

The next chapter would make that lesson more practical. At SIOS, cloud would no longer be only architecture or internal strategy. It would have to become product, and customers would need to understand it, buy it, trust it, and operate it. That is a different test.

Learning the language of business did not take me away from technology. It taught me how technology becomes real inside institutions.