After All Six Sessions of Technovate Thinking — The Self That Can Structure, and the Self That Lacks Logic [Technovate Thinking ⑫ Day6 Part2 — Series Finale]

This is the final installment of a 12-part series documenting what I learned from the “Technovate Thinking” course at business school.

Based on the reflection assignment I submitted for the final class, I’ll organize what changed over all six sessions, what I’ve brought back to my daily work, and how I plan to deepen my learning going forward. As the conclusion to a series I’ve been writing across 12 articles, I want to be as honest as possible.

1 Organizing My Learning: Three Pillars Took Shape
2 A Workplace Insight: Means Can Generate New Ends
3 Broadened Horizons Through Class Discussion
4 The Next Step After Scratch: Returning to Python
5 What I Learned from Writing 12 Articles
6 If I Had to Sum Up All Six Sessions in One Sentence
7 For Those Considering Taking Technovate Thinking
8 Closing Thoughts
9 Books Referenced Throughout This Series

Organizing My Learning: Three Pillars Took Shape

Looking back across all six sessions, I can see that three pillars formed within me. Let me reflect on each one alongside specific experiences from the course.

Pillar ①: The Technovate Problem-Solving Process

“Envision the desired state, design the algorithm, implement and verify/improve.” I first encountered this process as a concept in Session 1, experienced it end-to-end through the Session 4 report, and applied it to my own business in the Session 6 final assignment.

What’s important is that this is not a framework exclusively for IT professionals. It’s a framework for business leaders to think about “how to use technology.” The technological details change every year, but this process itself remains constant.

For example, in the Session 4 report assignment, I visualized an inefficient business process using a Transition Diagram and designed which steps could be replaced by technology. What I realized during that exercise was that if you cut corners at the “envision the desired state” stage, everything downstream goes off track. Rushing ahead with “let’s just use AI” without proper problem definition is exactly what it looks like when you skip this first step.

In the final assignment’s “virtue accumulation system” as well, I spent the most time on defining the problem upfront. It took multiple rewrites to refine “key person relationship management” from a vague theme into the specific problem of “a structure dependent on individual gut feel.” That experience drilled the importance of the process’s first step deep into my bones.

Pillar ②: Hands-On Experience with Programming’s Building Blocks

Variables, lists, conditionals, loops, block definitions, flowcharts. The hands-on experience I gained through Scratch has become the foundation for evaluating and selecting no-code tools and AI.

When I first encountered Scratch in Session 2, I experienced basic operations — “storing values in variables,” “branching logic with conditionals,” “repeating with loops” — by assembling blocks. The point wasn’t to learn coding itself, but to physically understand “how logic works”.

For instance, when evaluating no-code tools now, questions naturally surface: “How does this tool handle conditionals?” “Can it do loops?” “How does it manage variables?” Without the Scratch experience, these questions wouldn’t even occur to me.

On the other hand, the distinction I wrote about in the Session 2 article — between “the ability to structure” and “the ability to build logic” — the former I could leverage, the latter still needed work — only deepened through all six sessions. My years in the IT infrastructure background gave me a well-developed ability to classify, organize, and structure things, and that served me well in both Scratch and no-code environments. But the ability to “build logic from a blank slate” turned out to be less developed than I’d assumed.

In the Session 3 algorithm exercises, when asked to “design a sorting algorithm yourself,” I could understand it intellectually but my hands wouldn’t move. The ability to organize using existing frameworks and the ability to create logic from scratch are completely different muscles. That was a humbling realization.

Pillar ③: The Perspective That “User Organizations Should Proactively Design Data Structures and Algorithms”

This was the insight from the course that left the deepest impression.

Traditionally, “algorithm design” and “data structure definition” in IT adoption were considered the engineer’s job. The business side would communicate requirements, and technical design was left to the engineers — this division of labor was “common sense.”

But what data to use to capture a business problem, and what logic to use to solve it, should be designed by the person who knows the business best. The ability to do logical design at a level where you can tell engineers “what to build and how” — I came to understand, with genuine conviction, that this is the essential capability for a “business leader in the Technovate era.”

