Passar a barra

Imagina um enorme porta-contentores a chegar a Leixões ao fim da tarde. O comandante conhece o navio melhor do que ninguém, mas não conhece aquela barra como quem a atravessa todos os dias: as correntes, os bancos de areia, o movimento de entrada e saída do porto. Por isso, a lei obriga-o a receber a bordo um piloto da barra¹, alguém com conhecimento local da água e das suas armadilhas.

Numa manobra muito perigosa, o piloto sobe por uma escada lateral, com o navio ainda em andamento, e pouco depois assume a condução da manobra. O comandante não sai da ponte. Continua responsável pelo navio e por toda a gente a bordo.

Durante a manobra, há duas pessoas com autoridade sobre o mesmo navio e uma equipa de ponte que trabalha com as duas. Parece uma receita para a confusão, e quase sempre corre bem. A razão é simples: quase nada fica por combinar.

Em terra, as coisas nem sempre são assim. Pensa num cruzamento sem sinalização, numa estrada secundária. Não há semáforos, nem sinais de prioridade, nem marcas no chão. Cada condutor chega convencido de que sabe quem tem prioridade: um porque vem da estrada mais larga, outro porque vem da direita, outro porque passa ali todos os dias. Durante algum tempo, tudo corre bem. Os condutores reconhecem-se, abrandam, trocam um gesto com a mão. Até ao dia em que dois avançam ao mesmo tempo e o acidente é inevitável.

A posteriori, alguém pergunta como é que um condutor experiente pode cometer aquele erro. A pergunta faz sentido, mas também é simplista e inocente. Também precisamos de perguntar: que regra é que estava em vigor e como é que temos a certeza que todos a conheciam?

Muitas organizações funcionam mais como este cruzamento do que como a ponte de um navio. Pedem autonomia, iniciativa e capacidade de julgamento: a “pro-actividade” ouvimos nós. Os limites e fronteiras ficam implícitos, não existem marcações no chão nem sinais a indicar a prioridade, ficam sustentados pela proximidade, rotina, pela memória de conversas e pelo entendimento de cada pessoa. Quando uma decisão provoca um conflito, descobrimos que havia várias versões do que era esperado e cada um tinha a sua expectativa como legítima.

A experiência ajuda-nos a identificar riscos. A liderança ajuda-nos a tornar os limites compreensíveis. Precisamos das duas coisas para que a autonomia seja possível e sobreviva ao primeiro erro.

Como se navega a dois

Tudo assenta em poucos documentos e numa conversa curta. Quando o piloto chega à ponte, o comandante entrega-lhe o cartão do piloto, uma folha que resume o navio: dimensões, calado, como responde ao leme, que equipamento está avariado. O piloto traz o seu plano para a passagem: o caminho, as velocidades, os pontos onde vai mudar de rumo, o momento em que entram os rebocadores. O guia da associação internacional de pilotos diz que cada missão “deve começar com uma troca de informação entre o comandante e o piloto”². Em poucos minutos, os dois juntam o que sabem e acordam o caminho antes de o navio ficar comprometido.

Depois, a responsabilidade não muda de mãos: “o comandante mantém a responsabilidade última pela segurança do seu navio”³. Em contrapartida, as recomendações da IMO atribuem ao comandante e à equipa de ponte o dever de apoiar o piloto “para garantir que as suas ações são acompanhadas a todo o momento”⁴. O comandante deixa a condução ao piloto e acompanha cada ordem contra o plano acordado. Quem recebe a condução também tem deveres. Comandante, oficiais e piloto “partilham a responsabilidade por uma boa comunicação”⁵.

A supervisão tem um critério de retoma de controlo conhecido de antemão. Segundo uma análise de uma mútua de seguros marítimos, o comandante fica “obrigado a retomar a condução”⁶ se as ordens do piloto puderem pôr o navio em perigo. A retoma tem um motivo definido, e no resto do tempo o piloto conduz.

A equipa de ponte também fala. O Nautical Institute afirma que “o «desafio» é um princípio-chave da boa gestão de recursos na ponte”⁷, e há formação que propõe uma escada para o fazer: “perguntar, sugerir, insistir”⁸. Quem vê um risco começa por perguntar, depois sugere e, se for preciso, insiste.

