Dealing with complexity

This piece is part of the ongoing Founders Guide. I'm jotting these notes while helping a handful of first-year startups wrestle their product ideas into something that actually ships.

---

Early founders don’t talk enough about complexity. You notice it the moment you promise a “quick” integration and, three sprint-reviews later, discover the requirement list has doubled. Complexity creeps in quietly—first through people, then through features, and finally through code.

I’ve spent the better part of fifteen years architecting everything from mobile banking to small fitness trackers (fun fact: the latter was harder). Even with that mileage I still lose the occasional fight—no single person can hold a multi-team project together by sheer force of will. You need a group of competent adults, a plan that tolerates change, and a healthy respect for chaos.

We know why projects fail—bookshelves groan under post-mortems—so why does the failure rate barely move?

Short answer: big-bang builds rarely work. Gall’s Law (1975) still holds—“a complex system that works is invariably found to have evolved from a simple system that worked.” We keep forgetting this and attempt green-field mega-launches anyway. I’ve done it twice; both times we ended up rebuilding in smaller increments six months later.

The longer answer sits below. I’m grouping thoughts into rough buckets, but don’t treat them as a syllabus—some parts matter more than others, and that changes week to week.

1. The soft skills that keep projects from exploding
2. Daily habits that nudge a product forward
3. Potholes you’re likely to hit (and a few you won’t see coming)
4. A grab-bag of tactics that have bailed me out more than once

The cheapest way to handle a complex project is to shrink the scope. Half the features, twice the chance of launch.

When I say “complex,” I’m not talking about a ten-million-line codebase. I mean projects with cross-company integrations, moving deadlines, and a parade of “just one more feature.” The hard part is rarely code; it’s the surrounding swirl of people and processes.

Soft skills to manage projects effectively

Writing code is the easy bit. Herding humans, reading board-room politics, and deciding quickly under uncertainty—that’s where projects live or die. Three traits make the biggest dent for me.

Expect the unexpected (and have a plan B…C…D)

Flexibility beats optimism. Any schedule that assumes “everyone stays healthy and all vendors deliver” belongs in fiction. My default planning buffer sits at about a third—more if the tech stack is new to the team (I might be paranoid, but the hit rate justifies it).

Variables outside your control:

1. Flu season sweeps half the devs.
2. A senior engineer jumps ship mid-sprint.
3. A freelancer ghosts Slack on hand-over day.
4. Key supplier files bankruptcy (yes, this happened to us in 2019).
5. Feature creep quietly doubles the scope.

(Side note: most “technical” overruns I’ve seen were actually feature-scope explosions. Kill the extra features and the code usually calms down.)

Murphy’s Law applies with annoying consistency. Project management often feels like surfing—balance just long enough and hope the wave breaks where you expect.

I recall reading somewhere that roughly half of projects blow past budget and two-thirds miss their schedule. Sobering, but not surprising.

A quick dev-friendly illustration: we once planned a smooth Stripe checkout, then realised mid-build that Stripe forbids CBD products. The alternative PSP supported only SOAP. One protocol switch later we were juggling manual currency conversions and a brand-new set of failure modes. Nobody had budgeted that.

Get comfortable making hard calls

During crunch you have minutes, not days. I’ve learned (the embarrassing way) that a so-so decision executed today beats a perfect decision next week. You can steer a moving vehicle; you can’t steer one parked in analysis paralysis.

My crisis checklist looks like this:

1. Identify the blast radius—what’s truly at risk?
2. Skip blame (post-mortems come later).
3. List immediate options and find someone who’s solved a similar mess.
4. Draft plan A, plus at least one fallback.
5. Loop in stakeholders fast—silence breeds panic.
6. Once stable, document causes and patch the process.
7. Take a breather (burned-out leaders compound errors).

Learn to talk to humans

Code can’t save you from bad conversations. I watched an ML initiative implode last year because leadership never budgeted time for validation infrastructure. Engineers knew; executives didn’t. By the time they synced, trust had evaporated and the project died.

Keep discussions factual, not personal. Politics will show up anyway—especially inside large corporates—so learn just enough diplomacy to navigate without drowning in it.

Staying on track single day at a time

Daily discipline beats heroic sprints. A few practices I lean on (I could be wrong, but they’ve held up across half a dozen teams):

First, clarify the problem. One pager, whiteboard sketch, napkin—doesn’t matter, as long as the team can point at the same mountain. Feature creep loves vague goals.

“If you don’t know where you’re going, any road will take you there.”

I interview users early—even five short calls surface edge cases product owners never imagine. In 2020 we avoided a month of re-work on a finance app after a tester casually mentioned that some banks deliver CSV statements in Latin-1. None of us had considered encoding at that stage.

