If I were building this team today, knowing what AI can do now, what would it look like?

I've been hearing versions of this question from almost every CEO in our portfolio. And I think it's the right question at the right time.

What Zero-Based Engineering Means

In finance, zero-based budgeting means you don't start from last year's budget and adjust. You start from zero and justify every dollar. No line item gets a free pass just because it existed before.

Apply that to your engineering team.

Don't start from your current headcount and ask "who can I cut?" Start from zero and ask "what do I actually need built, maintained, and operated, and what's the best way to do each of those things today?"

The answer in 2024 would have been very different from the answer today. AI coding tools have gone from cute autocomplete to genuine capability. Not for everything. But for enough that the math has changed.

The Maintenance vs. Creation Distinction

Here's the nuance most people miss: AI is much better at maintaining existing code than most people think, and less reliable at building complex new systems than the hype suggests.

Maintaining a codebase (fixing bugs, writing tests, updating dependencies, refactoring for performance, adding straightforward features to established patterns) is where AI tools are already shockingly competent. An engineer paired with Claude Code or Cursor can maintain a codebase at a pace that would have required a team of three eighteen months ago.

But there's an important caveat. A recent benchmark called SWE-CI, out of Alibaba Research, tested something most AI benchmarks don't: what happens when an AI agent has to maintain a system over time. Not just write code once, but repeatedly modify a real codebase across dozens of commits spanning months of evolution. The results were sobering. Even the best-performing models broke existing behavior in roughly half of their maintenance iterations.

The failure modes tell you a lot about where the limits actually are. Agents apply minimal fixes to a failing test without understanding broader dependencies, causing cascading regressions. They change a function signature but don't update callers across the codebase. Over many iterations, they accumulate duplicated logic and inconsistent abstractions. They treat tests as constraints to bypass rather than signals about how the system is supposed to work.

In other words: AI agents can generate technical debt just as fast as they generate code.

This doesn't mean AI can't maintain systems. It means the kind of maintenance matters. AI is excellent at well-scoped, pattern-following work within clean codebases. It struggles with the kind of long-horizon stewardship that requires understanding dependencies, preserving architectural intent, and predicting the ripple effects of changes.

Building new systems from scratch, making judgment calls about tradeoffs, understanding the business context behind technical decisions: this still requires experienced humans. AI makes them faster, not optional.

The implication: you probably need fewer maintenance engineers and more architect-level thinkers than you currently have. But the architects aren't just designing new things. They're the ones who understand the system well enough to direct AI effectively and catch the failure modes that don't show up in test suites until it's too late. The ratio has shifted, but the senior end of the ratio matters more than ever.

What Does the Team Look Like?

If I were building a startup engineering team from zero today, here's roughly how I'd think about it:

1-2 senior engineers who think in systems. These are your architects. They make the hard calls: what to build, how to structure it, where the complexity lives. They use AI tools aggressively but their value is judgment, not keystrokes. They're also the ones who can spot when AI-generated changes are introducing the kind of slow architectural erosion that doesn't show up in test suites until it's too late.

AI-augmented "full stack operators." Engineers who are comfortable using AI to move fast across the stack. They're not specialists in one layer. They're generalists who can ship end-to-end with AI doing the heavy lifting on boilerplate. One of these people today can cover ground that used to require a frontend dev, a backend dev, and a QA engineer.

A DevOps/infra person (maybe). Depending on your stack. If you're on Vercel/Railway/managed everything, you might not need this. If you're running your own infrastructure, you still do. AI hasn't automated "3am the database is on fire" yet.

Product-minded leadership. The more AI handles the how, the more important it is to have humans focused on the what and why. Product sense becomes your scarcest resource, not engineering capacity.

What you probably don't need: large teams of mid-level engineers writing CRUD endpoints, manual QA teams, or dedicated frontend/backend splits for standard product work.

You're Not Just Rebuilding the Team. You're Rebuilding the Product.

There's a second zero-based question most founders aren't asking yet, but should be:

If I were designing this product today, who would be using it?

Not just who. What.

The first generation of software was built for humans clicking buttons. The next generation is being built for AI agents making API calls. And the gap between those two is bigger than most people realize.

Think about what's already happening. AI agents are booking travel, managing inboxes, writing code, doing research, placing orders. They don't need beautiful UI. They need clean APIs, structured data, predictable behavior, and good documentation. The "user" increasingly isn't a person. It's software acting on a person's behalf.

This changes what you build and how you build it.

Your product needs to be findable and usable by agents, not just humans. Well-documented, with predictable error handling and sensible defaults. Tool-use schemas and structured outputs aren't nice-to-haves anymore. They're how your product gets chosen by the AI layer sitting between you and the end user.

You also need two kinds of UX now. One for humans, one for agents. Humans want intuitive flows. Agents want predictable contracts. Building both well requires a different kind of product thinking than most teams have today.

And distribution changes too. If agents are choosing tools on behalf of users, your moat isn't brand awareness or ad spend. It's being the tool the agent picks. Reliability, speed, and being easy for an AI to work with matter more than your landing page.

So what does this mean for the team?

You need people who understand how AI agents consume software, not just how humans do. Product people who think about what the agent experience looks like. Engineers who design for machine callers first. People who are building the connective tissue between your product and the agentic ecosystem, not just shipping features for a dashboard.

This is the deeper version of the zero-based question. It's not just "what team do I need to build what I'm building?" It's "am I even building the right thing for the world that's emerging?"

How Do You Manage the Risk?

This is the part most founders get stuck on. "Okay, I believe the team could be smaller. But how do I get from here to there without breaking everything?"

Three approaches I'm seeing:

Component-by-component refactor. Take your existing codebase and, module by module, assess: can AI reliably maintain this? Is the code well-structured enough that an AI tool can work with it? If yes, you've reduced the human maintenance burden for that component. If no, refactor it until it is. That's a one-time engineering investment that pays dividends.

This is the conservative approach. Lower risk, slower payoff. Good if your product is in-market with paying customers and you can't afford instability.

Parallel "red team" rebuild. Stand up a small team (or even one senior engineer with AI tools) to rebuild a component or service from scratch in parallel. Compare quality, speed, and maintainability against the existing system. If the rebuild wins, swap it in. If not, you've learned something about where the boundaries of AI-assisted development actually are for your specific stack.

This is the aggressive approach. Higher risk, faster learning. Good if you have components that are already technical debt and need to be rewritten anyway.

