Do the teams in your organization work well together? Are there protocols in place for smooth interaction?<\/p>\n\n\n\n
In Team Topologies<\/em>, software engineers Matthew Skelton and Manuel Pais show you how to set up your development teams to work as efficiently as possible. They recommend dividing your workforce into four types of teams, and then they outline three ways these teams can most effectively work together.<\/p>\n\n\n\n Keep reading to learn about the three Team Topologies<\/em> interaction modes.<\/p>\n\n\n\n\n\n\n\n Let\u2019s consider the most productive ways for the four types of teams in Team Topologies<\/em> to relate to each other. According to authors Matthew Skelton and Manuel Pais, there are three main ways your teams should interact with each other. The three Team Topologies<\/em> interaction modes are collaboration, x-as-a-service, and facilitating<\/strong>.<\/p>\n\n\n\n (Shortform note: In addition to interacting with each other, your teams can also solve problems by interacting with your customers. Customers can be valuable sources of feedback<\/a>, providing outside perspectives that can help your teams tune the user experience.)<\/p>\n\n\n\n Skelton and Paid argue that it\u2019s important to explicitly define interactions among your teams because, if one team needs to communicate with too many other teams to get work done, it can lead to delays. You should encourage teams to interact only when it improves the speed and quality of the work being done.<\/p>\n\n\n\n (Shortform note: To avoid the costs of unnecessary interactions, it may be helpful to explicitly state which projects will require interaction and which projects will not<\/a>. This way, you can be sure that your teams will only interact in situations in which you know that your organization stands to benefit.)<\/p>\n\n\n\n While interaction modes should be well-defined, it\u2019s important to note that these modes are not rigid, as your teams will often need to switch modes as their relationships and projects evolve. <\/p>\n\n\n\n The first mode of interaction is c<\/strong>ollaboration, which occurs when two of your teams come together to work on a shared project<\/strong>. As Skelton and Pais argue, your organization can use collaboration to generate new ideas<\/a> and ways forward by allowing two teams to work on the same project without having to wait on each other. However, you shouldn\u2019t allow more than two teams to cooperate on a single project. When you bring too many teams onto a project, you increase the amount of time spent coordinating and reduce efficiency overall. <\/p>\n\n\n\n (Shortform note: In addition to generating new ideas, collaboration can also increase morale and contribute to a positive work environment<\/a> at your organization. collaboration allows multiple teams to get to know each other and increases team spirit by bringing many individuals together to work toward common goals. Over time, this can create cohesion in your organization, as through multiple iterations your teams will get a better sense of the organization\u2019s big picture.)<\/p>\n\n\n\n According to Skelton and Pais, collaboration allows different teams to bring their various skills and approaches to a shared problem. If you notice that a team is working on a problem that extends beyond its areas of expertise, it may be helpful for them to cooperate with another team with complementary skills. Collaboration also serves as a powerful opportunity for members of both teams to share skills that will increase their autonomy after their collaboration ends.<\/p>\n\n\n\n (Shortform note: Collaboration between teams builds skills and practices that may be useful for other teams in your organization\u2019s future. To capitalize on this, encourage cooperating teams to extensively document their work<\/a>, especially any new solutions or work practices they establish. This way, if those skills or solutions become relevant to another team later on, they\u2019ll be able to quickly access that information.)<\/p>\n\n\n\n For collaboration to be successful, you should encourage both teams to take full responsibility for their shared project. Your teams may cooperate more or less closely depending on how intertwined their projects are. At times, your teams will remain more distinct, offering each other unique knowledge and perspective. At other times, teams might more fully merge, acting as a larger team with many hands working toward one goal.<\/p>\n\n\n\n For example, suppose the team that works on your app\u2019s content algorithm wants to cooperate with the UX team to innovate novel ways of presenting content to app users. This shared goal requires heavy use of both teams\u2019 products, so these teams would likely need to cooperate closely. By contrast, if your UX team needed to cooperate with the team charged with your app\u2019s security features, they likely wouldn\u2019t need to merge as fully, as their respective projects are more distinct from each other.<\/p>\n\n\n\n (Shortform note: To encourage both cooperating teams to take responsibility<\/a> for a shared project, you should provide shared incentives that they must work together to achieve. In The Five Dysfunctions of a Team<\/em><\/a>, author Patrick Lencioni recommends setting goals across both teams and rewarding both teams<\/a> for meeting these shared performance goals. By creating these shared rewards, you\u2019ll encourage each team to prioritize shared results over the team\u2019s individual interests.)<\/p>\n\n\n\n Because of Conway\u2019s law, Skelton and Pais note that software produced by two of your teams working in collaboration will result in an architecture that splits operational responsibility between the two teams. This blurring of boundaries can cause cumbersome monoliths to form if you leave it unchecked. To prevent monoliths from forming, when it comes time to actually deploy a piece of software, you should encourage one team to take sole ownership of the project from that point onward.<\/p>\n\n\n\n (Shortform note: When deciding which of the two cooperating teams should take ownership of the final product, you should give control to the team that is best equipped to manage the software going forward<\/a>. Often, one team will be more technically qualified than the other in terms of professional experience and skills. If not, you should consider which team originally owned the project, as they\u2019ll likely be more invested in its continued success.)<\/p>\n\n\n\n Skelton and Pais\u2019s second mode of interaction is the x-as-a-service<\/strong> model. In the x-as-a-service model, one team uses a software product provided to them by another team<\/strong>. This model increases efficiency by preventing your teams from wasting time on problems that other teams have already solved. As opposed to collaboration, one team may provide their product to however many of your teams can make use of it, thanks to the low communication requirements of the x-as-a-service model.<\/p>\n\n\n\n (Shortform note: The x-as-a-service model is especially relevant for your organization\u2019s cloud computing services. Using cloud computing, you can ensure that your workforce can work and communicate no matter where in the world they are<\/a>. As remote work becomes more common<\/a>, you may need to assign more teams to provide cloud services to an increasing number of internal consumers.)<\/p>\n\n\n\n X-as-a-service interactions are common between platform teams<\/a> and other teams. For example, one of your platform teams might develop and maintain the software that other teams in your organization use to communicate with each other in real-time. While the other teams offer feedback, your infrastructure team maintains the software on their own, treating the teams that use it as consumers of their own product.<\/p>\n\n\n\n (Shortform note: The x-as-a-service model has striking similarities to the concept of internal customer service, which is the idea that customer service principles can be applied within your organization to increase employee satisfaction and effectiveness<\/a>. In the x-as-a-service model, providing teams are responsible for the customer experience of internal software consumers, ideally providing them with a product that makes their jobs easier and incorporating their feedback the same way many organizations make use of customer feedback.)<\/p>\n\n\n\n According to Skelton and Pais, your providing teams must have a clear understanding of the needs of the teams that use their products. The software they produce must be highly polished and easy for teams throughout your organization to use. Otherwise, it will only cause delays as other teams will have to wait on the providing team to troubleshoot and fix bugs. To avoid these kinds of situations, you can encourage the providing team to focus on features that improve the user experience.<\/p>\n\n\n\n (Shortform note: As they attempt to improve the internal user experience, providing teams should focus specifically on creating strong communication channels<\/a>. By making it easier to access knowledge within their software, providing teams help consuming teams both use the software itself and communicate issues with the providing team.)<\/p>\n\n\n\n To streamline x-as-a-service interactions, instruct your providing teams to create guides for how to use their programs and how best to communicate feedback. Using these guides will help your other teams to better understand and use the software products.<\/p>\n\n\n\n (Shortform note: Providing teams can use feedback from consumer teams to improve the quality of their software guides. Experts recommend that you use internal feedback to create FAQs (frequently asked questions) and troubleshooting guides that help address common problems<\/a> consuming teams encounter with a piece of software. A well-made troubleshooting guide saves time for both teams in an x-as-a-service interaction, as it empowers consumer teams to solve their own problems without waiting for assistance from a provider team.)<\/p>\n\n\n\n The final mode of interaction Skelton and Pais describe is facilitating<\/strong>. <\/strong>Facilitating occurs when one of your teams needs assistance, expertise, or knowledge from another team<\/strong>. Your facilitating team focuses on imparting new skills and knowledge to another team, while the other team attempts to learn new skills they can apply to their projects, thereby increasing productivity. <\/p>\n\n\n\n (Shortform note: The skill sharing that takes place in facilitating interactions can be especially important in helping get new hires up to speed<\/a>. While new hires will also learn from the other members of their teams, you can make use of facilitating to speed this process along.)<\/p>\n\n\n\n Facilitating should be the default mode for your enabling teams<\/a> and will be most common in interactions involving those teams. However, facilitating can occur between any two teams when one team needs specific knowledge that another of your teams has access to.<\/p>\n\n\n\n In a guiding interaction, the guide team does not<\/em> work on the other team\u2019s software. This allows the team that’s receiving guidance to maintain full end-to-end ownership of their products. Because the facilitating team cannot directly impact the other team\u2019s software, it\u2019s important that you encourage receiving teams to maintain an open mind. When the team receiving guidance is unable to accept help due to pride or other factors, they won\u2019t fully internalize new information, which means your facilitating team\u2019s hard work will be wasted.<\/p>\n\n\n\n (Shortform note: Recent psychological research corroborates Skelton and Pais\u2019s assertion that open-mindedness impacts a team\u2019s ability to make use of facilitating. Studies have shown that open-mindedness increases a group\u2019s capacity to learn<\/a>. Experts theorize that this occurs because open-minded individuals and teams are more able to recognize their own shortcomings, which in turn makes them more receptive to growth.)<\/p>\n\n\n\n Facilitating teams typically work with many other teams to increase productivity and sharpen skills across your organization. By providing their outside perspective, guiding teams<\/a> can help your other teams identify areas for improvement.<\/p>\n\n\n\n (Shortform note: One way facilitating teams can help sharpen skills is by conducting code reviews, in which they manually look over another team\u2019s code<\/a>. By getting hands-on with another team\u2019s work, they can provide much more detailed feedback and training.)<\/p>\n\n\n\n As Skelton and Pais state, facilitating teams can also help identify patterns in interactions among your other teams. For example, they might notice that many teams have the same issues with the code provided by a single complicated-subsystem team. They can then present these issues to the complicated-subsystem team and, if necessary, present new approaches that might help address them.<\/p>\n\n\n\nTeam Topologies Interaction Modes<\/h2>\n\n\n\n
Mode #1: Collaboration<\/h3>\n\n\n\n
Mode #2: X-as-a-Service<\/h3>\n\n\n\n
Mode #3: Facilitating<\/h3>\n\n\n\n