[High-Performance Team] Culture, Technical Practices, and Reflections (Part 3/3)

[High-Performance Team] Culture, Technical Practices, and Reflections (Part 3/3)

---

In Part 1/3 I covered the diagnosis and the 5-pillar framework. In Part 2/3, team design and stack consolidation. Now comes the section that makes everything else work in practice: the culture and technical practices.

You can have the perfect framework and the ideal team, but without a defined and practical culture, it falls apart within weeks. Culture isn’t declared — it’s designed.

Culture Principles

Async First

Async work by default, meetings only when strictly necessary. Written documentation replaces most syncs.

This isn’t just a preference — it’s a design decision. With a distributed team and a 6+ hour sync window, meetings become the most expensive bottleneck that exists. Every hour of meeting with 5 people is 5 engineer-hours. A well-written document costs 1 hour and scales infinitely.

Radical Candor

Transparency and direct communication. Honest feedback, no politics or hidden agendas.

In practice: if something doesn’t work, it’s said. If someone isn’t performing, it’s addressed directly. If a technical decision was wrong, it’s acknowledged and corrected. No beating around the bush, no CYA emails, no “let’s discuss offline” that never gets discussed.

Real Autonomy

Every developer is a complete engineer: development, infrastructure, databases. With the permissions and access needed to execute without depending on other teams for every operation.

This point is critical and where most organizations fail. They ask for ownership but don’t grant access. They demand speed but require 3 approvals for a deploy. If you want autonomy, you have to give the permissions that enable it.

Clear OKRs and KPIs

Objectives defined at the engineering level and per team. Every person knows exactly what’s expected and how it’s measured. No ambiguity.

Attitude

Collaboration, business focus, entrepreneurial mindset, doers, self-management. This isn’t an aspirational list — it’s the standard that defines how the team operates.

Continuous Growth

Keep learning and improving incrementally. Avoid “we’ve always done it this way” as justification for not changing.

Technical Practices

Practice	Standard
Git	Trunk-Based Development
Code Review	Standardized evaluation process
Coverage	>80% per project
Documentation	Mandatory for every new feature and architecture
Permissions	Full access to workflow tools for all devs
Languages	Golang / Python primarily
Architecture	Monolith First, simple and scalable designs
Monitoring	Dashboards and alerts per team, direct ownership
Environments	Staging ≈ Production, both functional
Quality	Each dev/team owns quality of their deliverables
CD	GitHub Actions
CI	Code quality tools + integration and unit tests
On-call	24/7, documented
External services	Require validation document and formal presentation
Methodology	Scrum (15-day sprints), standardized estimation
Meetings	Monthly business review + All-hands monthly

Every practice is there for a reason. It’s not an aspirational checklist — it’s the minimum standard. If a project doesn’t have >80% coverage, it’s not ready. If a feature doesn’t have documentation, it’s not done.

The Monolith First Principle

I want to pause on this point because it’s counter-intuitive for many.

In a company with 160 microservices where only 66 were actively used, the answer wasn’t more microservices — it was consolidation. Simple, scalable designs, validated jointly by the team before implementation.

It’s not that microservices are bad. They’re a tool, not a religion. And when you have a compact team, you can’t maintain 160 independent services. The math doesn’t work.

Monolith First means: start simple, separate when you have evidence that you need to separate. Not the other way around. Distributed complexity has a cost that most teams underestimate until it’s too late.

Problems the Framework Needed to Solve

Part of the analysis included documenting existing problems:

1. Lack of documentation — Entire projects without technical documentation, architecture decisions unrecorded, tribal processes living in one person’s head.
2. Lack of alignment — Every team worked differently: different tools, different processes, different definitions of “done.”

These two problems were the root of many others. Without documentation, knowledge is lost with every person who leaves. Without alignment, scaling processes is impossible.

Final Reflections

This framework isn’t perfect or universal. It was born from a specific context — a LatAm FinTech where the engineering team was working in isolation from the business, with no product focus or impact metrics. There was no cohesive team as such — just groups of people working in parallel without alignment. The challenge wasn’t just optimizing, but building a real team for the first time.

The underlying principles are adaptable:

1. Measure before you cut — Map your entire scope before making team decisions.
2. Less is more — A small, senior team outperforms a large, junior one.
3. Autonomy requires real permissions — You can’t ask for ownership without granting access.
4. Consolidate before you build — If you have 160 services and use 66, your first project is consolidation, not creating service 161.
5. Design culture, don’t declare it — A values document on the wall doesn’t change behaviors. Concrete, measurable practices do.

I’m sharing this because I believe this kind of knowledge shouldn’t stay locked in a spreadsheet that nobody will ever open again. If you’re in a similar position — leading engineering at a startup that needs to do more with less — I hope some of this is useful.