The hybrid. Refactor the stable, well-understood parts. Rebuild the parts that are already a mess. Most teams should do this.

The Stability Question

One thing I keep hearing from CTOs: "But can I trust AI to maintain my codebase long-term?"

The honest answer is: it depends on your codebase.

If your code is well-typed, well-tested, modular, and follows consistent patterns, AI tools are remarkably good at working with it. They can read the patterns, follow the conventions, and extend the system coherently. The SWE-CI data backs this up: AI agents perform best in codebases with clear structure and comprehensive test coverage. The failures cluster in the messy parts, where high-churn files with accumulated complexity are exactly where cascading regressions concentrate.

If your code is a tangled monolith with no tests, implicit dependencies everywhere, and tribal knowledge locked in the heads of engineers who've since left, AI will struggle with it just like a new hire would. Except the new hire might eventually figure it out through sheer determination, while the AI will confidently produce something that looks right and isn't.

This means investing in code quality isn't just good practice anymore. It's a prerequisite for being able to run a lean team. The teams that can reduce headcount are the ones whose code is clean enough for AI to work with. Technical debt has become a hiring cost.

What I'd Tell a Founder Right Now

If you're a Series A or B company with 8-15 engineers and you haven't done this exercise, do it this quarter. Not because you need to fire people. Maybe you don't. But because you need to know:

• Which parts of your system can AI reliably maintain today?

• Which parts need human judgment and how much?

• Where is your team's time actually going: new features, maintenance, firefighting?

• If you were hiring from zero, would you hire the same roles?

The companies that figure this out early will operate at 2-3x the efficiency of those that don't. And in a market where efficiency is the new growth, that's a real competitive advantage.

This isn't about replacing engineers with AI. It's about being honest about what the job actually requires now, and building a team that reflects that reality instead of last year's.

If you're a founder thinking about this and want to compare notes, I'm collecting frameworks and examples from across our portfolio. Reach out.

But here's the thing: negativity is self-fulfilling in innovation ecosystems.

Innovation requires the suspension of disbelief. Someone has to look at a two-person team with a half-built product and say "I think this could be something." That's the spark. Without it, the cycle doesn't start.

And in a risk-averse environment like Singapore and Southeast Asia — where the cultural default is already caution — the cost of collective negativity is even higher. When the prevailing narrative is "it's a bad time to start," people don't start. Talented engineers stay at Google. Ambitious MBAs go into banking. Second-time founders sit on the sidelines and wait. The pipeline doesn't shrink — it never fills.

That's the real doom loop. It's not that companies build smaller. It's that the companies never get built at all. The best founders, the ones who would have taken the leap, read the room and decide it's not worth the risk. And then five years later we wonder why there aren't enough breakout companies.

This is a talent problem disguised as a sentiment problem. Singapore has spent decades building itself into a global hub — attracting the best engineers, operators, and entrepreneurs from across Asia. That's working. But the moment the narrative shifts to "this ecosystem doesn't produce winners," the calculus changes. Why would a top AI researcher leave San Francisco for Singapore if the story she hears is that the ecosystem is broken? Why would a second-time founder from Jakarta choose to build here instead of closer to US capital? Every cycle of pessimism sets the timeline back — not by quarters, but by years. Because talent pipelines take years to build and months to lose.

Silicon Valley's magic was never the weather or the capital or Stanford. It's the pervasive, almost irrational belief that surrounds you. It's an ambition factory. You show up and everyone around you is trying to build something enormous — and that makes you believe you can too. The belief is the infrastructure. It's what makes a first-time founder look at an impossible problem and think "why not me?"

That's not an accident. It was built over decades by people who chose optimism even when the data was mixed. The early days of the Valley had plenty of failures and false starts. What it had that we sometimes lack was the collective refusal to let the failures define the narrative.

Singapore and Southeast Asia don't need to copy Silicon Valley. We have our own strengths and our own path. But we need to learn that lesson: the story you tell about your ecosystem becomes the ecosystem you get.

I'm not arguing for delusion. I'm not arguing for fake-it-till-you-make-it accounting fraud. I'm arguing for actual belief in human endeavor — the kind that looks at real strengths and says "we can build on this."

And there's plenty to believe in:

• Human capital — Singapore's technical training pipeline is world-class. The region is producing better engineers, product people, and operators than it ever has.

• Capital availability — There is more capital available in SEA than at any point in history. Yes, it's more selective now. That's not a bad thing.

• Ecosystem maturity — We have experienced founders on their second and third companies. We have operators who've scaled to $100M+ revenue. That didn't exist ten years ago.

• The talent magnet is working — Singapore is attracting global talent in AI, fintech, and deep tech. That's not a given — it's the result of deliberate policy and real quality of life. Don't take it for granted by telling those people they've come to a dead-end market.

• Regional tailwinds — 700 million people, fastest-growing digital economies in the world, young populations going online-first. The structural opportunity hasn't changed because some portfolio companies got marked down.

The question isn't whether the ecosystem has problems. It does. The question is whether we talk about those problems in a way that attracts the people who will solve them — or in a way that sends them somewhere else.

Belief is contagious. So is cynicism. We get to choose which one we spread.

In practice, they butcher it.

Unless your name is Mike. Mike collects his flat white with the quiet confidence of a man whose name has never been misspelled. The system was built for Mike.

My name is Shiyan. Two syllables. Not complicated — unless you've never seen it, which is everyone at every Starbucks everywhere. I've been Shyan. Shayn. Cyan. Shi-Anne. Once, memorably, Sean.

Dale Carnegie understood something Starbucks didn't: a person's name is the most important word in the world to them. That's why you use it — it says "I see you."

But getting it wrong? Repeatedly? In public? That says "I see someone who is vaguely you but not quite." Which is worse than not trying.

So I became 47.

The barista doesn't flinch. Doesn't ask me to spell it. Just writes it and moves on. "47!" — and I collect my coffee with zero psychic damage.

It's faster too. No spelling. No "sorry, one more time?" No three-attempt back-and-forth while the line grows. Two digits. Done.

Starbucks should have done this from the start. Numbers. Coffee comes out faster. Nobody gets their identity bruised at 8am. The baristas don't have to pronounce Siobhan.

Unless your name is Mike. Mike, you're fine. The rest of us will be over here, properly caffeinated and psychically intact.

The deck is the easy part. Market size, traction, team slide — every founder knows the beats. But the most useful information in a pitch meeting has nothing to do with what's on the slides. It's in what happens between the founders when things get uncomfortable.

