The hard lessons from a broken delivery cycle, scaled-down team, and what actually moves the needle on shipping speed.

When I joined, delivery was broken.

We were shipping once every three to six months. Those releases weren't particularly impactful. At the same time, we had contractual obligations stacking up—features and deliverables that were months, sometimes over a year, overdue.

The team wasn't incompetent. It was fragmented.

We had around 7–8 developers, but output didn't reflect that. There was no real alignment with the business. No clear prioritisation. No system that ensured work moved forward predictably. Everything felt reactive.

Within 6–12 months, we were shipping meaningful updates every one to two weeks.

At one point, we dropped to just two engineers. Delivery didn't slow down. It got faster.

This wasn't a story about working harder. It was about removing friction, forcing clarity, and making some uncomfortable decisions.

The Fundamental Rule

Speed comes from clarity, not effort.

You can't ship faster than your organisation can think. You can't move faster than your constraints let you. You can't decide faster than you have information.

Once those three things line up, speed is the natural outcome—not the goal.

Part I: Stabilising the Chaos (Weeks 0–4)

Facing Reality: Missed Contracts and Broken Delivery

Before fixing anything, I had to be honest about what was actually broken.

  • We were behind on contractual commitments
  • The team was disconnected from the business
  • There was no reliable roadmap
  • Delivery was inconsistent and unpredictable
  • Quality was low, and testing was almost nonexistent

Most importantly, there was no shared understanding of what "good" looked like.

You can't improve delivery speed if you don't first define what delivery actually means.

Fewer People, More Output

This is the part that makes people uncomfortable.

We reduced the team significantly—down to two engineers at one point.

And delivery improved.

Not because smaller teams are magically better. But because:

  • Prioritisation became ruthless
  • Communication became direct
  • Ownership became obvious
  • Waste became visible

When you have a larger, unstructured team, inefficiency hides in the gaps. With a small team, it's exposed immediately.

We cut delivery time by 1–2 weeks almost instantly—not by adding process, but by focusing only on what actually mattered.

This reset everything.

Ruthless Prioritisation: Cutting to What Actually Matters

(Covered in above section)

Part II: Fixing the Foundation (Product + Process)

Tech Is Only as Good as Product

One of the biggest issues wasn't engineering—it was product.

There was no clear way work was defined, scoped, or prioritised. Engineers weren't underperforming. They were under-directed.

So I stepped into product. Not in title, but in function.

I built:

  • A clear product strategy
  • A structured roadmap
  • Defined timelines
  • Standards for writing tickets
  • A feedback loop with the business and clients
  • Analytics to inform decisions

There were weeks where I spent more time doing product work than technical work. That wasn't ideal. But it was necessary.

Because you cannot have a high-performing engineering team without a high-performing product function.

Tech doesn't decide what to build. It executes. If product is weak, engineering becomes chaotic.

Once product matured, everything downstream improved.

Structure Beats Talent (Every Time)

Before, everything lived in a single board.

  • No separation between product and engineering
  • No separation within engineering
  • No defined stages
  • No definition of done

That's not a system. That's a dumping ground.

We introduced structure:

  • Separate boards for product and engineering
  • Clear ownership per team (backend, frontend, data, platform—even if people were cross-functional)
  • Defined stages: backlog → in progress → testing → done
  • A strict definition of done
  • Mandatory testing before release

This alone reduced rework significantly.

When people know what "done" means, quality improves without needing more oversight.

Part III: Rebuilding the Team

Everyone Becomes a Full-Stack Engineer

We removed specialisation.

  • No "frontend developer"
  • No "backend developer"
  • No "platform engineer"

Everyone became an engineer. Full stop.

This wasn't ideological. It was practical. We couldn't afford bottlenecks:

  • If one frontend developer is off, frontend work stops
  • If backend becomes a queue, everything slows down

So we upskilled everyone. Frontend engineers learned backend and platform. Backend engineers learned frontend. Everyone understood the full system.

The result:

  • No single points of failure
  • Better system-wide thinking
  • Faster delivery under constraints
  • Higher team resilience

When someone went on holiday, work didn't stop.

That's when you know your system is working.

Daily Accountability Changes Everything

We introduced strict daily stand-ups. Not status theatre—actual accountability.