Quando o navio sai do porto e o piloto desce para a lancha, a ponte fica entregue ao oficial de quarto. Durante quatro horas, de dia ou de noite, é ele quem vigia o rumo, a velocidade e os outros navios, enquanto o comandante descansa. Não precisa de pedir autorização a cada passo, porque trabalha com ordens permanentes que o comandante e os oficiais assinam e que ficam “disponíveis para consulta na ponte a todo o momento”⁹. As mesmas ordens dizem quando tem de chamar o comandante, por exemplo quando a visibilidade desce abaixo de um valor definido¹⁰. Num navio de investigação, uma dessas regras diz apenas “NA DÚVIDA, CHAMAR O COMANDANTE”¹¹.

A autonomia também se ganha. Um comandante que entra muitas vezes no mesmo porto pode obter uma licença que o dispensa do piloto. Numa portaria portuguesa de 1990, essa licença exigia-lhe provar que “frequentou o porto pelo menos duas vezes por mês” nos nove meses anteriores, e manter essa regularidade depois. Previa também uma averiguação preliminar depois de um acidente¹². A dispensa assentava em sinais observáveis, mantinha-se com a prática e era revista quando alguma coisa corria mal.

Somando tudo, a bordo há cinco coisas que tornam a delegação segura: uma conversa antes de largar, ordens escritas que toda a gente conhece, clareza sobre quem tem a condução em cada momento, critérios para chamar o comandante, e regras para retomar a condução e devolver a autonomia.

Precisamos mesmo disto numa tech?

A bordo está em jogo a vida das pessoas. Numa equipa de tecnologia, o pior que costuma acontecer é uma sprint perdida ou uma dependência partida, o que parece quase anedótico ao lado das consequências que podem acontecer num navio. Mas a diferença joga a favor do argumento. Se, onde o erro pode custar vidas, a solução da profissão foi ter poucas regras claras, uma conversa antes e alguém a acompanhar, é difícil justificar que, onde o erro custa uma semana de trabalho, cada decisão precise de uma assinatura.

Há outras diferenças. A bordo existe um comandante por lei, e nas empresas a autoridade é muitas vezes partilhada. O piloto é externo e temporário, enquanto quem recebe autonomia numa equipa trabalha lá todos os dias, e por isso a figura mais próxima de um profissional sénior é o oficial de quarto.

A delegação

Delegar é acordar fronteiras, e as fronteiras raramente ficam escritas.

Delegar implica acordar que decisões uma pessoa pode tomar, dentro de que limites, com que recursos e em que situações precisa de envolver outros. A responsabilidade por explicitar e rever esse acordo pertence tanto a quem delega como a quem recebe autonomia.

A informalidade pode funcionar muito bem quando o entendimento é realmente partilhado. Organizações que valorizam rapidez conhecem esse prazer: poucas reuniões, decisões a andar, confiança entre pessoas que se conhecem. Mas a informalidade torna-se frágil, às vezes perigosa, quando cada pessoa absorveu uma ideia distinta do colega.

Colaborar num projecto implica vários acordos

Autonomia pode querer dizer coisas muito diferentes. Uma pessoa pode entender a autonomia como a possibilidade de decidir e informar. O seu gestor pode esperar uma recomendação ou proposta de solução sujeita a aprovação. Um stakeholder pode acreditar que qualquer alteração depende do seu consentimento.

Enquanto não há conflito, estas diferenças passam despercebidas. A qualidade da delegação revela-se quando é preciso tomar uma decisão difícil, sobretudo se os interesses não coincidem. Mesmo a bordo, onde quase tudo está escrito, a ambiguidade aparece. Um piloto de barra norueguês escreve que as expectativas dos comandantes vão de um papel “facilmente confundível com o comando a um papel puramente consultivo”¹³.

A mesma pessoa, dois âmbitos

Pensa num developer que trabalha num produto. Pertence à equipa de engenharia e responde ao diretor de engenharia, que cuida das ferramentas, dos processos, da qualidade técnica e do acompanhamento da sua carreira. No dia a dia, recebe requisitos e prioridades do product manager desse produto, que responde pelo roadmap e pela direção.

