Equipos en la Cultura Organizativa

Este elemento es una ampliación de los cursos y guías de Lawi. Ofrece hechos, comentarios y análisis sobre los equipos en la cultura organizativa. Puede interesar también lo siguiente:

• Aprendizaje Organizacional
• Formas de Organización Administrativa
• Estudio Hawthorne
• Carreras Profesionales

Visualización Jerárquica de Cultura Organizativa

• Empresa y Competencia > Organización de la empresa > Política de la empresa
• Trabajo y Empleo > Condiciones y organización del trabajo > Condición de trabajo
• Trabajo y Empleo > Administración y remuneración del personal > Administración del personal
• Empresa y Competencia > Gestión administrativa > Gestión > Gestión de conocimientos
• Empresa y Competencia > Gestión administrativa > Gestión > Gestión empresarial

A continuación se examinará el significado.

¿Cómo se define? Concepto de Cultura Organizativa

Véase la definición de cultura organizativa en el diccionario.

Cultura Organizativa en las Empresas

Nota: Véase más acerca de la ausencia de estructura organizativa.

Redacción de un escalafón profesional

Un buen escalafón es un elemento crítico para utilizar en la contratación, en la redacción de las evaluaciones de rendimiento y, por supuesto, en el proceso de promoción. Si tiene la oportunidad de crear un documento de este tipo, no tema implicar a su equipo. Los mejores procesos y documentos reflejan al equipo en su conjunto y no sólo su sesgo del momento, y una de las mejores cosas de crear estos escalafones en una empresa pequeña es que puede implicar a mucha gente sin una tonelada de burocracia en el proceso.

He aquí algunas cuestiones importantes que debe tener en cuenta a la hora de redactar una escala o escalafón (en inglés, “ladder”) profesional para su organización:

Solicite la participación de su equipo

Para redactar un escalafón mejor, tuve que cambiar mi enfoque. En primer lugar, en lugar de hacerlo yo sola, recabé el apoyo de los altos directivos y de los ingenieros del equipo para que me aportaran comentarios y detalles. Les pedí que subrayaran las cosas que no entendían. Les pedí que propusieran reescrituras, adiciones, ediciones y detalles. Lo discutimos en grupo e hicimos que subgrupos trabajaran en las partes de la escalera que más les importaban. Por ejemplo, los colaboradores individuales más veteranos trabajaron en las expectativas técnicas y de habilidades para los niveles de colaborador individual.

Busque ejemplos

En segundo lugar, conseguí más ejemplos de escalafones de amigos de otras empresas que me ayudaron a aportar algunas ideas para los detalles. En la actualidad hay muchos buenos trabajos que puede utilizar si necesita redactar algo, pero en aquel momento tuve que investigar pidiendo a la gente que imprimiera lo que consideraba que podía compartir, o que me diera notas de alto nivel. Los mejores detalles procedían de amigos de Empleadores más importantes, sobre todo de aquellos con una sólida reputación técnica. Puede ser difícil explicar el alcance del trabajo que se espera a niveles técnicos muy altos, y tener esos ejemplos de empresas más grandes realmente nos ayudó a poner los detalles por escrito.

Sea detallista

Uno de los mayores retos a los que se enfrentará a la hora de redactar un buen escalafón es esbozar los detalles. Quiere algo que sea inspirador y descriptivo pero que se ajuste a su empresa. No tiene sentido esperar que un director de un equipo de ingeniería de 50 personas en una startup dirija, digamos, toda una división, del mismo modo que podría tener sentido tener esa expectativa en una gran multinacional. Piense en el tipo de detalles que buscaría a la hora de decidir si alguien debe ser contratado en un nivel o ascendido a un nivel, e intente incluir esos detalles según proceda.

Utilice tanto descripciones extensas como resúmenes

Dividí el escalafón en dos documentos. El primero era una versión abreviada en hoja de cálculo que me permitía ver los distintos atributos de nivel uno al lado del otro y ver cómo evolucionaban a través de los niveles crecientes. Esto me resultó útil porque, a medida que redactaba, podía ver cómo pasaba de un nivel al siguiente y cómo las funciones ampliaban su alcance, habilidades y responsabilidades. El segundo documento fue la versión extensa. Redactar la versión larga me resultó útil porque sentí que podía contar una historia más completa sobre los actores de cada nivel. En lugar de limitarse a visualizar el nivel como un conjunto de habilidades y atributos, el escalafón en formato largo se lee un poco como una revisión del rendimiento de una persona que funciona bien en cada nivel. Usted -y sus empleados- pueden ver cómo esas habilidades trabajan juntas para formar un papel completo. ¿Cuántos niveles debe tener su escalera? Tendrá que responder a dos preguntas más para resolver ésta. Primero, ¿cómo paga a la gente? Y segundo, ¿cómo reconoce los logros?

