Creditas: Managing Team Cognitive Load with Team Topologies for Fast Flow of Value

25 Jul

Authors: Aleix Morgadas, (former Head of Engineering at Creditas) and Juliana Chaoud (former VP of Engineering at Creditas)

Reviewed by Manuel Pais, co-author of Team Topologies.

Key points

The primary business and operational outcomes achieved by Creditas through the adoption of Team Topologies included:

Successful Product Release: After suffering long-term delays, the organization successfully released a product to production within the first quarter of shifting toward the new model.
Increased Delivery Speed: Teams achieved a fast flow of value, transitioning to a model where they could iterate and ship product increments on a weekly basis.
Enhanced Autonomy and Ownership: Transitioning to full-stack, stream-aligned teams eliminated handovers and coordination overhead, empowering engineers with direct ownership over both their code and product backlogs.
Reduction in Customer-Facing Issues: Following the implementation of a dedicated Payments Platform Team, Creditas experienced a considerable reduction in user tickets affecting account creation and transaction management.
Cultural Shift and Shared Language: Team Topologies principles became deeply embedded into the product-engineering culture, providing a unified language to diagnose friction and scale healthy team practices across the broader Creditas organization.

Founded in 2012, Creditas, a Brazilian fintech, is a consumer lending startup that operates a digital platform providing secured loans and low interest rates. By 2022, Creditas had over 3.000 employees and was serving a broad range of products related to consumer loans, with B2C and B2B2C models.

Two years earlier, Creditas started a multi-product initiative to offer a single credit card that connected multiple existing and new products, to help clients access better loans.

The goal was to verify fast product market fit for those product initiatives, but things didn't go according to plan.

In this case study, we will deep drive into how we evolved from a single team with multiple products, to a full product tribe with a platform team to support internal stream-aligned teams for fast flow of value.

Single team and multi-product initiative

Creditas wanted to provide a coherent experience to access all their products. That meant having a single application, as well as a unique credit card.

In order to support these product initiatives, the engineering strategy involved building what's necessary and externalizing as much as possible.

So, the initial product initiative contained several bets, including:

Credit Card
Employee Benefits
Digital Account with PIX

PIX is a payment platform in Brazil that allows users to make instant payments and transfers between bank accounts using a variety of identifiers, such as mobile phone number, email address, or QR code.

These products were designed to provide better loans, tailored to the customer’s needs by expanding the touchpoints in their journey—from asking for a loan to using the Creditas card day to day.

Depending on which products the client signed up for, using the credit card would potentially give them the most benefits.

The main challenge was the unexpected amount of effort required to create a compelling experience using all the products simultaneously. This challenge materialized with:

Business pressure to cut corners to verify product-market fit, creating more product and technical debt as the pressure increased over time.
High dependencies on external services that weren't addressing the product needs and forcing Creditas to custom-build parts of the system, or asking those providers to custom-build solutions for us, increasing the dependency.
The inexperienced team adopted microservices architecture early, creating a distributed monolith with a poorly implemented hexagonal architecture.
Teams lacked mobile skills, forcing the business to hire an external consultancy company to support the product development.

Multiple teams and multi-product initiative

In 2020 none of the products were released to the public. We had some products in closed beta for some employees to verify the usage, but nothing was ready to be released to the public.

The lack of visible progress, delays and defects, caused some key stakeholders to leave. They were replaced with a new leadership team who decided to invest in three teams, one per product initiative, to form a tribe.

At that point, staff including principal engineers used Domain-Driven Design to model the different services. But they made a common mistake of focussing on the backend systems, not the mobile application or product as a whole.

The initial intention was to reduce the distributed monolith problem, to build more adaptable product solutions in the future.

However, they underestimated the complexities of the team's dependencies and the flow of change. Falling back on previous ways of working, and pre-established architecture, the problem became worse as more lines of code were added.

Furthermore, the newly-formed tribe did not live in a vacuum. It had dependencies to existing Creditas products, in addition to the new initiatives.

Before the product was validated, new business initiatives were built on top of existing products.

More investment and higher expectations created a sunk cost bias. This in turn made it harder to stop the initiative with Creditas instead investing ever more resources. The initial problem wasn't solved, it just became worse.

Delays, burnout, rework, stress, individual heroics and unpredictable results prompted leadership to look for a new way to approach the tribe's challenges, this time from an engineering point of view.

Looking at the high-stakes business challenge from a Team Topologies point of view

Aleix joined Creditas at this point in proceedings, in early 2021. One year later, the multi-product initiative started with multiple teams, and no product had been released into production yet.

As part of the initial assessment, Aleix talked to people that knew the full story, who could provide the most context.

At first, people tended to focus on problems at the team level. Even though they were important, and provided huge insights into people's frustrations, we decided to focus on a higher view—the tribe delivery process.

Teams were pushing hard, people were stressed, and tired of constant rework because the requirements kept changing. We identified individual heroes who were dealing with huge challenges. However, the problem wasn't at team level, but how we worked as a tribe, and how leadership managed change.

We spent time observing the flow of change, from idea all the way to production, and this is what we found:

