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

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

---

In Part 1/3 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.