Team Structures

Multiple team structures can work to deliver software projects. There is no real one size fits all, however, there are common components that can be seen across different structures. At San Digital we believe that Engineer-led teams deliver great results for short duration high-impact projects.

The Surgical Team

One of the first discussions of software development team structure was in Fred Brook’s “The Mythical Man-Month: Essays on Software Engineering” written in 1975. The most famous principle discussed in the book is that adding more developers to a late project will actually delay it further. There is, however, discussion of the most appropriate structure for dividing up and delivering a software project.

“Mills proposes that each segment of a large job be tackled a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.”

This quote from the book sounds like an episode of Mad Men, the book even talks about team secretaries, but the intent is obvious, split the work up into team sized chunks and then support someone in getting the work done. The context for this team structure is important though, it’s from an era of punched cards and time-shared access to machines. Very few people had the skills to design software and computer access was limited, so the intent was to remove any obstacles and make best use of resources in the most organised way possible.

A surgeon being watched by a crowd of people

Whilst skilled developers are still scarce access to compute is now ubiquitous reducing the need to manage access.

The Agile Team

In the spring of 2000, a group of 17 developers wrote the Agile Manifesto which details 12 principles for software development that aim to improve the development process. The only mention of anything close to team structure in the manifesto is:

  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Some of these imply a structure but there is nothing explicit. In the years since the manifesto was written Agile with a capital A has grown with various methodologies wrapping themselves around the original intent of the manifesto as a mechanism to sell consultancy. As a result, a semi “standard” team structure has been created along with an associated set of ceremonies. A full cross-functional agile team tends to have a:

  • Product Owner (Tactical)
  • Business Analyst
  • UX Designer
  • Testers
  • Front end developers
  • Back end developers
  • Database Developers
  • Other ancillary roles such as content designer

The ceremonies generally are adapted from the scrum methodology with daily stand ups, sprints, print planning and retrospectives. Team members from the business are included in all ceremonies.

Post it notes

The ceremonies associated with agile e.g. the daily stand ups, are intended to ensure that there is communication between all of the team members and the business representatives. In practice, over a project of any length the business representatives become fatigued and attendance to the ceremonies decreases, interaction becomes mediated via the product owner and business analyst creating a disconnect.

Also, as some team members are not fully utilised, they will be on multiple projects that can cause issues with bloated teams. In some cases team members may even be full time on a project full time but finding work to fill time. Finding work is wasterful at best, and has the potential to be very detrimental to the project.

Agile as a set of principles works and delivers value, agile teams delivered by large consultancies do deliver results but can be very costly and risk losing the close collaboration between business and implementor.


Not in this case Just a bunch of disks, more a bunch of Developers. This is what happens when an agile team is created in an ad hoc way with people that have never worked together before and have to build relationships with each other as well as the business to get anything done. This can work out just fine, but it can also go badly wrong.

A herd of sheep


An engineer-led team can work within any methodology the key difference is prioritising communication between the implementing individuals and the business domain experts. Reliance on partial roles is also minimised by ensuring that members of the team have multiple skill sets e.g., a User Experience Engineer would cover roles traditionally defined as UX Designer 50% and Front-End Developer 50%. A single individual with both capabilities reduces communication and context switching for the whole team.

There are many places where capabilities are adjacent and can be amalgamated under a delivery focused role, this isn’t pre-defined and is very much determined by the teams make up.

Engineers working on a building site

Other functions need to be in place to enable the team e.g., delivery and project management but these should be in service to the Engineer-led team in a similar way to the Surgical Team but focused on a team not an individual.

If skills are required but not available in the team an expert should be seconded to the team with spare capacity to be able take the time to pair with one of the team members to help broaden their knowledge. A good example of this is solution architecture – an engineer could gradually increase their understanding by pairing, and then over time produce designs that are reviewed by an expert.

This team structure does not aim to produce the proverbial “Jack of all trades, master of none”. But more to create a T-shaped skill set, on the assumption that an individually fully engaged with the domain and user needs is more important than absolute mastery. Where depth of knowledge is required, it can be applied through pairing and review, which also serves to share knowledge and develop individuals.


