Merging two teams for fast flow
Fintech Engineering Strategy. Post III
The Fintech post series aims to share my personal experience as an engineer manager and later on as head of engineering, which were the challenges, the decisions, and the good and bad outcomes they had. The content has been adapted to keep the decisions without disclosing internal information.
Fintech Engineering Strategy Post Series
Post II. Building a product vision, and a team, and replacing Ktor with Spring Boot incrementally.
Post III. Merging two teams for fast flow. [This post]
Post VI. Reducing the chaos before addressing the complex socio-technical system
As Team A, we started to perform and deliver at a good pace.
We were proud of our rhythm of continuous improvement and continuous learning, and the DORA metrics started to be high-performing most of the time.
We stopped being an isolated team as the practices and methodologies got internalized by the team members, and we got exposed to the tribe's challenges.
The tribe had three products owned by three teams with the same name, let’s recall that we are naming them A, B, and C. We were the Team A, but the business bet wasn’t the product A.
The business bet was the product B owned by team B. They got all the business attention and pressure.
The Team B shared some difficulties in delivering the product, like:
Lack of order and unpredictable results.
Managing individuals.
Heroics.
Stress.
A lot of similarities to what I shared with you in the previous post. Why not apply the same thing in this context? Because context matters.
A key difference was that Product A was mainly company employees, while Product B was a mix of company employees and external consultancy.
As we learned, we had some people leaving the team and we had the opportunity to operate under the radar until we adopted the methodologies.
It would have been a mistake to apply the same approach.
We needed to think as a tribe how to address this high-stake business challenge.
Understanding the organization chart
The company was super big. It had a lot of products, user personas, and departments.
A tribe consisted of:
Tribe leadership with Product, Business, Design, and Engineering.
Different team types:
Product-Engineering
Operations
Customer-Success
Teams were meant to deliver with as high autonomy as possible
Reporting lines were quite strict. It created information flow too fast between types of teams due to most information being passed either in leadership 1:1s within the same department or slower between “departments”, as they required a meeting with all people involved which were usually led by business.
Teams were able to gather all the context from different people and departments as the culture of seeking the context was super present and people were open to sharing the context as much as possible. This was the unofficial structure of how to gather information, by creating human relationships to support each other outside the formal communication channel. It worked quite well even though it created pressure within the organization of constant communication to have the whole context in a rapidly changing organization.
Understanding the flow of change
Tribe-level leadership had a key role in pushing progress further. As the products required more teams, the coordination of the initiatives was part of the tribe leadership responsibilities, creating a dynamic on how to distribute work between teams that are needed to deliver a new product feature or a business capability.
As the cost of coordinating and collaborating between multiple teams was higher, we added more importance to planning. It created pressure on tribe leadership to be more correct and unable to collaborate as much as they would like with the teams to have a shared understanding. Making the relationship between tribe and team leadership a management-heavy activity.
Here was the interesting behaviour, if an initiative doesn’t fit in a team backlog, it is pushed into another team’s backlog even though it’s not “completely” their domain.
As domains and responsibilities were blurry, it created a flexible backlog which helped business initiatives to be prioritized each quarter at the same time it started to create technical debt as a solution could be started by one team, and then it made a handover to another team. Ownership wasn’t there.
This worked when the domain complexity was reasonable, which helped with fast business iteration until the domain complexity wasn’t manageable anymore and slowed down the teams’ velocity until the point that it was hard to deliver value.
High-stake business challenge
The business potential of Product B is huge. The need to release the product as soon as possible the business opportunity is there and other players are moving ahead.
Vision
We saw the engineering practices of Team A performing, we bet that investing in Team B to adopt them will help Product B to be generally available sooner.
We considered multiple approaches:
An enabling team to help Team B with the capability gaps that we identified.
Split the domain into two teams.
Merge Team A into Team B, and freeze the Product A development.
We decided to merge both teams and remove the handover from the tribe-level leadership so that Team B can be more autonomous E2E.
Why merge both teams and not the other options?
Keep reading with a 7-day free trial
Subscribe to Engineering Strategy to keep reading this post and get 7 days of free access to the full post archives.