The Pitch Is a Performance. The Q&A Is the Truth.

Founders rehearse their pitch. They should. But the rehearsed version is the highlight reel. The real signal comes when I ask a hard question and watch what happens next.

Not what they say. What they do.

Who answers first? Does one founder always jump in, or do they naturally divide based on expertise? When I push back on an assumption, does the CEO get defensive or curious? Does the technical cofounder sit quietly the whole time, or does she come alive when we get into the details?

These micro-moments tell me more about the health of a founding team than any reference check.

The Cofounder Who Talks Over the Other

This is the one I watch for most carefully, because it's the most common and the most revealing.

Here's what it looks like: I ask a question. Cofounder B starts answering. Cofounder A jumps in three seconds later — not to add, but to redirect. Sometimes it's subtle: a slight lean forward, a "well, what she means is..." Other times it's not subtle at all.

What I'm reading: Does Cofounder A not trust B to represent the company? Is there a disagreement they haven't resolved, and A is afraid B will say the wrong thing? Or is A just nervous and over-indexing on control?

None of these are automatic disqualifiers. But they tell me something about how this team makes decisions when I'm not in the room.

The best founding teams I've seen have an almost effortless handoff. One finishes, the other picks up. They know each other's strengths and they trust each other to speak. That trust is visible. So is its absence. When one founder says something slightly wrong, does the other flinch — or let it go because they trust their cofounder to course-correct? When I ask a tough question, do they look at each other for reassurance, or does one look to the other for permission to speak? Different dynamics entirely.

How They Handle "I Don't Know"

I asked a founder last month about their churn rate in a segment they'd just entered. She paused, looked at her cofounder, and said: "Honestly, we're eight weeks in. We have early signals but I'd be making up a number if I gave you one. Here's what we're tracking and when we'll have real data."

I leaned in harder after that answer than I had during the entire pitch. Not because the answer was impressive — but because it told me something about how she'd operate when things got hard. She'd call me with the bad news, not just the good.

Contrast that with the founders who give a confident-sounding non-answer, hoping I won't notice. Or worse, invent a number. I almost always know when someone is bullshitting a metric — and even if I don't catch the specific lie, the instinct to perform certainty instead of demonstrating honesty is its own signal.

Founders who can say "I don't know" in a pitch meeting — where the stakes feel enormous — are almost always the ones worth backing.

The Response to a Challenge

I almost always push back on something during a pitch. Not to be adversarial — but because I want to see how the founders engage with disagreement.

Some founders get defensive. Arms cross. Voice tightens. They're not hearing me — they're preparing their rebuttal while I'm still talking. Others get curious: "Interesting — what makes you say that?" They lean in. They might still disagree, but they engage with the substance.

Then there's performative agreement. "That's a great point!" followed by zero incorporation of the feedback. It feels positive in the moment, but it tells me they'll say whatever they think I want to hear. And if they do that with me, they'll do it with customers, with hires, with their board.

The founders I want to back can hold their conviction and genuinely engage with a counterargument. That's rare.

The Interpretation Problem

Here's the uncomfortable truth about everything I just wrote: I could be wrong.

Is he confident or arrogant? Does she talk too much, or is she just excited? Is that silence discomfort or thoughtfulness? Is he dominating the conversation or is he just Italian?

Reading people is not a science. It's pattern matching filtered through my own biases — cultural, personality, experiential. A founder who makes intense eye contact might read as "passionate and convicted" to one investor and "aggressive and hard to work with" to another. A quiet cofounder might be deferential, or she might be the one who actually runs the company and doesn't feel the need to perform.

I try to hold my reads loosely. First impressions are data, not verdicts. When something feels off, I name it — sometimes in the meeting, sometimes in a follow-up. "I noticed X — can you tell me more about how you two work together?" The answer matters less than whether they're willing to engage with the question honestly.

The founders who worry me aren't the ones who send ambiguous signals. It's the ones where every signal points the same way and they can't see it themselves.

What I'm Actually Looking For

I'm not looking for perfection. I'm not looking for founders who agree on everything. Some of the best pitches I've seen involved cofounders openly disagreeing in front of me — but doing it with respect and genuine curiosity about each other's perspective.

Trust. Not "we've been friends since college" trust — but "I trust you to represent our company accurately even when I'm not talking" trust.

Complementarity. Are they actually better together than apart? Or is one person clearly the founder and the other along for the ride?

Self-awareness. Do they know what they don't know? Can they talk honestly about their weaknesses without it feeling rehearsed?

Resilience under pressure. When I push, do they crumble, posture, or engage? Because I'm a friendly investor in a conference room. Customers, competitors, and crises will be much less polite.

The pitch meeting is just a window. The best ones don't feel like pitches at all — they feel like two sides genuinely trying to figure something out together. That energy is hard to fake. And when you feel it, you remember it.

Every parent I know is asking some version of the same question: what should we actually be teaching our kids now that AI can do... most things?

It's not a theoretical question for me. I have three kids. The oldest is nine. By the time she enters the workforce, the landscape will be unrecognizable. So what do I optimize for?

Not coding. AI writes code better than most humans already. Not memorization. AI has perfect recall. Not even "STEM" as a blanket answer — because the rote parts of STEM are exactly what gets automated first.

Here's what I keep coming back to.

Persuasion. AI can generate a perfect pitch deck. It cannot look across the table and feel that someone's afraid. The most persuasive people I've met aren't the ones with the best arguments — they're the ones who sense what someone needs to hear before they know it themselves. That's not logic. It's attunement. Reading the room, feeling the tension, knowing when to push and when to sit in silence. Persuasion that actually moves people starts with emotional awareness — understanding where someone is before trying to take them somewhere else. AI will make everyone's arguments sharper. The edge will belong to people who know how to make others feel understood.

Collaboration. AI is a solo force multiplier. But the hardest problems aren't technical — they're human. A team falling apart because two people won't say what's actually bothering them. A project stalling because someone feels unheard and has checked out. Collaboration isn't project management. It's emotional labor. It's noticing when someone's energy shifts in a meeting. It's having the conversation nobody wants to have. It's holding space for disagreement without letting it curdle into resentment. Kids who learn to sit with discomfort — their own and other people's — will be able to do things AI never will.

Curiosity. The kids who thrive won't be the ones who were forced to learn. They'll be the ones who wanted to. Curiosity is the engine. Without it, AI is a toy. With it, AI is a superpower. A curious kid with access to AI can teach themselves almost anything. An incurious kid with the same access will use it to cheat on homework.

