Structuring a Software Delivery Team for Maximum Collaboration

Share the joy

I have been working at JustGiving for almost 3 years and since then we have grown and shaped ourselves in many different ways, albeit never compromising our mission and values, which are the main reasons my job is so rewarding. That and people.

One of the biggest challenges I faced during this period was to help scale the Software Delivery Team from about 20 to over 60 people whilst maintaining a delivery focused group working together in a somewhat consistent way.

I like to think that part of my role is being the “social architect” for the Software Delivery Team since one of my responsibilities is to support and nurture the team from the bottom up, and make sure that scale as well as transformation, do not come at a cost for engagement and collaboration.

When you look at it, it’s about fostering our values by creating the space and structure that allows people to do 3 things:

  1. Share and blend their talents to create and deliver amazing products
  2. Discuss ideas, have constructive debates and actively listen to everyone’s voice in an all inclusive decision making process
  3. Use agility to quickly test ideas, reflect and adapt, fail fast and learn as opposed to unduly plan every single move

We do these things by organising ourselves into Swarms, Squads, Specialists and Disciplines as depicted in the diagram below. So let me explain you all of these concepts one by one.


Before I begin here’s a disclaimer:

Reality is not always like pretty diagrams, however we always aim to evolve into the best version of ourselves. The most important thing is that we are in it together to deliver great products which are scalable, maintainable, extensible and highly available! So let’s start…

Swarm is a group of people with a common mission such as building the mobile app or providing reliable payment solutions, and is sponsored by a Management Team (MT) member who sets the stage for the people in that group to perform. Effectively this means that the MT devises the key areas to focus on each quarter and it is then up to each Swarm to execute and keep a close eye in the metrics that help us measure success.

Within Swarms we have the concept of a Squad. In essence a Squad is a group of people (.NET Developers, Front-End Developers, Software Developers in Test), who have the skills and ability to turn ideas into a living product. They are self-organising teams that determine their own way of working but for the most cases use Scrum or Kanban which are Agile Development Practices.

Part of the Squad is also the Lead Developer who helps align the Squad with the business direction, optimises the team output and keeps the fingers on the pulse of how the team is operating. The Lead Developer is a facilitator, organiser and invests time and energy to enable the Squad to thrive!

Each Squad works closely with Specialists who provide capabilities such as Design, UX, Copy, Architecture, CTO, DB Administration and Operations. Specialists work across different Squads and are involved in different projects but they are part of the day-to-day activities and sit closely with the Squads. So even though a Squad is the basic unit of development they work with Specialists every single day.

To glue all of this together the Product Manager (PM) comes along. The PM understands our users, the market competition and future trends, therefore setting the vision, owning the product backlog and setting priorities. In our structure, the PM is part of a Swarm, however sometimes we have more than one PM in a Swarm and sometimes we have a PM working with more than one Squad.

Things brings us to the Discipline areas, which are groups of individuals that have similar skills and are working within the same technology area, for example Front-End. Each Discipline meets regularly to discuss technical evolution, align best practices and keep consistency across teams. A Discipline spans across multiple Squads and even Swarms and is brought together by a Discipline Lead who facilitates collaboration and communication between the group and understands the demand of their disciple skills across the bigger team.

Finally, something that is not depicted in the diagram but is very important, are Communities of Interest. These are groups of people with common interests that get together for all different reasons, such as personal development, skills development, fun, etc. for example we have Communities of Interest around:

  • Functional Programming
  • Gameblast
  • Football
  • Blogging

So this is pretty much how we organise ourselves in the Software Delivery Team. It is within our nature to always better ourselves and establish the right conditions and environment for people to collaborate and grow. That is to say that what has been described in this post may have evolved by the time you finish reading! But this is good news for people that are passionate about collective thinking and maximising collaboration. I know I am, what about you? Share your ideas in the comments section below.

Thanks for reading!

Originally published on Medium.

Share the joy

About the author

Ana Henneberke

Head of Software Delivery - I love team dynamics, agile engineering practices, collective thinking, inclusion and science of happiness!

View all posts

Leave a Reply

Your email address will not be published. Required fields are marked *