Considere cómo se relaciona el escalafón con el salario

Su departamento de RRHH querrá utilizar la escala profesional para ayudar a establecer las expectativas salariales. Normalmente, cada nivel tendrá una banda salarial, o un rango entre un salario base mínimo y máximo que una persona en el nivel puede ganar. Si no tiene muchos niveles, tendrá que tener bandas salariales muy amplias para tener en cuenta el hecho de que dos personas dentro de ese nivel pueden tener un rendimiento muy diferente, y para tener en cuenta el hecho de que los ingenieros tienden a esperar obtener aumentos salariales con frecuencia, sobre todo en las primeras etapas de su carrera.

Ofrezca muchas oportunidades tempranas de ascenso

Algunas personas aconsejan tener muchos niveles al principio del escalafón para tener en cuenta el hecho de que los ingenieros que inician su carrera esperan aumentos y ascensos frecuentes. Es posible que quiera poder ascender a alguien cada año durante los dos o tres primeros años de su carrera. Si ése es el caso, cree varios niveles que abarquen el papel de ingeniero de software y proporcione bandas salariales relativamente estrechas para esos niveles, con la expectativa de que las personas en esos papeles sean ascendidas rápidamente o se marchen de su empresa.

Utilice bandas salariales estrechas para las etapas iniciales de la carrera profesional

Muchos niveles y bandas salariales estrechas significan que puede ascender a la gente rápidamente y justificar que se les suban los sueldos, al tiempo que mantiene casi igual el sueldo de toda la gente de un determinado nivel. Esto es bueno si le preocupa pagar de forma justa y evitar los prejuicios que podrían llevarle, por ejemplo, a pagar más a los hombres que a las mujeres en el mismo nivel. Por desgracia, es increíblemente difícil crear suficientes detalles entre niveles cercanos para que una persona pueda distinguir fácilmente a alguien que está en un nivel u otro.

Utilice bandas salariales anchas cuando y donde tenga menos niveles. Las bandas salariales anchas y los pocos niveles hacen una distinción más clara entre las competencias de cada nivel, y deberían hacer más fácil saber quién está operando en cada nivel. En el caso de niveles muy espaciados, querrá tener bandas salariales amplias y querrá que esas bandas salariales se solapen. Así, una banda de ingeniero de software puede ir de 50 a 100.000 dólares, y una banda de ingeniero de software senior puede ir de 80 a 150.000 dólares. Eso significa que un ingeniero de software fuerte puede ganar más que un ingeniero senior. Necesita este margen de maniobra para retener a los talentos que rinden bien en sus niveles actuales pero que no están preparados para asumir la responsabilidad adicional del siguiente nivel. También se encontrará utilizando este margen de maniobra para contratar a personas que están en la valla en el nivel inferior con la expectativa de que serán promovidos rápidamente.

Considere sus niveles de ruptura

Es habitual que las empresas tengan ciertos niveles que consideran “arriba o fuera”. Se trata de puestos al principio de la carrera profesional en los que la falta de ascenso significa que la persona no ha alcanzado la madurez o la independencia necesarias para permanecer en la empresa. Esta política tiende a traducirse en su escalera como un nivel de ruptura implícito o explícito. ¿Cuál es el nivel más bajo en el que la gente puede sentarse para siempre, sin ascender nunca pero sin rendir por debajo de sus posibilidades? Este es su nivel de ruptura. En muchas empresas, se sitúa en torno a ingeniero superior. Alguien que ha llegado hasta aquí es un miembro sólido del equipo, pero puede quedarse en este nivel indefinidamente por decisión propia. Es bueno tener una noción de dónde está esto. Puede que incluso quiera utilizarlo como el punto en el que los niveles de su escalera se vuelven más difíciles de alcanzar. Espere que su equipo se agrupe en torno a este nivel, con menos personas por encima o por debajo.

Reconozca los logros

