I'm one month into the Executive MBA program at the Rotman School of Management, and it's already challenging assumptions I didn't know I had.
This isn't a review of the program. It's a real-time account of how business education is reshaping my thinking as a technology leader—the specific concepts, frameworks, and conversations that are changing how I approach my day job.
Why an Executive MBA Now?
After more than a decade in technology roles—from software engineering at Morgan Stanley to solution architecture at Air Canada—I noticed a recurring pattern: the most impactful projects weren't won or lost on technical merit. They succeeded or failed based on organizational dynamics, stakeholder alignment, and strategic positioning.
I could design elegant architectures. I could lead engineering teams. But I kept running into the same friction points:
- Building business cases that resonated with non-technical executives. I knew a platform investment would pay off, but I couldn't always articulate why in financial terms that CFOs found compelling.
- Navigating organizational politics that determined which projects got funded, staffed, and supported. Technical merit was necessary but rarely sufficient.
- Thinking strategically about where technology creates competitive advantage versus where it's simply table stakes. I had strong instincts but wanted frameworks to sharpen them.
- Understanding the broader business context in which technology decisions get made. Every architecture exists within an economic, competitive, and regulatory environment that shapes what's possible.
The EMBA wasn't about career pivoting away from technology. It was about becoming a more effective technology leader by understanding the business side of the equation with the same depth I understand the technical side.
Why Rotman Specifically
Rotman's emphasis on "Integrative Thinking"—the ability to hold two opposing ideas in tension and produce a synthesis that's superior to either—resonated with how I already think about architecture trade-offs. Every significant design decision involves holding competing concerns (performance vs. cost, flexibility vs. simplicity, speed vs. quality) and finding a synthesis.
The program's structure also matters. As an executive program, my classmates are mid-to-senior leaders across industries, not recent graduates. The learning comes as much from peer conversations as from professors and case studies. And the weekend format makes it possible to maintain a full-time leadership role while studying—difficult, but possible.
Month One: What's Landing
The Case Method Is Remarkably Like Architecture Reviews
Rotman uses the case method extensively, and it turns out the skills are surprisingly similar to what I do in architecture reviews:
- Diagnose before prescribing. The case method forces you to articulate what problem you're actually solving before proposing solutions. In technology, we often jump to solutions too quickly. A stakeholder says "we need a microservices architecture" when the actual problem might be "our deployment frequency is too slow."
- Consider multiple perspectives. A good case analysis examines the situation from the CEO's perspective, the CFO's, the customer's, and the front-line employee's. Good architecture does the same—considering the developer experience, operational burden, cost profile, and business agility simultaneously.
- Make explicit trade-offs. Cases rarely have a single "right answer." They have options with different trade-off profiles. Sound familiar? That's every architecture decision I've ever made.
The biggest difference: in case discussions, you have to articulate your reasoning out loud to a room full of accomplished professionals who will challenge you. It's uncomfortable and incredibly effective at sharpening thinking.
Finance Fundamentals Changed How I Build Business Cases
Understanding how to think about NPV (Net Present Value), IRR (Internal Rate of Return), and the time value of money has already changed how I frame technology investments to leadership.
Before Rotman, a typical business case from me might have said:
"This platform will save us $2M per year in infrastructure costs and improve deployment frequency from monthly to daily."
After one month of finance fundamentals, the same case becomes:
"This $3M platform investment generates a projected NPV of $4.2M over 5 years at a 12% discount rate, with payback in 18 months. The IRR of 38% significantly exceeds our cost of capital. Beyond the quantifiable cost savings, the improved deployment frequency de-risks our ability to deliver the three revenue-generating initiatives planned for next fiscal year."
The second version speaks the language that finance teams and boards use to allocate capital. It frames the investment not as a cost but as a return on capital deployed—which is how executives think about every spending decision.
Accounting Is Not Just for Accountants
I'll be honest: I expected the accounting module to be the most tedious. Instead, it's given me a new lens for understanding enterprise software decisions.
Understanding how capital expenditures (CapEx) vs. operating expenditures (OpEx) flow through financial statements explains why cloud migration is often more attractive to CFOs than the technical benefits alone would justify. A shift from on-premises infrastructure (CapEx—depreciated over years, sits on the balance sheet) to cloud services (OpEx—expensed immediately, doesn't tie up capital) changes the company's financial profile in ways that matter to investors.
This also clarified something I'd observed but never fully understood: why some organizations are reluctant to invest in platform engineering despite clear technical benefits. When the investment is capitalized as a software asset, it creates depreciation expense over future years. When it's classified as operational spending, it hits the P&L immediately. The same dollar amount can have different strategic implications depending on how it's accounted for.
The Cohort Effect Is Real
My classmates come from healthcare, manufacturing, financial services, consulting, government, real estate, and a dozen other industries. The diversity of perspective is the single most valuable aspect of the program so far.
A few examples that stuck with me:
- A marketing executive's approach to customer segmentation gave me new ideas for how we might think about service tiers in platform engineering. Not all internal customers have the same needs, and treating them identically wastes resources and frustrates power users.
- A supply chain leader's framework for managing uncertainty maps directly to architectural resilience. She uses probabilistic modeling for demand forecasting in ways that parallel how we should think about capacity planning and failure modes.
- A healthcare COO's experience with regulatory compliance highlighted parallels with aviation regulation that I hadn't considered. Both industries deal with safety-critical systems, audit requirements, and the tension between innovation and regulatory conservatism.
- A real estate developer's perspective on long-horizon investments challenged my tendency to evaluate technology investments on 2-3 year horizons. Some platform decisions have 10+ year consequences.
The hallway conversations between classes are often as valuable as the lectures themselves.
Applying It at Work
I'm already using concepts from the program in my day-to-day role:
Stakeholder Mapping
For a cross-functional initiative I'm leading, I applied a stakeholder analysis framework from our strategy module. Mapping stakeholders on two dimensions—level of influence and level of interest—helped me sequence conversations more effectively.
High influence, high interest stakeholders get detailed briefings and input opportunities. High influence, low interest stakeholders get concise executive summaries. Low influence, high interest stakeholders get regular updates. This sounds obvious written down, but I wasn't doing it systematically before.
Financial Modeling for Platform Investments
Instead of presenting a platform investment as a cost savings exercise, I built a proper financial model with sensitivity analysis. What if adoption is 20% lower than projected? What if the timeline extends by 6 months? What's the break-even point under pessimistic assumptions?
Presenting this analysis—with transparent assumptions and honest risk assessment—generated more executive confidence than the optimistic "we'll save X million dollars" pitch I would have made before.
Porter's Five Forces for Vendor Selection
We were evaluating vendors for a new capability. Instead of just comparing feature matrices, I applied Porter's Five Forces framework to assess each vendor's competitive position:
- Supplier power: How dependent would we be on this vendor? What's our switching cost?
- Buyer power: How many alternatives exist? Do we have leverage in negotiations?
- Competitive rivalry: Is this a commodity market or a differentiated one?
- Threat of substitution: Could an open-source alternative or internal build replace this?
- Barriers to entry: Is this vendor's position defensible, or could their advantage erode quickly?
This analysis surfaced risks that the technical evaluation alone would have missed—particularly around vendor lock-in and switching costs.
The Time Challenge
Let's be honest: balancing a demanding job, an MBA program, and life outside work is hard. I won't sugarcoat it. The reading load is substantial, the assignments are rigorous, and the opportunity cost of weekend classes is real.
What's helping me manage:
- Ruthless prioritization: Each week, I identify the 3-5 things that absolutely must get done across work, school, and personal life. Everything else gets deferred or delegated.
- Blocking focused time: Study time on my calendar is as non-negotiable as a customer meeting. If it's not blocked, it gets filled.
- Being transparent: My team knows I'm in the program and that some weeks will be harder than others. Transparency builds trust and allows them to step up when needed.
- Finding synergies: Many assignments can be connected to real work challenges. A finance case study becomes practice for an actual business case. A strategy framework gets applied to an actual vendor decision.
- Accepting imperfection: I'm not going to be the best student in every class and the most responsive leader every week simultaneously. Accepting that trade-off is itself a lesson in resource allocation.
What I Didn't Expect
A few surprises from month one:
- How much I don't know about how businesses actually work. I had a reasonably sophisticated understanding of technology organizations. My understanding of how finance, marketing, operations, and strategy functions operate was superficial at best.
- How much my technology background is valued by classmates. I assumed I'd be the one learning from the "business people." Instead, it's genuinely reciprocal. My ability to explain technology implications in accessible terms is as valuable to them as their business frameworks are to me.
- How energizing it is to be a student again. After years of being the person others come to for answers, it's refreshing to be in an environment where I'm explicitly there to learn.
Looking Ahead
The program is structured around building blocks that culminate in an integrative capstone project. I'm particularly looking forward to the strategy and organizational behavior modules later in the program—both areas where I feel the gap between my current capabilities and where I want to be.
I'll continue documenting this journey, focusing on the specific concepts and frameworks that are changing how I think about technology leadership. Not in a theoretical way, but in terms of how they're immediately applicable to the work I'm doing.
If you're a technologist considering an executive education program, I'm happy to share more about the decision process and experience so far. And if you're a Rotman alum, I'd love to connect—the network is clearly one of the program's most enduring benefits.
The best investment you can make is in the mental models that shape your decisions. One month in, I'm already seeing returns.