Fintech Engineering Strategy Post Series
Post I. A legacy, a deadline, and no team. [This post]
Post II. Building a product vision, and a team, and replacing Ktor with Spring Boot incrementally.
Post VI. Reducing the chaos before addressing the complex socio-technical system
You will find an Engineering Strategy that:
Team level impact, suitable for people in a Tech Lead position.
Limits Work in Progress to boost velocity.
Tough deadline with high uncertainty and leadership attention to deliver on time.
Build a team from 0 with internal rotation.
Removing bureaucracy during a high risk delivery by implementing novel approaches to fast delivery.
This post assumes you are familiar with the Engineering Strategy structure. Please, read the Designing an Engineering Strategy post series if you find yourself unfamiliar with the structure Diagnosis → Direction → Coherent Actions to describe an Engineering Strategy.
March 2021, I join a FinTech as Engineer Manager in their offices at the lovely and sunny Valencia, Spain.
A FinTech based on São Paulo, Brazil with an office in Spain. It offers loans with the lowest rate on the market.
It had multiple things that made it attractive when I decided to join:
Big and complex domain. FinTech, loans, and applied to multiple verticals such as loans based on payroll, cars, houses, and business services. I joined the latest business unit.
Growing product-engineering team.
Working for a company outside Spain which I could learn a new language.
Good company values and employee benefits.
Proved business model.
Enough time on the market so that there’s an existing software in place that will need to be evolved and maintained (legacy).
I join as a engineer manager with influence on:
Engineering.
People.
Organization.
Space to make mistakes and learn from them.
With those points on the table, I considered the company to be a great company to push myself outside my comfort zone.
The context
I start on March 1st of 2021 and I start my onboarding. I recall having my calendar full already for the first three days with sessions like company values, ways of working, the first three months expectation, and so on.
My manager wasn’t in the office, she was in Brazil. Indeed, no one of my team was in the office, I’m the first for this team.
I recall one of the first conversations, the summary could be something like:
You are hired for a product that hasn’t been released to the public but it needs maintenance and adjustments from time to time because it’s regulated by the Central Bank of Brazil.
The team was disassembled almost a year ago.
The main developers and product manager who developed the product from grown-up left the company almost a year ago.
A couple of developers have the context of the application because we had to do some fixes the past quarter as an exceptional thing.
We have an important delivery in two months due to new regulations.
We don’t know what needs to be delivered because we don’t have the full picture of what’s done and what’s missing.
We have Business Experts and a Product Manager that’s working to capture those requirements and will be delivered to you.
You need to hire your team, and onboard them.
TLDR; You have a deadline. We don’t know what needs to be delivered yet. You don’t have a team, you need to hire people and onboard them, while being familiar with a code base that the people who wrote it is no longer here.
I loved the challenge. Let’s see what we done to overcome the situation.
Engineering Strategy
Context
My leader added me to several meetings to meet the business experts that could provide me as much as context as needed while supporting me on a different fronts like hiring, understanding the business requirements, and find the people that knew something about the software in place.
Organization and product structure
I’m part of the Team A, and I co-live in a tribe with three other teams. Each team is responsible for a product.
Architecture
The architecture diagram is messy and incomplete because the point is to show the coupling and services ownership.
DevEx
Deployment on backend is fully automated and don’t require human intervention.
Delivery experience on mobile require deeper expertise on how it works to deliver features in the next app publishing process to the Google Play and Apple Store.
Both components have tests.
Diagnosis
The product is heavy regulated and requires Brazilian regulation experience to understand and the new regulatory measures by the Central Bank of Brazil, what what is missing in our product to fulfill those regulatory requirements. Which means, all the product information is in Portuguese.
The software is a mobile application based in React Native.
The backend is a set of microservices in Kotlin and Ktor that talks with each other via HTTP APIs.
The product is part of a set of initiatives that got more priority and it created technical debt on how the different products co-live in the mobile application and the logic is implemented cross microservices.
We can see the coupling of the services based on the past product prioritization.
We cannot fix the technical debt as part of the delivery.
Direction
We will focus on high visibility of the initiative state and communicate often with the main stakeholders. We will limit the work in progress and we will keep a small team with high cohesion on the delivery by doing pairing to limit the risk of integrating the mobile and backend later than sooner.
Actions
Build a team with internal people, preference if they already worked with the source code before.
Limit the work in progress to one, if not possible due to blocking external dependencies, two is OK.
Limit people working in the initiative to limit the onboarding pressure.
Pairing for fast knowledge transfer.
Removing PR at least two approval requirements.
Do not change technologies nor aim to reduce technical debt as part of the delivery.
Start by mobile user journey and adapt the backend to support the new requirements.
Outputs and outcomes
Desired
The delivery risk was more about the unknown state of the product than the new requirements that needed to be implemented.
A lot of the pressure went away when the PM collected the new requirements within the first two weeks and we were able to plan accordingly.
An internal mobile developer joins the team to support the mobile part based on Brazil.
A recent hire joins the team based on Spain.
An internal experienced product manager joins the team.
8 of the 11 new features are delivered on time, the remaining with low priority low risk are delivered on the following week after the deadline.
We become more familiar with the source code.
Undesired
The mobile developer returns to their initial team and the mobile knowledge is lost in the team.
Reaching the milestone shows that the product has lower priority, we lack a product vision, documentation, and understanding the past decisions.
Learnings
Having a supporting leader is crucial.
Having a supporting network with other teams and people is crucial.
The higher the delivery pressure is, you will have more resources available to fix the problem ASAP but it can cause more harm than good.
Here, based on the experience I had, limiting the work in progress and not onbording new people creates better results than the opposite.
High cohesive team over a lot of individuals with the temporarily mission of delivering some features so they can come again to their usual teams.
Remove delivery blockers as soon as you find them.
Being part of a high risk delivery, novel practices such as removing PR bureaucracy are good time to introduce due to pressure of “just deliver it ASAP, do what you need to do”.
The developer that did internal rotation wondered why that’s possible to change the status quo within one week and stay with the new approach.
They went from, this isn’t possible to we did it in a record time.
Communicating often, async and sync, and showing progress early creates trust with leadership and team.
If the new requirements would have been unachievable with the current team of four people, we could have known during the first two weeks of delivery. Leaving us with a month and a half to take more drastic decisions, but lucky us it wasn’t the case.
