Guilherme Starling
Three decisions · and what each one cost

The interesting part isn't what got built.

Anyone can list outcomes. What tells you whether an operator is any good is the decision that produced them: what the alternative was, what it cost to choose, and what they'd do differently now.

So these three are written as decisions, not as achievements. Each one includes the trade-off I accepted, because a case study without a cost is marketing.

01

Hire the leaders before the builders

2024 – 2025
The situation

Products were live and revenue was compounding, and there was no technology organization behind any of it: no structure, no hiring process, no career framework, no governance. Delivery worked because specific people made it work — which is a strategy with a hard ceiling and no warning before you hit it.

The decision

Design the structure before hiring into it, and hire leadership before individual contributors — then grow that leadership internally rather than importing it.

The reasoning was narrow: the things I could not do myself were exactly the things a technical leader does. Judge depth in an interview. Grow a mid-level engineer into a senior one. Say no to the wrong architecture with enough authority that it sticks. Every one of those is a compounding decision, and every month without someone making them is a month of debt that shows up two years later.

What it cost

Under delivery pressure, hiring a leader instead of two developers looks exactly like buying overhead, and it felt that way for the first two quarters. Raw output was slower than it would have been. That was the trade, made deliberately and defended more than once.

What it produced
  • 0 → 50people in 21 months
  • 10 / 40+direct and indirect reports
  • 100%of the company's current Product and Engineering leaders came out of that bench
What I'd do differently

Write the career framework in month one instead of month nine. We hired well and then spent a quarter retrofitting a structure people could see themselves in. That framework isn't bureaucracy — it's the promise you make at the offer stage, and we were making it verbally for far too long.

02

Build the reporting layer instead of licensing it

2026
The situation

Decisions about pricing and where to put the next engineer were being made on reporting that arrived after the month had closed. By the time a number was visible, the decision it should have informed was already behind us. The obvious move was to ask for headcount.

The decision

Don't ask for headcount, and don't renew the BI licence either. Build the reporting layer with AI instead of buying it — scheduled data routines, generated dashboards, workspace and credential management — on top of an analytical platform built from zero.

What made it the right call wasn't the cost saving; it was that a licensed tool would have given us the same reports on the same delay, because the constraint was never the visualisation layer. It was that nobody owned the numbers underneath it.

What it cost

The company now owns a system it has to maintain, and that is a real liability rather than a footnote. It only works because the team was reorganised around it — self-service instead of a request queue — and it would become a problem the day that stops being true. A licence is someone else's problem to keep running; this one is mine.

What it produced
  • Retiredthe licensed BI tool, and the cost with it
  • In-monthmargin visibility per product and per process, where month-end reporting used to be
  • 493 → 50divergences against the accounting close, once reconciliation was automated

The residual 50 turned out to be the more valuable half: they weren't errors in the routine, they were a defect in the manual process the routine was being checked against.

What I'd do differently

Name an owner for every metric on day one instead of week six. A number nobody owns doesn't get used — it gets admired. We spent a few weeks learning that the expensive way.

03

Govern the portfolio by economics, not by preference

2024 – 2026
The situation

A single-product lender had become three: payroll-deductible credit, pró-soluto real-estate credit and vehicle financing. Three risk profiles, three funding structures, one operational spine — and a planning process built when there was only one thing to plan.

The visible symptom was that roadmap arguments were won by whoever argued best, which is a fair description of most companies at that size and a terrible way to allocate engineers.

The decision

Put the portfolio's economics between the teams and the roadmap: prioritization frameworks, product rituals and operating routines, so that where the next engineer went was argued in contribution, risk and funding cost rather than in conviction.

What it cost

Governance is a tax on speed, and it's paid by the people who were moving fastest before it existed. Saying no in a framework people can see is more defensible than saying no in a meeting, but it isn't more popular.

What it produced
  • R$500M+company loan originations since inception, across the three products (≈US$92M)
  • 75K+active users the company reached
  • One spinean operation that didn't need rebuilding for each new product

The scale figures on this page are the company's, built by a lot of people over seven years. What's mine is the mandate, the call, and the team that delivered it — and that distinction is the whole reason these are written as decisions.

I'm an operations leader — Head of Operations, Chief of Staff, country lead — looking for the same kind of problem at a company with more scale and velocity than I've seen up close. Belo Horizonte, Brazil, UTC−3, full overlap with CET and ET.

Três decisões · e o que cada uma custou

A parte interessante não é o que foi construído.

Qualquer um lista resultado. O que diz se um operador presta é a decisão que produziu aquilo: qual era a alternativa, o que custou escolher, e o que ele faria diferente hoje.

Então estas três estão escritas como decisões, não como conquistas. Cada uma inclui o trade-off que eu aceitei, porque case sem custo é peça de marketing.

01

Contratar os líderes antes dos construtores

2024 – 2025
A situação

Os produtos estavam no ar e a receita compondo, e não havia organização de tecnologia por trás de nada disso: sem estrutura, sem processo de contratação, sem plano de carreira, sem governança. A entrega funcionava porque pessoas específicas faziam funcionar — o que é uma estratégia com teto duro e nenhum aviso antes de você bater nele.

