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 I. A legacy, a deadline, and no team.

• Post II. Building a product vision, and a team, and replacing Ktor with Spring Boot incrementally. [This post]

• Post III. Merging two teams for fast flow

• Post IV. Simplifying a Ports and Adapters architecture and remove anti-corruption layers made sense from a sociotechnical perspective.

• Post V. Going to production killed fast flow. Understanding how company culture materializes on unaligned team dynamics.

• Post VI. Reducing the chaos before addressing the complex socio-technical system

---

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.

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.

1. The current tribe started as one team.

2. The team had the goal to build three products with an expectation of lower complexity by externalizing the high complexity to external partners.

3. At the beginning, the product A was the entry for all other products.

4. The products turned out to be more complex than expected.

5. The initial team left and three teams formed to drive those products forward.

Context

Team

Architecture

Macro

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.

Micro

The service has a “ports and adapters architecture” using Ktor and (IIRC) Exposed for the persistence layer.

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.

• Stress.

• Managing individuals.

• Heroics.

• Onboardings require three months until people become confident about changing code.

Using the Wardley Mapping Doctrine, I could identify some behavior as Phase 1.

Wardley Mapping - Doctrine

Using the Kanban Maturity Model, I could also identify the team as ML0 Oblivious.

Link

The business challenge

We need to push the product forward to make it generally available. We need predictability and introduce change more easily.

Engineering Strategy