Why I Studied “Technovate Thinking” at Business School Despite Working in IT 【Technovate Thinking ① Day1 Part1】

I’m writing a 12-part series documenting what I learned in a business school course called “Technovate Thinking.” This is Part 1.

In this first installment, I’ll cover why someone with an IT infrastructure background would bother taking this course in the first place, along with what I reflected on during the Session 1 pre-work: how the evolution of ICT is reshaping my own work.

Why Would Someone in IT Study “Technovate Thinking”?

I’ve spent most of my IT career on the infrastructure side — servers, networks, identity platforms, cloud architecture. That’s been my day-to-day for years.

“You’re already in IT — why take an IT course at business school?” I get asked that a lot. The answer is surprisingly straightforward.

Working in infrastructure, I’d started feeling left behind by the conversations happening around software development and DX.

Infrastructure? That’s my comfort zone. But when it came to how algorithms are designed in application development, how data flows through systems, and how all of that translates into user value — I couldn’t speak from firsthand experience. Whenever AI or data-driven topics came up, I could only respond from an infrastructure perspective. There was a gap, and I knew it.

The other reason was that I wanted a structured framework for “how business leaders should think about IT.” There’s a world of difference between having a vague sense of something and being able to articulate it clearly. I had no plans to become a professional developer, but I wanted to experience the logic of that world at least once with my own hands.

The gap between “sort of knowing” and “being able to explain” actually grows wider the longer you’ve been in IT. More years of experience don’t automatically close it — if anything, the opposite happens. You get buried in day-to-day operations, and the boundary between what you know and what you don’t becomes increasingly blurry. That sense of urgency, more than anything, is what drove me to the business school classroom.

What Exactly Is “Technovate Thinking”?

In a nutshell, the course is about learning a problem-solving approach for the Technovate era, where computers handle large-scale data processing and repetitive tasks while humans own the logical design. Students actually write programs and work toward applying these skills to real business problems.

The keyword is “division of roles.” You separate what the computer should do from what humans need to think through. It’s not about delegating everything to engineers, nor about coding everything yourself. It’s about becoming a business leader who can handle the logical design.

The course spans six sessions. The first half covers programming fundamentals and algorithmic thinking through hands-on work with Scratch. The second half explores applied technologies like AI, IoT, and no-code platforms. The final session is about solving a real problem from your own business using the tools you’ve learned. It’s designed so you don’t just sit and listen — you build things with your own hands and take the skills back to your workplace.

The textbooks are Learning Programming and Algorithm Basics with Scratch (Revised 2nd Edition) for the early sessions, and IT Skills as a Weapon: What They Teach at Business School throughout the entire course. The first book gets you building in Scratch; the second provides management-level IT literacy. A two-pronged approach.

Session 1 Takeaway: Thinking About How ICT Evolution Is Changing My Work

The pre-work for Session 1 included an assignment to think about how ICT evolution is impacting your own work. I reflected on my day-to-day reality and organized my thoughts into four key shifts.

① Shifting Business Processes — “Adapting Work to IT” Instead of the Other Way Around

Traditionally, systems were customized to fit existing business processes. Every workplace had that one person who knew the current setup inside out and could craft bespoke designs to accommodate complex requirements.

Now, the direction has reversed. For the sake of accuracy, speed, and security risk reduction, business processes are being standardized and structured to fit IT systems. In other words, business operations are being reshaped into forms that AI and automation can handle effectively. This isn’t confined to isolated pockets — the wave is spreading across entire organizations.

When you’re in the trenches, this feels obvious. But the act of writing it down reveals how much of your understanding is genuine versus merely intuitive. There’s something powerful about taking inventory of what you “thought you knew.”

② People and Organizations — From “Implementation Support” to “Co-Design”

In recent years, IT literacy on the business side has risen dramatically. It’s now common to receive sophisticated requests that reference AI and data analytics.

To meet these expectations, IT professionals need to move beyond simple “implementation support.” They need to understand the technology and propose solutions that connect it to business objectives. The demand for AI-driven optimization proposals and operational redesign is growing, and the passive “wait for requirements to come to us” model no longer works.