Algunas empresas quieren mantener los niveles en secreto, pero eso suele ser imposible. La gente hablará. Sin embargo, puede salirse de su camino para enfatizar ciertos niveles mientras mantiene otros en secreto, posiblemente incluso de los propios empleados. Algunos departamentos de RR.HH. tienen números de nivel salarial separados que utilizan para hacer un seguimiento de la remuneración de los empleados y que están totalmente desconectados de las escalas profesionales. No abogo por ello. Sin embargo, sí le animo a que al menos algunos de sus niveles sean ascensos clave, que se compartan y celebren. Creo que el ascenso a ingeniero superior es un gran acontecimiento, así como el ascenso a ingeniero de plantilla y, si tiene esa función, a ingeniero principal. En la vía de la gestión, un ascenso a director es digno de celebración, al igual que un ascenso a vicepresidente. Tener niveles clave que no estén demasiado próximos entre sí da a la gente un logro mayor por el que luchar más allá del próximo aumento de sueldo, y hace que estos niveles sigan pareciendo importantes desde el punto de vista de una carrera más amplia.

Divida las vías de gestión y las técnicas

Es bastante obvio en estos tiempos que necesita vías separadas para la gestión y la contribución individual. No querrá que la gente sienta que la única vía de ascenso es la gestión de personas, porque no todo el mundo es apto para ese papel. Comúnmente, verá una división por encima de ingeniero superior donde las organizaciones empiezan a especificar niveles de gestión y niveles técnicos. Sin embargo, no debe esperar necesariamente tener el mismo número de personas en los niveles técnicos superiores que en los niveles de gestión superior. La alta dirección es generalmente una necesidad de volumen. Necesita suficientes directivos para gestionar a las personas que tiene en el equipo. El nivel técnico superior depende de la complejidad y el alcance del liderazgo técnico que requieran sus equipos y productos. Es posible tener un equipo grande con pocos técnicos superiores, o un equipo pequeño con muchos técnicos superiores y menos directivos. Sería poco habitual tener un equilibrio perfecto en este sentido.

Convertir las habilidades de gestión de personas en un requisito

Considere la posibilidad de convertir las habilidades de gestión de personas en un requisito a mitad de carrera. Anime a todo el mundo a tener algún tipo de experiencia en gestión o tutoría antes de poder ascender por encima del nivel de la división de vías. En la mayoría de las empresas, las vías deberían dividirse cuando las personas empiecen a mostrar liderazgo, tanto si ese liderazgo implica la gestión de personas como el diseño de software. Pero incluso cuando se diseña software, se está tratando con otros humanos y con necesidades humanas. Los grandes colaboradores individuales senior siguen sabiendo gestionar proyectos y ser mentores de los miembros más junior de su equipo, así que considere la posibilidad de hacer de la experiencia en liderazgo (normalmente a través de actuar como líder técnico) un requisito para ascender a los niveles de colaborador individual senior.
Años de experiencia. A nadie le gusta poner barreras artificiales a la gente, y los años de experiencia pueden parecer la barrera más artificial. Dicho esto, le animo a que sea prudente en esta cuestión. En mis escalafones, distingo los niveles clave por una expectativa de aumento de la madurez, y éstos suelen corresponderse con los años de experiencia en el sector, así como, en menor medida, con la edad. Por ejemplo, tomemos el caso del ingeniero de plantilla. Hace falta mucha madurez individual para pensar en proyectos de gran envergadura, lo que constituye, en mi opinión, el rasgo distintivo de un ingeniero de plantilla. Ser un programador brillante no basta para ser un gran ingeniero de plantilla; hay que haber demostrado un historial de realización y apoyo de trabajos de larga duración para justificar este título. No tiene por qué poner los años de experiencia como requisito estricto para los niveles, pero considere la posibilidad de tener algunas reglas empíricas, sobre todo si es la primera vez que redacta una escalera y despliega niveles.

No tema evolucionar con el tiempo

. Cuando redacta un escalafón como éste, está creando un documento vivo que tendrá que evolucionar a medida que crezca su empresa. Probablemente se le escaparán algunos detalles. Mi escalafón era difícil de interpretar para los desarrolladores centrados en el frontend debido a mi propio enfoque en el desarrollo de infraestructuras, así que tuvimos que ajustarlo para que tuviera más en cuenta lo que significaba ser un alto directivo dentro de ese mundo.

Equipos interfuncionales