São dois âmbitos diferentes sobre a mesma pessoa. A equipa de engenharia é a casa do developer, e naquele produto é o PM quem orienta o trabalho. Na maior parte dos dias, isto funciona sem atrito.

As zonas cinzentas aparecem nas decisões que tocam os dois âmbitos. Quem decide se o developer passa duas semanas a resolver dívida técnica em vez de entregar uma funcionalidade? Quem decide se sai do produto para reforçar outra equipa? O diretor de engenharia gere a pessoa, e o PM conta com aquela capacidade para cumprir compromissos. Nenhum dos dois devia decidir sozinho, e o developer não devia ser o último a saber.

Por isso, ajuda mais perguntar quem decide este tipo de decisão, e quem tem de ser ouvido antes, do que perguntar quem manda nesta pessoa.

A bordo, esta ambiguidade resolve-se antes de largar: o comandante e o piloto sabem quem tem a condução e em que condições ela muda de mãos. Nas equipas, essa conversa raramente acontece.

As conversas têm de ser claras

Uma ideia comunicada pode passar por hipótese, consulta, proposta e decisão. Se ninguém nomear a passagem entre esses estados, uma pessoa pode ouvir “vamos explorar” e a outra “vai acontecer”.

No navio, a passagem da condução é dita em voz alta na ponte e fica registada. Toda a gente sabe quem a tem em cada momento. Numa equipa, essa passagem raramente é anunciada.

A ambiguidade é stressante

A literatura sobre os papéis no trabalho aponta na mesma direção e convém lê-la com cuidado. Uma meta-análise recente, com 515 estudos e cerca de 788 mil trabalhadores, concluiu que a ambiguidade de papéis foi o stressor mais prejudicial na maioria dos resultados estudados. Nas palavras da autora principal, “a ambiguidade de papéis, não ter clareza suficiente sobre o próprio trabalho, foi o mais prejudicial”¹⁴. Uma meta-análise anterior, com 169 amostras e mais de 35 mil trabalhadores, já tinha encontrado a ambiguidade de papéis entre os stressores mais fortemente associados a pior desempenho¹⁵.

Na gestão de decisões, a consultora Bain descreve o mesmo padrão. Num fabricante automóvel que falhava prazos, o marketing e o desenvolvimento achavam ambos que lhes cabia decidir as características dos novos modelos. O resultado foram decisões revistas vezes sem conta e vendas perdidas. Para os autores, o culpado é a “ambiguidade sobre quem responde por que decisões”¹⁶.

Quando uma linha vermelha invisível é ultrapassada

O que acontece quando o acordo só existe na cabeça de cada um.

Há dois erros que podem ocorrer numa organização.

O primeiro acontece quando os limites só se tornam claros depois de uma decisão ou situação dar para o torto. A organização acaba por avaliar pessoas segundo expectativas em relação a esses limites que nunca tinham sido partilhadas.

O segundo acontece quando a autonomia é lida como liberdade para alterar direcção, compromissos, dependências ou abrangência de outras equipas sem as consultar. Nesse caso, deixa de existir coordenação suficiente e pode haver quebra de confiança em todo o processo.

Resolver só o primeiro produz equipas que decidem sem olhar para os outros.

Resolver só o segundo produz equipas que pedem autorização para tudo.

Um pedido simples que mexe com todos

Caso real: sistema de design tokens

Lidero várias equipas de design, e delegar faz parte do meu dia, tal como ser responsabilizado. Um dos projetos em que isso mais se notou aconteceu na equipa de design system da Namecheap e da Spaceship. O pedido do negócio parecia pequeno: suportar dark mode. Para o cumprir, era preciso passar de paletas de cores simples e decisões de design que poderiam ser inconsistentes para um sistema semântico de design tokens. Como somos exigentes queríamos fazer bem feito.