The belief you can learn anything. This might matter most. Not "you're smart" — that's fragile. But "you can figure this out if you're willing to put in the work." The rate of change means constant relearning. Kids who believe they can adapt will. Kids who've been told they're either gifted or not will freeze.

Agency. The willingness to act without being told. To see a problem and start solving it. AI lowers every barrier to building — but someone still has to decide to build. Agency is the difference between a kid who consumes and a kid who creates.

So where does school fit?

School still matters. You need foundational knowledge. You can't think critically about nothing — you need facts, frameworks, context to reason with. Reading, writing, math, science — these aren't obsolete. They're the substrate everything else runs on.

The question isn't whether school matters. It's whether school as currently designed builds or breaks the skills that matter most.

Because here's the tension: school is great at building foundational knowledge. School is also great at crushing curiosity, agency, and self-belief.

Standardized tests reward compliance, not curiosity. Grades reward right answers, not interesting questions. The kid who asks "why?" too many times gets labeled difficult. The kid who colors inside the lines gets praised.

How do you build knowledge without killing the drive to use it?

Some stress is good. But how much?

This is the part I wrestle with most.

Kids need challenge. Struggle builds resilience, grit, the belief that hard things are possible. A kid who's never uncomfortable never grows. Shielding them from difficulty isn't kindness — it's deprivation.

But there's a line. Too much pressure doesn't build resilience. It builds anxiety, avoidance, learned helplessness. And the line is different for every kid — which makes it impossible to systematize, which is exactly what school tries to do.

The right amount of stress: enough that they stretch, not so much that they break. Enough that they fail sometimes and discover they can recover. That's where growth lives.

I don't have answers. I have experiments.

Expose them to hard things early, with support. Celebrate effort and process, not just outcomes. Let them use AI as a tool, but make sure they understand what's happening underneath. And above all — protect curiosity. A curious kid with foundational knowledge and agency will figure out the rest.

The skills that matter in the AI age aren't new. Persuasion, collaboration, curiosity, agency, the belief you can learn anything — these have always mattered.

What's new is that everything else is getting automated.

These aren't soft skills anymore. They're the only skills.

Everyone keeps saying writing code is dead. They're not wrong — but not quite right either.

What's dead is the value of typing code. AI writes functions faster than I can describe what I want. It has more patterns in memory than any engineer could accumulate in a career.

What's alive — more than ever — is knowing what to build and why.

The Meta Engineer

There's a new archetype emerging. I've been calling it the meta engineer.

Not the person who writes the best code. The person with taste.

AI generates clean, functional code at absurd speed. But ask it to decide which modules to build, how they talk to each other, what to leave out — it stumbles. It optimizes locally. It doesn't see the whole board.

The meta engineer looks at what AI produced and says "no, not like that." They know that just because you can build something doesn't mean you should.

Taste is making good decisions with incomplete information. Pattern recognition plus judgment plus restraint.

Will AI Get There?

Honest question I keep asking: will models develop taste too?

Right now they write perfect functions but can't answer "should this function exist at all?" They'll build you an elegant solution to a problem you shouldn't be solving.

The gap might close. But taste is downstream of values, context, and lived experience. It's shaped by watching systems fail in production. By shipping too early and feeling the pain. By choosing simplicity when every instinct says add more. That's harder to replicate than pattern matching.

And even if models get there — someone still decides what "good" means for this product, this user, this moment. That's not a technical problem.

Taste and Agency Are Rarer Than You Think

Most engineers don't have strong taste. They build what they're told. They'll implement the spec even when the spec is wrong.

Most people with taste don't have agency. They see the problems but can't act — wrong role, wrong seniority, wrong culture.

The combination is rare. And becoming more valuable, not less.

I saw this with a 19-year-old intern at a portfolio company. He doesn't write code the traditional way. He spends hours exploring tradeoffs with AI as his sparring partner — generates five approaches, evaluates each one, picks the best fit or rejects them all and reframes the problem.

He's not grinding LeetCode. He's developing intuition. His architectural instincts are sharper than some senior engineers I've worked with. He can't always explain why something feels right, but he can feel it. That's taste in formation.

The Taste Paradox

This is where it gets personal.

How do you develop taste if you don't write code yourself? Chefs taste thousands of dishes. Writers read thousands of books. You need deep exposure to the medium — but do you need to produce in it?

Can a so-called non-technical person develop technical architecture taste?

Let's find out. Because that's me.

I don't have a CS degree. But I'm actively building — making architecture decisions, evaluating tradeoffs, shipping real code with AI as my co-pilot. Not as a tourist, but as someone who lives with the consequences.

What I've learned: taste isn't about syntax. It's about structure, simplicity, and knowing what to cut. It's the instinct to ask "do we actually need this?" before building it.

But there's a floor. You need enough technical literacy to evaluate what AI produces. You can't edit a novel if you've never read one.

Can a non-technical person develop real technical taste? The answer isn't yes or no yet. It's: keep building and find out.

The Skill Shifted

Writing code is dead the way typing manuscripts is dead. The physical act got automated. The thinking behind it matters more than ever.

The meta engineer isn't a worse version of an engineer. They're a different kind — and an increasingly essential one.

The question isn't whether AI will replace engineers. It's whether you'll develop the taste to direct it.

The moment that happens, something's already broken. A good group chat runs on collegiality — people sharing what they've learned, building on each other's thinking, assuming good intent. Nobody's pulling rank because nobody needs to. The ideas speak for themselves.

But get the dynamics wrong, and you end up in a place where people are defending their right to have an opinion instead of actually exchanging them. The magic is gone, and it's very hard to get back.

I've been in a lot of group chats — mostly on WhatsApp — and the gap between the great ones and the terrible ones is enormous. It comes down to three things: who's in the room, who set the tone, and whether people are advancing the conversation or just occupying space in it.

Composition is casting

A group chat is like casting a movie. Every person you add changes the dynamic.

The best groups I've been in share a specific context. Not "people who are generally interesting" — people working on the same thing right now.

Take the Claude Code groups I'm in. The ones that work aren't "AI enthusiasts." They're people actively building with the same tool, hitting the same walls, at roughly the same skill level. Someone posts a problem, three people recognize it because they hit it last Tuesday.

The ones that don't work split between people who joined "to learn" and deep practitioners. Neither group gets what they need.