Work backward from the release date

Dependencies matter more than headcount. Content before dev, UX before UI, legal before rollout—simple Gantt logic, yet half the delays I see relate to something upstream not being ready.

Common chain:

1. Finalize content →
2. UX mock-ups locked →
3. Stakeholder sign-off →
4. Development starts.
5. Parallel work exists, just don’t pretend everything can overlap.

Assemble a real A-team

Complex work wants experienced hands. Every major component should have an owner who can say “ship it” without asking me first. (Well, more like 90 % autonomy—some decisions still need a sanity check.)

Define who decides what, and how often the group syncs. I default to a 30-minute Thursday checkpoint—short, brutal, and focused on blockers.

Structured programming helps too: tree-shaped dependencies, limited cross-talk between modules, clear supervision hierarchy. The fewer surprises in the call-graph, the fewer surprises at 2 a.m. launch night.

Then iterate mercilessly. Agile isn’t an excuse for endless scope changes; it’s a guard-rail that lets you recover when the real world punches your assumptions.

No amount of testing can prove software right, yet one test can prove it wrong.

Plan a buffer—beta cycles uncork bugs you didn’t even know existed. We usually reserve at least one sprint purely for “stuff we missed.” It still gets tight.

Most likely issues during the early stages.

You’ll hit problems in three flavors:

1. Business: time-to-market pressure and thin budgets
2. Management: fuzzy ownership and rosy assumptions
3. Product: questionable tech choices and bad estimates

Business Issues

Executives want “best-in-class” tomorrow. Reality says pick two: scope, time, money. Push back early—reducing scope often yields better outcomes than beefing up process.

Keep the deadline, trim the features—or keep the features and move the date. There is no secret third option.

Budgets come with strings. Consultants will wave efficiency charts; investors will chase vanity milestones. Your job is to translate tech constraints into business language before fantasy-roadmaps crystallize.

Management Issues

Delegation ≠ abdication. Give teams goals, not a void. When a decision sits blocked for days, step in. Momentum compounds; so does drift.

Pessimistic estimates hurt feelings, but optimistic ones kill launches. Plan as if every task slips a bit—you’ll still end up crunching, just less.

• Unsent email → confusion
• Undecided spec → stalled sprint
• Unowned risk → midnight fire-drill

Pretend release is next month—urgency reveals weak links while there’s still room to patch them.

Product Issues

Lack of a unified vision tops this list. Two stakeholders, three opinions—politics ensues. Keep a single north star and park side quests in a backlog.

Nobody tells a builder to add a basement after the roof is done, yet software teams hear “now make it multi-tenant” in week twelve.

Legacy systems amplify pain. Evaluate them early—black-box surprises get pricier every sprint you delay.

General Tips

A handful of habits that save me grief:

Document everything

If it isn’t written, it didn’t happen. Specs, decisions, “why we ignored that edge case”—future-you will thank you.

Revisit the plan regularly

Each milestone invalidates some old assumption. Surface it before it bites.

Broadcast progress honestly

Bad news ages like milk. Weekly digests keep stakeholders calm and rumors short-lived.

Keep optionality alive

Design for change, but don’t over-optimize on day one. YAGNI still applies.

Do your homework

Talk to someone who’s shipped similar tech. A two-hour coffee can offset weeks of blind alleys.

Minimize moving parts

Fewer subcontractors, fewer integration points, lower entropy. When reduction isn’t possible, enforce strict comms channels.

Frequently asked questions

1. What’s the difference between software projects and other engineering projects?

Change velocity. Mid-build scope shifts—from “make it fly” to “make it reach space”—are bizarre in aerospace but Tuesday in software.

2. How to estimate a megaproject?

Never solo-estimate. Break work into modules, get multiple teams to size them, average the numbers, then pad ~25 % for hidden dragons—communication, integration, security hardening, etc.

3. Can I trust developers to meet their estimates?

You can trust their intent, not their clairvoyance. Add a buffer. Even a “simple” currentTime helper mutates once time zones, DST, and leap seconds pop up.

Moving forward

Startups mature: chaos shrinks, processes sprout. Whether you ship or stumble, the lessons compound. Say yes to big, interesting work—worst case you gain scar tissue and better instincts for the next round.

That’s it from my end. Go build something tricky; let complexity teach you.

---

Thanks for reading! Here are a few links you might enjoy:

• 🛠️ How to be a better technical manager
• 🚀 Founders Guide 2022
• 📚 Q&A for Startup Founders
• 📰 Previous Newsletter Issues