As implicações eram enormes. No código, a implementação de um sistema de design tokens era uma breaking change que obrigava a refazer todos os componentes e interfaces, e cada equipa teria de interromper os seus próprios projetos para fazer uma migração para usar estes design tokens. No Figma, todas as equipas de design tinham de converter as suas paletas para o novo sistema, sob pena dos mockups ficarem estáticos e incapazes de receber updates. Essa migração não pode ser feita aos bochechos, pois os dois sistema não podem ou não devem viver juntos ao mesmo tempo no produto por muito tempo.

É neste tipo de projeto que uma autonomia mal acordada pode correr muito mal. Se a equipa de design system decidisse sozinha, impunha custos a toda a empresa sem os negociar. Se cada decisão precisasse da minha aprovação, o trabalho ficaria à minha espera, e eu teria de ter o mesmo conhecimento dos detalhes que os designers estavam a construir. Precisávamos de saber e definir, desde o início, quem decidia o quê e quando era preciso envolver outros. À nossa escala, era uma entrada na barra: um super navio, muita gente a bordo, um canal estreito e pouca margem para manobras improvisadas.

Responsabilizar sem precisão

Os erros vão acontecer.

Uma decisão tomada pode ter uma lógica razoável e ter sido mal alinhada ou implementada. Admiti-lo ajuda a evitar duas conclusões fáceis: culpar apenas quem decidiu, ou concluir que ninguém tem responsabilidade.

Tem de haver consequências…

A responsabilização útil da pessoa começa por descrever a conduta, as expectativas existentes e o impacto que pode existir. Distingue erro de julgamento, ambiguidade de comunicação, falta de capacidade e incumprimento deliberado, que podem pedir respostas diferentes. “Tem de haver consequências” não esclarece, por si só, o que falhou nem como evitar a repetição.

Há quem receie que olhar para o contexto da tomada de decisão seja uma forma de arranjar desculpas. A literatura sobre cultura justa conhece essa suspeita (“há quem suspeite que uma cultura justa significa deixar as pessoas impunes”) e responde com uma combinação de confiança, aprendizagem e responsabilização¹⁷. Amy Edmondson, que estuda como as equipas aprendem com as falhas, dá aos gestores uma instrução simples: “a tua principal tarefa é fazer com que se possa falar das falhas”¹⁸.

No mar, a análise de um acidente olha para todo o conjunto. Em novembro de 2007, com nevoeiro cerrado, o porta-contentores Cosco Busan embateu na proteção de um dos pilares da ponte entre São Francisco e Oakland e derramou cerca de 200 mil litros de combustível na baía. O investigador norte-americano apontou vários fatores: o desempenho do piloto, uma troca de informação incompleta antes da partida e “a supervisão ineficaz, por parte do comandante, do desempenho do piloto e do progresso do navio”. Entre os fatores contributivos esteve também a falta de formação da tripulação por parte da empresa¹⁹. O relatório avalia a decisão individual e as condições em que foi tomada, e é isso que torna a análise justa e útil.

Está resolvido, vou fazer micro-gestão

Depois de um erro, a tentação de acrescentar mais níveis de aprovação é compreensível. Pedir alinhamento antes de uma decisão com impacto significativo noutra equipa pode ser boa supervisão, e pedir maior visibilidade depois de uma falha também.

O risco de microgestão aumenta quando a revisão se estende a decisões de baixo risco que estavam delegadas, quando as aprovações se multiplicam sem necessidade clara ou quando já não existe uma condição para devolver autonomia. A distinção depende do âmbito, da proporcionalidade e da duração. Um controlo temporário sobre uma categoria de decisões pode ajudar a recuperar confiança. Um controlo indefinido sobre tudo pode esvaziar o papel de quem continua formalmente responsável. A Harvard Business Review resume o desafio como dar às pessoas “o espaço de que precisam para ter sucesso e aprender”²⁰.

A bordo, a retoma da condução tem um motivo definido e um fim previsto. Em muitas equipas, acontece por reflexo e fica sem data para terminar.

Informação publicada, acordo por confirmar

A bordo, entregar o cartão do piloto é só o primeiro passo. Os investigadores de incidentes notam que, muitas vezes, fica por aí: o cartão foi entregue, mas o plano da manobra nunca foi revisto nem comunicado à equipa de ponte²¹.