This doesn't mean small is always better. A 200-person group can work — but the shared context has to be sharper to compensate for the size.

You built it. You own it.

If you created the group, you're the culture setter. The first week is wet concrete.

Model what you want. If you want high-signal posts, your first ten messages better be high-signal. People don't read rules. They read the room.

Be opinionated early. The instinct is to be welcoming — "share whatever!" — but that's how you get noise. This group is for X. We talk about Y. When you share something, include Z. People don't resent opinionated norms. They're relieved by them. Walking into a group with clear expectations is easier than guessing what's appropriate.

Onboard into the culture, not just the group. When someone new joins a group that's been running for months, they see a wall of messages and have to guess. A quick DM — "here's what this group is about, here's how we use it" — takes 30 seconds and prevents weeks of drift.

Prune. Sometimes the dynamic shifts because of one or two people who don't match the culture. Your job is to address it — privately, directly, kindly. Most people won't, which is why most large groups eventually degrade.

Large groups: more surface area, more risk

Small groups are forgiving. In a 100+ person chat, one tangent buries an important thread under 60 messages in twenty minutes.

Lurkers being the majority is fine — it's the model. A large group is part conversation, part ambient knowledge feed. But one loud voice has outsized impact. In a 6-person chat, someone who responds to everything is annoying. In a 150-person chat, they set the culture.

And the death spiral is specific: quality drops → best contributors go quiet → casual members mute → the only people left talking are the ones who drove everyone else out. By the time you notice, it's too late.

WhatsApp makes this harder — no threads. Every tangent plays out in the main chat. Two people going back and forth about something niche can bury a question the whole group would've benefited from answering.

Advance the ball, don't occupy the airspace

Think of a group chat like a soccer match. The best players receive the ball, advance it, and pass. They don't dribble in circles at midfield.

Advancing the ball: adding information nobody had. Asking a question that sharpens the discussion. "I tried that — here's what happened."

Occupying the airspace: restating what someone said, slightly rephrased. Reacting to every message. Writing paragraphs when a sentence would do.

The worst behavior is the person who responds to everything but advances nothing. The chat feels active but is actually useless. Thirty new messages, and you close it knowing exactly as much as before. In a small group, that's annoying. In a large group, it's fatal — because the people who do advance the ball feel drowned out, so they stop. Then all you have left is noise.

The best contributors are often the quietest. They lurk for 20 messages, then drop one that changes the direction of the conversation.

A good group chat culture gives people permission to not respond. An emoji reaction is almost always better than a message that says "great point."

The real test

The test of a good group isn't how many messages it generates. It's whether people open it on purpose — not to clear a notification, but because they want to see what's there.

Here are three that I keep coming back to and recommending to founders. They're all short reads. They'll all change how you think about your job.

1. Leadership Without Easy Answers — Ronald Heifetz

This is the book that rewired how I think about leadership. I took Heifetz's class at the Kennedy School, and his core idea has stuck with me ever since: the hardest leadership problems aren't technical — they're adaptive.

Technical problems have known solutions. Someone has the expertise, you apply it, done. Adaptive challenges are different. They require people to change their beliefs, habits, or identity. And that's where everything gets hard, because change means loss — and people resist loss even when the change is right.

Sound familiar? Every pivot, every reorg, every "we need to rethink our strategy" conversation is an adaptive challenge. Heifetz gives you the framework to understand why your team pushes back even when they intellectually agree with you, and what to do about it.

The key insight: your job as a leader isn't to have the answers. It's to manage the rate of change your organization can absorb — enough heat to force progress, not so much that people break. He calls it the "productive zone of disequilibrium." I call it the most useful idea I've ever encountered for running a startup.

Read this if: You've ever been frustrated that your team "just won't get on board" with a decision that seems obviously right.

2. The Five Dysfunctions of a Team — Patrick Lencioni

This one reads like a novel — literally, it's written as a fable — and you can finish it in an afternoon. Don't let that fool you. The framework underneath is sharp.

Lencioni lays out five dysfunctions as a pyramid:

1. Absence of trust — people won't be vulnerable with each other

2. Fear of conflict — so they avoid honest debate

3. Lack of commitment — because without real debate, there's no real buy-in

4. Avoidance of accountability — without commitment, nobody holds anyone to anything

5. Inattention to results — and eventually people optimize for themselves, not the team

The pyramid matters because each layer depends on the one below it. You can't have healthy conflict without trust. You can't have commitment without conflict. It's sequential — and most founding teams are stuck at layer one or two without realizing it.

I think about this framework every time I see cofounders who are "nice" to each other in meetings but clearly not aligned. Niceness without trust isn't harmony — it's avoidance. And avoidance kills startups slowly, in ways that don't show up in your metrics until it's too late.

Read this if: Your founding team "gets along great" but somehow never resolves the hard disagreements.

3. The Hard Thing About Hard Things — Ben Horowitz

If Heifetz gives you the theory and Lencioni gives you the framework, Horowitz gives you the war stories. This book is what it actually feels like to lead a company through near-death experiences — the layoffs, the pivots, the moments where everything is falling apart and you still have to show up on Monday.

What makes this book different from most CEO memoirs is that Horowitz doesn't sanitize it. He talks about the loneliness, the self-doubt, the physical toll. He's honest about how many of his decisions were made with incomplete information under extreme pressure — and how that's not a bug of the job, it's the job.

Two ideas from this book I think about constantly:

"The Struggle." Horowitz names the emotional reality of building a company in a way that most startup literature doesn't. The Struggle is when you wonder why you started the company. When the easy answer is to quit and nobody would blame you. Naming it doesn't make it easier, but it makes you feel less alone.

Peacetime CEO vs. Wartime CEO. Different situations require fundamentally different leadership styles. Peacetime is about expanding advantages and building culture. Wartime is about survival — and the skills that make you great in one mode can make you terrible in the other. Most founders don't realize when they've crossed from one to the other.

Read this if: You're in the middle of something hard and need to know that other founders have been there and survived.

How They Connect

These three books aren't usually grouped together, but I think they form a complete picture:

Heifetz explains why leading people through change is so hard — because change requires loss, and loss triggers resistance. This is the theory of what's happening beneath the surface.

Lencioni shows you where teams break down — the specific layers of dysfunction that prevent people from doing hard work together. This is the diagnostic tool.

Horowitz shows you what it feels like to lead through it anyway — the emotional reality that no framework fully prepares you for. This is the field guide.

