Portada de Work Without Jobs sobre una mesa de madera, junto a tiras de papel multicolores entrelazadas.

Work without Jobs y la pieza que falta entre skills y trabajo

El libro Work without Jobs propone mirar más allá del puesto completo y vuelve visible una capa que una arquitectura de skills suele omitir: el trabajo que debe organizarse.

PRYSMAP5 min de lectura

Una organización puede construir un catálogo preciso, asociar skills con roles y evaluar miles de perfiles. Aun así, cuando aparece una prioridad nueva, la asignación vuelve a comenzar por una pregunta conocida: ¿qué puesto debería encargarse?

La información sobre capacidades existe, pero no encuentra una unidad concreta de demanda. Sabemos algo sobre las personas y algo sobre los cargos. Falta describir el trabajo con suficiente resolución para conectarlos.

La presentación oficial de Work without Jobs, de Ravin Jesuthasan y John W. Boudreau, propone un “sistema operativo del trabajo” que descompone los jobs en componentes y los reconstruye en combinaciones ajustadas a las capacidades de quienes contribuyen. MIT Press, Work without Jobs (se abre en una nueva pestaña).

Esta no es una reseña exhaustiva del libro. La fuente disponible para esta pieza es la presentación editorial de MIT Press, complementada con una guía de CIPD. El análisis se limita a esa tesis pública y a su aplicación en una arquitectura de trabajo.

Entre la skill y el resultado falta una demanda

Una skill describe una capacidad que puede manifestarse en distintos contextos. Un resultado expresa lo que la organización necesita conseguir. Entre ambos existe trabajo: decisiones, actividades, restricciones, interfaces y responsabilidad por consecuencias.

Si omitimos esa capa, una coincidencia semántica puede parecer suficiente. Una persona tiene “análisis de datos” y una iniciativa requiere “análisis de datos”. La asignación todavía necesita resolver qué datos, para qué decisión, con qué incertidumbre, en qué plazo y junto a qué otras contribuciones.

El trabajo no es una bolsa de tareas indiferenciadas. Su unidad útil debe conservar el contexto necesario para decidir quién puede contribuir y bajo qué condiciones.

Descomponer no significa atomizar

Pensemos en un proceso de reembolsos. El puesto tradicional puede reunir recepción, validación, análisis de excepciones, comunicación con clientes y autorización. Descomponer permite observar que no todas esas contribuciones requieren la misma combinación de experiencia ni ocurren con la misma frecuencia.

La organización podría automatizar una validación repetitiva, concentrar las excepciones poco frecuentes en una comunidad experta y acercar ciertas decisiones al equipo que conversa con clientes.

El riesgo es llevar la descomposición demasiado lejos. Si cada actividad se transforma en una tarea aislada, se pierde continuidad, aprendizaje y responsabilidad por el resultado completo. La pieza mínima no debería definirse por facilidad administrativa, sino por el significado que necesita conservar.

Un telar de madera produce una tela tejida al entrelazar numerosos hilos en una estructura común.

La guía de CIPD entiende el diseño del trabajo como el establecimiento de roles y responsabilidades para optimizar procesos, crear valor y cuidar la calidad del trabajo. Esa perspectiva introduce un límite importante: reconfigurar no consiste solo en aumentar eficiencia; también debe considerar cómo queda la experiencia de quienes realizan el trabajo. CIPD, Job design (se abre en una nueva pestaña).

Recomponer exige reglas, no solo un marketplace

Una vez descritas las unidades de trabajo, aparece la pregunta más difícil: cómo asignarlas. Las skills son una entrada, no el criterio completo.

La decisión puede necesitar evidencia de nivel, experiencia en contextos similares, disponibilidad, interés, requisitos regulatorios y continuidad operativa. También debe indicar quién responde por integrar contribuciones distribuidas.

La recomposición necesita límites de carga, acuerdos de prioridad, mecanismos de desarrollo y una responsabilidad reconocible por el conjunto.

Lo que cambia en una arquitectura de skills

Una arquitectura centrada únicamente en roles responde qué capacidades se esperan de una posición. Una arquitectura conectada con trabajo puede responder además dónde se utiliza una skill, en qué decisiones, con qué nivel de autonomía y junto a qué otras contribuciones.

Eso modifica varios usos. La movilidad deja de depender solo de la distancia entre dos roles y puede comenzar con una asignación acotada. El desarrollo se orienta hacia experiencias donde la skill debe aplicarse. La planificación compara demanda de contribuciones, no únicamente número de cargos.

No todo trabajo debe liberarse del rol. Los roles ofrecen identidad, continuidad, pertenencia y claridad contractual. La pregunta útil no es si deben desaparecer, sino qué componentes necesitan permanecer agrupados y cuáles conviene movilizar de otra manera. La elección entre amplitud, profundidad e integración ayuda a decidir qué configuración responde a cada demanda.

Una prueba pequeña antes de rediseñar la organización

Seleccione un resultado con demanda variable y límites conocidos. Describa entre cinco y diez unidades de contribución sin convertirlas en microtareas. Para cada una registre propósito, evidencia de término, decisiones, condiciones, riesgos e interfaces.

Después compare esa demanda con las capacidades disponibles. Observe qué asignaciones nuevas aparecen y qué protecciones hacen falta. No cambie todavía cargos ni contratos.

La prueba debería mostrar si la resolución adicional mejora la asignación o solo produce complejidad. También puede revelar que el problema original no era de skills, sino de autoridad, información o prioridades.

Esta lectura prolonga El organigrama no es un mapa del trabajo y Cuándo crear un nuevo rol y cuándo rediseñar uno existente. El organigrama representa una estructura; el rol reúne contribuciones; el trabajo muestra qué debe ocurrir. Ninguna capa sustituye por completo a las otras.

La promesa más útil de trabajar más allá del job no es eliminar puestos. Para explorarla, la organización debe probar primero una unidad de trabajo acotada y comprobar si mejora la conexión entre capacidad humana y demanda.

Para ampliar esta lectura, pueden consultarse Dynamic Capabilities: por qué una suma de skills no crea capacidad organizacional y Diseñar las interfaces entre equipos también es diseñar capacidad, que desarrollan dimensiones complementarias del problema.