# [High-Performance Team] Team Design and Tech Stack (Part 2/3)

How I designed the squad structure, defined the ideal developer profile, and planned the consolidation of a stack fragmented across 8 languages and 571 repositories.

Apr 11, 2026 · https://e1i0.com/en/high-performance-team-design-stack.html

---

In [Part 1/3](/en/2026/04/11/high-performance-team-diagnosis-framework.html) I covered the diagnosis and the 5-pillar framework. Now comes the concrete part: **designing the teams and deciding what to do with the tech stack**.

This is where decisions become real — every position has a cost, every language has a maintenance cost, and every service has an infrastructure cost. There's no room for "just in case" roles or technologies nobody masters.

## Team Design by Squads

With the scope mapped (21 projects, each evaluated by priority, tech debt, and required skills), I designed the structure around **product-oriented squads**. Each squad has clear ownership over a business domain.

### Squad Risk

| Role | Level | % Code | Responsibility |
| ---- | ----- | ------ | -------------- |
| Backend | Senior/Tech Lead | 50-70% | Maintenance + new features |
| Frontend | Senior | 90% | Maintenance + new features |
| Data Scientist | Lead | N/A | ML model development |
| Data Analyst | Senior | N/A | ML models (transaction, customer, client) |

**Goal:** Evolve the risk and fraud detection engine. This squad had the unique challenge of bridging software engineering and machine learning — something few teams pull off well.

### Squad Processing

| Role | Level | % Code | Responsibility |
| ---- | ----- | ------ | -------------- |
| Backend | Senior/Tech Lead | 50-70% | Maintenance + new features |
| Backend | Senior | 90% | Maintenance + new features |
| Frontend | Senior | 90% | Admin tools and panel |

**Goal:** Maintain, stabilize, and harden the core payment processing architecture. The business core required solidity, not constant innovation.

### Squad Growth

| Role | Level | % Code | Responsibility |
| ---- | ----- | ------ | -------------- |
| Backend | Senior/Tech Lead | 50-70% | New features — onboarding |
| Backend | Senior | 90% | Tech debt — decouple financial operations |
| Backend | Senior | 90% | New features — onboarding |
| Frontend | Senior | 90% | Internal tools / panel improvements |

**Goal:** Streamline onboarding and simplify processes. One of the backends was dedicated exclusively to resolving tech debt and decoupling the financial operations architecture.

### Squad Payments

| Role | Level | % Code | Responsibility |
| ---- | ----- | ------ | -------------- |
| Backend | Senior/Tech Lead | 50-70% | New features — integrations |
| Backend | Senior (x2) | 90% | New features — payment methods |
| Frontend | Senior | 90% | New features — integrations |
| Mobile | Senior | 90% | New features — integrations |

**Goal:** Develop new integrations and payment methods. The largest squad because it was the growth engine.

### Squad Data

| Role | Level | Responsibility |
| ---- | ----- | -------------- |
| Data Engineer | Senior/Lead | Pipelines and data infrastructure |
| Data Analyst (x2) | Senior | Exploratory analysis, insights, dashboards |
| BI | Senior | Strategy, trends, business patterns |

**Goal:** Build and maintain the data infrastructure. Transform data into actionable insights for business decisions.

### Squad Platform

| Role | Level | Responsibility |
| ---- | ----- | -------------- |
| DBA | Senior | DB stability, resource optimization |
| SRE | Senior | Infra stability, simplification, costs |
| Security | Senior | Security processes, regulatory compliance |

**Goal:** Keep everything running. Three people for the entire platform sounds aggressive, but with service consolidation (160 → 45) and developers with autonomy to manage their own infra, it was viable.

### Design Principle

Every role was justified by scope. There were no "just in case" positions or buffers. If a project wasn't high priority, it didn't get a dedicated squad — it was covered by rotation from existing squads. The result: a structure where every person had visible impact and real ownership.

## The Ideal Developer Profile

It's not enough to define positions — you need to define **what kind of person** you need in each one. I defined 9 characteristics for the engineer this team needed:

1. **Maturity** — Past the phase of trying cool technologies because they're trendy. Chooses tools because they solve the problem, not because they're trending on Hacker News.

2. **Responsibility** — Owns projects end-to-end. Ensures they work well and constantly seeks to improve them.

3. **Autonomy** — Covers the full spectrum. Self-manages without needing micromanagement.

4. **Business Focus** — Cares that everything they build has real impact. Understands the business well and knows why they're building what they're building.

5. **Smart Decisions** — Avoids one-way-door decisions (irreversible) whenever possible. Focuses on team-based, reversible decisions that can be iterated in 1-2 days.

6. **Simple Solutions** — Avoids over-engineering. Has the ability to solve problems directly and efficiently.

7. **Scalability** — Experience designing and building solutions that scale.

8. **Experience** — 7+ years of high-level software development with demonstrable growth.

9. **Entrepreneurial Mindset** (nice to have) — Affinity with startups and their pace of work.

This profile is demanding. But in a compact team, each person has to be exceptional. There's no room for "still learning" or "needs constant supervision." Every developer is a multiplier, not a resource.

## Tech Stack

### The Fragmentation Problem

The stack was diverse — too diverse:

- **8 languages** in production: Golang, C#, TypeScript, JavaScript, Ruby, Java, PHP, Python
- **571 repositories** on GitHub (475 mapped)
- **158 microservices** in production
- **MongoDB**: 3 databases, 240 collections
- **Fragmented CI/CD**: Jenkins, Drone, and GitHub Actions coexisting

Every extra language is a cost: libraries, dependencies, expertise, tooling, debugging. With a compact team, maintaining 8 languages means some services depend on a single person who "knows Ruby" or "knows that Java service." That's a bus factor of 1 — unacceptable.

### The Projection: Consolidate

| Aspect | Before | Projection |
| ------ | ------ | ---------- |
| Primary languages | 8 | 2 (Golang + Python) |
| Microservices | 160 (66 used) | 45 |
| CI/CD | Jenkins + Drone + GitHub Actions | GitHub Actions |
| Frontend | TypeScript + JavaScript | TypeScript |

The consolidation toward **Golang and Python** as primary languages wouldn't happen overnight. It was a gradual migration: new services in Golang/Python, legacy services get migrated when touched, untouched ones get deprecated.

Consolidating from 160 to 45 services didn't just reduce infrastructure costs — it simplified the mental map that every developer needed to understand the system.

## What's Next?

With teams designed and the stack defined, the most important piece was missing: **the culture and technical practices** that would make all of this work day-to-day. A team of seniors without a clear culture quickly becomes a group of people doing whatever they want. I cover that in [Part 3/3: Culture, Practices, and Reflections](/en/2026/04/11/high-performance-team-culture-reflections.html).