Together, they give you the vocabulary to understand what's happening in your team, the framework to diagnose where you're stuck, and the reassurance that the struggle is the job — not a sign you're doing it wrong.

If you only read one, read Heifetz. If you need motivation to get through next week, read Horowitz. If you think your team is fine but somehow nothing is getting decided, read Lencioni.

Or read all three. They're short. And you'll be a better founder for it.

I've been thinking about this a lot lately, partly because I keep seeing the same pattern play out across startups I've worked with. And partly because of something I learned years ago in Ronald Heifetz's class at the Kennedy School that I keep coming back to — his framework on adaptive leadership crystallized something I'd been struggling to articulate.

The Scene

Here's a scenario that plays out constantly:

A cofounder throws out "what if we pivot to X?" in a Monday standup. To him, he's brainstorming. He's being transparent, thinking out loud, inviting debate. That's what cofounders are supposed to do, right?

But the founding engineer who's been heads-down building for six months hears something completely different. He hears: my work might be worthless. He doesn't push back — not because he agrees, but because there's a power dynamic he can feel but can't quite name. The person who controls his equity just casually suggested his last six months don't matter.

The cofounder walks away thinking "great brainstorm." The engineer goes quiet, starts updating his LinkedIn, and ships a little slower each week. Nobody talks about why.

Neither person is wrong. But something important just broke, and neither of them has the language for it.