Nas equipas acontece o mesmo. Uma das formas de clarificar fronteiras é ter uma apresentação geral ou um documento acessível e acordado por todos. Torna a mudança visível, mas nem sempre confirma que as pessoas afetadas compreenderam e aceitaram o que muda para elas. Quem propõe uma mudança deve identificar os interlocutores críticos e pedir uma resposta concreta. Quem recebe esse pedido também tem responsabilidade de responder, levantar objeções e cumprir o acordo. A coordenação é recíproca.

Se a organização só funciona quando alguém persegue cada pessoa por vários canais, é razoável examinar o sistema de decisão. Nem toda a falha se resolve acrescentando esforço individual de comunicação.

Falo disto com conhecimento de causa. No projeto de tokens comunicámos por muitos canais: documentação, reuniões com stakeholders e uma apresentação pública do projeto à empresa, até à passagem para implementação. Mesmo assim, algumas equipas foram surpreendidas pelo impacto quando chegou a hora de migrar. Hoje teria estado mais perto dos stakeholders principais, para confirmar que percebiam o que aquilo significava para eles e para lhes dar espaço para fazer perguntas.

O que podemos fazer

Cinco movimentos, ordenados no tempo: antes, durante e depois da decisão.

Nada do que se segue substitui o discernimento. O objetivo é reduzir ambiguidade, e qualquer instrumento que gere mais autorizações do que clareza precisa de ser simplificado. Também não proponho aplicar tudo de uma vez. Cada movimento resolve uma parte do problema descrito acima.

1. A conversa antes de largar

O comandante e o piloto combinam o caminho antes de o navio ficar comprometido. Numa equipa, o equivalente pode ser um acordo de delegação curto.

Há uma forma de tornar o acordo visível sem escrever manuais. A Management 3.0 propõe sete níveis de delegação: informar, vender, consultar, acordar, aconselhar, perguntar e delegar (no original, Tell, Sell, Consult, Agree, Advise, Inquire e Delegate). O ponto de partida é que “a delegação não é uma coisa binária”²². Para cada área de decisão, a equipa marca até onde vai a autoridade e revê esses níveis com regularidade, avançando quando há maturidade. Para decisões que atravessam equipas, a Bain acrescenta cinco papéis: quem recomenda, quem tem de concordar, quem executa, quem dá contributo e quem decide¹⁶.

Proponho um acordo de delegação que cabe numa tabela de sete linhas. Não é preciso documentar cada gesto. Uma frase inequívoca sobre quem decide pode evitar várias reuniões posteriores, e a pessoa que recebe a responsabilidade também deve perguntar quando não percebe o seu mandato.

Questão	Acordo a tornar explícito
Que resultado se espera	Resultado, critérios de qualidade e prazo relevante.
Quem decide	Decisões autónomas, decisões sujeitas a consulta e decisões que exigem aprovação.
Quem é afetado	Responsáveis e equipas cujos compromissos podem mudar.
Quais são os limites	Capacidade, orçamento, compromissos e riscos que não podem ser assumidos unilateralmente.
Quando se pede ajuda	Alterações de âmbito, conflitos, bloqueios e riscos que exigem escalada.
Como se acompanha	Canal e frequência suficientes para dar visibilidade sem duplicar o trabalho.
Como se revê o acordo	Momento de revisão e condições para aumentar ou reduzir supervisão.

Cada linha corresponde a algo que o piloto e o comandante combinam antes de largar. A última é a que mais se esquece: o acordo tem uma data de revisão e condições para subir ou descer o nível de supervisão.

No sistema de tokens, essa conversa inicial definiu a ordem do trabalho. Deleguei a exploração nos designers da equipa: primeiro identificavam requisitos e constrangimentos, e só depois propunham soluções. O meu papel ficou igualmente claro. Juntava arquitetura e development às discussões, para que as propostas fossem exequíveis, e mantinha informadas todas as equipas afetadas.

2. As ordens permanentes

O oficial de quarto decide sozinho durante horas porque tem ordens escritas, sempre à mão na ponte. Numa equipa, esse papel cabe ao briefing e a um registo partilhado das decisões.

