[High-Performance Team] The Diagnosis and Optimization Framework (Part 1/3)

[High-Performance Team] The Diagnosis and Optimization Framework (Part 1/3)

---

A while back, while working as an engineering leader at a LatAm FinTech, I had to face a challenge that many engineering managers know but few document: redesigning an entire engineering organization — teams, services, culture, tech stack — with the goal of building a leaner, more effective structure.

It wasn’t just an efficiency problem. The engineering team was working in isolation from the business, with no product focus or impact metrics. There was no cohesive engineering team as such — just groups of people working in parallel without alignment. The challenge wasn’t just optimizing resources and speed, but building a real team for the first time: one that understood the business, aimed to deliver measurable value, and operated as a unit.

It took me a month to design the complete framework. I don’t want it to be forgotten, so I decided to share it as an open playbook for anyone who needs it.

This isn’t textbook theory. It’s a framework I built with real data, real problems, and real constraints.

Note: This methodology was designed at a time when LLMs were just entering the development scene. Today, with AI tools integrated into engineering workflows, many of these decisions — especially around per-person capacity, automation, and team structure — would probably be different and even more efficient. The objectives remain the same; the means to achieve them is what would change.

The 4 Objectives

It all started with a simple question: what does this engineering organization need to be truly effective?

The answer condensed into 4 clear objectives:

1. Maximize efficiency — achieve more with a more focused structure.
2. Accelerate execution velocity — less friction, more delivery.
3. Reduce costs to the minimum — infrastructure, tools, services.
4. Build a high-performance team — greater ownership, commitment, and execution.

These aren’t independent objectives. Each feeds the next. A compact, senior team naturally executes faster, spends less on overhead, and has greater ownership because each person has visible impact.

The Optimization Framework: 5 Pillars

Pillar 1 — Compact, High-Performance Team

The team was large, but it wasn’t effective. Too many people doing too little, with cross-dependencies and limited autonomy.

The proposal was to redesign the structure. A compact team of senior people, with complete skill sets and real autonomy, consistently outperforms a large team where ownership is diluted. The key: clear scope and the tools needed to execute without friction.

Pillar 2 — Simplify the Workflow

Bureaucracy was killing velocity. Permissions that took days, unnecessary approval processes, developers who couldn’t touch the database or infrastructure without requesting access.

The proposal: developers with complete skill sets. A senior developer should be able to handle databases, infrastructure, and development without depending on other teams for every step.

Metric	Before	Projection
Average Lead Time / Cycle Time	X days	1-2 days
Percentage of blocked tasks	High	Minimal

Pillar 3 — Service and Tool Consolidation

This was one of the most impactful findings. The company had 160 recognized microservices, of which only 66 were actively used. The rest was dead legacy, abandoned experiments, and duplications.

The projection: consolidate to 45 functional services and keep only what generated value.

In parallel, the use of external tools (monitoring, identity management, repositories, etc.) could be reduced by 30% by eliminating redundancies and unnecessary licenses.

Metric	Before	Projection
Microservices	160 (66 used)	45
Tool/service usage	100%	70%

Pillar 4 — Operational Support Automation

Developers were spending a significant percentage of their time on operational support tasks: handling tickets for internal admin tools, running manual queries, resolving client configuration issues.

The goal was clear: reduce support tasks done by developers to less than 5% — as close to zero as possible. Everything repetitive should be automated. Everything configurable should have an interface for the operations team.

Metric	Before	Projection
% operational support done by devs	High	<5%

Pillar 5 — New Culture and Ways of Working

The first 4 pillars are structural. This one holds everything together. Without a defined and practical culture, the rest falls apart within weeks. I go deeper on this in Part 3/3 of this series.

Scope: Complete Project Mapping

Before touching teams or technology, I needed to understand the complete scope. I mapped 21 projects evaluating each across these dimensions:

• Tech debt (High/Medium/Low)
• Maintenance level required
• New features level expected
• Business priority
• Required skills (Frontend, Backend, Data, etc.)
• Product goals and associated KPIs

The result was a matrix that allowed you to see at a glance where the value was and where the waste was.

High-Priority Projects

The projects that demanded the most attention and had the highest business impact:

• Onboarding — Self-onboarding process for clients. High tech debt, new features needed. Goal: significantly reduce onboarding time.
• New Payment Methods (BNPL, cashin, cashout) — Growth engine. Low legacy, high in new features. Goal: multiple integrations working perfectly, increase checkout conversion.
• Risk & Fraud Detection Engine — Transaction risk assessment system. Low legacy, high in new features. Goal: keep chargeback rate and decline rate at optimal levels.
• Dispute Management — Dispute representation and management processes. High tech debt, new features needed.
• Core Payment Processing — Business core. Medium tech debt, required stabilization and hardening.

Maintenance Projects

Projects that needed to work well but didn’t require constant innovation:

• Client Dashboard — Web app for clients to see their business status.
• Internal admin tools — Process configuration and maintenance.
• Financial Operations (dispersions, withholdings, balances) — Core financial processes.
• Infrastructure and Platform — Cloud, CI/CD, databases.

Projects to Consolidate or Deprecate

• Legacy payment processing — Old systems that needed migration.
• Legacy transfers — Low priority, low maintenance.
• Legacy collection channel — In decline.

What’s Next?

With the diagnosis and framework defined, the next step was designing the concrete teams — who, where, doing what — and deciding what to do with a tech stack fragmented across 8 languages and 571 repositories. I cover that in Part 2/3: Team Design and Tech Stack.