What my MBA at Polytechnique taught me about digital transformation

After twenty years of designing systems, the question I was missing wasn't technical: it was knowing how to connect an architecture decision to a business decision, in both directions. The Digital Transformation Strategist program at École Polytechnique Executive Education filled exactly that gap, with a level of rigor I didn't expect from an MBA: as much methodological discipline as on a technical subject.

A curriculum that doesn't stop at strategy

The program blends a theoretical technical track with a methodological one, designed to answer each other rather than stay side by side:

Block	Content	What it concretely brings
Technologies	Cybersecurity, AI, blockchain	Understanding what a technology actually enables, not what a sales pitch claims
Methodology	Transformation project management, change management	Structuring a transformation that goes beyond the technical scope alone
Opportunity study	Market analysis, validating a real need	Avoiding building a technical solution to a problem that doesn't exist
Business model	Structuring the value proposition and revenue	Translating a technical capability into a viable economic model
Strategy	Aligning company vision with the transformation roadmap	Justifying a transformation decision at the level it needs to be justified: beyond the product

What sets this program apart from a pile of business concepts is the demand for "concrete": every theoretical block gets translated into a real case study, not an academic exercise isolated from any operational constraint.

What the technology block actually changed

The "Technologies" block only had value because it refused to stay at the level of a sales pitch. Two areas in particular changed how I approach my engagements:

Area	What twenty years of code had already given me	What the program added
Cybersecurity	A developer-side practice of the subject (securing code, access, data)	A product and market-side reading: how a vendor builds a security offering, how a buyer evaluates a solution, where the genuinely defensible value sits against competitors
AI	A daily practice of AI as a development tool	A strategic reading grid: telling apart a genuinely differentiating AI capability from a marketing argument, and assessing where AI changes a business model rather than just a product feature

That distinction matters especially on the digital transformation project detailed below: cybersecurity wasn't treated there as a technical subject to secure, it was the product itself to position and sell, which demands a completely different analysis grid than the one a developer uses to secure their own code.

The format: assessed like a real mandate

The program runs on a tight format of roughly forty hours. What changes the nature of the commitment isn't the hour count, it's the validation method: a memo on a professional project, individual or group, followed by a defense in front of a jury. That's not an end-of-module multiple-choice quiz, it's the exercise you find on a real engagement: defending a recommendation in front of people who will challenge it, not just read it.

   Vision              Strategy              Business model         Execution
 (where the        ──▶ (how to get      ──▶  (how to fund it    ──▶ (transformation
  company wants          there, which          and make it            plan, memo,
  to be in 3-5           levers to pull)       viable)                 defense)
  years)

That sequence, which echoes the exact title of one of the program's modules ("from vision to strategy"), isn't a slogan: it's the order in which the jury expects the reasoning to be built. Proposing a technical execution before establishing the strategy that justifies it is exactly the kind of shortcut a defense exposes.

The project: turning a distributor into a supplier

The project I led with my team during the program was built around a real case: evolving a company from distributing cybersecurity products (reselling third-party vendors' catalogs) to supplying cybersecurity products (designing and owning its own offering). That shift isn't just a marketing pivot, it's a complete change of business model.

Aspect	Distributor	Supplier
Product ownership	Resells a third-party vendor's catalog	Designs and owns its own product
Margin	Resale margin, dependent on the vendor's terms	Margin on the value created, structurally higher
Dependency	Depends on the vendor's roadmap and priorities	Controls its own technical roadmap
Required skills	Sales and logistics	R&D, product security, direct customer support
Risk	Low technical risk, limited margin	Higher technical and execution risk, higher potential margin

That table sums up in a few lines what the project required detailing over several months: which internal skills already existed and which were missing, what product roadmap was realistic given the resources, and above all, what business model made the transition viable without jeopardizing the existing distribution business during the transformation.

Why this isn't just a marketing pivot

The most common temptation on a case like this is to treat the transformation as a communication problem: rebranding as a "supplier" without actually changing the revenue structure or internal skills. The program's Business model innovation module makes that trap visible immediately, because it forces you to answer four questions in order, with no skipping ahead:

Business model question	What it forced us to settle on this project
What value proposition?	Proprietary product vs. value-added resale: two incompatible propositions, not a simple positioning choice
Which customer segments?	The distributor's existing customers aren't automatically buyers of a proprietary product
What cost structure?	R&D and product security are new fixed costs, absent from the distributor model
What revenue streams?	Resale margin negotiated per contract vs. recurring product margin: two different cash flow dynamics

Answering "yes" to all four rows without an internal contradiction is what separates a real transformation plan from a storytelling exercise. That's exactly the test a jury defense applies, question by question.

The most underestimated risk: the transition period

The distributor/supplier table above describes two stable states. What it doesn't show is the in-between period, where the company has to operate both models at once: keep generating distribution revenue while the proprietary supply capability gets built, without either one cannibalizing the other too early or starving it of the resources it needs. That transition phase, more than the end state, is what demanded the most modeling work in the project: how long it can reasonably last, what signal triggers shifting a majority of resources toward the new model, and what fallback scenario exists if the proprietary product's traction is slower than expected.

What twenty years of code don't teach

Technical skill teaches you to correctly build what you decide to build. It doesn't teach you to assess whether what you're about to build answers a real market need, how to finance it, or how to align an entire organization behind that choice. On this project, my natural role was challenging the technical feasibility of every scenario the team considered, a reflex that business training alone doesn't give you: many digital transformation plans fail because they're validated by people who understand the market but not the real constraints of technical execution, or the other way around.

What that changes in my engagements

That dual skill set concretely changes the kind of engagements I can take on: beyond architecture or development, I can challenge a digital transformation decision before it turns into code, at the point where a correction still costs a meeting, not a rewrite. It's a different role from a tech lead in the strict sense, but it rests on the exact same discipline: never separate a technical decision from its business justification, or the reverse.