Na minha equipa, este acordo vive em dois sítios. O primeiro é o briefing. Há projetos em que os designers têm muita liberdade para propor e opinar, e outros em que é preciso cumprir e entregar o que foi pedido, e digo-o logo no início. O segundo são documentos partilhados, acessíveis a toda a empresa, onde registamos as decisões, os action points e as dúvidas que saem das reuniões regulares de acompanhamento. Ter uma única fonte de verdade evita que o acordo se disperse por conversas privadas.

Um bom acordo também pode resolver duas necessidades de uma vez. No design system mobile, o desenvolvimento precisava de uma única fonte e o design precisava de duas, uma para Android e outra para iOS. O consenso foi manter duas bibliotecas de Figma independentes e uma terceira que reúne ambas.

3. Saber quem tem a condução

A precisão verbal é uma forma barata de prevenção. “Ainda não está decidido.” “Quero que recolhas as necessidades.” “Só comunicamos a mudança depois deste alinhamento.” Cada frase diz em que estado está a ideia: hipótese, consulta, proposta ou decisão.

Quem fala deve explicitar o estado. Quem transmite a informação deve preservá-lo. Se surgir uma discrepância, interessa reconstruir as palavras e a sequência antes de atribuir intenção. É o equivalente a anunciar na ponte quem tem a condução.

4. Quando chamar o comandante

A bordo, há limiares escritos para chamar o comandante e uma regra para todos os outros casos: na dúvida, chama-se.

Um acordo só ajuda se for fácil de aplicar quando a decisão aparece. Na prática, resume-se a poucas perguntas que qualquer pessoa pode fazer a si própria antes de avançar. A decisão está claramente dentro do meu acordo? Altera âmbito, direção aprovada ou compromissos? Mexe no esforço, nos prazos ou nas dependências de outras equipas? Há alguma aprovação por resolver?

Três princípios tornam estas perguntas úteis. Na dúvida, pergunta-se à liderança direta, sem parar o trabalho que não depende de respostas. Enquanto não houver decisão registada, comunica-se o bloqueio, e cabe a quem tem autoridade fechar o ciclo. E o caminho termina sempre numa ação: executar dentro das condições aprovadas ou manter o acordo anterior.

A escalada também funciona de baixo para cima. Como a equipa de ponte faz com o piloto, espera-se que os profissionais seniores desafiem uma orientação arriscada, primeiro com uma pergunta, depois com uma sugestão e, se for preciso, insistindo. O silêncio de quem reporta não valida a decisão de quem decide.

5. Retomar e devolver a condução

Quando o comandante retoma a condução, fá-lo por um motivo conhecido de antemão, e devolve-a ao piloto quando esse motivo desaparece. Nas equipas, retomar decisões sem dizer porquê, nem até quando, é o caminho mais curto para a microgestão.

No projeto de tokens, eu tinha o meu próprio critério de retoma. Houve vários desacordos, e procurámos resolvê-los com factos e contra-argumentos válidos. Os leads da equipa tomaram a iniciativa em boa parte das decisões, e eu moderava em algumas situações. Só bloqueava uma decisão quando havia um impacto que não tínhamos previsto ou quando o esforço não se justificava para o objetivo.

Retomar a condução é a parte fácil. A parte difícil é a conversa que vem a seguir, quando é preciso perceber o que falhou. Nos relatórios de acidentes marítimos, a análise começa por reconstruir o que cada pessoa na ponte sabia, via e podia fazer em cada momento, e só depois tira conclusões. É um bom método também para as equipas: avaliar uma decisão com a informação que existia quando foi tomada. O que só se soube depois serve para aprender.

Imagina uma equipa que altera um componente partilhado e, sem o saber, parte um fluxo de que outra equipa depende. Antes de se falar em consequências, há perguntas mais úteis. A dependência estava registada em algum lado? Quem a conhecia? Havia um momento previsto para a validar? Se a informação existia e estava à mão, houve um erro de julgamento e faz sentido pedir mais cuidado. Se não existia, o problema está sobretudo no sistema, e é aí que se corrige primeiro.