A decisão

Desenhar a estrutura antes de contratar para dentro dela, e contratar liderança antes de indivíduos — e depois formar essa liderança por dentro em vez de importá-la.

O raciocínio era estreito: as coisas que eu não conseguia fazer sozinho eram exatamente as que um líder técnico faz. Avaliar profundidade numa entrevista. Formar um engenheiro pleno em sênior. Dizer não para a arquitetura errada com autoridade suficiente para o não durar. Cada uma dessas é uma decisão que compõe, e cada mês sem alguém tomando elas é um mês de dívida que aparece dois anos depois.

O que custou

Sob pressão de entrega, contratar um líder em vez de dois desenvolvedores parece exatamente comprar overhead, e pareceu isso nos dois primeiros trimestres. A produção bruta foi mais lenta do que teria sido. Esse foi o trade, feito de propósito e defendido mais de uma vez.

O que produziu
  • 0 → 50pessoas em 21 meses
  • 10 / 40+reportes diretos e indiretos
  • 100%dos líderes atuais de Produto e Engenharia da empresa saíram daquela bancada
O que eu faria diferente

Escrever o plano de carreira no mês um, não no mês nove. Contratamos bem e depois passamos um trimestre remendando uma estrutura na qual as pessoas conseguissem se enxergar. Esse plano não é burocracia — é a promessa que você faz na hora da proposta, e a gente estava fazendo ela de boca por tempo demais.

02

Construir a camada de reporting em vez de licenciá-la

2026
A situação

Decisões de preço e de onde colocar o próximo engenheiro estavam sendo tomadas sobre um reporting que chegava depois do mês fechado. Quando um número ficava visível, a decisão que ele deveria ter informado já tinha passado. O movimento óbvio era pedir headcount.

A decisão

Não pedir headcount, e também não renovar a licença de BI. Construir a camada de reporting com IA em vez de comprá-la — rotinas de dados agendadas, dashboards gerados, gestão de workspace e credenciais — em cima de uma plataforma analítica construída do zero.

O que fez disso a decisão certa não foi a economia; foi que uma ferramenta licenciada teria dado os mesmos relatórios no mesmo atraso, porque a restrição nunca foi a camada de visualização. Era que ninguém era dono dos números embaixo dela.

O que custou

A empresa agora é dona de um sistema que precisa manter, e isso é um passivo real, não uma nota de rodapé. Só funciona porque o time foi reorganizado em volta dele — self-service em vez de fila de pedido — e viraria problema no dia em que isso deixar de ser verdade. Licença é problema de outro para manter de pé; esse aqui é meu.

O que produziu
  • Aposentoua ferramenta licenciada de BI, e o custo junto
  • Dentro do mêsvisibilidade de margem por produto e por processo, onde antes era relatório de fechamento
  • 493 → 50divergências contra o fechamento contábil, depois que a conciliação foi automatizada

As 50 que sobraram acabaram sendo a metade mais valiosa: não eram erro da rotina, eram defeito no processo manual contra o qual a rotina estava sendo conferida.

O que eu faria diferente

Nomear um dono para cada métrica no dia um, não na semana seis. Número que ninguém tem como dono não é usado — é admirado. A gente gastou algumas semanas aprendendo isso do jeito caro.

03

Governar o portfólio pela economia, não pela preferência

2024 – 2026
A situação

Uma financeira de um produto só tinha virado três: crédito consignado, crédito imobiliário pró-soluto e financiamento de veículo. Três perfis de risco, três estruturas de funding, uma só espinha operacional — e um processo de planejamento construído quando só havia uma coisa para planejar.

O sintoma visível era que discussão de roadmap era ganha por quem argumentava melhor, o que descreve bem a maioria das empresas daquele tamanho e é uma péssima forma de alocar engenheiro.

A decisão

Colocar a economia do portfólio entre os times e o roadmap: frameworks de priorização, rituais de produto e rotinas de operação, para que onde o próximo engenheiro ia fosse discutido em contribuição, risco e custo de funding, e não em convicção.

O que custou

Governança é imposto sobre velocidade, e quem paga é quem estava correndo mais antes dela existir. Dizer não dentro de um framework que as pessoas enxergam é mais defensável do que dizer não numa reunião, mas não é mais popular.

O que produziu
  • R$500M+originados pela empresa desde o início, nos três produtos (≈US$92M)
  • 75 mil+usuários ativos que a empresa alcançou
  • Uma espinhauma operação que não precisava ser reconstruída a cada produto novo

Os números de escala desta página são da empresa, construídos por muita gente ao longo de sete anos. O que é meu é o mandato, a decisão e o time que entregou — e essa distinção é a razão inteira de isso estar escrito como decisão.

Sou um líder de operações — Head de Operações, Chief of Staff, country lead — procurando o mesmo tipo de problema numa empresa com mais escala e velocidade do que eu já vi de perto. Belo Horizonte, Brasil, UTC−3, sobreposição total com CET e ET.