How do you account for Conway's Law in team design?

Conway's Law — the idea that your system architecture will mirror your communication structure — is central to how we approach team topology. We look at your architecture first, then design teams that own coherent parts of it rather than cutting along technology layers. A team that owns a whole domain end-to-end ships faster than a team that only owns the backend or the frontend of that domain.

Engineering Team Design for Startups

Sound familiar?

What happens when team structure isn't intentional

Most engineering teams don't think about structure until it's already causing problems. These are the patterns we see most often.

The team is too flat for the stage

Ten engineers all report to the CTO. Every decision gets bottlenecked. The CTO is in every meeting. Nobody has a clear owner for anything and accountability is blurry.

The wrong seniority mix

Too many junior engineers with one stretched senior trying to review all their work, mentor them and ship at the same time. Velocity stalls. The senior burns out.

Interviews that don't test what matters

The scorecards were written by whoever had time. Different interviewers ask different questions. Calibration is inconsistent and you're making offers without confidence.

Headcount grows but structure doesn't

The team doubles but the topology doesn't change. Teams form organically around whoever shouted loudest. A year later you need a reorg — which is painful and expensive.

What we cover

Six areas we design together

Each engagement is shaped around your current stage and what's coming next. These are the areas we can own, advise on, or hand over as a fully documented framework.

Team topology design

Stream-aligned teams, platform teams or functional squads — designed around your architecture and communication needs, not a generic org chart. Conway's Law baked in from the start.

Team structure mapped to system boundaries
Ownership model & team interfaces defined

Role levelling framework

Clear seniority bands from Junior to Principal, with explicit expectations at each level for technical depth, scope of impact, autonomy and mentoring responsibility. Built to scale with the team.

Levelling rubric per seniority band
Career ladder & growth path documentation

Hiring plan & headcount sequencing

When to hire, what to hire, and in what order. Headcount sequencing that builds capability without creating dependencies or bottlenecks — mapped against your 12-month delivery roadmap.

12-month headcount plan with rationale
Prioritised hire sequence & timing triggers

Job descriptions & hiring bar

Role-specific job descriptions that attract the right candidates and set honest expectations — not generic templates. Hiring bar definition that everyone on the panel is calibrated to before the first interview.

Role-specific JDs per open position
Hiring bar definition & panel calibration guide

Technical interview framework

Structured scorecards for each stage of the interview process, with evaluation criteria that actually discriminate between seniority levels — not trick questions, but signal-based assessments.

Stage-by-stage interview scorecard set
Calibration guide & debrief structure

Reorg planning & transition

When the existing structure no longer fits, a reorg needs a plan — not just a new org chart. We design the transition to minimise disruption to delivery, team confidence and product momentum.

Transition plan with sequenced milestones
Communication framework for the team

Who it's for

Right for teams at a structural inflection

Engineering Team Design tends to create the most value at specific growth moments — not as a continuous engagement.

Strong fit

Seed — making first hires

You're about to hire your first 3–8 engineers. This is the moment to establish levelling, process and topology — before bad patterns set in and are hard to unwind. Structural investment here compounds positively over the next 18 months.

Strong fit

Series A — scaling from 5 to 20

You have a team. It's grown informally and now the structure doesn't scale. Decisions are bottlenecked, ownership is blurry and your best engineers are spending time on coordination rather than building. This is the right moment to formalise.

Specific moment

Series B+ — planning a reorg

The structure you built at Series A is starting to buckle under team growth. A reorg is the right call but needs careful planning — the wrong transition destroys morale and slows delivery for months. We can help design it right.

Free Tool

Not sure how your team's structure is affecting delivery speed?

Run the Engineering Velocity Scorecard →

From TechTekGo

Further reading from our Engineering Leadership editorial series.

Guide Engineering Team Design Guide → Insight Conway's Law and Your Engineering Teams → Insight Signs Your Engineering Team Is Too Big → How-To How to Plan Your First Engineering Reorg →

FAQ

Common questions

Anything else? Book a call and we'll answer it directly.

The best time is just before you start growing — typically when your team is 3–5 engineers and you're about to hire your next two or three. The worst time is after you've already made the hires and the wrong structure is embedded. Most companies call us at either the Seed stage (making first hires) or at Series A (when the team has outgrown an informal structure).

Both, depending on what you need. The core engagement is process design: role levelling, job descriptions, interview scorecards and hiring bar definition. But we can also sit on interview panels, help evaluate candidates, advise on final decisions, and coach your team on giving calibrated feedback after each interview.

Conway's Law — the principle that your system architecture will mirror your communication structure — is central to how we approach team topology. We start with your architecture and design teams that own coherent domains end-to-end rather than cutting along technology layers. A team that owns a whole domain ships faster than a team that only owns the backend of that domain while another team owns its frontend.

A Head of Engineering should inherit a functional structure, not design it from scratch while also managing the team and shipping product. Engineering Team Design gives them — or you — the structural foundation before or alongside that hire: the levelling framework, topology, hiring bar and interview scorecards. The Head of Engineering then operates within it rather than spending their first six months reinventing it.

We work well alongside HR and People partners — they own the people processes (comp bands, onboarding, culture), we own the engineering-specific substance: what seniority levels mean technically, what a senior engineer should be able to do at this stage, what questions belong in a technical interview and why. The deliverables slot into whatever people infrastructure you already have.

A focused engagement — levelling framework, job descriptions and interview scorecards for a specific set of roles — typically takes 2–3 weeks. A full org design including team topology, hiring roadmap and reorg planning runs 4–6 weeks. We can also work in a lighter advisory mode alongside an active hiring period, reviewing and refining as you go.

Free 30-minute discovery call

Already seeing the cracks — or want to get ahead of them?

Tell us where you are with the team — how many engineers, what the topology looks like, and what's starting to break. We'll tell you honestly what the structural gaps are and what to fix first.

Book a free discovery call → All Engineering Advisory services

Build the Team Structurefor Where You're Going