¿Con quién trabaja? ¿A quién rinde cuentas? ¿Con quién colabora? Las respuestas son obvias tanto en las empresas extremadamente pequeñas (respuesta: todo el mundo) como en las muy grandes (respuesta: existe una estructura bastante clara que se estableció antes de que usted se incorporara). Como líder de una empresa en crecimiento, tendrá que ayudar a responder a estas preguntas a su equipo y a su empresa al menos una vez, y probablemente varias. ¿Cuáles deberían ser las respuestas?

La Ley de Conway se cita a menudo en los debates sobre este tipo de estructura. En ella se afirma: “Las organizaciones que diseñan sistemas… se ven obligadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones”.

Cuando reunimos equipos interfuncionales, estamos reconociendo que la comunicación más importante -la comunicación que debemos favorecer por encima de todo- es la que conduce a un desarrollo y una iteración eficaces del producto. Tenga en cuenta que esta estructura no producirá necesariamente la tecnología más eficaz. De hecho, probablemente producirá sistemas con algunas ineficiencias en comparación con las empresas que tienen una estructura de equipo más centrada en la ingeniería. Así que, si adopta esta estructura, tendrá que decidir dónde está dispuesto a encajar algunos golpes en el diseño del sistema para crear productos de la forma más eficaz.

Estructurar equipos interfuncionales

¿Cómo funcionan las tuercas y los tornillos de estas estructuras “pod”? Un elemento que suele causar ansiedad es quién dirige a quién. Cuando pasamos a esta organización por equipos, no cambiamos las estructuras de gestión. Los ingenieros eran dirigidos por directores de ingeniería y dependían de mí. Los jefes de producto informaban al jefe de producto. Pero la determinación de quién trabajaba en qué lo hacía en gran medida el propio pod. Esto significaba que aún podías obtener orientación técnica y supervisión de tu responsable de ingeniería, pero tu trabajo diario estaba determinado por las necesidades de la hoja de ruta del pod.

Por supuesto, cada función tiene sus propias necesidades específicas. Por lo general, alguien en ingeniería tiene que supervisar los sistemas centrales críticos, y es probable que necesite unos cuantos especialistas alrededor para cosas como la plataforma web central, móvil o ingeniería de datos. Yo mantuve estas funciones en una pequeña organización de infraestructura que, por lo general, no estaba asignada al desarrollo de productos. Incluso con un grupo dedicado a la infraestructura, los ingenieros asignados a los pods de producto siguen necesitando algo de tiempo para dar cuenta de las tareas específicas de ingeniería como las guardias, las entrevistas y el mantenimiento de la ingeniería (también conocida como deuda técnica). Aconsejo reservar un 20% de todo el tiempo de ingeniería para este tipo de tareas, basándome únicamente en mi experiencia personal y en la de mis compañeros en la gestión de la ingeniería.

Esta estructura interfuncional no es exclusiva de las pequeñas startups. Muchas grandes empresas también estructuran sus equipos de esta manera. Los bancos, por ejemplo, suelen tener equipos de tecnología adscritos a áreas específicas del negocio y, aunque la estructura de gestión está formada por ingenieros, la hoja de ruta y el trabajo diario están determinados conjuntamente por las necesidades de la unidad de negocio y su equipo de ingeniería asociado. Por lo general, existe un equipo de infraestructura centralizado que da soporte tanto a los sistemas fundamentales como a los grandes marcos y tecnologías que utilizarán muchos equipos de toda la empresa. Incluso muchas empresas tecnológicas están estructuradas de este modo, aunque las propias “unidades de negocio” pueden estar dirigidas por antiguos ingenieros que actúan como gestores de producto o de negocio en lugar de como especialistas de negocio.

Las implicaciones de la estructura interfuncional son sutiles. Los valores de todos los integrantes de estos equipos empezarán a cambiar. En las estructuras centradas en la tecnología, en las que los ingenieros trabajan únicamente con otros ingenieros, en particular con ingenieros de su mismo “tipo” (móviles, backend, middleware, etc.), la atención se centra en ser el mejor ingeniero según alguna medida de excelencia en ingeniería. Las personas que diseñan sistemas complejos o que conocen los detalles del último iOS son los líderes y los modelos a seguir para los equipos. En una estructura centrada en el producto, el enfoque del liderazgo cambia. Ahora los ingenieros que tienen el mejor sentido del producto, los ingenieros que son capaces de conseguir características de forma rápida y eficiente, y los ingenieros que se comunican mejor con las otras funciones comenzarán a emerger como los líderes del equipo.

