Why I'm Doing This

After twenty years of building and running enterprise IT, I noticed that the interesting problems in my day job had stopped being technical ones. The technology is almost always the easy part. The hard parts are: how does a technology decision reshape an organization; how do regulators and public opinion actually move in response to new systems; how do you set innovation priorities when every option looks plausible on a slide.

Those are not questions that get easier by doing more of the same work. They get easier by sitting with people who have studied them carefully, reading the literature, and being forced to defend your positions in front of someone whose job is to find the weak points.

So I put myself back in a classroom. Late-career, mid-company, with two decades of delivery behind me. It is uncomfortable in exactly the way it is supposed to be.

What I'm Studying

The program centers on advanced studies in technology leadership, innovation, and policy. The material ranges across four rough areas: strategy in technology-driven businesses; technology policy and its interaction with regulation; leadership in complex, technical organizations; and innovation frameworks that try to explain why some efforts produce new capability and others produce expensive presentations.

I'm not going to list specific courses or faculty here — the point of this page is the shape of the learning, not a transcript. If you're curious about specifics, reach out.

The Practitioner-Scholar Shift

There is a particular discomfort in moving between operating mode and learning mode. In my day-to-day role I am paid to make decisions quickly and correctly, to convert ambiguity into action, and to own the outcome. In a classroom, the best students are the ones who resist making the decision too quickly, who sit with the ambiguity, who treat the case study as a question rather than a problem.

Practitioners want answers. Academics want better questions. Both postures are valid — but they don't coexist naturally. Holding them both means accepting that some weeks you'll close a laptop having produced nothing shippable and instead have moved a mental model half an inch.

The best moments have been the ones where an academic framework cleanly explained something I'd seen in production but never had language for. The next-best moments have been the opposite — where a framework that looks clean on the page falls apart the instant you put real organizational dynamics into it, and the faculty are genuinely interested in hearing why.

Ongoing Notes

I'm using this as a long-running series on the blog. Not weekly recaps — those would be boring to write and worse to read — but reflections when something genuinely changed my mind or when I noticed a pattern worth sharing. Planned and in-progress pieces include:

  • Week N: Thoughts on the real cost of optionality in technology strategy
  • A framework I learned that changed my mind about platform decisions
  • Practitioner tension: when academic models don't survive reality
  • What policy people get wrong about operating constraints — and what operators get wrong about policy
  • The innovation framework I keep returning to (and the one I keep arguing with)

Links will appear on the blog index as they're written.

Open Invitation

If you're currently in a similar program, or considering one — especially if you're also a working practitioner deciding whether late-career study is worth the time — I'd love to compare notes. The population of senior IT leaders going back to school is small, and most of us are figuring this out without a reference group. Happy to trade reading lists, argue about frameworks, or just commiserate about the logistics of doing graduate-level work while running a real team.