Cómo funciona una empresa tech por dentro y dónde encaja el equipo de datos

Hasta ahora hemos hablado de datos, formatos, bases de datos y pipelines. Cosas técnicas. Pero hay algo que casi ningún curso te cuenta y que descubrirás el primer día de trabajo con una mezcla de curiosidad y susto: una empresa no es un montón de gente escribiendo código en silencio. Es un organismo vivo, con áreas que tiran en direcciones distintas, personas con nombres y prioridades, reuniones, tickets, urgencias y política. Y tú, como profesional de datos, vas a estar justo en el centro de ese organismo, porque los datos los toca absolutamente todo el mundo. Esta lección es un mapa de ese territorio.

Te lo digo por experiencia: la gente que empieza y no acaba de encajar casi nunca es por falta de conocimiento técnico. Fracasan porque no entienden cómo funciona la empresa, no saben con quién hablar, se pelean con la persona equivocada o construyen algo que nadie pidió. El contexto profesional no es "blandito", es tan importante como saber escribir un JOIN. Vamos a por él.

### Las áreas de una empresa tecnológica

Imagina una empresa ficticia que usaremos toda la lección: NébulaGo, una app de reparto de comida a domicilio con 400 empleados. Pide desde el móvil, un repartidor lo lleva, pagas con tarjeta. Suena simple, pero detrás hay un ejército de personas organizadas en áreas. Una empresa es como un hospital: no todo el mundo es cirujano. Hay médicos, enfermeros, administración, limpieza, farmacia, urgencias. Cada área es imprescindible y todas tienen que coordinarse o el paciente se muere. En una empresa tech pasa lo mismo.

Estas son las grandes áreas que encontrarás en casi cualquier empresa de tecnología. Los nombres varían (a veces se juntan, a veces se parten), pero la función es siempre la misma:

• ▹Producto: decide QUÉ se construye y para quién. Los Product Managers hablan con usuarios, priorizan funcionalidades y escriben qué debe hacer la app. En NébulaGo, Producto decide si añadir "propina al repartidor" antes que "pedidos programados".
• ▹Ingeniería / Tecnología: construye el producto. Frontend, backend, apps móviles, infraestructura. Son quienes escriben el código que hace que la app funcione. Aquí, dentro, vive normalmente el equipo de datos.
• ▹Datos: convierte lo que pasa en la empresa en información para decidir. A veces es parte de Ingeniería, a veces un área propia. Aquí estás tú.
• ▹Negocio / Operaciones: hace que la máquina funcione día a día. En NébulaGo, Operaciones gestiona la flota de repartidores, los tiempos de entrega, los acuerdos con restaurantes.
• ▹Marketing / Ventas: consigue usuarios y clientes. Campañas, publicidad, captación de restaurantes. Generan MUCHOS datos (clics, campañas, conversiones) y piden MUCHOS informes.
• ▹Finanzas: controla el dinero. Facturación, nóminas, presupuestos, previsiones. Es uno de los consumidores de datos más exigentes: si un número está mal, es un problema serio.
• ▹People / RRHH: cuida de las personas. Contratación, nóminas, desarrollo profesional, cultura. Es quien te contrata a ti y quien gestiona tu carrera.

La clave que quiero que retengas: estas áreas no viven aisladas, se necesitan constantemente. Marketing lanza una campaña y quiere saber si funcionó — pide datos. Finanzas cierra el mes y necesita cuadrar ingresos — pide datos. Producto quiere saber qué funcionalidad usa la gente — pide datos. Operaciones quiere optimizar rutas de reparto — pide datos. ¿Ves el patrón? El área de Datos es transversal: sirve a todas las demás. Por eso tu trabajo te pondrá en contacto con casi todo el mundo de la empresa, y por eso entender qué hace cada área es parte de tu oficio.

### El área de tecnología por dentro

Vamos a hacer zoom dentro de Ingeniería, porque es donde probablemente vivas. "Ingeniería" o "Tecnología" no es un bloque monolítico: se divide en especialidades, igual que en un hospital hay traumatología, cardiología y pediatría. Un ingeniero de frontend y uno de infraestructura hacen trabajos tan distintos que casi hablan idiomas diferentes.

