Engineering Teams

Conventions First

Rules, strong base technical knowledge, and architecture rules — the foundation everything else is built on. Without shared conventions, every engineer and every AI tool makes different decisions. Inconsistency compounds over time.

Naming, file structure, error handling patterns, testing scope — decide once, follow everywhere.
Conventions accelerate teams by removing decisions that should not be made per-task.

IT evolves too fast for silos. Teams need to catch up together and form their own opinions.

Engineers need broader scope. Multi-area growth and multi-team experience matter more than deep single-area expertise.
A unified language (TypeScript everywhere) enables knowledge sharing and cross-project code review.
When frontend engineers can read backend code and vice versa, the team moves faster.

Members Are Broad Generalists

Specialists become architects. Members become generalists. A member who understands backend, frontend, and mobile at a working level contributes more than one who only knows a single area deeply. The deep expertise lives in the architects who design the rules.

Members spend most of their time on problem-solving, letting AI handle coding.
Engineers who enjoy understanding business problems and making tradeoffs will thrive.
Engineers who are only comfortable writing code will struggle.
See organization-structure for how architect and member roles relate across the full organization.

Ship Fast with Quality

Not a contradiction when the team focuses on the right layer. Speed and quality multiply when architecture enables parallel work and conventions prevent mistakes.

Backend engineers must think about: mobile impact, frontend contracts, long-term evolution, business implications. Backend is not isolated. Backend is leverage.

Smaller Teams, Better Design

AI changes the team size equation. One engineer with AI has the implementation capacity of a small team — with zero coordination cost between decision-makers.

Fewer people need to align → specs are simpler, decisions happen faster.
Design stays coherent — it comes from one mind, not a committee.
When a feature requires multiple engineers, designate one person as the design owner. Others contribute. One person keeps the vision coherent.
More documentation is not the answer. Fewer people aligned on a clear direction is.

Architecture Enables Org Scaling

Module ownership, clear boundaries, reduced change amplification. Architecture decisions are team decisions. Code structure should reflect team structure.

When architecture enables independent teams, fear of change drops.
When fear of change drops, shipping speed increases.

Metrics

Cycle Time: PR to release. Measures the entire pipeline, not just coding.
P50/P75 performance: real user experience, not synthetic benchmarks.
AI vs manual contribution ratio: how much work is AI-assisted.
Code review quality: depth of feedback, not speed of approval.

Decision Criteria

When scaling a team, evaluate: can each team deploy independently? Can they own a module end-to-end? If not, the architecture needs to change before the team grows. Adding people to a coupled codebase makes it slower, not faster.

When deciding team size for a feature: prefer smaller. Communication overhead grows fast with each person added. One engineer with AI can replace the output of a small team. Only add people when the problem demands multiple specializations — and designate one design owner to maintain coherence.

When choosing between depth and breadth for engineers: prefer breadth. A full-stack engineer with lead-level knowledge across areas contributes more than a specialist in one area who cannot review adjacent code.

Anti-patterns

Silos by specialty — backend team, frontend team, mobile team with no cross-review or shared context.
Adding people without fixing architecture — more engineers on a coupled codebase creates coordination overhead, not speed.
Conventions after the fact — trying to standardize after inconsistency is entrenched is much harder than starting with conventions.
Measuring only speed — cycle time without code review quality creates fast but fragile output.
Treating all leadership as one role — business constraints, org constraints, and technical constraints need different owners. See organization-structure.