Resumen:
Los equipos de sistemas de diseño ajustado pueden moverse más rápido, aclarar prioridades y extender su impacto más allá de su tamaño al planificar estrategias.
Lo pequeño es la norma para los equipos de sistemas de diseño. A pesar del alcance y el riesgo del trabajo que realizan, el equipo de Design Systems sigue siendo ágil. Si bien el tamaño pequeño a menudo se considera una limitación, también es la razón por la que los equipos de sistemas de diseño pueden operar con tanta eficacia, cuando el entorno es una elección operativa deliberada en lugar de una asignación de recursos preestablecida.
Los sistemas de diseño se mantienen pequeños
El tamaño del equipo de sistemas de diseño no es directamente proporcional al tamaño de la empresa. Según el informe anual de sistemas de diseño de Zeroheight de los últimos cinco años, la mayoría de los equipos de sistemas de diseño están formados por sólo entre 2 y 5 personas, y a menudo equilibran el trabajo del sistema con las responsabilidades del producto. Incluso en organizaciones grandes con más de 5.000 empleados, el tamaño medio del equipo es de entre 9 y 11 personas, lo que dista mucho de seguir el ritmo del crecimiento de la organización. Independientemente del tamaño de la organización, los equipos de diseño de sistemas rara vez superan las 20-25 personas.
Este patrón sugiere que los entornos lean son más que una simple limitación de recursos. Los equipos pequeños de sistemas de diseño integrado pueden estar mejor equipados para construir Sistema eficaz. Nuestras conversaciones con los profesionales confirmaron esta suposición: muchos señalaron que los equipos pequeños eran un factor de su éxito. Los equipos más pequeños son más cohesivos, más fáciles de coordinar y más capaces de mantener una visión clara del sistema que los equipos más grandes.
Menos personas, menos obstáculos
En equipos pequeños de sistemas de diseño, no es necesario transmitir el contexto; Es visible y compartido por todo el equipo. Las personas que definen el alcance del componente son las personas que lo implementan y lo respaldan. El equipo avanza al mismo ritmo y todos participan en las decisiones clave: los miembros del equipo están alineados en cuanto a por qué un componente tiene un alcance determinado, qué equipos de productos están esperando y qué limitaciones técnicas afectan la implementación. Hay poca necesidad de traspasos formales, sincronización de estatus o reinterpretaciones de decisiones pasadas porque no hay nadie que no esté involucrado.
Este entendimiento compartido permite que los equipos pequeños avancen rápidamente. Cuando surge un conflicto, se resuelve más rápidamente: menos personas significa menos opiniones para conciliar y menos aprobaciones para hacer avanzar las decisiones.
Un propietario de un producto de sistemas de diseño que entrevistamos citó el tamaño del equipo como un factor de éxito:
“Lo mejor de este equipo es que realmente hacemos que las empresas crean El equipo trabajará como un grupo integrado.. Eso es lo que cambia las reglas del juego: la rapidez con la que podemos hacer las cosas y la facilidad con la que podemos hacerlo. Detectamos los casos extremos antes y mejor que por nuestra cuenta… Yo, siendo muy cercano a los arquitectos técnicos, cuando los desarrolladores tienen preguntas sobre el diseño, hablan y el diseño habla. Poder tener estas conversaciones en una habitación cada dos días nos ha permitido avanzar muy rápidamente.“.
Los profesionales que han trabajado con pequeños equipos de sistemas de diseño y luego los han ampliado también reflexionan sobre los beneficios de los equipos pequeños. Cuando sus equipos son más pequeños, las decisiones se toman más rápido, el trabajo es más eficiente y se dedica menos tiempo a la coordinación. A medida que los equipos de diseño de sistemas crecen en tamaño, administrar equipos más grandes requiere más ceremonia, más búsqueda de consenso, y el trabajo de administrar el equipo comienza a competir con el trabajo que el equipo debería estar haciendo.
Los roles ambiguos promueven una mejor colaboración
La mayoría de los equipos de productos por encima de cierto tamaño operan mediante especialización. Diseño de diseñador. Los ingenieros implementan. Los gerentes de producto tienen prioridad. Escrito por estratega de contenido. Cada disciplina tiene su propio flujo de trabajo y ciclo de revisión. El trabajo entre estos expertos se produce a través de traspasos: requisitos del producto, especificaciones del diseño e implementación del proyecto. Cuanta más gente participe, más transiciones habrá y más esfuerzo será necesario para garantizar que todos estén en sintonía.
Por el contrario, cuando entre 3 y 5 personas apoyan a una organización de cientos o miles de personas, la carga de trabajo entrante a menudo requiere que cada persona dedique trabajo más allá de su disciplina principal: los diseñadores crean API de componentes, los desarrolladores critican los diseños y los propietarios de productos participan en el trabajo práctico.
Cuando las personas naturalmente van más allá de las descripciones de su trabajo, desarrollan una comprensión práctica de disciplinas adyacentes, lo que les ayuda a convertirse en mejores colaboradores. Los desarrolladores que han participado en revisiones de diseño no sólo entienden lo que se propone, sino también por qué existen ciertas limitaciones. Los diseñadores que contribuyen a los documentos de implementación obtienen una comprensión más clara de la viabilidad, los límites del sistema y los costos de la tecnología.
Esta polinización cruzada proporciona a los miembros del equipo una experiencia más amplia, acelera los ciclos de retroalimentación entre disciplinas y promueve una comprensión compartida de todo el sistema que los expertos en equipos grandes rara vez desarrollan.
La priorización forzada crea un enfoque estratégico
Los equipos pequeños no pueden hacerlo todo y esta limitación actúa como una brújula para ayudar a los equipos de diseño de sistemas a definir prioridades estratégicas y evitar compromisos excesivos.
Cuando los recursos son escasos, cada decisión sobre qué construir implica una decisión sobre qué No Hospedarse. Este enfoque alinea el sistema de diseño con la hoja de ruta del producto y lo conecta con el impacto real en el negocio. El equipo construye menos componentes, pero los que construye son los que el equipo de producto realmente necesita. Escribe menos documentación, pero lo que escribe es necesario y preciso.
Los sistemas de diseño atraen naturalmente una gran cantidad de solicitudes, a menudo más allá de lo que cualquier equipo puede soportar de manera realista. Una escala más pequeña hace que las prioridades sean visibles y razonables. Crea un consenso de que la capacidad es limitada, lo que a su vez hace que la despriorización sea más fácil de justificar.
De hecho, el tamaño pequeño ayuda a reducir la fricción. Cuando las limitaciones son claras, es más probable que los equipos de producto acepten un “ahora no” o incluso un “no” rotundo. El resultado es un sistema enfocado que evita extenderse demasiado y mantiene la coherencia, en lugar de uno que intenta acomodarlo todo y pierde el enfoque.
Escalar a través de contribuciones y campeones
Por necesidad, los equipos pequeños aprenden a extender su influencia a través de personas ajenas al equipo. Los equipos de sistemas de diseño eficaces cambian su papel de productores a facilitadores, amplificando su influencia a través de partidarios, contribuyentes y colaboradores de otras partes de la organización que se convierten en participantes activos en el desarrollo del sistema de diseño. Este modelo generalmente produce una adopción del sistema de diseño más fuerte que la propiedad concentrada porque las personas que usan el sistema también ayudaron a construirlo. Una comunidad autoseleccionada es más sostenible que un liderazgo que empodere al sistema porque opera con motivación intrínseca.
Un solo profesional describió una hoja de ruta diseñada desde el principio y ejecutada con socios. Lanzaron programas campeones que otorgaron a los equipos de productos la propiedad de sus contribuciones a sistemas específicos y trabajaron para incorporar las prioridades del sistema de diseño en las hojas de ruta de otros equipos. Los resultados fueron triples: el trabajo se asignó sin agregar personal, el liderazgo vio el sistema como intrínsecamente ligado al trabajo del producto en toda la empresa, la buena voluntad informal se convirtió en una asignación formal y el equipo de producto tenía una razón legítima para dedicar tiempo al trabajo del sistema de diseño porque también estaba en su hoja de ruta.
A medida que el sistema madura, los equipos pequeños pueden cambiar la forma en que emplean su tiempo. Para trabajos de alta prioridad, lo harán ellos mismos. Para todo lo demás, recurren a actuar como consultores: brindan orientación, revisan contribuciones y mantienen estándares de calidad sin asumir responsabilidad por la entrega. Este enfoque permite al equipo mantener la influencia en un espectro más amplio que construir todo ellos mismos.
pequeña realidad
Es importante trazar una línea muy fina entre capacitar a un equipo pequeño para que opere de manera efectiva y esperar que un equipo con poco personal absorba una demanda ilimitada. Si bien celebramos los triunfos logrados por los equipos de Lean Design Systems, también debemos reconocer los desafíos que enfrentan.
Hay poca holgura ya que el pequeño equipo opera dentro del sistema. Cuando una persona se va, gran parte de las capacidades del equipo se pierden. Cuando alguien se va, a menudo se lleva consigo conocimientos institucionales indocumentados porque no hay tiempo suficiente para cristalizar lo que se compartió informalmente. Las mismas características que hacen que los equipos pequeños crezcan rápidamente (el contexto en la cabeza de las personas) también los hacen frágiles.
hay otro La diferencia entre una saludable flexibilidad de roles y una sobrecarga insostenible. Un diseñador que recoge suficiente código para impulsar su propio token o corrección de color es polinización cruzada. Un diseñador se convirtió en el tercer ingeniero del equipo, lo que lo dejó sintiéndose presionado ya que nadie más tenía tiempo para entregar el producto. Los equipos pequeños están más cerca de esta línea que los equipos grandes, y con solo un cambio en el alcance o la dotación de personal, el equilibrio puede cambiar rápidamente.
Las limitaciones de capacidad también determinan qué trabajo se puede y qué no se puede realizar. a veces esto significa valioso El proyecto perdió prioridad. Los esfuerzos de soporte integrales (como documentación sólida, soporte personalizado para equipos de consumidores y expansión multiplataforma) son más difíciles de mantener en un modelo de equipo pequeño. Sin embargo, son estas inversiones las que permiten que los sistemas de diseño escale y ofrezcan un valor constante entre los equipos.
Diseño pequeño y valor predeterminado pequeño
Mantener un equipo de sistemas de diseño pequeño y central debería ser una estrategia deliberada de operaciones de diseño, no un compromiso de personal. Las ventajas que se analizan en este artículo no provienen únicamente del tamaño pequeño. Provienen de equipos pequeños que operan bajo condiciones específicas: alcance claro del sistema, aceptación de los altos ejecutivos y expectativas alineadas con lo que el equipo realmente absorbe. El tamaño pequeño hace posible la cohesión, pero el resto del andamiaje debe estar en su lugar para convertir la cohesión en impacto.
En muchas organizaciones, ser más pequeño no es una elección consciente sino una desafortunada elección predeterminada. Los equipos se mantienen ágiles porque el trabajo está infravalorado o carece de apoyo ejecutivo. “Lean”, “scrapy” y “hacer más con menos” se convirtieron en palabras entrañables para describir la falta de inversión. En estos casos, las limitaciones superan los beneficios: agotamiento, entrega lenta, deuda de mantenimiento creciente y apoyo desigual.
La conclusión es, Si una organización quiere ampliar el soporte que brinda un sistema de diseño, primero debe proporcionar a los equipos los recursos adecuados y tratar su trabajo como una prioridad. Esto significa combinar un equipo pequeño con expectativas realistas, patrocinio organizacional y la voluntad de agregar capacidad real cuando el alcance del sistema exceda el ancho de banda del equipo, no solo a través de contribuyentes y defensores, sino a través de la plantilla real.
en conclusión
Los equipos de diseño de sistemas pueden ser pequeños y Todavía tiene un impacto significativo. Esta no es una excusa para que las organizaciones carezcan de personal suficiente en sus equipos de sistemas de diseño, sino más bien una oportunidad para reconocer que los equipos pequeños son un modelo operativo estable y retienen los elementos que los hacen efectivos mientras encuentran formas de escalar el sistema sin perder esas ventajas.
Los equipos de sistemas de diseño más resilientes no intentan hacerlo todo ellos mismos. Aprovechan la colaboración para crear sistemas, documentación y una comunidad de defensores.
Los equipos pequeños no pueden construirlo todo. Pero un equipo que trabaja con fluidez en todas las disciplinas, establece prioridades rigurosamente y permite que otros contribuyan de manera efectiva puede sostener un sistema que escala mucho más allá de su propio tamaño.