• ▹Frontend: la parte visible de la app, lo que ve y toca el usuario. Botones, pantallas, colores. En NébulaGo, la pantalla donde eliges tu hamburguesa.
• ▹Backend: la lógica que hay detrás, donde vive el servidor. Procesa el pedido, cobra la tarjeta, avisa al restaurante. El backend es quien PRODUCE la mayoría de los datos que tú vas a usar.
• ▹Mobile: las apps nativas de iPhone y Android. A veces se separa de frontend porque requiere tecnología distinta.
• ▹Infraestructura / DevOps / SRE: mantiene los servidores encendidos, los despliegues funcionando y la casa en pie. Son los "fontaneros" de lujo: si caen, todo cae.
• ▹Datos: tu equipo. Pipelines, warehouses, informes, modelos.
• ▹QA / Testing: se asegura de que lo que se lanza no está roto. Los controladores de calidad de la fábrica.
• ▹Seguridad: protege los datos y los sistemas de ataques. Cada vez más importante, sobre todo si manejas datos sensibles.

Ahora, ¿cómo se organizan estas personas? Aquí aparecen palabras que oirás mucho. La unidad básica es el equipo (5-9 personas suele ser el tamaño ideal). Muchas empresas modernas copiaron un modelo que Spotify popularizó hacia 2012: las squads (equipos pequeños y autónomos con una misión concreta, por ejemplo "el equipo de pagos") se agrupan en tribus (varias squads del mismo dominio, por ejemplo "toda la tribu de checkout"). Curiosidad histórica: en 2020, un antiguo product manager de Spotify publicó un artículo contando que aquel modelo "solo fue una aspiración y nunca se implementó del todo". No fue un comunicado de la empresa, pero lo respaldaron varios ex compañeros, incluido uno de los autores del documento original. El vocabulario se quedó igual, y hoy lo usan miles de empresas. Es un buen recordatorio: en tecnología, muchas "mejores prácticas" son modas que se copian sin cuestionar — y a veces copiadas de alguien que tampoco las estaba aplicando.

Dentro de un equipo hay dos grandes caminos profesionales que conviene entender desde el día uno. El IC (Individual Contributor, contribuidor individual) es quien hace el trabajo técnico: escribe código, diseña pipelines, resuelve problemas. El manager es quien dirige personas: reparte trabajo, hace seguimiento, se ocupa de que el equipo funcione y crezca. No es que uno esté por encima del otro: son carreras paralelas. Puedes llegar a ser un ingeniero altísimamente respetado (y bien pagado) sin gestionar a nadie. Muchos junior asumen que "crecer" significa "ser jefe", y no es verdad.

La escala de seniority es la progresión de tu carrera. No son solo años: es cuánta autonomía tienes y cuánto impacto generas. A grandes rasgos:

1. 01.Junior: aprendes. Te dan tareas bien definidas y alguien revisa tu trabajo. Se espera que preguntes mucho. Aquí empiezas tú.
2. 02.Mid (semi-senior): ya trabajas de forma autónoma en tareas normales. Ejecutas sin que te lleven de la mano.
3. 03.Senior: resuelves problemas complejos y ambiguos, ayudas a los junior y tomas decisiones técnicas. Eres una referencia.
4. 04.Staff / Principal: tu impacto va más allá de tu equipo. Defines cómo se hacen las cosas en toda la organización. Es la cima de la carrera de IC.
5. 05.Lead / Manager: dejas (parcial o totalmente) de programar para dirigir personas y estrategia. Camino distinto, no "superior".

### El equipo de datos por dentro: quién es quién

Y llegamos a lo importante: tu casa. "El equipo de datos" suena a un bloque uniforme, pero dentro hay roles muy distintos que la gente confunde constantemente (incluso los reclutadores). Vamos a separarlos con claridad, porque saber quién hace qué te ayudará a colaborar bien y a decidir hacia dónde quieres crecer.

• ▹Data Engineer: construye y mantiene las tuberías de datos. Ingesta, ETL/ELT, infraestructura, que los datos lleguen limpios y a tiempo al sitio correcto. Es el fontanero que instala y mantiene las cañerías por las que circula el agua (los datos).
• ▹Analytics Engineer: coge los datos crudos que tú dejaste y los transforma en modelos limpios y bien organizados listos para analizar (típicamente con SQL y herramientas como dbt). Está a caballo entre el Data Engineer y el Data Analyst.
• ▹Data Analyst: responde preguntas de negocio con esos datos. Construye dashboards, informes, análisis. "¿Cuánto vendimos el mes pasado por ciudad?" es su territorio. Habla directamente con Marketing, Finanzas, Operaciones.
• ▹Data Scientist: usa estadística y machine learning para predecir y experimentar. "¿Qué clientes van a dejar de pedir el mes que viene?" es una pregunta de Data Scientist.
• ▹ML Engineer: coge los modelos del Data Scientist y los pone en producción para que funcionen de verdad, a escala y de forma fiable. Es el puente entre "un modelo en un notebook" y "un modelo que decide en la app".
• ▹Data Architect: diseña la arquitectura global de datos. Qué tecnologías, cómo encajan, cómo escala. Es el arquitecto que dibuja el plano del edificio antes de que los albañiles (los data engineers) construyan.
• ▹Data / Analytics Lead o Manager: dirige el equipo, prioriza el trabajo, conecta con el negocio y protege al equipo del caos. Traduce "lo que quiere el CEO" en "lo que hace el equipo".