Based on conversations and a short survey, we were able to detect some team cognitive load drivers that helped explain the reality teams were facing:

Team alignmentIn order to work effectively, teams need a clear purpose and shared meaning. Without it, team members are inclined to go off in different directions and do their own thing, leading to errors and delays which generate fear and distrust, so that improvements seem impossible. All this increases cognitive load.
Team interactionIneffective team interaction leads to communication gaps. This causes confusion and distrust, wastes time and reduces productivity, leading to increased cognitive load.

Those team cognitive load drivers pointed us to two main assumptions:

The teams’ mission was either unclear or constantly changing, and the scope of the team/ownership wasn’t defined.
The constant interaction between teams made the problem worse, as they had to constantly collaborate due to a tightly coupled architecture.

Understanding the problem helped us pull together the right people—the leadership team—to solve the problem. Team alignment and team interaction problems are difficult to solve at team level without involving others.

But leadership was in execution mode, busy, and unable to address those concerns. Time was critical, and stopping everything wasn’t an option. In order to narrow down the conversation, we also assessed the team cognitive load of the leadership team, to find any insights that could help us reduce team cognitive load to a manageable level.

These were the top three team cognitive load drivers for the leadership team:

Solution alignmentWithout a common understanding of the solution, deliverables may vary within the team. These discrepancies in expectations lead to constant friction, and with this slow, ineffective work—increasing cognitive load.
Team alignmentIn order to work effectively, teams need a clear purpose and shared meaning. Without it, team members are inclined to go in different directions and do their own thing, leading to errors and delays which generate fear and distrust, and improvements seem impossible. All of which increases cognitive load.
Role loadRole overload is associated with various aspects of psychological strain, such as increased job stress, anxiety and mental overwhelm —all of which are linked to high levels of cognitive load.

We found an interesting insight.

The management’s cognitive load drivers influenced stream-aligned teams’ cognitive load, directly or indirectly.

So, we had the next hypothesis.

By addressing the management’s cognitive load first, we should improve the whole tribe's cognitive load, as they are highly related.

In order to do this, we had to have an overview of the complete tribe process.

The entire tribe was reliant on endless handovers between teams and constant synchronization to make sure things happened as planned.

Defining the problem, including its effect on leadership, allowed us to consider possibilities that might have previously been overlooked and focus our attention on the teams.

The decision to assess leadership cognitive load was key to moving away from potential solutions such as changing processes, tribe reorgs, or laying-off employees.

Removing handovers and adopting stream-aligned teams

This led us to our next hypothesis.

By removing the handovers between teams, we should gain more team autonomy and ownership. This would decrease the level of coordination, and improve team alignment for the specific product needs.

In order to do so, multiple things had to happen.

Teams had to become full-stack.
The product backlog had to be defined in collaboration between teams and leadership up front before the quarterly planning decisions. The backlog had to follow the team mission and domain boundaries.

Long story short, we aimed to create a space to empower teams.

However, shortly after announcing the new direction and encouraging staff to adopt the new working practices, we faced multiple unforeseen challenges.

Team cognitive load didn't reduce—it simply increased in other areas. Specifically:

Role ClarityRoles and responsibilities were not clearly defined, so people didn’t know exactly what was expected of them.
ProcessIneffective, outdated work processes, plus lack of sufficient transparency, decreased team morale, increased frustration and a slow down work and productivity— all leading to stress and high cognitive load.
Task complexityCognitive load depends on task complexity, because it is determined by the number of interacting information elements that have to be related, controlled and kept active in working memory during task performance.

Empowering teams is difficult, time-consuming and complex.

We expected an increase of cognitive load. Identifying which areas were most heavily impacted helped us identify how best to reduce it, and track when it returned to acceptable range.

For this, we created two enabling teams:

Lean Inception Enabling Team. Focused on training and facilitating a Lean Inception for the leadership team and the stream-aligned teams. The primary focus was to reduce the process cognitive load driver, to make the transition to the new way of working smoother.
Mobile Enabling Team. Focused on upskilling the developers on mobile development, and the current mobile platform. We measured the success by monitoring the task complexity cognitive load driver.

The role clarity cognitive load driver required that leadership make clear in our 1:1s the expectations on our roles based on the new context.

As leadership, we had to constantly remind staff of our vision in order to avoid losing momentum, and keep morale high—asking for some teams to push, and others to have patience.

The key approach was to not change the working protocols for all the teams simultaneously. That’s why we focused on the teams that were most open to change and likely to benefit most from it.

We co-planned the product roadmap for Credit Card and Benefits with the facilitation of the Lean Inception Enabling Team—a two-person team that included me. This required constant collaboration with the leadership team.

In addition, the Mobile Enabling Team focused on training the Benefits team developers on React Native, and the specific mobile platform we had at Creditas. The reason to focus on the Benefits team was:

Credit Card already had a dedicated mobile developer.
Benefits had the most UI intensive work planned for that quarter.

After two months of the new practice, we assessed the team cognitive load and concluded that it was not only significantly improved, but had become acceptable again.

We learned that:

Team cognitive load might intensify before you are able to address it. In order to improve it, a thoughtful and focused plan is the best approach.
Failing to assess the team cognitive load and make a focused plan could prevent the initiative from succeeding, and cause it to rollback to previous ways of working.

During that quarter, we were able to release a product to production, which had been the main objective of all this investment.

Employees had ownership of the code and product backlog. Engineers helped each other gain the necessary skills to be full-stack developers. And our product managers efficiently involved the whole team in finding a solution.

Investing in a platform team inside the tribe to further reduce cognitive load

After three months, we assessed the team cognitive load again to obtain a holistic view of the tribe cognitive load.

Image: insights from assessing team cognitive load using Teamperature

We expected task complexity and contextual complexity (frequently changing requirements, external circumstances, or interruptions) to no longer be the main cognitive load drivers, not least because the context had changed.

However, the main reason was neither mobile, nor the processes. When we started to ship fast, we faced bottlenecks that previously weren’t significant enough to get our attention.

After talking to the teams, we found that we had a technical problem.

Multiple teams had to modify shared services that nobody owned. The code was legacy—full of edge-cases, nested IFs, and very error-prone. Those microservices communicated with an external system that was also unstable, making the entire debugging process extremely challenging and time-consuming

Teams tried hard not to break any critical use case by keeping the systems healthy by both understanding the whole codebase and other teams’ needs.

We analyzed the problem from two different perspectives:

The human: The amount of context needed to make a change in the shared systems required constant collaboration between the senior developers. This prevented them from training more junior people, causing difficulties down the road.
The technical: Systems were highly coupled, and lacked several resiliency methods. Coordinating the changes in order not to affect delivery was challenging.

The high-stakes challenge required a deeper conversation between the leadership and teams. Continuing to invest in the same approach seemed to be ineffective, both in the short- and long-term.

Allocating time within teams didn’t work well as an approach. No meaningful progress was made.

We decided to invest in a platform team.

The platform team had the following goal:

We enable payments tribe teams to deliver faster by providing a reliable XaaS of the main and critical use cases regarding account management and transactions.

In order to measure the initiative’s success and impact, we set new metrics:

A reduction in task complexity, contextual complexity and communication cognitive load drivers.
Significant decrease on user tickets impacting the account creation, and transaction management.

We got the go-ahead from leadership to invest in this platform team.

So, we announced the new engineering strategy to the teams. We identified the key people who could join the platform team from existing stream-aligned teams that understood the context and were already familiar with the code. They could focus on providing a great platform as a product experience.

Adding a platform team also increased the team cognitive load

We were too optimistic about the way the initiative was set up.

The world platform is often overloaded, and people understand very different things.

We provided training for the Platform Team on the Team Topologies principles to make sure we didn’t create a platform that nobody uses. Or worse, everyone uses it, but it adds more cognitive load, and has the same resiliency problems.

We were able to train the new Payments Platform Team on:

User research. Understanding the internal customer's needs.
Product approach. Smaller and continuous increments over big bang releases.
Thin platform over big platform. We facilitated several event storming sessions, to shape the smallest platform domain to address user needs and prioritize a great DevEx over too many features. It was critical to understand what the platform team should and shouldn’t do, otherwise, we could apply the antipattern of receiving the features that stream-aligned teams either don’t want or don’t have capacity to use.

The platform team was able to deliver meaningful increments within one month, showing great progress and gaining leadership trust. After two months, we saw a considerable reduction in customer facing issues, and an increased speed for teams delivering features related to accounts and transactions.

Conclusion

Adopting Team Topologies principles was key to moving from a tribe that was unable to deliver, to a set of high-performing teams, able to iterate and ship product increments weekly.

In order to make sensible decisions, we focused on the human aspect of the challenge with team cognitive load. It helped us to:

Spot the areas that caused friction.
Have focused conversations with the teams in order to make meaningful decisions.
Focus first on achieving end to end flow of value with stream-aligned teams before starting a platform team.
Allocate enabling work. This was key to reducing cognitive load, on both stream-aligned teams and platform teams.
Measure the improvements over time.
Understand the consequences of leadership decisions, and act on them to mitigate the initiative risks. Recognize that improving a cognitive load driver can increase other drivers and affect further initiatives.
Create a shared language to address the areas that needed improvement.

The last point was super important for us because previously teams communicated their complaints in a very different way. It was always hard to understand the root causes, and time-consuming trying to address problems. By having a shared language, we were all able to communicate our needs and challenges faster, and create cross-team initiatives instead of local ones.

After a while, Team Topologies and managing team cognitive load became part of the product-engineering culture, and we started to scale these new principles within the whole Creditas organization. This helped our tribe, as well as the business units around us, and enabled our teams to be healthier while achieving fast flow of value.

Scale out adoption and awareness of Team Topologies across the enterprise

Next steps: applying Team Topologies at scale

Request a keynote talk to inspire your teams and kickstart a transformation initiative
Order 50 or more copies Team Topologies Second Edition now in bulk - with free worldwide shipping
Buy an Enterprise Content License with access to a huge library of official Team Topologies workshop and training materials to catalyse large-scale transformation
Get an online consultation on Team Topologies with one of the co-authors of the book