Building a product vision, a team, and replacing Ktor with Spring Boot incrementally
Fintech Engineering Strategy. Post II
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. [This post]
After the first deadline, we had time to understand the product vision, build the team, and start making steps forward to reduce the technical debt in the areas that could impact the coming deliveries.
The first thing that happened was that people who joined us for the delivery went back to their teams, so we started opening two positions, which we filled with internal rotation from another team within the tribe so that they would have already the context and be familiar with the source code as permanent moves.
Aleix's Learnings is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
The product that we owned as team A, let’s call it product A, is a legacy at least 1-year-old, which was in production for a small set of users before being generally available for all user base.
The tribe had three products, let’s call them A, B, and C. The order in which things happen is relevant.
The current tribe started as one team.
The team had the goal to build three products with an expectation of lower complexity by externalizing the high complexity to external partners.
At the beginning, the product A was the entry for all other products.
The products turned out to be more complex than expected.
The initial team left and three teams formed to drive those products forward.
As you can guess, a change in any product will impact many shared services, creating the need for coordination between teams and adding processes to prevent a change in one product from breaking the other.
We can find a lot of duplicate code as DTOs between the presentation layer and the persistence layer, while the domain logic is almost anemic.
We need to follow the HTTP calls between services to understand the user journey as a whole.
There is a good enough test suite that covers the main use cases for each service.
Team dynamics and characteristics
The leadership and the team members that joined the team shared their pain points and I was able to see some areas of attention such as:
Lack of order and unpredictable results.
Onboardings require three months until people become confident about changing code.
Using the Wardley Mapping Doctrine, I could identify some behavior as Phase 1.
Using the Kanban Maturity Model, I could also identify the team as ML0 Oblivious.
The business challenge
We need to push the product forward to make it generally available. We need predictability and introduce change more easily.
Keep reading with a 7-day free trial
Subscribe to Aleix's Learnings to keep reading this post and get 7 days of free access to the full post archives.