Over the years, we noticed how difficult it is to develop software with high performance and efficiency and how important the team factor is in this equation. Sometimes we don’t realize that we do not always need the best language, technology, or any advanced or crazy concept to achieve the best results. What we do need, instead, is to maintain the best organizational structure in mind so as to keep things simple.
By teaching us how we must prepare ourselves to achieve the best mid and long-term cost-benefit for our team, the Team Topologies concept has helped guide us in our current evolution at Pipefy. When studying Team Topologies we noticed significant similarities while revising all the foundations of software development. This gave us insights into every stage of this process.
We could observe that Team Topologies is a different way of thinking about how a company must be organized, as it is not a methodology exclusively aimed at developers and effectively concentrates a wide range of techniques to help both managers and devs. By focusing on the sought-after status quo or fast flow, this approach aims at a better organizational architecture so as to obtain the highest quality in deliveries, high performance, and maturity of a company, which benefits the whole workflow and mitigates factors such as stress and burnout.
I like to think of Team Topologies as not only an agile methodology, as Matheus Skelton went further by skillfully combining many techniques and models, focusing on the best in terms of XP, DevOps, SRE, among others, and delivering solid and high-quality technical content at every phase. All of this can be adapted to build an organized model based on our team’s communication structure and interaction.
- The problem with Organizational Charts
- Conway Law
- Reverse Conway Law
- Size of the team
- Cognitive Load
- Fundamental Topologies
- The problem with Organizational Charts
Most companies around the world are organized into hierarchies, which are visually represented by a complex, dull, and linear Hierarchical Chart that shows teams, departments, and units. This vertical work and communication model implies that such division of control can create an environment that allows for a great deal of innovation. At the same time, everything is delivered fast, as if we operated as a production line in a factory.
But we know that if we build software in this hierarchically restrictive model, we will cause problems in contribution, communication, and, most importantly, engagement, certainly creating unreal expectations due to communication coming from the sides or the top of the chain. As a result, developers may only want to know how they are placed in this hierarchical chart, and turn their own workflow into bottlenecks on a daily basis.
Even in the best-organized companies, this chart is usually outdated, difficult to read, and totally out of sync with the real world. If we need to keep teams motivated, this model will make it more difficult for teams to deliver their best results.
As Pflaeging suggests, the key to success in organizational work is understanding the interaction between the informal structure and the value generation structure.
Team Topologies focuses mainly on empowering teams by setting dynamic organizational structures with well-defined interaction models that facilitate the rapid adoption of new conditions by a team. So when seen as building blocks, engineers, devs, and POs work together since they are a group of people acting in the same context.
With the aim of eliminating the rigidity and difficulty of maintaining the organizational chart system by applying the TT concepts here at Pipefy, we studied and discussed communication-centered organizational models. For this purpose, we need to understand the Conway Law.
- Conway Law
When we think of a company and consider its successful growth, the organization becomes a key concern, as well as its team structure, software structure, and, most importantly, its communication.
Created in 1969, the Conway Law gives us an opportunity to consider these aspects as the main focus of our analysis, and later we found out that ignoring this law can make all the difference on the impact your software can produce or not.
Conway’s thesis defends that when companies design their systems, they are destined to produce copies of their communication structures. This can be good or bad, as big communication problems in your company may probably reflect on the quality of your product.
Simply put, if communication with business teams is not clear, this will result in fewer chances of having a successful product and it would be no use working with the best technologies and engineers. On the other hand, if an organization is arranged into functional silos such as QA, DBA, Frontend, Backend, etc., it is unlikely that a well-designed end-to-end product can be produced.
If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.
Ruth Malan.
- Reverse Conway Law
In the Conway approach, we tend to inevitably copy our organizational model into our code. When we invert this concept, we replicate our software model in the organization. In other words, we have to reshape the way teams communicate before the software is ready.
If the state of an organization must include its teams and organizational structures to achieve a desirable architecture, then it should support the abilities of the teams to best perform their work, from design to development, with no need for complicated communication among teams.
In other words, when we apply the Reverse Conway Law, we can design our teams so that they become a match to the needs of software design due to the fact that developers were given different functions.
As a safety measure and with the changes brought by the fast flow, we must keep in mind that the scope of the team and its architecture must be aligned. Therefore, after having a draft of the attributes for the tea, we must apply code architecture best practices, such as:
- Low coupling: Components must not be strongly dependent on other components.
- High Cohesion: Components must have clear responsibilities and boundaries, by indicating a strong relationship with their internal elements.
- Software architecture principles like SOLID (single responsibility, open-closed, Liskov substitution, interface segregation, and dependency inversion), KISS (keep it simple, stupid), and DRY (don’t repeat yourself)
These practices facilitate optimization and enhance the way we explore how our architecture facilitates fast changes at a relatively low cost.
- Size of the team
Once we have a good idea of our team in relation to its size, we must take into account the relationship among its members. Because Team Topologies mainly focuses on breaking any possible communication barriers, it’s no use counting on the best engineers in the world if there are communication breakdowns.
The limit of a team is more than just a number. We must think that a team has to foster internal trust and a good rapport as in a soccer team. Dunbar’s research shows that when we are able to foster trust within a small team, this results in better productivity. Of course, there are exceptions in which large teams are able to keep high levels of trust, but these are rare cases. If we think of our team as we do about our family, it is natural we do not keep in contact with all members, and Dunbar succeeded in finding some trust patterns in his study.
Even after finding the right numbers and the right people, we still need to change the team’s mindset in order to get communication flowing in a way that benefits a compact team with the necessary knowledge. For this purpose, all members must understand that they have to put the team’s needs before individual needs by complying with basic work agreements such as mapping discussions and investigations, and keeping the focus on the team’s needs, whether they are goals, or initiatives, punctuality, etc.
- Cognitive Load
It is no use having an adequately sized team but having a lot of responsibilities. Therefore, for a team to keep focused and deliver its best possible performance, we must be able to measure its cognitive load and identify bottlenecks before it is too late. In order to better understand what cognitive load is, we first need to understand how we learn. Our memory is divided into Working Memory and Long-Term Memory. Some studies, such as John Sweller’s “Cognitive Load Theory (1988),” show that we are able to keep anywhere from seven to nine processes in our working memory. By knowing that a person has such a limit for processing information, we have to plan ahead so as to prevent information overload.
But what is cognitive overload after all?
The used amount of working memory resources.
John Sweller
Regardless of how honest your team is, the cognitive overload is difficult to measure, and inadequate management of the cognitive load can result in serious difficulties for a product, as well as for quality of communication.
This load is divided into three different moments: Intrinsic, Extraneous, and Germane. In the realm of software development, we can define them as:
Intrinsic: The complexity of doing something new, such as when we have an Epic or very big task to be done, and how much of our cognitive resources will be needed to transfer this information to long-term memory.
Extraneous (Irrelevant): This type of load creates distractions and prevents our working memory from functioning correctly, like when working in a noisy environment, lacking development tools, or badly written code. All of this can block learning and makes it more difficult to access long-term memory, therefore we should reduce this load as much as we can.
Germane (Relevant): This is the load that implies deeper processing which is known as flow, a cognitive level in which we are able to process complex information, access our long-term memory, and better interact with our reasoning. For this reason, this is the load we must maximize.
When the load factor is not correctly addressed on a daily basis, we might notice the team starts losing focus and time simply due to an excessive amount of responsibilities and domains. The image below shows that the features and tasks compete with other crucial points that use up our cognitive capacity, which we do not always pay attention to.
We need to be cautious and able to manage our communication and our team organization very well, so as to benefit from the Cognitive Load Theory to its fullest potential. In order to do this, we must manage the Intrinsic load, like when we break an Epic into Stories and later into tasks, thereby reducing irrelevant load, working in a quiet environment, reducing the number of frameworks and keeping code healthy, and lastly, maximizing the use of our Relevant Load by means of adequate repetition in different contexts.
- Fundamental Topologies
When we have defined the size, domains, and people of a team, we are able to find out what its topology is. This way, every service or application created must be owned by a team with the cognitive capacity to build and operate it. This may raise doubts, such as: Do we have the right team for the right moment? Or, is capacity lacking in some areas that appear to not have owners? Therefore, we must think in terms of how each team fits into the organization. In order to make this process simpler, we can reduce the number of team variations to four fundamental teams through Team Topologies.
Stream-Aligned Teams : The continuous workflow which is strongly aligned with a business domain or organizational capacities is the foundation of these teams. This team is responsible for delivering value and must keep its purposes, aims, and responsibilities very clear. These can range from a simple product, service, or persona, to a set of features or user journeys.
Enabling Team: This is a high-performance team that is composed of experts with a high technical level or business ownership who scaffold the development of stream-Aligned teams, as the latter will be focused on high-value deliveries. Because this team has a strong collaborative sense, they are able to share knowledge and boost the stream-aligned team’s autonomy without becoming heroes.
Complicated-Subsystem Teams : This team is responsible for building and maintaining a part of the system strongly dependent upon specific knowledge, and most team members are specialists in a given field with a strong understanding of performing changes in system modules and submodules.
Platform-Teams: The purpose of this team is to allow the stream-aligned team to deliver their work with complete autonomy. This team provides services to reduce the cognitive load, which is necessary for the stream-aligned teams to build these services.
Continuous Improvement
After our teams are defined, adjusted, and classified, we are able to support their fast and sustainable growth with deliveries of different teams at different moments. This creates a low coupling environment, good communication, guides our decisions to achieve ‘fast flow,’ and gives the organization a realistic mission.
How can value-oriented technology be applied? This question is carefully studied here at Pipefy, and we are organizing ourselves in a way that the answers to this question allow for simple changes with the highest impact. Therefore, we are always revisiting and refactoring our workflow by applying Team Topologies, focusing on People First, and using many approaches for aligning our team reorganization with our goals, clients, and business value.
Reference:
Team building with Team Topologies
Written by: Eduardo Hattori