Projeto B2: acting as an engineer in a global team

Nível: B2

Objetivo

Demonstrar comunicação B2 produzindo, do começo ao fim, os quatro artefatos centrais da engenharia em time global: um RFC, uma defesa de design review, um postmortem de incidente e um executive summary para liderança. Cada artefato deve ser coerente, conciso, tecnicamente crível e culturalmente adequado para um time distribuído.

Explicação

O Projeto B2 integra tudo o que foi estudado de B1 e B2 em um único ciclo de duas semanas. Não é 'tudo o que vimos': é a capacidade de usar vários padrões juntos, no ritmo e na ordem certos, sem perder clareza nem profissionalismo.

1. RFC (Request for Comments)

Um RFC de uma a duas páginas tem seis blocos, nesta ordem:

• Problem: qual é a dor real, com dados. `The problem is p99 latency on checkout averaging 2.1 seconds.`
• Goals: o que precisa ser verdade depois do projeto. `p99 latency below 400 milliseconds.`
• Non-goals: o que está fora de escopo. `We are not changing the payment provider.`
• Options: pelo menos duas alternativas, com trade-offs explícitos. `Option A: caching layer; Option B: database read replica.`
• Decision: qual opção foi escolhida e por quê. `We are going with Option A because the prototype reduced p99 by 35%.`
• Roll-out plan: como o change vai chegar aos usuários. `Staged: 1% day one, 10% day two, 100% day five.`

A ordem importa: o problema justifica as metas, as metas limitam as opções, as opções sustentam a decisão, e o roll-out é o compromisso operacional.

2. Design review

A design review é onde a decisão é defendida ou revisada. Três movimentos B2:

• Opening statement: uma frase com o problema, a decisão e o trade-off. `Today I'm proposing Option A: a caching layer in front of the database, trading memory for latency.`
• Handling Q&A: discordar com educação, adiar com plano. `I see your point about cache invalidation; let's park that and validate in the prototype.`
• Closing decision: fechar a conversa de forma executiva. `I will go with Option A unless I hear concerns by Friday.`

A review é técnica e adulta: senior engineers discordam, mas fecham a decisão na mesma call quando possível.

3. Incident response + postmortem

Quando a produção quebra, a linguagem muda: frases curtas, com timestamp, com ação. O postmortem vem depois, em texto longo e blameless.

• During the incident: `14:02 UTC: error rates spiked on checkout. 14:05 UTC: I declared an incident. 14:08 UTC: we rolled back the deploy. 14:15 UTC: error rates returned to normal.`
• In the postmortem: root cause (a causa fundamental), contributing factors (o que tornou o incidente mais provável), e action items (tarefas com owner e prazo). `Root cause: a missing index in yesterday's migration. Contributing factors: no canary, no load test on the new index.`

O tom é blameless: ninguém é apontado pelo nome; o que muda são os sistemas.

4. Executive summary

Liderança lê cinco coisas em uma página:

• Decision needed: a escolha que precisa ser feita. `Approve the staged roll-out of the new caching layer.`
• Current status: onde o projeto está. `Design review complete; prototype in progress.`
• Risk: o que pode dar errado. `A regional database outage could delay the roll-out by one sprint.`
• Impact: o que muda se for aprovado. `p99 latency reduced by 35% in the prototype; projected $400k in annual savings.`
• Recommendation: a recomendação final. `Approve Option A with the staged roll-out plan.`

A linguagem é direta, sem jargão desnecessário, com números quando possível. O 'so what' para o leitor vem na segunda linha.

Exemplos

Erros comuns

• Colocar a solução antes do problema no RFC: a audiência precisa do problema para avaliar a solução.
• Listar opções sem trade-offs: opção sem trade-off é propaganda, não engenharia.
• Sair da design review sem fechar a decisão: indecisão custa ciclos do time e atrasa o roll-out.
• Misturar hipótese com fato no postmortem: 'achamos que foi o banco' antes de confirmar vira narrativa, não análise.
• Apontar pessoas pelo nome no postmortem: tom blameless protege o time e produz mais sinal por incidente.
• Colocar jargão de engenharia no executive summary: liderança não precisa saber o que é TTL de cache; precisa saber o impacto em dólares.
• Esconder o risco no executive summary: liderança prefere um risco explícito a uma surpresa no roll-out.
• Fechar sem pedir a decisão: se a call acaba sem 'approve / reject / defer', o trabalho não terminou.

Prática guiada

Reescreva cada bloco abaixo no padrão B2 do Projeto.

