All Articles
Tech Leadership May 20, 2021 · Updated August 12, 2026

5 Practical Lessons for Any Startup

Feras Hirzalla

by Feras Hirzalla

Founder & CEO, Buttercloud

5 Practical Lessons for Any Startup

There are a handful of principles that hold up remarkably well across different companies, stages, and industries — not because they’re clever, but because they describe patterns that repeat regardless of how careful a team is. Here are five that have proven especially valuable and lasting.

The Rule of 3 and 10

Coined by Hiroshi Mikitani, founder and CEO of Rakuten, the rule holds that every time your team roughly triples in size — rounding to the nearest multiple of 10 — everything changes. Not some things. Everything.

When you go from one person to three people it’s different. When it’s just you, you know what you are doing and then you have three people and you have to rethink how you are doing everything. But when there are 10 people it’s all going to change again. And when there are 30 people it will change again. Same when you reach 100 people.

Sequoia Capital, “The Rule of 3 and 10”

Everything from team dynamics and communication tools to meetings, payroll, and the intentional or natural formation of hierarchy gets affected. The mistake founders make is assuming their current processes will scale linearly — that if a weekly standup works for 6 people, it’ll basically work for 20 with a few tweaks. It won’t. It needs to be rebuilt, not adjusted.

A team hovering around 6–10 people feels this acutely: a change of plus or minus one person can have a genuinely palpable impact and force a rethink of things that felt settled the week before. A simple, common example: a 20-minute morning standup that stays sharp at 6 attendees starts creeping toward the hour mark by 10, not because anyone’s being long-winded, but because the math of “everyone gives a 2-minute update” simply doesn’t scale the way it feels like it should.

The practical takeaway isn’t to panic before each threshold. It’s to expect friction at 3, 10, 30, and 100, and treat the resulting discomfort as a signal to redesign the process — not evidence that something’s broken.

Why Should You Edit Your Team?

As CEO of Square (now Block) and Twitter, Jack Dorsey has described his own role less as a builder and more as an editor. In a 2015 interview, he put it this way:

“I think I’m just an editor, and I think every CEO is an editor. I think every leader in any company is an editor. Taking all of these ideas and editing them down to one cohesive story, and in my case my job is to edit the team, so we have a great team that can produce the great work — and that means bringing people on and in some cases having to let people go.”

Jack Dorsey, via CNBC

The framing matters because it reorients what “growing a team” actually means. It’s not purely additive. Editing implies removal as much as addition — trimming what doesn’t fit the story you’re trying to tell, even when that’s uncomfortable. Kevin Rose has used the word “pruning” for the same idea, which captures something the word “editing” doesn’t quite: pruning isn’t punitive, it’s what you do to encourage healthier growth elsewhere.

Editing your team is as much about nurturing culture as it is about skill composition. Every team member needs to be paddling in the same direction at roughly the same speed — not identically, but compatibly enough that the difference doesn’t create constant friction.

Brooks’ Law

Fred Brooks coined this rule in The Mythical Man-Month, originally about software projects specifically, but it generalizes to nearly any team-based effort under deadline pressure:

“Adding manpower to a late software project makes it later.”

Ramp-up time, communication overhead, and the simple fact that new hires can’t take on truly concurrent work immediately all combine to make a late project later, not sooner, when you throw people at it. This gets overlooked constantly — by clients, by project managers, and by startups trying to accelerate growth by hiring faster.

The deeper issue for an early-stage team: hiring itself is expensive in founder time and attention, not just salary. That cost is often invisible until you’re mid-hire and realize how much focus it’s pulling from everything else. If you can afford to, hire proactively, ahead of the crunch, rather than reactively once the crunch has already started — a rushed hire made under deadline pressure is exactly the scenario Brooks’ Law warns against.

Broken Window Theory

How many times has “I’ll come back to it” or “I’ll clean it up later” turned out to be permanent? Whether it’s a piece of code, a skipped post-mortem, or a process shortcut, if it doesn’t come back to bite you directly, it tends to instigate decay in whoever inherits it next.

One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment — a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.

The Pragmatic Programmer, Andrew Hunt and David Thomas

The theory has a real, if implicit, effect on company culture even when nobody names it directly. One unaddressed shortcut signals that shortcuts are acceptable, and the next person facing a similar decision under time pressure will point to the first one as precedent. Leading by example here isn’t a platitude — it’s the actual mechanism.

What Gets Measured Gets Managed

Practicing continuous improvement — Kaizen, in the term’s original context — requires tracking whatever you’re trying to improve. Think of it like losing weight: stepping on a scale tells you whether you’ve lost weight, but it doesn’t tell you why, and it doesn’t guide the process on its own. Ask anyone who’s lost meaningful weight and they’ll tell you it’s nearly impossible without also tracking calories in and calories out — the input, not just the outcome.

This applies to nearly every dimension of a startup: platform performance, pricing experiments, whether flexible work-from-home policies actually change output versus strict in-office hours, and dozens of other decisions that feel intuitive but are actually measurable.

Improvement can sometimes be traced cleanly to a single cause. More often, it can’t — a marketing campaign works, and the honest answer is “we’re not entirely sure why.” That’s fine as a first pass, but it shouldn’t be the final answer, because without understanding the mechanism, you can’t reliably repeat the success. Keep asking why until you actually find the reason, not just a plausible-sounding one.

“Ask ‘why’ five times about every matter.”

— Taiichi Ohno, former Executive Vice President of Toyota, architect of the Toyota Production System

How Do These Five Actually Interact?

These aren’t five independent tips — in practice, they compound. A team that’s hit a Rule of 3-and-10 threshold and hasn’t rebuilt its processes is exactly the environment where Brooks’ Law damage happens fastest, because new hires are ramping up into a structure that’s already under strain. A team that’s been “edited” thoughtfully — the right people, paddling the same direction — absorbs a broken window faster, because someone notices and fixes it before it becomes precedent. And none of the first four matter much without the fifth: if you’re not measuring the effect of a process change, you won’t know whether the rebuild after crossing a threshold actually worked, or whether the team you edited is genuinely more effective, or just differently composed.

A practical way to use all five together: before every hiring push, check whether you’re about to cross a 3-or-10 threshold and plan for the process rebuild explicitly rather than reactively. Before adding headcount to a project that’s already late, ask whether Brooks’ Law is about to apply. Do a quick culture and skill audit — an editing pass — on a regular cadence, not just when something’s visibly broken. Fix the small things that everyone’s silently agreed to ignore, on a schedule, not just when they finally become urgent. And pick two or three metrics per major decision you make, so “did that work” has an actual answer six months later instead of a shrug.

None of these five lessons are complicated once stated. What makes them hard is that each one asks you to do something that feels counterintuitive under pressure — rebuild instead of patch, remove instead of only add, slow down instead of throwing people at a deadline, fix the small thing now instead of later, and measure the input instead of just celebrating the outcome. The founders who apply them consistently, especially when it’s inconvenient, are the ones who actually benefit from having known them.

Have a product idea to talk through?

We'll show you how we'd approach it — no pressure, just a real conversation.

Book a Discovery Call