I've been an engineer, engineering manager, consultant to engineering teams, founder/CEO, and product leader. I've turned around teams that were moving slowly, and I've been through stages of high speed and painful slowdowns myself. One thing has become obvious: you get speed when engineers feel empowered, and you lose it the moment you take that empowerment away.

Below are the principles that make the biggest difference.

Why it's worthwhile

Engineering takes deep thought, creativity, and focussed effort. Nothing demotivates a team faster than shipping something that customers barely use. If you want engineers to move quickly, they need to trust that the work is worthwhile, that what they’re building matters and has a real shot at being adopted.

Empowerment starts with meaning.

Provide the context

Great engineers want to understand the context behind what they're building. They want to know how the system will evolve, what future requirements might look like, and how their current architecture decisions will hold up over time.

Everyone has over-architected and under-architected something before. Those scars make engineers keenly aware of tradeoffs. So give them the information they need:

• How confident are we that this feature will be adopted?
• What have we validated?
• What’s still unknown?
• What does the next 3–12 months of roadmap actually look like?

Without context, engineers guess. And guessing slows everything down.

...and the Appetite

Telling any expert how long their work should take is a surefire way to look like an asshole. "And I need this in two weeks" type discussions lead to either demotivated developers forced into cutting corners or burning themselves out, or you looking ridiculous because it was a two day job.

A better conversation starts with: "Here's the context and what we want to achieve/learn with this release. What can we ship in two weeks?"

Now engineering is empowered to explore solutions, negotiate scope, and maintain quality. You may land at two months or two days, but it has been a peer negotiation to arrive at the right level of investment, not a top-down directive.

That's where speed comes from.

Committed dates

Estimating is notoriously hard. Agile exists because we're bad at predictions. But dates still matter: not for pressure, but for alignment. Marketing, sales, and partners all have their own schedules.

With a clearly prioritised list of features, engineering works out realistic dates based on capacity, who's best suited to each feature, and how much parallelisation is possible.

Developers aren't fungible. Two developers on a feature rarely means half the time. Sometimes it means twice the time due to conflicts and dependencies. Let engineers and engineering management make the call about what's most efficient and fastest.

No fake dates

If you want to kill trust and motivation, give teams fake dates tied to external events that quietly slip away.

I've seen it happen time and again that a leader puts a date out there: a partner launch, sales deal closing, board meeting, you name it.

Engineering rallies and kills themselves to meet the date. Then the partner delays, the deal dies, or they run out of time in the board meeting to look at the product.

If this happens once or twice, engineers understand this. Of course they're disappointed but it's out of your control.

If this happens frequently, dates become meaningless and teams slow down.

Limit Crunch Mode and Callouts

Crunch mode happens. A critical bug, a big launch, a presentation. It's times like this that bond a team. I still remember fixing a production issue at 11pm and sharing pizza in an empty office kitchen with my teammates. That camaraderie is powerful.

But crunch mode cannot be the norm.

Engineers on call should be compensated even if they don't get called. Being on call means limiting their evening and weekend plans so they're ready to respond if needed.

And if out-of-hours callouts happen too often, that’s a leadership problem: fix the underlying issues or staff a proper rotation.

Nothing burns out a team faster than constant emergencies.

Empower Engineers to Make Architectural and Technical Decisions

Engineers are custodians of their systems. They want the software to work as intended, be able to be extended cleanly, not be expensive to maintain, and stay fit for purpose. When they own a system end-to-end, they make better decisions, and move faster because they don’t need to constantly ask for permission.

For larger architectural and technical decisions, especially in teams bigger than a couple of developers, a lightweight RFC is ideal. One engineer, tech lead, or architect is the decision owner, with input from a small group of engineers and product peers. Feedback is time-boxed, usually to 5 days, and then the owner decides.

This prevents top-down directives that demotivate engineers and stops endless debate cycles that kill momentum.

Poor architecture and unaddressed tech debt slow teams silently. Empowered ownership reduces both.

Tech debt

Tech debt inevitably makes its way in over time. It slows new feature delivery and demotivates engineers who constantly have to deal with suboptimal past decisions.

