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?
Enabling Team
Team A was able to adopt new practices by being under the radar and not having a huge delivery pressure, giving the team the time and space to fail and learn. In a situation of high delivery pressure, it doesn’t have the best conditions for an Enabling Team and facilitation to succeed.
The tendency in this situation is to treat the enabling team as new team members to help with the delivery as more developers. Breaking the purpose of facilitation of an enabling team to fill the team capability gaps.
Split the domain into two teams
Splitting the domain would have added a lot of pressure on the leadership team and Team B. You need to collaborate first to:
Understand the business and product context.
Understand the source code.
Decide which area to split into two for team responsibilities.
Coordinate the new collaboration with Team H (dependent on Team Product B) and the Operations Team. Increasing the pressure on leadership for coordination. (More managers here please!)
The possibility of just being one big team because of the constant required coordination but with splitter dailies was a plausible reality.
We discarded both options in favor of merging teams.
What about Product A development?
We were able to negotiate with the business the priorities, and after assessing product B's potential vs product A potential, it was fine to freeze the development until we overcome this situation.
Merging both teams
By being part of the same team, we could introduce some dynamics that would improve fast knowledge transfer such as pairing or mob programming.
Team B shares the business, product, and code knowledge with new team members from Team A.
Previous Team A members are able to share the practices and methodologies with Team B members.
With pairing, we can create a higher trust relationship between people so that we have a strong relationship in a high-pressure context.
Win-win situation.
I also wanted to reduce the amount of coordination possible between teams at the cost of coordinating 12 team members.
Why?
Isn’t 12 people too much? We knew from past experience that some people left due to the new practices, we expected that this would happen and it would reduce the team size in the following weeks.
Indeed, it was what happened. At least 6 people left the company. It was key to introduce pairing to fast knowledge transfer, otherwise, the impact of that decision would have been huge within the organization. Impact on the delivery of the product, which was the key reason why we started this merge.
So, we improved internal knowledge transfer without the increase of cross-team coordination/collaboration. An essential point for a fast flow of change.
Removing the leadership handover
Changing organizational behavior that has been there for a long time is hard. It becomes part of the culture.
“We always did it this way”
At ThoughtWorks, I learned a way to make the decision process more collaborative and to help teams own the process E2E, using the Lean Inception.
Lean Inception has a lot of positive outcomes, the one I needed was aligning people to build the right product.
Instead of just receiving a backlog, Lean Inception focuses on building it collaboratively by having a conversation with all the important people in the room.
Even though the product was quite defined, I considered Lean Inception to be a great fit for:
Aligning people and knowledge transfer. Team A new joiners needed to ask people to the business experts.
Reduce scope. What’s done, what’s pending, and what’s essential to the first release.
Moving from we need everything to iterate after releasing.
Create a shared ownership of what is being decided.
If I receive a backlog, my buy-in is lower compared to when I understand where it comes from and my opinion is heard.
One key reason why waiting to have it all was that the delivery speed was slow. If I’m able to release every few days, we can plan ahead and know that we are able to handle new requirements at a good pace. On the other hand, if we take months to deliver something, we don’t have the flexibility to release it now and fix it as we go.
Delivery speed gives the option to release sooner rather than later.
That’s why we adopted many of the Team A dynamics to improve the DORA metrics to create the environment that allows us to release without a “feature-complete product”. It gives confidence not only to the engineering team but also to the whole people involved in the product.
The end flow of change based on that change was the next
The leadership didn’t behave as a platform or enabling team (yet), but they were part of the product definition within the team.