The “virtue accumulation system” from the previous article was a direct practice of this pillar. The idea of using Cialdini’s six principles as scoring axes arose precisely because I understand the substance of business relationships. If I’d simply handed an engineer the brief “build a relationship management system,” this design would never have emerged.

Another memorable moment was during a class discussion when someone from manufacturing said, “Factory quality control data structures should be designed by the veteran floor workers.” Completely different industry, same fundamental truth. The person with business context designs the data structure; engineers implement it — the class converged on this conclusion in a moment that felt electric.

A Workplace Insight: Means Can Generate New Ends

One of the insights I wrote about in my reflection was the paradigm shift: “means can generate new ends.”

Normally, problem-solving follows the sequence “end, then means.” You start with a challenge and select tools or technology to solve it. But in the Technovate context, exposure to new tools or technologies can reveal problems you hadn’t even noticed before. The means comes first and illuminates a new end.

When I built the AI Coach app in Session 5, my initial goal was “leverage my body composition data.” But through building it, I realized “output quality changes dramatically depending on prompt design,” which spawned a new learning objective: “prompt design skill.” The means updated the end.

This happens in everyday work too. Adopting a new BI tool reveals patterns in metrics you’d never paid attention to, spawning new improvement themes. Having ChatGPT summarize meeting notes exposes that the meetings themselves are poorly run. The value of “just trying it” lies not only in getting the expected solution, but in encountering questions you never anticipated.

I experienced this sensation repeatedly throughout the Technovate Thinking course. Touching Scratch made me realize “my logic-building skills are lacking.” Using Gephi taught me “network visualization is more accessible than I thought.” None of these insights were visible before I got my hands dirty.

Broadened Horizons Through Class Discussion

One surprisingly impactful element of the Technovate Thinking course was the value of class discussions.

Business school brings together people from all sorts of industries and roles. Even learning the same “Transition Diagram,” the design looks completely different when someone from IT (like me) applies it to system development state transitions versus when someone from healthcare applies it to patient treatment processes.

During the Session 4 report presentations, someone from real estate had organized “property state transitions” using a Transition Diagram — “Vacant, Viewing Scheduled, Application Submitted, Contract Signed, Move-in” — and designed how technology could streamline each transition. It was remarkable how the same framework applied to a different domain could yield such fresh perspectives.

There was also a moment when a classmate said, “Understanding something intellectually and doing it with your hands are completely different,” and the entire room nodded. Everyone had experienced the Scratch exercises where “the logic should be right, but it won’t run.” “You only discover gaps in your understanding when you get hands-on” — that was a shared epiphany for the whole class.

Exposure to these diverse perspectives is a value you simply can’t get from studying alone. If I’d been learning by myself, I might have stayed confined to “applying Technovate Thinking to IT industry problems.” Hearing how others applied the frameworks in their industries deepened my appreciation for their universality and sharpened my own understanding.

The Next Step After Scratch: Returning to Python

The clearest direction for what comes next is returning to Python.

I’ve actually attempted Python before. I bought the books, set up the environment, and made it through the first few chapters. But at the time, I had no clear sense of what I’d use it for, so I couldn’t sustain it. “I want to learn programming” as a motivation wasn’t strong enough to push through the walls.

But now things are different. Through Scratch, I’ve physically handled the foundational programming concepts — “variables,” “lists,” “conditionals,” “loops.” And most importantly, I now know exactly what I want to do with Python.

Specifically, I have three goals.

First: being able to implement the logic I design, by myself. The “virtue accumulation system” from last time went as far as design, but implementation relied on Gephi’s existing features. If I can write the scoring algorithm in Python, I’ll be able to go from design to implementation solo.

Second: automating data preprocessing and analysis. My daily work involves mountains of Excel file manipulation. Automating that with Python would directly improve my productivity. In fact, I’m already using Python scripts for running this blog (like automating WordPress posts). I want to become more fluent.