What strikes me most as an infrastructure professional is that this shift is no longer “someone else’s problem.” Cloud automation, Infrastructure as Code, Zero Trust architecture — none of these are just about “deploying” anymore. They require the ability to explain why a particular design was chosen and to make decisions collaboratively with business stakeholders. Technical skill alone isn’t enough. Communication alone isn’t enough. You need the ability to bridge both in your own words.

③ Redesigning Governance and Risk Management

AI adoption brings new risks. As automation reduces human involvement in execution, the challenge of ensuring accountability and explainability in decision-making grows. “We automated it, so we’re fine” doesn’t cut it. We’ve entered a phase where automation itself demands a redesign of governance.

In infrastructure operations, this has been a recurring theme for years. Automating incident response flows, tuning monitoring thresholds — these are fundamentally about designing quality assurance for “the parts where humans are no longer making decisions.” My background made this concept click easily. At the same time, I realized I hadn’t articulated how my existing experience connects to these newer challenges.

④ Client Relationships — From “Delivery” to “Co-Creation”

As DX accelerates on the business side, the role expected of IT is evolving — from “build and deliver” to “design transformation together.”

Projects where you collaborate with business teams to envision the target state and provide end-to-end support from tool adoption to operational design are becoming the norm. Co-creative team structures and the development of new capabilities are needed simultaneously. The era of siloed “infrastructure only” or “operations only” teams is fading.

What Emerged from Organizing These Four Shifts

Looking at all four together, what struck me most was that the importance of “IT that adapts to change” is overtaking “IT that maintains and protects.” I’m not dismissing defensive IT. Rather, the structural shift is this: automate and standardize the defensive layer, then redirect that freed-up time and brainpower toward adapting to change.

For someone with an infrastructure background, this is a tough question to face. The longer you’ve worked in defensive IT, the more your professional identity is tied to “keeping things running.” That value doesn’t disappear, but it’s no longer sufficient on its own. You have to confront that head-on.

And to take on that “adaptive IT” role, you need a solid understanding of technology coupled with the ability to envision, design, and communicate. That’s exactly the gap I wanted to fill by taking Technovate Thinking. I didn’t fully realize that until I finished writing these four points.

The Value of Studying IT at Business School — Putting Words to What You Feel on the Ground

Writing down what I’d vaguely sensed in my daily work crystallized it into four distinct themes. That alone was incredibly valuable. No matter how many years you spend in the field, there are countless insights that remain unformed until you commit them to paper.

The value of studying IT at business school may not lie in acquiring new knowledge per se, but rather in the practice of translating on-the-ground intuition into structured language. At least, that was my takeaway after completing Session 1.

When you’ve worked in IT for a long time, “aha moments” are everywhere in your daily work. But they accumulate as vague impressions somewhere in your brain — never shaped into something you can communicate to others. You might say in a meeting, “I think DX is fundamentally about this,” but whether your words actually land with the audience is another matter entirely.

The power of articulation bridges the gap between “thinking it” and “being able to convey it.” And that power doesn’t develop just by staying on the front lines. You need to step back, reframe your experience through a different lens, and reorganize it. The pre-work for this course was exactly that kind of opportunity.

As the course progresses, I’ll naturally pick up programming and algorithm skills. But what may matter even more is the process of redefining — in my own words — what I’ve observed throughout my career. Recognizing that in the very first session felt like a strong start.

Next Up: Building a “Book Recommendation Program” in Scratch

Session 1 came with another substantial pre-work assignment: build a program in Scratch and represent its algorithm as a flowchart.

As someone with zero development experience, I’ll share how I approached it, where I went overboard, and where I discovered that my existing skills actually served me well. That’s the story for next time.

Books Referenced in This Article

These are the two textbooks used in Session 1.

Learning Programming and Algorithm Basics with Scratch was approachable enough that even I — with no development experience — could work through it without getting stuck. In fact, after reading the entire book before tackling the assignment, I ended up building something… let’s just say “overly ambitious.” That story is coming up next.