No pretendo hacer aquí ningún juicio de valor, pero le animo a que sea consciente del enfoque producto/negocio frente al enfoque tecnología y lo aplique allí donde tenga sentido. ¿Qué es lo verdaderamente importante para el éxito de su empresa o de su organización? Si lo más importante es hacer evolucionar un producto que es una función de muchas áreas empresariales diferentes que se unen, probablemente quiera líderes que tengan ese sentido empresarial. Por otro lado, en las áreas en las que la tecnología debe ser sólida como una roca o excepcionalmente innovadora y vanguardista, probablemente quiera equipos que tengan más un enfoque de ingeniería y que estén dirigidos por personas que puedan diseñar sistemas complejos. No tiene por qué decantarse totalmente por una u otra opción, pero reconozca que una de ellas dirigirá la empresa en su conjunto y -especialmente si su función es de alta dirección- centre su conjunto de habilidades en la que la propia empresa valore más y contrate para la otra.

Evaluar su propia experiencia

Algunas cuestiones clave son las siguientes:

• ¿Qué políticas tiene ahora? ¿Qué prácticas? ¿Ha redactado ya alguna de ellas? ¿Cuándo fue la última vez que las revisó?
• ¿Tiene valores de empresa? ¿Cuáles son? ¿Cómo los reconoce en su equipo?
• ¿Tiene una escala profesional? ¿Cree que refleja fielmente el equipo actual? ¿Refleja el equipo que quiere tener en el futuro? Si no es así, ¿puede mejorarlo?
• ¿Qué riesgos son los más preocupantes para su equipo? ¿Para su empresa? ¿Cómo puede mitigar esos riesgos sin sobrecargar a su equipo con procesos y burocracia innecesarios?

Crear una política cultural

En algunas ocasiones, es preciso crear una política cultural propia, diferente de modelos, que no pueden “copiarse” aunque haya similitudes entre las organizaciones (véase más).

Revisor de hechos: Hemmingims

Características de Cultura organizativa

Recursos

Traducción de Cultura organizativa

Inglés: Organisational culture
Francés: Culture organisationnelle
Alemán: Organisationskultur
Italiano: Cultura dell’organizzazione
Portugués: Cultura organizacional
Polaco: Kultura organizacyjna

Basado en la experiencia de varios autores, mis opiniones, perspectivas y recomendaciones se expresarán a continuación (o en otros lugares de esta plataforma, respecto a las características en 2026 o antes, y el futuro de esta cuestión):

Tesauro de Cultura organizativa

Empresa y Competencia > Organización de la empresa > Política de la empresa > Cultura organizativa
Trabajo y Empleo > Condiciones y organización del trabajo > Condición de trabajo > Cultura organizativa
Trabajo y Empleo > Administración y remuneración del personal > Administración del personal > Cultura organizativa
Empresa y Competencia > Gestión administrativa > Gestión > Gestión de conocimientos > Cultura organizativa
Empresa y Competencia > Gestión administrativa > Gestión > Gestión empresarial > Cultura organizativa

Véase También

• Condición de trabajo
• Liderazgo educativo y docente
• Teoría de la Modernización
• Teoría de la Contingencia
• Teoría de la Burocracia
• Gestión pública
• Taylorismo
• Seguridad en el trabajo
• Ergonomía
• Estructura Social
• Ciencia Administrativa
• Teoría Organizaciónal
• Teoría de la Movilización de Recursos
• Lugar de trabajo
• Entorno laboral
• Estructura Organizativa
• Antropología Organizativa
• Cambio organizativo
• Organización Administrativa
• Mecanismos de Coordinación
• Glosario de Cambio Positivo en el Trabajo
• Gestión del Comportamiento Organizativo
• Administración del personal
• Nombramiento de personal
• Contrato de trabajo
• Período de prueba
• Personal
• Descripción de funciones
• Calificación del personal
• Estatuto del personal
• Contratación de personal
• Carrera profesional
• Concurso administrativo
• Diseño Organizacional
• Innovación Organizativa
• Estrategia organizacional
• Gestión de conocimientos
• Gestión empresarial
• Aprendizaje organizacional
• Política organizacional
• Gestión de recursos humanos
• Cultura empresarial

Derecho del Trabajo, Economía Cultural, Estudios Culturales, Gestión de los Recursos Humanos, Psicología Industrial, Sociología Cultural, Sociología Organizacional

▷ Esperamos que haya sido de utilidad. Si conoces a alguien que pueda estar interesado en este tema, por favor comparte con él/ella este contenido. Es la mejor forma de ayudar al Proyecto Lawi.