A team grouping (tribe) with local optimization thinking. Making sense of complex socio-technical system

Fintech Engineering Strategy. Post VII

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.

• 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. Part I

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

• Post VII. A team grouping (tribe) with local optimization thinking. Making sense of complex socio-technical system. [This post]

---

If you didn’t read the previous posts yet, I suggest you to because it is a continuation and I assume you have all the context. Check it here:

Reducing the chaos before addressing the complex socio-technical system

Moving into the next big thing, how did we end up in this situation in the first place?

Then, it was time to tackle the next big thing. The tribe.

What’s happening at a tribe level that our socio-technical systems is that fragile? Which dynamics do we have that causes this situation over and over again?

It looked like the there was no root cause, but a set of things that were interrelated that caused the system to behave the way it was doing it.

How did we start tackling the complexity? How did we find some signals to tell us what was goining on? Well, it was a mix of things.

I considered that focusing on the social interactions, responsibilities, and employee experience could give us some good insights.

I’m gonna explain here how we combined Team Topologies, Context Mapping, Team Cognitive Load, Core-Domain Chart, and Wardley Mapping to uncover where to do a set of micro interventions to the socio-technical system.

As an outcome of the workshops we did, we came up with this way of describing the architecture that shown business purpose inspired on DDD Subdomain types.

An architecture diagram that shows business purpose

So, let’s start with the engineering strategy that I’m so proud of that I was able to do with a very talented people. It contains:

• A great implementation of a Platform as a Product approach based on Team Topologies.

• How we measured Team Cognitive Load to bring focus and direction.

• Investing in moving non-competitive services to supporting subdomains.

• How a set leadership decisions created success for some teams but created a huge inertia on others to adopt the new approach.

Engineering Strategy