Seja qual for a resposta, a reação deve ser proporcional e ter uma finalidade que se consiga explicar: reparar o que se partiu, ajustar o acordo, dar formação, ou aumentar o acompanhamento durante um período definido. Corrigir uma decisão e apoiar quem a tomou cabem na mesma conversa, e o apoio pode ser concreto: rever prioridades, clarificar quem decide, ajudar a reparar a relação com a equipa afetada. A investigação sobre exigências e recursos no trabalho vai no mesmo sentido, com uma nuance: num estudo clássico, recursos como autonomia e feedback amorteceram o efeito das exigências no burnout, mas o efeito confirmou-se em 18 de 32 combinações testadas para exaustão e cinismo, e não para a eficácia profissional²³. Sem meios, a autonomia transforma-se numa transferência de risco.

Apoiar também é dar meios a quem tem de mudar. Na migração para tokens, usámos um tradutor com IA que convertia as classes antigas nos novos tokens, e tratámos à mão os casos sem conversão direta. Do lado do Figma, a equipa de design system deu formação às outras equipas, acompanhou a migração e ajudou diretamente nos projetos para a acelerar.

Quando, depois de uma falha, o controlo aumenta, três perguntas ajudam a mantê-lo saudável. Sobre que categoria de decisões incide? Até quando? Que sinais fazem devolver a autonomia? Pedir maior visibilidade ganha legitimidade quando tem finalidade, âmbito e critérios de revisão claros. É a lógica da retoma do comando e da licença de pilotagem: poucos casos, critério conhecido e regresso previsto.

Então levamos as pessoas pela mão sempre?

Um sénior não deveria precisar de regras para tudo.

Concordo. O objetivo é explicitar fronteiras relevantes e deixar o discernimento a trabalhar. Bom julgamento também inclui reconhecer quando é preciso consultar.

Depois de um erro, o líder tem de acompanhar mais.

Pode ter de o fazer. O acompanhamento ganha legitimidade quando tem finalidade, âmbito e critérios de revisão claros.

Ninguém pode garantir que todas as pessoas leram a informação.

Não pode. Por isso, as alterações de compromissos precisam de confirmação junto dos responsáveis críticos, e não apenas de publicação. Também é preciso cobrar resposta a esses responsáveis.

A informalidade torna a organização mais rápida.

Pode tornar. A questão é saber se a rapidez inicial compensa o custo de reparar entendimentos incompatíveis.

Falar de contexto e apoio pode diluir a responsabilidade.

Só se o contexto for usado para dispensar a avaliação da conduta. Uma análise completa examina tanto a decisão individual como as condições em que foi tomada.

O momento do desacordo

Uma equipa precisa de saber o que pode decidir e deve poder explicar como chegou a uma decisão que correu mal. O líder precisa de definir critérios e tornar o seu próprio critério compreensível.

Depois de um erro, podemos esclarecer uma fronteira, corrigir um compromisso, definir melhor o contexto e melhorar o julgamento. Também podemos acrescentar tantas aprovações que ninguém volte a decidir sem autorização. Os dois caminhos oferecem mais controlo imediato. Só o primeiro preserva a capacidade de a equipa trabalhar com autonomia.

A qualidade da delegação mede-se também nesse momento: no que fazemos com a autonomia quando ela produz uma decisão de que discordamos.

No sistema de tokens, a definição semântica ficou em grande parte com os designers. Não concordei totalmente com a profundidade das dependências entre tokens. Era lógica, mas difícil de perceber e de explicar. Como se tratava de um sistema, a escolha fazia sentido racional apesar do esforço necessário para a compreender e implementar, e por isso manteve-se.

O trabalho principal foi feito por uma equipa restrita de designers, com a colaboração pontual de outros, e afetou todos os produtos da empresa. Hoje o dark mode é uma opção standard em todos eles, sem esforço extra para as equipas. A acessibilidade e o contraste mínimo para a leitura de textos, ícones e outros elementos passou a ser garantido pelo próprio sistema. Entregámos algo que muitos utilizadores pediam, e o sistema tornou-se a base de um design system mais robusto para as duas marcas, que depois se estendeu às plataformas mobile.