If we're properly empowering engineers: giving them context, ownership, and reasonable timelines, we naturally reduce the amount of new tech debt we're creating. Engineers should not feel pressured to make bad compromises they know will hurt the system later.

For existing debt, treat it as an intentional part of the roadmap, not a “when we have time” fantasy. KTLO (Keep The Lights On) work often lands around 30% of capacity. Involve engineers or EMs early in roadmapping so that tech debt is visible, scoped, and dealt with at the right time.

And don’t fall behind on dependencies. It’s a false economy. A one-hour upgrade today becomes a two-week migration next year. Set a policy for how many major versions behind you’re willing to tolerate.

No-Blame Culture

Early in my career I screwed up, big time. We maintained databases containing critical financial data for national postal services. One day I ran a SQL update that should’ve deleted one row. It deleted ten million.

The only reason we recovered was because I immediately shouted for my manager. He sprinted over, we stopped log shipping, and recovered from backup. Crisis averted.

If I had been scared of punishment, junior me might’ve tried to fix it alone, which would've only made it worse, even irrecoverable. Instead, we had psychological safety to surface problems without hesitation.

A no-blame culture turns potentially catastrophic mistakes into recoverable ones, and it surfaces bad news fast.

It isn’t about avoiding accountability. It’s about removing fear so people raise issues early. When someone brings us bad news, the first words out of our mouth should be “thank you.” The moment people start hiding problems or hesitating, the team slows down. You can’t fix what you can’t see.

When an engineer speaks up and says: "hey, CPTO, I wasn't able to ship this on time because I had to wait three days for you to reply to my questions" you're in a good place.

Praise that honesty publicly and own where you bottlenecked the team, and fix it. That behaviour spreads and speeds follows.

Make Space for Everyone to Be Heard

Removing fear of blame is only half of psychological safety. The other half is valuing and acknowledging everyone's contributions. Especially for quieter engineers, there's a fear of being ignored as they don't naturally jump into discussions.

Good process makes contributions accessible and safe for everyone, not just the confident extroverts. RFCs, PRDs, roadmapping, and biweekly meetings open up regular forums for collaboration.

A written agenda circulated before the meeting gives more introverted types who don't naturally speak up in meetings a chance to gather their thoughts and share in advance. Starting meetings with a few minutes of silent reading and commenting helps too.

Once the discussion begins, a structure prevents dominant personalities from taking over. The chair, who is often the decision maker, time boxes conversations to focus discussions and stops a single voice from monopolising the meeting.

The chair uses prompts like "What's your view?" or "What are we missing?" to invite dissenting opinions and open the conversation to all. Specifically say "I could be wrong" or "I've changed my mind on this before" lowers the social cost of disagreeing.

And sometimes the most powerful tool is silence. Those awkward long silences often prompt folks who would never interrupt on their own to speak up, surfacing valuable new insights.

Finally, there must be a single clear decision maker. They ensure all voices are heard, weigh the options, and choose a direction. Every voice is heard and momentum isn't lost as the team can move forward with clarity.

Call out their work

It's usually a product manager or leadership presenting new features or the roadmap internally. Make sure engineering gets explicit credit.

I've done credit reels, had engineers demo features at our all-hands, dropped random Slack high fives, and named engineers directly in quarterly business reviews.

Engineers aren't code monkeys. They are co-creators of the product. Visibility and acknowledgment is motivation which leads to momentum.

Sprints are immutable

One of my principles is that each two week sprint is immutable. Once committed, they don't change except in exceptional circumstances.

Engineers do their best work when they trust that their focus won’t be disrupted mid-stream. Flow state is a real and ultra-productive mode. Asking them to context switch between different pieces of work only makes everything take longer.

Immutable sprints gift the team clarity and focus that creates speed.

Empowering Engineers Creates Speed

Empowering engineers is a key piece of creating high velocity product teams.

Build worthwhile things.

Give context.

Let them negotiate scope.

Protect their time.

Don’t play games with dates.

Limit crunch mode.

Create a no-blame culture.

Make space for quieter voices.

Let them own architecture.

Handle tech debt intentionally.

Give credit publicly.

Keep sprints stable.

Do this well, and engineering becomes the engine of speed.