In some organisations, the way engineering teams are structured can significantly impact the ability to deliver software effectively. For smaller systems supported by only a few engineers, this is often less noticeable. However, as systems grow in size and complexity, team structure becomes increasingly important.
Ideally, engineering teams should be organised to support effective communication and ownership. The fewer teams that need to coordinate to deliver a change, the easier it becomes to move quickly and safely.
There is no single “perfect” team design. The optimal structure depends on the nature of the systems being built, the types of changes being made, and the frequency at which those changes occur.
An engineering topology assessment examines how teams are currently structured, how they interact with the systems they support, and whether the current organisation enables or hinders delivery.
Signs You Might Benefit From an Engineering Topology Assessment
Organisations often consider an engineering topology assessment when they start experiencing challenges such as:
- Changes require coordination across multiple teams, slowing down delivery.
- System ownership is unclear, with multiple teams responsible for overlapping areas.
- Teams frequently block each other due to dependencies in the architecture.
- Platform or infrastructure teams are overloaded supporting too many product teams.
- Rapid company growth has outpaced organisational design, leaving team structures unclear.
- Engineering leaders feel the organisation is becoming harder to scale, even though headcount is increasing.
In these situations, reviewing how teams are organised around systems and capabilities can help restore delivery flow and improve long-term scalability.
Types of Engagement
I have seen many organisations reach this stage as their systems and teams scale. There are a couple of forms of engagement I can offer to support.
Engineering Topology Assessment
An engineering topology assessment begins with a discovery phase to understand how engineering work is currently delivered across the organisation.
This typically includes reviewing:
- Recent engineering initiatives and how they were delivered.
- The systems currently supported by engineering teams.
- Team structures and reporting lines.
- The distribution of skills and responsibilities across teams.
- Dependencies between teams when delivering changes.
From this analysis, I develop a recommended team topology and operating model alignment. This outlines how teams could be structured around systems, capabilities, or value streams to improve delivery flow, clarity of ownership, cross-team communication and long-term organisational scalability.
The outcome is not simply a new org chart, but a practical framework for structuring teams in a way that better supports the organisation’s engineering goals.
Professional Pathways
In many organisations, unclear or inconsistent career progression frameworks can contribute to organisational friction and make it difficult for engineers to grow into leadership roles.
As part of a topology engagement, I can also support the development or refinement of engineering professional pathways.
This involves defining clear expectations for different levels of engineering seniority, including technical responsibilities, leadership expectations and/or scope of architectural ownership.
Clear professional pathways help organisations:
- Support engineers in progressing their careers
- Identify leadership potential earlier
- Ensure consistent expectations across teams
- Strengthen the pipeline for future technical leadership roles
Engagement Format
Before beginning the engagement, we will hold an initial discussion to understand the organisation’s engineering structure, platform complexity, and current challenges.
Based on this conversation, I will propose a structure for the engagement. While each organisation is different, a typical approach may include:
Phase 1: Discovery & Assessment
A structured discovery process involving interviews with engineering leaders and teams, along with a review of systems, team structures, and recent delivery patterns.
Phase 2: Topology Analysis
Analysis of current team interactions, dependencies, and delivery constraints to identify areas where the current organisational design may be impacting delivery.
Phase 3: Recommended Team Topology
Development of a proposed team structure and operating model aligned to system boundaries, capabilities, or value streams.
Phase 4: Organisational Alignment
Where appropriate, defining supporting changes such as professional pathways, ownership models, or communication patterns.
Phase 5: Handover
Presentation of findings and recommendations, along with documentation to enable the organisation to implement changes internally.
Example Expected Outcomes
At the start of the engagement we will agree the specific deliverables expected. These may include:
- Assessment of current engineering team structures
- Identification of delivery bottlenecks caused by organisational design
- Analysis of system ownership and cross-team dependencies
- Recommended team topology aligned to system boundaries or value streams
- Optional development or refinement of engineering professional pathways
Rates
Engagements can be structured on either an inside or outside IR35 basis, depending on the nature of the work and client requirements.
Day rates and commercial arrangements can be discussed following the initial scoping conversation.