Each engineer had to answer:

  • What did I deliver yesterday?
  • What am I delivering today?
  • Am I blocked?
  • Am I on track?

Every task had:

  • A clear assignee
  • A deadline
  • An estimate

Nothing vague. Nothing floating.

This did two things: It surfaced problems early. It forced clarity at the task level.

If something slipped, we knew immediately—not two weeks later.

Delivery speed is often just the speed at which you detect and resolve problems.

Remove Yourself as the Bottleneck

A common failure mode in leadership is becoming the communication hub.

I refused to do that.

If an engineer had a question about a ticket, they didn't come to me. They went directly to:

  • Product
  • The business stakeholder
  • The client-facing team

Whoever originally requested the work.

This removed layers:

  • Faster clarification
  • Better understanding
  • Stronger relationships

It also created ownership. Engineers weren't just executing tasks. They understood why they were doing them.

That alone improves quality and speed.

Force Alignment Through Proximity

We introduced a simple rule: Minimum one day per week in the office.

Not for control. For alignment.

That one day allowed:

  • Direct conversations with product
  • Faster feedback loops
  • Stronger team cohesion
  • Better cultural integration

Remote works—but only if alignment already exists. We didn't have that yet.

This small constraint made a disproportionate difference.

Part IV: Simplifying the System

Simplify the Architecture

At one point, infrastructure was spread across four different clouds.

That's not flexibility. That's chaos.

We consolidated everything into a single cloud. Then we:

  • Simplified the architecture
  • Documented everything clearly
  • Created shared diagrams
  • Made architecture visible to the entire team

If your team doesn't understand your system, they can't move quickly within it.

Clarity reduces hesitation. Hesitation kills speed.

Documentation Is a Delivery Tool

We made documentation a first-class citizen. Not as an afterthought, but as part of the system.

  • Clear architectural diagrams
  • Structured internal docs
  • Strong in-code documentation
  • Strict typing across the codebase

Strict typing, in particular, reduced entire classes of bugs. It also made onboarding faster and changes safer.

Good documentation doesn't slow teams down. It prevents them from slowing down later.

Part V: Speed Through Systems

Automate Everything Repetitive

We identified manual processes—especially in data and analysis—and automated them.

Before: Analysts performed every step manually

After: Systems handled the heavy lifting. Analysts focused on reviewing outputs.

This had a massive impact:

  • Faster turnaround
  • Higher consistency
  • Lower error rates

Automation isn't about replacing people. It's about removing low-value work so people can focus on high-value decisions.

Make Quality Measurable

We introduced monitoring across the board:

  • Uptime monitoring
  • Error tracking
  • Security monitoring
  • User behaviour analytics

We moved to tools like Segment and Amplitude to make data accessible—not just to engineers, but to product and account teams.

This mattered. Because now:

  • Product decisions were data-driven
  • Issues were detected immediately
  • Clients could be understood, not guessed

Speed without visibility is dangerous. You'll move fast and break things you don't even notice.

Engineers Own Cost

One of the most underrated changes: cost awareness.

Every architectural decision had to include a cost estimate. Not optional.

Engineers had to understand:

  • Infrastructure impact
  • Scaling implications
  • Budget constraints

This created a different mindset.

Instead of just asking "Will this work?", the question became: "Is this the right trade-off between performance and cost?"

That's how you build systems that scale sustainably.

Part VI: What Actually Moved the Needle

Why Two Engineers Outperformed Eight

If I had to summarise what made the biggest difference, it wasn't any single change.

It was the combination of:

  • Clear priorities (product)
  • Strong structure (process)
  • High ownership (people)
  • Reduced friction (communication)

We didn't add complexity. We removed it.

We didn't hire our way out of the problem. We designed our way out.

Conclusion: Delivery Is an Organisational Problem

Most teams think delivery speed is an engineering problem.

It's not.

It's an organisational problem that shows up in engineering.

If your team is slow, don't start by asking:

"How do we make developers faster?"

Start by asking:

  • Do we know what we're building?
  • Is work clearly defined?
  • Can people act without friction?
  • Are we aligned as a business?

Because once those are fixed, speed is the natural outcome.

Not the goal.

What's one structural change that moved the needle on your team's delivery speed? 👇

Andrei Nita
Chief Technology Officer
Building teams that ship