Why Change Is Hard (Even When It's Right)

This is where Heifetz helped me see something I'd been missing. He draws a distinction between two kinds of problems:

Technical problems have known solutions. The server's down — fix it. You need a CFO — hire one. These are hard but straightforward. Apply expertise, solve problem.

Adaptive challenges are different. They require people to change their beliefs, habits, or identity. Pivoting the product. Shifting from founder-led sales to a sales team. Confronting a cofounder about performance. These don't have a playbook. They require people to let go of something — and that letting go is where everything gets stuck.

Here's the thing most founders miss: people don't resist change because they're weak. They resist because change means loss.

That engineer isn't being "sensitive." He's processing real losses — six months of work, his identity as the technical architect, his sense of control over the product's direction. You can't logic someone through that. It has to be metabolized.

Here's what most people miss about high-growth startups: they aren't a series of stable periods interrupted by occasional change. A high-growth startup is one long, continuous adaptive challenge. Every quarter, roles shift. The engineer who was a generalist now needs to be a manager. The cofounder who did everything now needs to delegate. The scrappy sales process needs to become a real team. The whole company needs to re-learn how it works, over and over, at a pace most people have never experienced.

That's not a bug — that's what growth looks like from the inside. And treating these constant adaptive challenges like technical ones — just make the rational decision and move on — is how you end up with a team that looks aligned in meetings and falls apart everywhere else.

The Thermometer You're Not Reading

Heifetz talks about the leader's job as managing the "productive zone of disequilibrium." Think of it as a thermometer:

Too cold: Everyone's comfortable. No urgency. "Things are fine" when they're clearly not. You're burning runway while the team optimizes things that don't matter.

Too hot: Panic. People shut down, get political, or leave. You've pushed so hard and so fast that nobody can think straight.

The sweet spot: Uncomfortable but not overwhelmed. This is where growth happens — where people are stretched enough to change but supported enough to not break.

The cofounder in our story cranked the heat to maximum without realizing he was holding the dial. That's the thing about power dynamics in startups — cofounders often don't realize they can't "just brainstorm" anymore. Their words carry weight they didn't ask for and might not want. A casual "what if" from the person who signs the checks lands very differently than the same words from a peer.

Feelings Are Data, Not Noise

Startup culture fetishizes rationality. "Don't be emotional." "Move fast." "Data-driven decisions." But feelings are the data that tells you the temperature.

Anxiety in the team? You might be moving too fast or not communicating enough context. Apathy? Not enough urgency, or people don't understand why their work matters. Conflict? Could be productive friction — or a sign you have a values problem you're not addressing.

Ignoring feelings doesn't make them go away. They leak out as passive aggression, quiet quitting, hallway politics, and slow-rolling decisions. The engineer in our story didn't say "I feel threatened." He just... disengaged. And by the time that's visible in the metrics, it's usually too late.

High Performance ≠ No Friction

This is where people get confused. Psychological safety — Amy Edmondson's term — doesn't mean everyone's comfortable all the time. It means people feel safe enough to take risks, disagree, and say "that scares me and here's why" without it being career suicide.

The best startup teams I've seen run hot. They argue, they challenge, they move fast. But they do it inside a container where people trust that the discomfort is in service of something, not just chaos.

Heifetz calls this the "holding environment" — the structure that lets people do hard work without falling apart. In practice, it's less mystical than it sounds. It's a cofounder who says "I want to stress-test our direction — nothing is decided, I need your honest take" before riffing on pivots. It's separating exploring ideas from making decisions and being explicit about which one you're doing.

That's it. That's the whole trick. Frame before you explore. Name which mode you're in.

Managing the Rate of Change

Your job as a leader isn't to eliminate discomfort — it's to make sure your team can absorb the rate of change the business demands. And in a high-growth startup, that rate is relentless.

This means you're not "managing through a change" like it's a one-time event. You're constantly calibrating: How much can this team take right now? What do they need to let go of this month? Have they processed the last shift enough to handle the next one?

Name what's being lost. Every time a role changes, a product pivots, or a process gets replaced — something dies. Someone's identity, someone's work, someone's comfort. "I know this means some of what you built won't ship as-is." People can handle hard news. What they can't handle is pretending there's no cost.

Sequence the losses. Don't drop the pivot, the reorg, and the new OKRs in the same week. People can metabolize one hard thing at a time. Stack them and they shut down.

Decide and move. Psychological safety doesn't mean consensus. You can acknowledge the cost and still make the hard call. In fact, that's exactly what good leadership is — being honest about the tradeoffs and then deciding anyway. The acknowledgment is what earns you the speed.

Why Startups Get This Wrong

Founders are selected for conviction and speed — the opposite of what adaptive leadership requires. You got funded because you had a bold vision and the intensity to pursue it. Nobody invests in "I'm going to carefully regulate my team's emotional temperature."

VC pressure makes it worse. When you're burning $200K a month, slowing down to acknowledge feelings seems like a luxury. But the irony is that ignoring the emotional reality is what actually slows you down — through turnover, through disengagement, through teams that nod in meetings and drag their feet everywhere else.

And "culture" gets reduced to perks and values posters instead of the actual emotional reality of how people work together. Your culture isn't your ping pong table. It's what happens when the cofounder throws out a pivot idea on a Monday morning.

The Point

The best founders I've worked with aren't the ones who move fastest. They're the ones who know when to turn up the heat and when to let the room cool down. They understand that every strategic change has a human cost, and that pretending otherwise doesn't make them tough — it makes them blind.

Leadership isn't having the vision. It's having the courage to sit in the discomfort with your team while you figure it out together. And sometimes, it's as simple as saying: "I know this is hard. Here's why we're doing it anyway. Tell me what you're worried about."

That's not soft. That's how you build a team that can actually survive the thing you're building together.

I've been thinking about this a lot lately, partly because I keep seeing the same pattern play out across startups I've worked with. And partly because of something I learned years ago in Ronald Heifetz's class at the Kennedy School that I keep coming back to — his framework on adaptive leadership crystallized something I'd been struggling to articulate.

The Scene

Here's a scenario that plays out constantly:

A cofounder throws out "what if we pivot to X?" in a Monday standup. To him, he's brainstorming. He's being transparent, thinking out loud, inviting debate. That's what cofounders are supposed to do, right?

But the founding engineer who's been heads-down building for six months hears something completely different. He hears: my work might be worthless. He doesn't push back — not because he agrees, but because there's a power dynamic he can feel but can't quite name. The person who controls his equity just casually suggested his last six months don't matter.

The cofounder walks away thinking "great brainstorm." The engineer goes quiet, starts updating his LinkedIn, and ships a little slower each week. Nobody talks about why.

Neither person is wrong. But something important just broke, and neither of them has the language for it.

Why Change Is Hard (Even When It's Right)

This is where Heifetz helped me see something I'd been missing. He draws a distinction between two kinds of problems:

Technical problems have known solutions. The server's down — fix it. You need a CFO — hire one. These are hard but straightforward. Apply expertise, solve problem.

Adaptive challenges are different. They require people to change their beliefs, habits, or identity. Pivoting the product. Shifting from founder-led sales to a sales team. Confronting a cofounder about performance. These don't have a playbook. They require people to let go of something — and that letting go is where everything gets stuck.

Here's the thing most founders miss: people don't resist change because they're weak. They resist because change means loss.

That engineer isn't being "sensitive." He's processing real losses — six months of work, his identity as the technical architect, his sense of control over the product's direction. You can't logic someone through that. It has to be metabolized.

Here's what most people miss about high-growth startups: they aren't a series of stable periods interrupted by occasional change. A high-growth startup is one long, continuous adaptive challenge. Every quarter, roles shift. The engineer who was a generalist now needs to be a manager. The cofounder who did everything now needs to delegate. The scrappy sales process needs to become a real team. The whole company needs to re-learn how it works, over and over, at a pace most people have never experienced.

That's not a bug — that's what growth looks like from the inside. And treating these constant adaptive challenges like technical ones — just make the rational decision and move on — is how you end up with a team that looks aligned in meetings and falls apart everywhere else.

The Thermometer You're Not Reading

Heifetz talks about the leader's job as managing the "productive zone of disequilibrium." Think of it as a thermometer:

Too cold: Everyone's comfortable. No urgency. "Things are fine" when they're clearly not. You're burning runway while the team optimizes things that don't matter.

Too hot: Panic. People shut down, get political, or leave. You've pushed so hard and so fast that nobody can think straight.

The sweet spot: Uncomfortable but not overwhelmed. This is where growth happens — where people are stretched enough to change but supported enough to not break.

The cofounder in our story cranked the heat to maximum without realizing he was holding the dial. That's the thing about power dynamics in startups — cofounders often don't realize they can't "just brainstorm" anymore. Their words carry weight they didn't ask for and might not want. A casual "what if" from the person who signs the checks lands very differently than the same words from a peer.

Feelings Are Data, Not Noise

Startup culture fetishizes rationality. "Don't be emotional." "Move fast." "Data-driven decisions." But feelings are the data that tells you the temperature.

Anxiety in the team? You might be moving too fast or not communicating enough context. Apathy? Not enough urgency, or people don't understand why their work matters. Conflict? Could be productive friction — or a sign you have a values problem you're not addressing.

Ignoring feelings doesn't make them go away. They leak out as passive aggression, quiet quitting, hallway politics, and slow-rolling decisions. The engineer in our story didn't say "I feel threatened." He just... disengaged. And by the time that's visible in the metrics, it's usually too late.

High Performance ≠ No Friction

This is where people get confused. Psychological safety — Amy Edmondson's term — doesn't mean everyone's comfortable all the time. It means people feel safe enough to take risks, disagree, and say "that scares me and here's why" without it being career suicide.

The best startup teams I've seen run hot. They argue, they challenge, they move fast. But they do it inside a container where people trust that the discomfort is in service of something, not just chaos.

Heifetz calls this the "holding environment" — the structure that lets people do hard work without falling apart. In practice, it's less mystical than it sounds. It's a cofounder who says "I want to stress-test our direction — nothing is decided, I need your honest take" before riffing on pivots. It's separating exploring ideas from making decisions and being explicit about which one you're doing.

That's it. That's the whole trick. Frame before you explore. Name which mode you're in.

Managing the Rate of Change

Your job as a leader isn't to eliminate discomfort — it's to make sure your team can absorb the rate of change the business demands. And in a high-growth startup, that rate is relentless.

This means you're not "managing through a change" like it's a one-time event. You're constantly calibrating: How much can this team take right now? What do they need to let go of this month? Have they processed the last shift enough to handle the next one?

Name what's being lost. Every time a role changes, a product pivots, or a process gets replaced — something dies. Someone's identity, someone's work, someone's comfort. "I know this means some of what you built won't ship as-is." People can handle hard news. What they can't handle is pretending there's no cost.

Sequence the losses. Don't drop the pivot, the reorg, and the new OKRs in the same week. People can metabolize one hard thing at a time. Stack them and they shut down.

Decide and move. Psychological safety doesn't mean consensus. You can acknowledge the cost and still make the hard call. In fact, that's exactly what good leadership is — being honest about the tradeoffs and then deciding anyway. The acknowledgment is what earns you the speed.

Why Startups Get This Wrong

Founders are selected for conviction and speed — the opposite of what adaptive leadership requires. You got funded because you had a bold vision and the intensity to pursue it. Nobody invests in "I'm going to carefully regulate my team's emotional temperature."

VC pressure makes it worse. When you're burning $200K a month, slowing down to acknowledge feelings seems like a luxury. But the irony is that ignoring the emotional reality is what actually slows you down — through turnover, through disengagement, through teams that nod in meetings and drag their feet everywhere else.

And "culture" gets reduced to perks and values posters instead of the actual emotional reality of how people work together. Your culture isn't your ping pong table. It's what happens when the cofounder throws out a pivot idea on a Monday morning.

The Point

The best founders I've worked with aren't the ones who move fastest. They're the ones who know when to turn up the heat and when to let the room cool down. They understand that every strategic change has a human cost, and that pretending otherwise doesn't make them tough — it makes them blind.

Leadership isn't having the vision. It's having the courage to sit in the discomfort with your team while you figure it out together. And sometimes, it's as simple as saying: "I know this is hard. Here's why we're doing it anyway. Tell me what you're worried about."

That's not soft. That's how you build a team that can actually survive the thing you're building together.

I'm walking them through the prompts I used to build it in Claude Code. "How long did this take?" they ask. Less than 30 minutes.

To prove the point, I do a live demo on the spot. We build a simple app to help people learn the ingredients and auspicious phrases for Chinese New Year yusheng — you know, the "huat ah!" stuff. Five minutes later, it's running on my laptop.

My cousin can't get over it. In his eyes, I'm not a technical person — I didn't study computer science, I've never worked as an engineer. And yet here I am, in the terminal, typing questions in plain English, and generating working applications. His wife keeps saying, "Oh man, we're behind. We really need to catch up." And I'm like — it's not hard. You just talk to it. And if you don't know how to do something, you ask, and it tells you.

This is just the most recent experience I've had where showing people what's possible has a far more powerful impact than any breathless article about AI taking our jobs. I'm not here to spread alarm. I just want people to experience the joy of turning an idea into something real.

Last week at our Hustle Fund offsite, I ran a similar demo for my non-technical colleagues. Within 90 minutes, every single one of them had shipped something working on their local machines — tools directly applicable to their jobs. They were so excited they kept building after the hackathon ended.

What struck me was the contrast to a hackathon we ran just a year ago. Back then, using what was state-of-the-art at the time, people would get stuck, couldn't quite get things working, got frustrated, and gave up. The tools were impressive but brittle.

Now? The capability gap has closed dramatically. And I'm seeing the habits stick. People are going back to their desks and building more. I think it's only going to get better.

So Why Aren't People Jumping In?

I think a lot of people are honestly just scared of things that feel technical. It's that weird thing where adults ask, "How do you turn on this TV?" while kids just press every button until something happens.

Somewhere along the way, we learn to be afraid of breaking things. We wait for permission, for a tutorial, for someone to tell us it's OK to try. Kids don't do that. They just go.

I really want to encourage people to go press all the buttons. Like the early internet, the folks who get their hands dirty now are going to have an outsized advantage — in their daily lives, in their work, in how they think about problems. And this is so exciting precisely because it's not just for engineers anymore.

The Real Shift

The bottleneck is no longer expensive engineers who can write bespoke code. It's shifting to: can you picture what you want to exist in the world?

Taste. Product sense. Problem identification. These are becoming the scarce and valuable skills. If you can understand a customer's problem and prototype a solution in an afternoon, that is a massive unlock. The person with the idea AND the ability to make it real — even a rough version — is incredibly powerful.

I'm not saying everyone needs to become an engineer. But if you have ideas and curiosity, the barrier to building just dropped to almost nothing. And at this point, the cost of not experimenting is higher than the cost of trying.

Start Small

Build something for yourself. Solve your own problem. Once you get that first experience of something working — something you made — you'll have ten more ideas you want to try. You'll make mistakes, but you'll learn. And honestly, it is just so much fun.

I'm constantly building and experimenting. I built tools to manage my personal portfolio. I build stuff for my kids that motivates them in ways they actually care about — my son is all about Pokémon, so all his learning tools are Pokémon-themed. My daughter loves baking, so hers are baking-themed. On the professional side, I'm looking at ways to help our team share data and ship internal tools frictionlessly.

The Call to Action

Download Claude Code. Open a terminal. Start talking to it. Give yourself 90 minutes. I think you'll surprise yourself.

P.S. This blog post was written using OpenClaw — I dictated my thoughts into WhatsApp, and my AI assistant drafted and published it. Yet another thing I'm experimenting with. Press the buttons, people.

The kids were immediately put to work opening instant noodle packets and peeling potatoes. K and I were led into the kitchen where we began scrubbing industrial-sized pots, pans and serving trays. Then we were handed eight legs of lamb and instructed to slice them up so they could be turned into satay. I love satay but have never actually made them from scratch before - it's harder than it looks to thread the meat onto sticks! Before you knew it, we'd prepared and packed 300 meals. "Willing Hearts is hard work" said the 6 year old. The kids lasted about 2.5 hours, and were taken to an early lunch by my uncle and parents while K and I finished packing meals.

It's a pretty impressive operation they have running, with <20 FTEs and most of the food donated. The cooks are FTEs and they use volunteers for chopping, packing, and delivery. They get pretty creative with the meals. At one point I saw a stack of chorizo and dry saucisson and wondered how it would be served. Fried rice, of course! We wandered past boxes of scones, rice, baby formula. All neatly organized and waiting to be transformed into delicious meals.

I used to think it was probably more effective for me to give money than spend 4 hours chopping vegetables, but I've come to believe it's a "yes, and..." situation. Those of us who can afford to give money should definitely do it, AND we should roll up our sleeves. We have to push ourselves to get out of our bubbles. Willing Hearts is non-denominational—we passed symbols of multiple religions around the facility. There's something fitting about that: feeding people is universal.

With so many causes one can give to, how do we narrow the list? For our family, it starts with values—what do we want to model for the kids? Food security felt tangible, local, and easy to explain. Then there's the boring-but-important question: is this organization well-run? Willing Hearts operates on fewer than 20 staff, most food is donated, and their financials are public. That matters. You can see the financials for all IPCs at https://www.charities.gov.sg/ which gives a sense of expense ratio, headcount, and how the government rates their operations.

If you're interested in volunteering, details here: https://willinghearts.org.sg/. Also consider donating to them, they are a registered IPC and eligible for the tax-deduction. We will definitely be back - the 9 year old wanted to return the very next day, for the 5am shift. I told her that was going to be challenging for her parents, given that it would be New Year's Day.