
Work without Jobs e o elo que falta entre skills e trabalho
O livro Work without Jobs propõe olhar além do cargo como um todo e torna visível uma camada que as arquiteturas de skills muitas vezes deixam de fora: o trabalho que precisa ser organizado.
Uma organização pode construir um catálogo preciso, associar skills a funções e avaliar milhares de perfis. Ainda assim, quando surge uma nova prioridade, a alocação volta a começar por uma pergunta conhecida: qual cargo deveria assumir essa responsabilidade?
Os dados sobre capacidades existem, mas não encontram uma unidade concreta de demanda. Sabemos algo sobre as pessoas e algo sobre os cargos. Falta descrever o trabalho com resolução suficiente para conectar os dois.
A apresentação oficial de Work without Jobs, de Ravin Jesuthasan e John W. Boudreau, propõe um “sistema operacional do trabalho” que decompõe os jobs em componentes e os reconstrói em combinações ajustadas às capacidades de quem contribui. MIT Press, Work without Jobs (abre em uma nova aba).
Esta não é uma resenha exaustiva do livro. A fonte disponível para este artigo é a apresentação editorial do MIT Press, complementada por um guia do CIPD. A análise se limita a essa tese pública e à sua aplicação em uma arquitetura do trabalho.
Entre a skill e o resultado, falta uma demanda
Uma skill descreve uma capacidade que pode se manifestar em contextos distintos. Um resultado expressa aquilo que a organização precisa alcançar. Entre os dois existe trabalho: decisões, atividades, restrições, interfaces e responsabilidade pelas consequências.
Quando essa camada é omitida, uma correspondência semântica pode parecer suficiente. Uma pessoa tem “análise de dados” e uma iniciativa exige “análise de dados”. A alocação ainda precisa esclarecer quais dados, para qual decisão, com que grau de incerteza, em que prazo e junto de quais outras contribuições.
O trabalho não é um conjunto indiferenciado de tarefas. Sua unidade útil precisa preservar o contexto necessário para decidir quem pode contribuir e em quais condições.
Decompor não significa atomizar
Pense em um processo de reembolso. O cargo tradicional pode reunir recebimento, validação, análise de exceções, comunicação com clientes e autorização. A decomposição permite perceber que essas contribuições não exigem a mesma combinação de experiência nem ocorrem com a mesma frequência.
A organização poderia automatizar uma validação repetitiva, concentrar exceções pouco frequentes em uma comunidade de especialistas e aproximar certas decisões da equipe que conversa com clientes.
O risco está em levar a decomposição longe demais. Se cada atividade virar uma tarefa isolada, perdem-se continuidade, aprendizado e responsabilidade pelo resultado completo. A unidade mínima não deveria ser definida pela conveniência administrativa, mas pelo significado que precisa preservar.

O guia do CIPD entende o desenho do trabalho como o estabelecimento de funções e responsabilidades para otimizar processos, criar valor e cuidar da qualidade do trabalho. Essa perspectiva introduz um limite importante: reconfigurar não significa apenas ganhar eficiência; também exige considerar a experiência de quem realiza o trabalho. CIPD, Job design (abre em uma nova aba).
Recompor exige regras, não apenas um marketplace
Depois que as unidades de trabalho são descritas, surge a pergunta mais difícil: como alocá-las? As skills são um dos insumos, não o critério completo.
A decisão pode exigir evidências de proficiência, experiência em contextos semelhantes, disponibilidade, interesse, requisitos regulatórios e continuidade operacional. Também deve indicar quem responde por integrar as contribuições distribuídas.
A recomposição precisa de limites de carga, acordos de prioridade, mecanismos de desenvolvimento e uma responsabilidade reconhecível pelo conjunto.
O que muda em uma arquitetura de skills
Uma arquitetura centrada apenas em funções responde quais capacidades são esperadas de uma posição. Uma arquitetura conectada ao trabalho também pode responder onde uma skill é usada, em quais decisões, com que nível de autonomia e junto de quais outras contribuições.
Isso muda vários usos. A mobilidade deixa de depender apenas da distância entre duas funções e pode começar com uma alocação delimitada. O desenvolvimento passa a se orientar por experiências em que a skill precisa ser aplicada. O planejamento compara demanda por contribuições, não apenas quantidade de cargos.
Nem todo trabalho deve ser separado da função. As funções oferecem identidade, continuidade, pertencimento e clareza contratual. A pergunta útil não é se devem desaparecer, mas quais componentes precisam permanecer agrupados e quais convém mobilizar de outra forma. A escolha entre amplitude, profundidade e integração ajuda a decidir que configuração responde a cada demanda.
Um pequeno teste antes de redesenhar a organização
Escolha um resultado com demanda variável e limites conhecidos. Descreva entre cinco e dez unidades de contribuição sem transformá-las em microtarefas. Para cada uma, registre propósito, evidência de conclusão, decisões, condições, riscos e interfaces.
Depois, compare essa demanda com as capacidades disponíveis. Observe quais novas alocações surgem e quais proteções são necessárias. Ainda não mude cargos nem contratos.
O teste deve mostrar se a resolução adicional melhora a alocação ou apenas produz complexidade. Também pode revelar que o problema original não era de skills, mas de autoridade, informação ou prioridades.
Esta leitura dá continuidade a O organograma não é um mapa do trabalho e Quando criar uma nova função e quando redesenhar uma existente. O organograma representa uma estrutura; a função reúne contribuições; o trabalho mostra o que precisa acontecer. Nenhuma camada substitui completamente as demais.
A promessa mais útil de trabalhar além do job não é eliminar cargos. Para explorá-la, a organização precisa primeiro testar uma unidade de trabalho delimitada e verificar se ela melhora a conexão entre capacidade humana e demanda.
Para ampliar esta leitura, consulte Dynamic Capabilities: por que somar skills não cria capacidade organizacional e Desenhar as interfaces entre equipes também é desenhar capacidade, que desenvolvem dimensões complementares do problema.





