High context. High ownership. High standards. Low bureaucracy.

Give engineers the problem, not just the ticket.

A ticket is a pre-defined task. Strong engineering teams are not conveyor belts for those tasks: engineers understand the customer, the problem, why it matters and the boundaries before they build a solution.

Bring engineers into discovery, customer conversations, ideation and design early. That context improves technical decisions and creates genuine ownership. It also turns product development into a shared activity instead of a hand-off between functions.

Engineers should help decide what gets built, not just how it gets built.

Move fast. Don’t lower the bar.

Startups need urgency. Decisions should not sit around for weeks and projects should not expand indefinitely. But speed is not an excuse for work nobody understands or standards nobody can defend.

Set the quality bar first. Then find ways to move quickly inside it: reduce scope, remove dependencies, automate toil, use better tools, make decisions faster and hire people with good judgement.

Set the bar, then move fast.

Scope is the easiest lever for speed.

Scope means the amount of work included. When a project looks too large, the first question should not be “How do we deliver this faster?” It should be “What is the smallest useful version that gives us something meaningful to learn?”

Small projects reduce coordination, encourage continuous shipping and create faster feedback loops. If something truly cannot be made small, break it into stages that produce useful outcomes independently.

Don’t ask how to make a big project faster. Ask how to make the project smaller.

Fix the constraint, not the backlog.

There will always be more features, maintenance and infrastructure work than a startup can justify doing. The goal is not to clear every task. It is to identify the constraint—the one thing genuinely limiting progress or customer value now.

That might be a fragile deployment process, unclear product direction, one missing senior hire, a recurring reliability issue, a decision nobody owns, or technical debt that slows every project.

Prioritise the blocker or enabler that changes what the team can do next.

The fastest teams communicate more.

Code is not the only useful output of an engineer. A good design note can prevent weeks of wasted implementation. A clear status update can unblock five people. A documented decision can stop the same debate repeating six months later.

Prefer proactive communication over silent execution. Write down decisions, risks, assumptions and trade-offs. Make it easy for the team to understand what is happening without scheduling another meeting.

If you can’t explain the code or the decision behind it, you’re not ready to ship it.

Engineering teams should be all-in on AI.

AI-assisted engineering is becoming part of the job, not an optional productivity hack for a handful of enthusiasts. Teams that dip their toes while a few individuals radically change how they work will create an adoption gap that compounds quickly.

Engineering leaders should have strong opinions about how AI changes discovery, design, implementation, testing, debugging, review, documentation and knowledge sharing. They should actively spread effective practices across the whole team, not simply buy licences and wait.

A few power users do not make an AI-enabled engineering team.

Guardrails create speed.

The answer to AI risk is not to move slowly. Set clear boundaries—often called guardrails—that let everyone move quickly: approved tools, data handling, review expectations, validation, security, intellectual property, decision rights and non-negotiable quality standards.

The same principle applies beyond AI. Good engineering standards remove decisions the team should not have to keep making. Within those boundaries, give people room to experiment and move fast.

Set the boundaries once. Move quickly inside them.

Hire people who make the team better.

Technical ability matters, but in a small team it is not enough. Communication, judgement, ownership, curiosity, humility and the ability to make other people more effective often separate a strong engineer from an exceptional one.

Avoid over-rewarding individual heroics. The highest-impact engineer may be the person who reduces ambiguity, unblocks others, improves the system, raises standards, shares context and helps the whole team move faster.

In a ten-person engineering team, soft skills aren’t soft. They’re infrastructure.

Create autonomy, mastery and purpose.

The job of engineering leadership is to create the conditions in which good people can do their best work.

How the pieces work together

Together, the principles form a simple sequence for choosing, delivering and learning from engineering work.

1. PurposeStart with the user and the problem.
2. ContextBring engineers into discovery early.
3. OwnershipLet engineers help shape the solution.
4. FocusPrioritise the blocker or enabler with the most leverage.
5. ScopeFind the smallest meaningful thing you can ship.
6. StandardsSet the quality bar and guardrails.
7. ExecutionMove quickly and communicate proactively.
8. FeedbackShip to users and learn from reality.
9. AI leverageUse AI aggressively across the loop to make the team better.