An Engineer-led team aims to make the best of Agile and Surgical teams while avoiding the lack of cohesion that comes from a “bunch of developers”. Engineer-led is not ideal for all project types, however, for high impact (short, high value) projects the lower utilisation can be tolerated in exchange for lowering the outcome risk.

Sustainability - engineering a sustainable future

At San Digital, we believe the work we do today should positively impact the environment and not compromise the ability of future generations. It seems obvious, but large organisations continue to think sustainability is a box-ticking exercise and an inconvenience.

Agile Businesses

There are more than enough articles about agile software development; this post is about agility elsewhere.

Jumping into the FHIR - type systems and objects

We have been doing a deep-dive on FHIR implementations and tooling following our initial FHIR investigation. A critical area of investigation for any system, particularly a large distributed system with many clients and peers that need longevity and guided evolution is its type system. Use of a strict type system can have many benefits - interoperability, governance, data quality, security, performance, developer experience, reduced component complexity and the ability to evolve services with confidence

Integrating with Events

The San Digital team has worked with numerous organisations in both the public and private sectors to transform their applications architecture into a flexible and business-focused model. Working with events at scale is key to maintaining individual teams' agility.

The process of building a mobile app

The team at San Digital has extensive experience developing apps for mobile devices, smartwatches, and smart TVs; using native and hybrid technologies (and everything in-between!) including using Rust for complex comms.

Low friction development environments

While setting up a sample project from an unnamed large vendor the other week I was disappointed by having to read large amounts of documentation and run various bits of script to install dependencies and set up infrastructure. We live in a world that has tools old (Make) and new (Docker) that can be combined to make onboarding engineers low or zero friction.

Cloud-native FHIR platforms

Continuing our series of posts on web protocols, we have been investigating more specialist protocols, in this case, "FHIR". We have produced a document based on our research, investigations and experience.

Team Structures

Multiple team structures can work to deliver software projects. There is no real one size fits all, however, there are common components that can be seen across different structures. At San Digital we believe that Engineer-led teams deliver great results for short duration high-impact projects.

Rules of the Road

This is called rules of the road but they aren't rules they're more guidelines, so they're rules until there is a good reason to ignore them.

Estimating and delivering defined outcomes

Recently there has been a shift away from time and materials projects towards defined outcomes, driven by various legislative changes, specifically IR35, but also cost control in the procurement function of larger organisations.

The San Digital Stack

San Digital has been designed as a remote first business from inception, on the assumption that it's easier to add offices later if they are necessary in an agile way. To work in collaborative way completely remotely takes a carefully thought out set of tools. Some of the ones that we use are really standard and some are a little more interesting.

Test driven design, or planning driven development

Design processes in most business software development resemble peer review or crowd-sourcing. A putative design is presented to peers, who will do their best to find problems while the originator of the design defends it against these challenges. Ideally, where they are demonstrated incorrect or incomplete the process will iterate and an updated design produced and defended.

A human view of computer vision at scale

Computers analysing and acting on what they see is not science fiction or even a new concept, it has been a reality of humankind's drive towards hyper-efficiency since around the time I was born.

Building scalable frontends

Scaling frontends is hard, actually scaling all codebases is hard, frontends just happen to be particularly visible and have a tighter feedback loop and a higher rate of change. As with all codebases, it is in principle possible to scale development through standards and integration processes, but these are a poor substitute for communication. Once development moves beyond the scope of a single team, either progress slows to take into account of different processes or implementations drift away from each other over time. Teams need to find a way to operate independently towards a goal.

Cross platform native mobile development with Rust

San Digital have extensive experience of mobile development and the use of Android as an embedded operating system. We treated android as a deployment target target for Rust firmware as well as writing our intricate real time communications component for both iOS and Android. This approach has advantages, you can maintain a single code base for a complicated communications layer, while also taking advantage of the full native capabilities of each platform

The evolution of web service protocols pt 2

At San Digital, some of us have been building things for people since the dawn of the web. Our historical perspective helps inform us about technological culture and trends today, almost compensating for the creaking knees.

The evolution of web service protocols pt 1

At San Digital, some of us have been building things for people since the dawn of the web. Our historical perspective helps inform us about technological culture and trends today, almost compensating for the creaking knees.