¿Y tú cuál eres? Depende de la ruta que estés haciendo. Si vas por ingeniería de datos, tu sitio es el primero: montar las tuberías y responder de que los datos lleguen limpios y a tiempo. Si vas por análisis de datos, es el tercero: coger esos datos y contestar la pregunta que alguien necesita para decidir. Los dos trabajáis con las mismas tablas. La diferencia es que uno responde de que lleguen y el otro de lo que significan. Y los otros cuatro roles no son escalones por encima de ti: son especializaciones. En una empresa pequeña los hará la misma persona; en una grande, seis.

La confusión más común del mundo de los datos es esta: ¿cuál es la diferencia entre Data Engineer, Analytics Engineer, Data Analyst y Data Scientist? Te lo cuento con una analogía de restaurante que no vas a olvidar. Imagina que el negocio es servir comida (información) a los clientes (el negocio):

• ▹Data Engineer = el que trae los ingredientes crudos a la cocina y monta las neveras, los fogones y las cañerías. Sin él, no hay materia prima ni cocina donde trabajar.
• ▹Analytics Engineer = el pinche que lava, corta y prepara los ingredientes dejándolos listos y ordenados para cocinar. Convierte el caos crudo en mise en place.
• ▹Data Analyst = el cocinero que emplata y sirve platos concretos que el cliente pidió: "quiero saber las ventas por ciudad" y sale el plato.
• ▹Data Scientist = el chef experimental que inventa recetas nuevas y predice qué le gustará al cliente el mes que viene con técnicas avanzadas.

Alrededor del equipo de datos orbitan otros roles que conviene conocer aunque no estén siempre presentes: el DBA (Database Administrator) cuida y afina las bases de datos operacionales; el BI Developer (Business Intelligence) es un perfil muy centrado en construir informes y cuadros de mando; y el Data Product Manager es un PM especializado que decide qué productos de datos se construyen y para quién, priorizando el trabajo del equipo con visión de negocio.

### Cómo se organiza el equipo de datos en la empresa

No solo importa QUIÉN está en el equipo, sino CÓMO se coloca dentro de la empresa. Hay tres modelos clásicos, y cada uno tiene sus ventajas y sus dolores. No hay uno "correcto": depende del tamaño y la madurez de la empresa.

Modelo centralizado: existe un único equipo de datos que sirve a toda la empresa. Marketing, Finanzas y Producto van todos a ese equipo con sus peticiones. Ventaja: conocimiento concentrado, estándares consistentes, la gente de datos aprende junta. Desventaja: se convierte en un cuello de botella — todo el mundo pide y el equipo no da abasto, y acaba lejos del negocio, sin entender bien cada área.

Modelo descentralizado o embebido: cada data engineer vive DENTRO de un equipo de producto (uno en el equipo de pagos, otro en el de logística). Ventaja: conoces a fondo tu dominio, estás pegado al negocio, respondes rápido. Desventaja: te sientes solo como perfil de datos, cada uno reinventa la rueda a su manera y no hay estándares comunes. Es fácil que tres equipos construyan tres pipelines distintos para lo mismo.

Modelo híbrido o hub-and-spoke: es la síntesis y hoy el más popular en empresas medianas y grandes. Hay un equipo central de plataforma (el hub) que construye las herramientas, los estándares y la infraestructura común, y data engineers embebidos (los spokes) repartidos en los equipos de producto que usan esa plataforma. Lo mejor de los dos mundos: estándares comunes y cercanía al negocio. Es donde probablemente acabes trabajando.

Y una palabra de moda que oirás seguro: data mesh. Es una evolución del modelo embebido llevada al extremo, propuesta en 2019: en lugar de un equipo central que posee todos los datos, cada equipo de dominio es dueño de sus propios datos y los ofrece como un "producto" al resto de la empresa, con calidad y documentación garantizadas. Es una idea potente pero compleja, y muchas empresas la nombran sin aplicarla de verdad. Como junior no necesitas dominarla; solo saber que existe y que es un intento de resolver el cuello de botella del modelo centralizado a gran escala.

