Principles for strong engineering teams.

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. Moving fast should not mean skipping review, ignoring established practices or shipping code the team cannot explain.

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.

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 constraint 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 is now slowing 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 the code or decision cannot be explained, it is not ready to ship.

Engineering teams should be all-in on AI.

AI-assisted engineering should be treated as a team capability, not left to individual preference. When effective practices remain with only a few people, the gap in speed, quality and ways of working grows across the team.

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 amount to team-wide adoption.

Choose workflows where AI can improve an outcome you can assess. Match adoption to the team’s data, security and quality constraints, and change course when the evidence does not support the approach.

Explore the AI Engineering Review for an independent view of current use and what needs to change.

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. Once those boundaries are set, give people room to experiment and 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 are often what 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.

Discuss your hiring or engineering organisation if expectations, roles or assessment are unclear.

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

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 where it improves the work, and verify its effect on quality and outcomes.

Where these principles are useful

Use them when you need to:

• Understand why delivery has slowed or become unreliable.
• Decide whether technical debt, team structure or unclear product direction is the real constraint.
• Assess a senior engineering hire or the shape of an engineering organisation.
• Introduce AI working practices without weakening quality, security or accountability.
• Decide which standards help the team move and which have become unnecessary process.