Small Groups, Big Impact: Why We Never Teach More Than 6

Every academy in Seoul will tell you their classes are “small.” It’s right there in the brochure, sandwiched between the stock photos of smiling children and the bullet points about future career readiness. Small classes. Personalized attention. Individual learning pace.

I know, because I’ve read those brochures. Most of them define “small” as fifteen students. Some stretch it to twenty. A few brave ones go as high as twenty-five and still use the word.

At C.Lab Academy, our maximum is six. Usually four or five. And I want to explain why — not as a sales pitch, but because I genuinely believe this is one of the most important decisions we’ve made, and it comes with real tradeoffs that I think parents deserve to hear about honestly.

What I Learned from Large Groups

Before I started C.Lab, I taught technology at a school in Seoul. I had classes of various sizes — sometimes twelve students, sometimes more. I loved the work. The students were fantastic. But I noticed something that bothered me, and it took a while to put into words.

In a class of fifteen kids learning to code, at any given moment, roughly a third of them are stuck. Not stuck in a dramatic, hand-raising way. Stuck in a quiet, staring-at-the-screen way. They’ve hit a bug, or they don’t understand the instruction, or they’ve lost track of where they are in the project. And they’re not asking for help.

Kids — especially kids between eight and fourteen — often won’t tell you they’re lost. Some are embarrassed. Some don’t want to slow down the class. Some aren’t even sure what their question is yet. They just know something isn’t working, and they’re hoping that if they stare at it long enough, it’ll fix itself.

In a group of fifteen, I couldn’t catch all of those moments. I’d be helping one student debug a loop while three others were silently stuck on something completely different. By the time I got to them, they’d been sitting in confusion for ten, fifteen minutes. That’s an eternity when you’re nine years old.

The students who were naturally confident or quick learners did great. They raised their hands, got my attention, and moved forward. The quieter ones — the ones who often needed the most support — fell behind. Not because they couldn’t learn, but because the environment didn’t give them the space to learn at their pace.

That pattern troubled me. And it’s a big part of why C.Lab exists.

What Changes at Six

Here’s what actually happens when you limit a class to six students. These aren’t theoretical benefits from a pedagogical textbook. These are things I observe every single week.

You See the Stuck Moments Before They Compound

With six students, I can scan the room and know, within seconds, who’s flowing and who’s hit a wall. The signs are subtle — a kid who stops typing, a furrowed brow, a sudden shift from engaged posture to slumped shoulders. In a large class, these signals disappear into the noise. In a small group, they’re impossible to miss.

This matters enormously in coding. A small misunderstanding in minute five can become a cascading disaster by minute twenty if no one catches it. A missing bracket, a misspelled variable, a logic error that makes the whole program behave in a way the child doesn’t expect. When I catch it early, we fix it together in thirty seconds and the child keeps building. When I catch it late, the child has spent twenty minutes frustrated and convinced they’re “bad at coding.”

Every Child Gets Known

After two or three sessions with a group, I know each child’s patterns. This one learns by watching first and trying second. That one jumps straight in and figures it out through trial and error. This one needs verbal encouragement. That one prefers to be left alone until they ask for help.

With fifteen students, I can learn names and general tendencies. With six, I know how each child thinks. And that knowledge changes everything about how I teach.

When Yuna gets stuck, I know she needs me to ask a question that guides her to the answer, not give her the answer directly. When Thomas gets stuck, I know he needs to see a working example, take it apart, and rebuild it. When Jihoon gets stuck, I know he just needs someone to say, “You’re closer than you think,” and he’ll push through on his own.

This isn’t magic. It’s just attention — the kind that’s impossible to give when your attention is split fifteen ways.

Collaboration Happens Naturally

Something I didn’t expect when I started teaching small groups: the kids help each other. Not because I tell them to. Because when there are only four or five of you around a table, you naturally see what the person next to you is doing. You lean over. You say, “Oh, I had that same problem — try this.” You share discoveries.

In large classes, collaboration has to be structured and assigned. In small groups, it emerges on its own. And the collaboration that emerges organically is more genuine and more effective than anything I could orchestrate.

I’ve watched a twelve-year-old patiently explain variables to a ten-year-old in simpler terms than I would have used — because the twelve-year-old understood the ten-year-old’s confusion in a way that only someone who just went through it can. That peer-to-peer teaching is incredibly powerful, and it happens because the group is small enough for kids to actually connect.

The Pace Belongs to the Students

