Going to production killed fast flow. Understanding how company "culture" materializes on unaligned team dynamics
Fintech Engineering Strategy. Post V
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 V. Going to production killed fast flow. Understanding how company culture materializes on unaligned team dynamics. [This post]
Post VI. Reducing the chaos before addressing the complex socio-technical system
On the previous post IV, I introduced that we 1) created a core team at tribe level 2) re-purposed the team to be a platform team.
But why did we re-purposed the team to be a platform team? In which context did it happen?
Context
We simplified the architecture, implemented the feedback and insights found by the beta customers. We released the MVP. 🙌
We reached a good team maturity at the same time the B2B2C product started to gain traction. The past decisions on focusing on this product to have a faster feedback loop started to pay-off.
The product value proposition was to help companies attract and retain talent by offering a better employee experience.
We onboarded few clients per month, which could mean between hundreds to thousands on employees. And with thousands of users per month, you start to see the system weaknesses. For the technical aspect, you see the service to start failing given several concurrent users. For the product/design aspect, you start seeing customers being unable to accomplish their main use case.
Customer tickets started to pile-up, developers were supporting the product constantly, and several manual processes that before weren’t painful, now was blocking all the fast flow.
Customer success team and Operations team were under pressure to resolve tickets to gain the customers trust and make sure they don’t churn. They hadn’t the right tools to make it happen, so they mainly created tickets for the Development Team to fix manually.
If the product-tech team is busy solving production issues, we weren’t improving the system. We weren’t able to escape the dynamics we created.
You know this virtuous cycle that deteriorates everything, architecture, code, team morale, customer trust, … which requires a bold decision to stop it.
In this post, which it needs to be spitted in multiple parts, I will go in depth on:
Understanding how the socio-technical system produced this result.
How leadership affected the whole team dynamics and how we had to change the whole tribe culture.
How using Team Topologies principles with Inverse Conway Maneuver while constantly measuring Team Cognitive Load helped us make sensible decisions.
Starting the change from the people and then though tech.
Understanding the technical landscape with Wardley Mapping and Domain Driven Design with Strategic Patterns.
Why the microservices failed and why the current approach didn’t work.
Directly challenge the company operating model on how it designed and decided the teams responsibilities.
Two teams discontinued and one team become a Platform Team.
I’m sharing with you a six month journey on how we changed completely a tribe from low performing to high performing and be a reference within the organization.
I hope you enjoy this in depth engineering strategy at multiple levels as much as I did working with my peers making it a reality.
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.