### El día a día y con quién hablas

Ya sabes quién es quién. Ahora, ¿cómo es un día normal? Lo primero que debes interiorizar es el concepto de stakeholder. Un stakeholder es cualquier persona interesada en tu trabajo o afectada por él: la analista que necesita tu tabla, el PM que espera tus datos, el jefe de Marketing que quiere un informe. No son "clientes" en sentido comercial, pero sí gente a la que sirves y con la que negocias prioridades. Aprender a hablar con stakeholders (entender qué necesitan de verdad, no lo que dicen literalmente) es una de las habilidades más valiosas de tu carrera.

El trabajo no te llega por telepatía: llega por tickets (tareas escritas en herramientas como Jira, Linear o Trello) que describen qué hay que hacer. Esos tickets se organizan en sprints, que son ciclos de trabajo cortos (normalmente 1-2 semanas) al final de los cuales el equipo entrega algo. Todo esto forma parte de las metodologías ágiles, la forma más común de organizar el trabajo en tech. No hace falta que las domines aún, pero sí que reconozcas las ceremonias que verás a diario:

• ▹Daily standup: reunión corta (10-15 min) cada mañana donde cada uno dice qué hizo ayer, qué hará hoy y si está bloqueado. De pie, para que sea breve.
• ▹Sprint planning: al empezar el sprint, el equipo decide qué tickets entran y se compromete con ellos.
• ▹Sprint review / demo: al final del sprint, se enseña lo que se ha construido a los stakeholders.
• ▹Retrospectiva (retro): el equipo reflexiona sobre qué fue bien, qué fue mal y qué mejorar. Es donde el equipo se cura a sí mismo si hay buena cultura.

Como profesional de datos, tus interlocutores habituales serán: otros analistas e ingenieros de datos (con quienes compartes fuentes y definiciones), los product managers (te explican qué necesita el negocio) y los stakeholders de Marketing, Finanzas u Operaciones (quienes reciben tus análisis). Vas a hablar con gente todo el rato. La imagen del profesional de datos aislado con sus auriculares es un mito: comunicar bien es la mitad del trabajo.

### Dónde encajas tú al empezar

Cerramos aterrizando en ti. Si vas por ingeniería de datos, entrarás como Junior Data Engineer. Si vas por análisis, como Junior Data Analyst. En los dos casos, reportarás a un lead o a un senior que hará de mentor. Te asignarán tickets bien definidos — en ingeniería: "ingesta este CSV al data lake", "arregla este pipeline que falla los lunes"; en análisis: "saca los KPI de la semana", "mira por qué bajó la retención". No se espera que diseñes la arquitectura ni que tomes grandes decisiones — se espera que aprendas, preguntes, entregues trabajo correcto y poco a poco necesites menos supervisión.

Tu crecimiento seguirá un camino claro: primero ganas autonomía en tareas normales (pasas a mid), luego empiezas a resolver problemas ambiguos y a ayudar a otros (senior), y en ese punto eliges tu rama: seguir profundizando en lo técnico hacia staff/principal, o girar hacia la gestión de personas como lead/manager. Ambos caminos son legítimos y bien pagados. Lo importante ahora no es esa decisión lejana, sino construir una base sólida: dominar SQL, Python, pipelines y entender el negocio. El resto llega solo.

1. 01.Una empresa tech se divide en áreas (Producto, Ingeniería, Datos, Operaciones, Marketing, Finanzas, People) que se necesitan mutuamente; Datos es transversal a todas.
2. 02.Ingeniería se subdivide en frontend, backend, mobile, infraestructura, datos, QA y seguridad, organizadas en equipos/squads/tribus.
3. 03.Existen dos caminos de carrera: IC (técnico) y manager (personas), y una escala de seniority de junior a staff/principal o lead.
4. 04.El equipo de datos tiene roles distintos: Data Engineer, Analytics Engineer, Data Analyst, Data Scientist, ML Engineer, Data Architect y Lead.
5. 05.Hay tres modelos organizativos: centralizado, embebido e híbrido (hub-and-spoke, el más común); data mesh es la evolución moderna.
6. 06.El trabajo llega por tickets y sprints, con ceremonias ágiles (daily, planning, review, retro), y colaboras constantemente con stakeholders.
7. 07.Empiezas como junior reportando a un mentor: tu trabajo es aprender rápido, entregar bien y ser fiable.