In a large class, the instructor sets the pace. They have to. With fifteen students at different levels, you teach to the middle and hope the outliers can adjust. The fast learners get bored. The slower ones get lost.

With six students, I can let the pace breathe. If everyone is absorbed in their project and making progress, I don’t interrupt with the next lesson — I let them keep building. If someone is struggling with a concept, I can spend five extra minutes with them without abandoning the rest of the group. The class shapes itself around the students, not the other way around.

This flexibility is especially important in coding, where progress isn’t linear. A child might breeze through three concepts in twenty minutes and then spend forty minutes on one bug. That’s normal. That’s how problem-solving works. But it only works if the environment allows for it.

The Honest Tradeoff

I want to be upfront about something, because I think parents respect honesty more than marketing.

Six students per class means C.Lab is more expensive per session than a large academy. That’s the tradeoff. We can’t spread the cost of an instructor across twenty students. We spread it across six. The math is simple and the result is a higher price point.

I’ve thought about this a lot. I’ve considered whether I could grow classes to ten or twelve and still maintain quality. And the honest answer is: I don’t think so. Not for coding.

Coding isn’t like learning a foreign language or studying for a math exam, where a good lecturer can effectively address a room of twenty. Coding is hands-on, individual, and full of moments where a child needs specific, personalized help right now — not in ten minutes when the instructor finishes with someone else.

Every time I’ve seen class sizes creep above six, the quality of the experience drops. Not dramatically. Not in a way that most people would notice. But I notice. I see the quiet kid in the corner who stopped trying. I see the fast learner who finished early and is now bored. I see the moments I missed because I was stretched too thin.

So we stay at six. It’s a deliberate choice, and it means C.Lab won’t be the cheapest option in Seoul. But I’d rather teach fewer students well than more students adequately.

What a Typical Class Looks Like

Since I’m asking you to trust me on all of this, let me show you what it actually looks like in practice.

A typical C.Lab session runs sixty to ninety minutes, depending on the age group. Students arrive, settle in, and I spend the first five minutes checking in — not about code, but about their week. This isn’t filler. It’s how I know what kind of energy each child is bringing to the table today.

Then we start. Sometimes there’s a new concept to introduce — a new Scratch block, a new JavaScript method, a new design technique. I explain it briefly, show one example, and then the kids start experimenting. From that point on, I’m moving around the table, watching screens, asking questions, offering nudges.

The room is usually a mix of focused silence and excited chatter. One student is deep in concentration, headphones on, building. Another is excitedly showing their neighbor something they just figured out. A third is staring at an error message, and I’m already pulling up a chair beside them.

At the end of the session, we take a few minutes for each student to share what they built or what they’re working on. This isn’t a presentation — it’s informal, low-pressure. But it gives every child a moment to be seen and to see what others are creating.

That last part matters more than you might think. When a child shares something they made with a small group of peers who actually know them, the response is genuine. Not polite applause from twenty strangers, but real interest from four friends who watched the thing get built.

Why This Matters for Coding Specifically

You might be wondering: does class size really matter this much for coding? Couldn’t you achieve similar results in a group of ten?

Here’s why I think coding specifically demands very small groups.

Code breaks in individual ways. When twenty students follow the same tutorial, they will produce twenty different bugs. Each bug requires specific diagnosis. There’s no generic fix you can announce to the room. “Check your semicolons” helps no one when the actual problem is a scope issue in one student’s code and a typo in another’s.

Debugging is where the real learning happens. Writing code is the easy part. Finding and fixing bugs is where children develop problem-solving skills, patience, and logical thinking. But debugging is also where frustration lives. A child who’s stuck on a bug for too long without help doesn’t learn persistence — they learn that coding is painful. The instructor needs to be close enough to intervene at the right moment: not too early (let them struggle productively) and not too late (before the frustration becomes discouragement).

Getting that timing right requires knowing the child. And knowing the child requires a small group.

An Invitation, Not a Pitch

If you’re comparing options for your child’s coding education in Seoul, I’d encourage you to ask one question of any academy you’re considering: How many students are in each class, and how does the instructor handle the moment when a child gets stuck?

The answer will tell you a lot about their teaching philosophy.

At C.Lab Academy, you’re welcome to sit in on a trial session and see our approach for yourself. Watch how the instructor interacts with each child. Count the students. Notice who’s engaged and who’s drifting. That will tell you more than any brochure ever could.

---

C.Lab Academy offers coding and digital art programs for kids aged 3 to 16 in Seoul. Classes are taught in French and English, with a maximum of six students per group.