1. RFC — Problem: troque 'We have latency issues' por uma frase com dado concreto.
2. RFC — Options: liste duas opções e escreva o trade-off de cada uma em uma frase.
3. Design review — Opening: combine problema, decisão e trade-off em uma frase de abertura.
4. Design review — Push-back: responda a um senior engineer que discordou usando 'I see your point, but...' + dado.
5. Postmortem — Root cause: separe claramente causa raiz de fatores contribuintes.
6. Executive summary — Recommendation: escreva a recomendação final em uma frase, com número de impacto.

Compare com a versão inicial: a versão B2 responde 'so what?' para a audiência em cada bloco.

Resumo

O Projeto B2 integra quatro artefatos em um ciclo: RFC (problem, goals, non-goals, options, decision, roll-out), design review (abertura com trade-off, manejo de Q&A, fechamento de decisão), postmortem (timeline com timestamp, root cause, contributing factors, action items com owner), e executive summary (decision needed, status, risk, impact, recommendation). O tom é blameless, conciso e executivo; jargão técnico só entra quando a audiência é técnica; números e prazos sempre.

História: Projeto B2: acting as an engineer in a global team

Nível: B2

História em inglês

Writing the RFC

On Monday morning, I drafted the RFC for the new caching layer and shared it on the team channel. I opened with the problem: p99 latency on checkout was averaging 2.1 seconds. I listed the goals: bring p99 below 400 milliseconds within the quarter. I made the non-goals explicit: we are not changing the payment provider. I presented two options with their trade-offs: a caching layer in front of the database, or a read replica. I closed with the roll-out plan: 1% on day one, 10% on day two, 100% on day five.

Defending the design in review

On Thursday, I defended the design in the design review with senior engineers in Berlin and São Paulo. I opened with: Today I'm proposing Option A, a caching layer, trading memory for latency. A senior engineer pushed back: I see the latency gain, but I worry about cache invalidation. I replied: I see your point; let's park that and validate in the prototype this week. At the end of the review, I said: I will go with Option A unless I hear concerns by Friday.

Leading the incident and writing the postmortem

On Friday at 14:02 UTC, error rates spiked on the checkout endpoint. I declared an incident at 14:05 UTC and took the role of incident commander. We identified the database as the prime suspect and rolled back the deploy at 14:08 UTC. Error rates returned to normal at 14:15 UTC; the team in San Francisco took over from there. On the following Monday, I wrote the postmortem: root cause was a missing index in the migration; contributing factors were no canary and no load test.

Presenting the executive summary

On Tuesday of week two, I joined the leadership call and presented the executive summary. I opened with: decision needed, approve the staged roll-out of the new caching layer. I followed with current status, risk, and impact: 35% latency reduction in the prototype, projected 400k in annual savings. I closed with the recommendation: approve Option A with the staged roll-out plan. The VP asked two clarifying questions, I answered both, and the decision was approved.

Tradução linha por linha

Notas de vocabulário

• I opened with the problem = integração B2: RFC começa pelo problema, não pela tecnologia.
• trading memory for latency = padrão 'trade X for Y' explicita o trade-off em uma frase.
• let's park that and validate in the prototype = park + validate + prazo: discordar com plano.
• I will go with Option A unless I hear concerns by Friday = fechamento B2: assertivo, com prazo e cláusula de escape.
• I declared an incident at 14:05 UTC = linguagem de incidente: timestamp + ação + papel.
• the database as the prime suspect = hipótese marcada como hipótese, não como fato.
• root cause ... contributing factors = postmortem: separar causa técnica de fatores sistêmicos.
• decision needed ... current status ... risk ... impact ... recommendation = ordem canônica do executive summary em cinco blocos.
• approve Option A with the staged roll-out plan = recommendation B2: nome da opção + qualificação do plano.
• the decision was approved = fechamento do projeto: a decisão sai da call, não fica em aberto.

Perguntas de compreensão

1. Por que o RFC abre pelo problema e não pela solução?
2. Qual é a função do 'park' em uma design review?
3. Como separar root cause de contributing factors no postmortem?
4. Por que o executive summary abre com 'decision needed'?
5. Qual é o tom certo de um postmortem?
6. Como fechar uma design review sem indecisão?
7. Por que usar estágios pequenos (1%, 10%, 100%) no roll-out?
8. Como declarar um risco no executive summary?
9. Qual é a estrutura canônica de um RFC B2?

Prática com a história

1. Reescreva 'I think we should use a cache' como abertura de design review B2.
2. Responda a um push-back: 'Cache invalidation is too complex for this scope.'
3. Escreva a primeira linha de um executive summary para aprovar um roll-out.
4. Separe root cause de contributing factors: deploy quebrou em produção.
5. Feche uma design review sem indecisão.
6. Declare um risco com prazo no executive summary.