Colaboração não serve para nada
(newsletter.posthog.com)- O ditado “sozinho você vai mais rápido, junto você vai mais longe” pode acabar destruindo uma startup
- A colaboração eficiente deveria ser como a ajuda de um GPS enquanto você dirige, mas a maioria das empresas sofre perda de velocidade por causa de feedback demais e papéis excessivamente distribuídos
- A PostHog, sob o valor “Você é o motorista (You're the Driver)”, enfatiza autonomia e alto senso de dono, além de minimizar colaborações desnecessárias
- As causas do excesso de colaboração incluem a vontade de ajudar, uma cultura excessivamente inclusiva, pedidos de feedback pouco claros, abuso de “let’s discuss” e fuga de responsabilidade
- A solução é uma abordagem prática: priorizar deploy imediato, deixar claro quem é o responsável, pedir feedback só às pessoas necessárias, dar feedback depois do lançamento e bloquear imediatamente colaborações desnecessárias
A armadilha da colaboração
- A frase "se quer ir rápido, vá sozinho; se quer ir longe, vá junto" mata uma empresa lentamente
- Isso é uma armadilha que justifica colaboração excessiva
- Colaboração útil deveria ficar no nível de orientação de rota ou informação ao redor enquanto se dirige
- Mas a maioria das organizações cai em uma colaboração ineficiente, como se várias pessoas ficassem revezando o volante
- O feedback certo ajuda a chegar mais rápido ao destino, mas feedback em excesso reduz a velocidade e cria o risco de nem chegar onde se queria
O paradoxo do feedback: fazer bem feedback é saber quando não dar feedback
- Na PostHog, com o crescimento, também aumentaram as colaborações que não agregam valor ou entregam valor muito baixo em relação ao tempo investido
- Em uma reunião recente da empresa inteira, o tema foi "colaboração é ruim"
- "Você é o motorista (You're the driver)" é um valor central da PostHog: "contratar gente excelente e não atrapalhar"
- Sem deadlines, coordenação mínima e gerentes não dizendo o que fazer
- Em troca, exige-se um senso de dono extremamente alto e a capacidade de fazer muita coisa sozinho
- Profissionais de marketing fazem deploy de código, pessoas de vendas respondem perguntas técnicas sem apoio e engenheiros de produto trabalham em toda a stack
- Quase sempre existe alguém melhor do que você em alguma coisa, então a tentação de colaborar é grande, mas colaborar força o motorista a desacelerar e explicar contexto, histórico e raciocínio
- Essa tendência aparece em algumas expressões recorrentes
- "Queria saber o que X pensa"
- "Quero ouvir a opinião de Y"
- "Precisamos trabalhar com Z"
- Isso às vezes leva a insights valiosos, mas sempre desacelera o motorista
- Corrói a motivação, a confiança e a eficiência do motorista, e no fim reduz o volume de entregas
Se colaboração é ruim, por que as pessoas fazem isso?
- Todo mundo contribui para o problema
- As pessoas querem ajudar: quando alguém posta no Slack algo em andamento, por causa da cultura de feedback os outros sentem que devem comentar
- Por outro lado, pedir feedback a pessoas específicas pode parecer pouco inclusivo, então isso não é feito (mesmo quando seria útil)
- Não há especificidade suficiente sobre que feedback é necessário: isso abre espaço para a colaboração se intrometer. Uma discussão sobre construir um recurso específico pode escalar para uma reavaliação de todo o roadmap do produto
- Quando alguém traz uma boa ideia, a reação padrão não é "faça isso", e sim "vamos discutir"
- Como prova, o Slack está lotado de "let's discuss"
- Isso desvia da execução para a discussão
- As pessoas estão ocupadas demais para executar, ou com preguiça, então querem só conversar
- PR → issue/RFC → Slack (hoje, na maioria dos casos, para aqui) → "vamos discutir"
- Não está claro quem é o dono (ou ninguém quer ser dono do que está sendo discutido)
- Por mais irritante que seja, às vezes uma pessoa só não consegue fazer o shipping do começo ao fim com qualidade alta o bastante, e não dá simplesmente para lançar e iterar depois
- Código quebrado pode ser corrigido, mas uma newsletter não pode ser reenviada
Como destruir a colaboração (e ir mais rápido e mais longe)
- Se a colaboração é o inimigo, como derrotá-la?
- O padrão deve ser executar primeiro: Pull request > Issue > mensagem no Slack
- Quando a colaboração estiver exagerada, é preciso traçar o limite com clareza: “você é o motorista, decida”
- Ao pedir feedback, marque pessoas específicas e diga exatamente o que quer delas, em vez de jogar a solicitação no vazio
- Em vez de revisão antes do lançamento, a preferência é por feedback depois do lançamento (antes da próxima iteração): feedback prévio pode virar um processo de aprovação disfarçado
- Líderes devem segurar o impulso de opinar e manter a postura de "você pode simplesmente fazer" (you can just do stuff)
- Cada pessoa deve agir como um "capitão bem informado" (informed captain)
- Pode ouvir feedback, mas a decisão final é sua
Conclusão
- Não dá para erradicar toda colaboração, e parte dela é útil (esta newsletter foi editada por Ian e Andy)
- Mas é preciso fazer um esforço deliberado para reduzir a colaboração por padrão
- Se você não estiver reduzindo ativamente a colaboração, provavelmente já está colaborando demais por padrão
- Como a colaboração inevitavelmente desacelera as coisas,
quanto menos se colabora, mais longe e mais rápido se pode ir
- Escrito por Charles Cook, que odeia água com gás (porque as bolhas são colaborativas demais)
12 comentários
Trabalhar junto é o certo.
Se essa pessoa estiver ausente (falecimento, doença, férias), vocês não vão atender o cliente?
Eu trabalho em uma empresa tão pequena que sou o único funcionário. Então faço a manutenção sozinho e desenvolvo sozinho... Como já faz tempo demais que estou assim, às vezes sinto vontade de trabalhar com outras pessoas. Trabalhar sozinho é solitário demais...
É um texto com provocação forte demais.
A individualidade do autor se destaca demais, então talvez ele não consiga se dar bem com outras pessoas?
Para criar uma única funcionalidade,
normalmente são indispensáveis papéis como designer, planejamento, gerente de projeto, front-end, back-end, QA etc.
Parece que a pessoa está fazendo afirmações exageradas para expor um problema que ela percebe.
Colaboração não deve significar algo conduzido como uma ágora.
Ainda assim, o uso excessivo de
let’s discusse a fuga de responsabilidade são, sem dúvida, dois problemas reais.Mas, na maioria dos casos, isso acontece porque não existem líderes ou responsáveis com visão e insight.
É justamente para isso que se faz pesquisa, se desenvolvem pessoas, se contrata ou se compra uma solução.
Quando se monta um time só com integrantes que obedecem bem, isso acaba se intensificando ainda mais.
Não me parece que esse seja um problema criado pela colaboração ou pelo trabalho individual.
Tenha em mente que a Posthog sempre escreve textos com esse tipo de linguagem bem forte.
Como o tom é forte demais, às vezes aparecem textos que parecem passar um pouco do ponto e se desviar do tema.
("Água com gás é tão boa!!!")
Água com gás, isso aí não é uma plataforma de lançamento de highball? Cof cof
Opiniões do Hacker News
Sempre que surgia colaboração, havia o conselho: “tem gente demais, X é o driver, então deixe que ele decida”
Mas, quando o gerente diz “você decide”, não aparece na reunião e depois volta dizendo “se fosse eu, teria feito diferente”, pedindo mudanças, os funcionários acabam indo embora
O gerente do meu gerente sempre fazia isso; quando eu abria um PR, no fim ele exigia um redesign completo
Acabei ficando com medo do trabalho em si, porque sabia que qualquer projeto teria de ser refeito do zero
Se o chefe reverte decisões com frequência demais, o time passa a empurrar de propósito todas as decisões para ele
No fim, o próprio chefe acaba sufocado pela sua necessidade de controle
Mas, no contexto de “o gerente não deve dar ordens”, ele é coerente
Porque ela sempre levava a ajustes infinitos de pixel, mudanças de layout e propostas de retrabalho completo da stack
Acho que o cerne do problema não é colaboração, e sim a estrutura de tomada de decisão
Feedback é uma oportunidade de aprendizado, mas, se não fica claro quem toma a decisão final, tudo anda mais devagar
Para decidir rápido, é preciso deixar claro quem é o responsável pela decisão e reconhecer que a maioria das decisões pode ser revertida
Se há menos colaboração, também há menos oportunidades de aprendizado
O responsável pela decisão deve ser claramente definido, mas precisa ouvir o feedback com atenção
Além disso, decisões reversíveis devem ser tomadas rapidamente
Dizem que colaboração reduz a velocidade, mas, na verdade, o processo melhora a qualidade
Há quem discorde só por discordar e, no fim, tente tomar para si a propriedade da ideia
Mesmo que a pessoa decisora esteja definida, se sua opinião for fraca, tudo acaba indo para um consenso da maioria
Se marcavam “request changes”, todo mundo tinha de seguir aquilo, e no fim a qualidade do código piorava
Acho muito melhor contratar gente boa e delegar poder de decisão
Deve fornecer direção, prioridades e frameworks para que o time consiga julgar por conta própria
Não concordo com o ódio à água com gás do autor, mas é bom ver os problemas de colaboração sendo tratados publicamente
Em várias empresas, já gastei 3 vezes mais tempo em picuinhas de estilo durante code review do que na implementação de fato
Minha posição é: “se isso te incomoda tanto, corrige você mesmo e me avisa”
Também foi compartilhado um vídeo relacionado
É tarde demais para lidar com isso na etapa de code review
O problema é quem não segue o estilo do código ao redor
Isso deve ser resolvido com linter ou com cultura
Uma funcionalidade feita sozinho, sem colaboração, vira um grande risco na manutenção
Se o sistema quebra quando eu não estou, a ausência de colaboração aparece como problema
O autor enfatiza viés para a ação, mas excluir colaboração gera silos e excesso de confiança
Uma cultura de Slack no estilo “vou fazer X, alguém tem alguma objeção forte?” funcionou bem
Por isso, o trabalho realmente avança
Anos atrás, enquanto entrevistava pessoas para um livro sobre GitHub, vi times que abriam um PR vazio antes de escrever código para obter aprovação de design
Isso não é colaboração durante a execução, e sim colaboração na fase de planejamento
Com boa escrita e boa comunicação, colaboração pode ser rápida e eficaz
Na era da IA, essa habilidade vai se tornar ainda mais importante
Sem reunião e sem compartilhamento, o mérito não aparece
Se você evita um problema, ninguém fica sabendo; por isso, em alguns lugares existe até uma cultura de “deixar o problema acontecer”
Só planejar não basta para imaginar a implementação
Como diz a última frase do texto, “boa colaboração existe”
O título é clickbait, mas a PostHog já é conhecida por esse estilo
Faz você olhar de forma mais crítica para o meme da “colaboração”
Este texto é um experimento mental equivocado
O problema não é colaboração, e sim a ausência de poder de decisão
Alguém precisa decidir com clareza, e quanto mais esse poder for delegado para baixo, mais rápido tudo anda
Textos assim distorcem a linguagem e têm uma toxicidade que esvazia conceitos necessários
Também é problemático quando, assim que alguém trava, a cultura vira “pergunta para o Bob”
No curto prazo é mais rápido, mas no longo prazo isso causa perda de oportunidade de aprendizado e sobrecarga de trabalho
Eu gosto quando meus colegas se interessam pelo meu trabalho
“Faz do seu jeito” na prática quer dizer “não me importo”
O problema não é colaboração, e sim colaboração ineficiente
PRs têm um entregável concreto, então a discussão fica mais clara
Tenho a impressão de que colaboração funciona melhor quando são duas pessoas
Duas pessoas conseguem entender a codebase juntas e revisar os PRs uma da outra
Mas, quando passam de três, a complexidade combinatória explode
Por isso, eu gostaria de estruturar projetos em times de duas pessoas
link de referência
Como na analogia do texto, a F1 é um esporte extremamente colaborativo
O piloto se comunica com o coach durante toda a corrida
Fico pensando se existe algo equivalente no software
Os comentários estão estranhos. Pelo resumo do texto, a ideia não parece ser trabalhar sozinho ou dizer que não é preciso ter equipe, mas sim reduzir a colaboração excessiva entre os membros do time.
Concordo.
Parece o resultado da combinação de um título caça-cliques com um leitor que não leu com atenção.
Não só em textos assim, mas até no YouTube tem muita gente que comenta vendo apenas o título.
Ao começar algo novo, você pode tentar seguir por um caminho seguro demais e acabar pedindo revisões em excesso às pessoas ao redor. Na prática, como essas pessoas ou a equipe talvez não conheçam bem o assunto, pode ser difícil até receber um bom feedback. No fim, a ideia parece ser que vale mais a pena primeiro criar alguma coisa e, mesmo que esteja indo na direção errada, receber depois um feedback concreto e retrabalhar a partir disso, porque assim dá para economizar tempo no geral.