No fim da manobra, com o navio atracado em Leixões, o piloto despede-se e desce para a lancha que o espera. Ninguém estranha a saída, porque estava combinado desde o início quando e como a condução voltava ao comandante. É esse tipo de delegação que vale a pena construir: clara à entrada, acompanhada durante a manobra e sem surpresas à saída.

Acordar antes, acompanhar durante, rever depois.

As opiniões expressas neste texto são pessoais e não representam a posição da Namecheap nem da Spaceship. Os exemplos foram descritos de forma a respeitar os acordos de confidencialidade a que estou obrigado.

Fontes

As citações em inglês aparecem no texto numa tradução minha. O excerto original de cada uma está na respetiva fonte.

1. Decreto-Lei n.º 48/2002, áreas de pilotagem obrigatória. Diário da República
2. IMPA, Guidance on the Master-Pilot Exchange. Excerto: “should begin with an exchange of information between the master and the pilot”. impahq.org
3. International Best Practices for Maritime Pilotage, ponto 4.3. Excerto: “The master retains the ultimate responsibility for the safety of his ship”. UK P&I Club
4. Resolução A.960 da IMO, citada em material do Steamship Mutual e da IMPA. Excerto: “to ensure that his/her actions are monitored at all times”. steamshipmutual.com
5. MAIB, anexos ao relatório sobre o CMA CGM Centaurus (2018). Excerto: “share a responsibility for good communications”. gov.uk
6. Maritime Mutual, análise do caso CMA CGM Centaurus. Excerto: “obligated to take back the con”. maritime-mutual.com
7. The Nautical Institute, via SWZ Maritime (2023). Excerto: “The “challenge” is a key principle of good bridge resource management”. swzmaritime.nl
8. Britannia P&I, webinar Bridge Resource Management under Pilotage (2022). Excerto: “Ask > Suggest > Insist”. britanniapandi.com
9. Manual de procedimentos de ponte, Universidade de Rijeka. Excerto: “available for consultation on the Bridge at all times”. pfri.uniri.hr
10. The Swedish Club, Bridge Instructions. swedishclub.com
11. Woods Hole Oceanographic Institution, ordens permanentes do comandante. Excerto: “CALL THE MASTER IF IN ANY DOUBT”. whoi.edu
12. Portaria n.º 268/90, licença de pilotagem. Diário da República
13. Halvard Grøneng, Bridge resource management, a pilot’s perspective, Gard. Excerto: “easily confused with command to that of a pure advisory role”. gard.no
14. Sawhney et al. (2026), A meta-analytic review of 60 years of role stressor research, Journal of Vocational Behavior, 167. Excerto da autora principal, em entrevista: “role ambiguity, not having enough clarity about your work, was the most detrimental”. HCAMag · DOI
15. Gilboa, Shirom, Fried e Cooper (2008), A meta-analysis of work demand stressors and job performance, Personnel Psychology, 61(2). Resumo na Lancaster University
16. Paul Rogers e Marcia Blenko (2006), Who has the D?, Bain & Company / Harvard Business Review. Excerto: “Ambiguity over who’s accountable for which decisions”. bain.com
17. Sidney Dekker, Just Culture. Excerto: “Some suspect a just culture means letting people off the hook”. Taylor & Francis
18. Amy Edmondson, entrevista na Harvard Business School Working Knowledge. Excerto: “Your number one job is to make failure discussable”. library.hbs.edu
19. NTSB, acidente do Cosco Busan (2007). Excerto: “the master’s ineffective oversight of the pilot’s performance and the vessel’s progress”. gCaptain · Professional Mariner · NTSB
20. Rebecca Knight (2015), How to Stop Micromanaging Your Team, Harvard Business Review. Excerto: “the space they need to succeed and learn”. hbr.org
21. CHIRP, Correspondence: Incidents Under Pilotage. chirp.co.uk
22. Management 3.0, Delegation Poker & Delegation Board. Excerto: “Delegation is not a binary thing”. management30.com
23. Bakker, Demerouti e Euwema (2005), Job resources buffer the impact of job demands on burnout, Journal of Occupational Health Psychology, 10(2). DOI