Third: integration with AI tools. Session 5 opened my eyes to the importance of prompt design, but the next level — calling APIs and programmatically processing AI output — requires Python.

Having gained a successful experience with logical thinking through Scratch, my motivation for learning Python syntax is now crystal clear. Approaching it knowing “what I’m learning this for” versus approaching it vaguely — the absorption rate is completely different. My previous “failure” was caused by unclear purpose. I can see that now.

What I Learned from Writing 12 Articles

Let me also touch on what I learned from the act of writing itself across this series.

Distilling six sessions into 12 articles turned out to be far more demanding than I’d anticipated. Attending each class, completing the assignments, then structuring and writing it all up as an article — I repeated this cycle 12 times.

But precisely because it was demanding, the returns were substantial. Just “attending” a class gets you to maybe 50% comprehension. Rewriting it in your own words brings you to 70%. Structuring it so a reader can follow takes you to 90%. Writing is, hands down, the most powerful form of output-based learning.

I struggled especially when writing the Session 3 article on algorithms. Concepts I thought I understood turned out to have fuzzy spots when I tried to put them into sentences. “Wait, I can’t actually explain this part clearly” — those moments happened again and again. That’s exactly what it means for writing to expose gaps in your understanding.

There’s another benefit: by writing consistently throughout the series, I now have a documented record of my own growth. Comparing the first article to this twelfth one, the depth of my understanding of Technovate Thinking is visibly different. What started as a vague grasp of “technology-driven problem-solving” has evolved into a concrete thesis: “Business leaders need to own data structure and algorithm design.” Having this evolution captured in writing is a personal asset.

If I Had to Sum Up All Six Sessions in One Sentence

If I had to distill all six sessions of Technovate Thinking into a single takeaway —

I discovered both “the self that can structure” and “the self that lacks logic.”

The structuring ability I’d built over years of IT experience held up in Scratch and no-code environments alike. Decomposing problems, organizing them, mapping them onto frameworks — that skill didn’t let me down.

But the ability to build logic from scratch was less developed than I’d assumed. Translating “I want this process” into “execute these steps in this order” — that’s a different muscle from structuring, and it needs to be trained through Scratch basics first and then seriously developed with Python.

Gaining this self-awareness was itself the greatest harvest of all six sessions. When you know your strengths and weaknesses, what to learn next becomes obvious. And that “what to learn next” — Python implementation, data structure design, prompt engineering — I now have genuine motivation to pursue.

For Those Considering Taking Technovate Thinking

Finally, for anyone considering a similar course, here’s my honest take.

Technovate Thinking is not a course that trains programmers. It’s a course that builds the ability to understand “what technology can do” and design “how to apply it to your own business.”

For those with an IT infrastructure background, it’s an experience that shatters your “I already know this” assumptions. You have the technical knowledge, sure. But the ability to translate business problems into the language of technology — designing data structures, setting algorithmic direction, and communicating that to engineers and executives — is an entirely separate skill.

For those without a tech background, it’s likely to be an experience that makes you feel “technology isn’t scary.” You’ll touch programming fundamentals through Scratch, build things with free tools, and come away with the confidence that “I can actually do this much on my own.”

Regardless of your background, you’ll gain from both “getting hands-on” and “debating with classmates.” It’s a kind of learning you simply can’t get from reading a book alone.

One thing to brace yourself for, though: the pre-session assignments are substantial. Classes are biweekly, but the assignments require real time commitment. That said, that “weight” translates directly into “depth of learning.” Hands-on work takes you to places that intellectual understanding alone never could.

Closing Thoughts

Thank you for following along through all 12 installments of this series.

What I learned in Technovate Thinking doesn’t end with this article. Armed with the “structuring ability” and the “awareness that my logic skills need work” I gained here, I’m moving on to the next phase of learning. Returning to Python, practicing data structure design, going deeper on prompt engineering. There’s no shortage of things I want to tackle.

“Knowing what to learn next” — that, in itself, is the greatest outcome of learning.