Five steps to team design success


Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” – Conway’s Law

This prescient observation of how software structures tend to follow social structures was made in 1967 and remains essential today when considering team design. In recent years, enterprises have used a microservices approach focused on delivering small, autonomous services while DevOps has emphasized collaboration between developers and business operations. Through it all, some important team design principles have emerged that are relevant to enabling successful digital transformations.

Following these five team design principles will give you a much better chance of succeeding at digital transformation:

  1. Organize teams within bounded contexts. In large domains, the same word can mean different things to different people, so divide your teams into different bounded contexts. For example, you could have a few teams working in a sales context, and a different set of teams working in a support context. But they are all working towards the same goal within that larger domain. In doing so, you enable structures that relate to change together and can be organized more closely. Doing this also improves shared understanding and reduces cognitive load, while giving you the ability to trace and understand service interactions.
  2. Embed business stakeholders within teams. When designing teams, you want to make sure there is a good balance between technical and business considerations, so it is crucial to always embed business stakeholders in your teams. Engineering and product teams can model a solution to a problem better if they are more closely connected to the business owner. Embedding business stakeholders in teams reduces the communication barriers between development teams and users. It also enables decision-making and problem-solving to live in the team that is most familiar with the problem.
  3. Teams own services indefinitely. From my experience, successful teams own the product that they produce. When you have a team that owns the service they are building, they have a much better perspective on what to do with the product and features. The traditional approach was that a development team would build an application and throw it over the fence to operations. This is no longer effective in the cloud-native world where applications availability is the responsibility of the developer and not the underlying infrastructure or operations. Developers need to own what they build, watch it run, and remain in contact with the day-to-day operation of their software.
  4. Keep your team sizes in check. Team size is very important and it is imperative to find the right balance. What size should your team be? As your teams are bounded by context, keep them small and focused. Make sure your teams don’t get so large that they lose the context of the team. As team size grows, the number of links and interactions in the team grows exponentially, and the less effective that team gets. Also, as a team adds members, there is less ownership and a lower sense of achievement for each person on the team. When pursuing a large project, do not put 100 people on a single team. Start with a small A-team of your high performers that can produce a product you are proud of and can build on.
  5. Consider using geographical boundaries to split out services. There is a trend towards deploying centrally-located teams, and when you are embarking on a large project, it is important to have your teams geolocated. Geolocated teams allow for fine-grained communication where people can frequently interact together face-to-face. This leads to shared ownership of code and infrastructure, as well as lower costs when coordinating changes. This approach helps minimize the need for hand-offs and allows for cross-pollination of team members.

A common theme that runs through these team design principles is fostering effective communication. Things such as e-mails, meetings and presentations can be productivity killers. Once, it was decided that the team I was on would go one full year without giving any presentations, and that worked out very well. Presentations were replaced with open discussions that allowed a natural and unboxed communication of ideas, and the team was able to focus on their goals. There are better ways for teams to communicate than email and presentations, one being team messaging technologies and shared workspaces.

Changing organizational structure is an uncomfortable topic. But, applying these principles will result in teams that communicate more effectively and are focused on outcomes over tasks. Teams will become responsible for the entire lifecycle and you will get systems that are organized around a specific business domain and are independently deployable and scalable. Just remember, people are always the keys to the success of any project, and having the right teams in place of the right size will help deliver positive business outcomes.

To learn more about how DXC can help you embark upon your digital transformation, visit Transforming to a Digital Enterprise.

Mudasser Zaheer headshotMudasser Zaheer (Maz) is passionate about digital transformations. He is currently responsible for Public Cloud Application services at DXC Technology. His previous roles include Chief Evangelist, Digital Transformation Officer and Chief Product officer for companies like HP Enterprise.


Enabling the Enterprise Through Hybrid Cloud

Three distinguishing characteristics of modern on-premises cloud platforms

Transforming to a digital enterprise


  1. Stuart Cartwright says:

    Very informative and relevant article. Great steps to emulate.

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.