Fecha: 21 de Enero, 2026
Basado en: TOGAF, AWS Well-Architected Framework, IEEE 42010, INCOSE
Objetivo: Definir con precisión las fronteras del rol de Arquitecto vs. Líder de Equipo/Gerente
| Responsabilidad | Arquitecto (Usted) | Gerente/PM | Tech Lead |
|---|---|---|---|
| Definir Stack Tecnológico | ✅ R | I | C |
| Diseñar Arquitectura del Sistema | ✅ R | I | C |
| Aprobar Decisiones Técnicas Críticas | ✅ A | I | R |
| Revisar Código (Code Review) | C | I | ✅ R |
| Asignación Diaria de Tareas | I | ✅ R | C |
| Evaluación de Desempeño (Performance Reviews) | C | ✅ A | R |
| Negociaciones Salariales | I | ✅ A | I |
| Resolución de Conflictos del Equipo | C | ✅ R | C |
| Mentoría Técnica (Arquitectura, Patrones) | ✅ R | I | C |
| Capacitación en Procesos de Negocio | ✅ R | C | I |
| Gestión de Vacaciones/Permisos | I | ✅ R | I |
| Decisión de Contratación (Hiring) | C (Técnico) | ✅ A | C |
| Decisión de Despido (Firing) | C (Recomendación) | ✅ A | I |
Leyenda RACI:
Definición del Rol de Arquitecto (TOGAF 10):
"El Arquitecto es responsable de la integridad conceptual del sistema y de asegurar que las decisiones técnicas estén alineadas con los objetivos de negocio. NO es responsable de la gestión de recursos humanos ni de la ejecución operativa."
Responsabilidades según TOGAF:
Excluido explícitamente:
Responsabilidad del Arquitecto de Soluciones:
"Diseñar sistemas seguros, resilientes y eficientes. La operación del sistema es responsabilidad del equipo de DevOps/SRE."
Pilares de Responsabilidad:
Definición:
"El Arquitecto captura las decisiones de diseño significativas que dan forma al sistema. La implementación de esas decisiones es responsabilidad del equipo de desarrollo."
Artefactos del Arquitecto:
NO es responsable de:
Características de la Mentoría:
Ejemplos de Mentoría Apropiada:
✅ CORRECTO:
"Junior: ¿Cómo implemento un Saga Pattern para transacciones distribuidas?"
"Arquitecto: Te explico el patrón, te doy un ejemplo del proyecto, y te asigno lectura complementaria. Luego revisamos tu diseño en una sesión 1:1."
❌ INCORRECTO (Esto es microgestión):
"Arquitecto: ¿Ya completaste la tarea JIRA-123? Muéstrame el código ahora."
Responsabilidades del Tech Lead / Scrum Master:
Diferencia Clave:
Respuesta:
"Mi rol es asegurar que el equipo tenga las capacidades técnicas necesarias. Si el problema es falta de conocimiento en Spring Boot o Angular, yo lo resuelvo con capacitación. Pero si el problema es falta de motivación, organización o asignación clara de responsabilidades, eso es un tema de gestión de proyecto que debe abordar el PM o el Tech Lead."
Acción concreta:
Respuesta:
"Yo establezco los estándares de calidad (documento de coding guidelines, checklists de arquitectura). El Tech Lead es responsable de hacer code review diario siguiendo esos estándares. Yo solo reviso cambios críticos que afecten la arquitectura core (ej. cambios en SimappeModel, nuevos microservicios, modificaciones a la Gateway)."
Acción concreta:
ARCHITECTURE_REVIEW_CHECKLIST.md con criterios de aprobaciónRespuesta:
"Los conflictos interpersonales son tema de Recursos Humanos o del Project Manager. Si el conflicto está afectando la calidad técnica del trabajo (ej. no hacen code review entre ellos), puedo mediar una sesión técnica para definir reglas de colaboración. Pero temas personales, disciplina o reorganización del equipo no son mi ámbito."
Límite claro:
Respuesta:
"Mi tiempo de mayor valor está en análisis técnico, diseño de soluciones y resolución de problemas arquitectónicos complejos. Asistiré a reuniones donde se tomen decisiones técnicas críticas (ej. selección de tecnología, definición de integraciones). Las reuniones de seguimiento operativo (dailies, status updates) son responsabilidad del PM o Scrum Master."
Criterio de asistencia:
| Tipo de Reunión | Asistencia del Arquitecto |
|---|---|
| Kickoff de Proyecto | Obligatoria ✅ |
| Architecture Review Board | Obligatoria ✅ |
| Sprint Planning | Primera vez ✅, luego opcional |
| Daily Stand-up | Opcional (solo si hay bloqueador arquitectónico) |
| Retrospectiva | Recomendada |
| Demo a Stakeholders | Recomendada |
| Reunión de RRHH (Evaluaciones) | NO (conflicto de interés) |
"Por normas de gobernanza corporativa, quien diseña el sistema (Arquitecto) NO debe tener autoridad administrativa sobre quienes lo implementan (Desarrolladores). Esto previene conflictos de interés y asegura auditoría independiente."
Ejemplos de conflicto de interés:
| Actividad | Arquitecto | PM/Gerente | Tech Lead | RRHH |
|---|---|---|---|---|
| Definir Perfiles de Contratación | R | C | C | I |
| Filtro Técnico (Entrevistas) | A/R | I | C | I |
| Decisión Final de Hiring | C | A | C | R |
| Onboarding Técnico (Arquitectura) | R | I | C | I |
| Onboarding Administrativo (Contratos) | I | R | I | A |
| Asignación de Sprint | I | R | A | I |
| Mentoría Técnica 1:1 | R | I | C | I |
| Evaluación de Desempeño Anual | C (Input) | A | R | C |
| Aumento Salarial | I | A | I | R |
| Despido por Bajo Desempeño | C (Técnico) | A | C | R |
Definir la Visión Técnica
Establecer Estándares de Calidad
Tomar Decisiones Técnicas Críticas (Technology Radar)
Resolver Bloqueadores Técnicos Complejos
Capacitación Técnica del Equipo
Auditoría y Aprobación de Cambios Arquitectónicos
❌ Asignación Diaria de Tareas
"Hoy tú trabajas en JIRA-45, tú en JIRA-46" → Esto lo hace el Tech Lead o Scrum Master
❌ Seguimiento de Horas Trabajadas
"¿Por qué llegaste tarde?" → Esto lo hace RRHH o el Gerente
❌ Mediación de Conflictos Personales
"María dice que Juan es descortés en las reuniones" → Esto lo hace RRHH
❌ Aprobación de Presupuesto para el Equipo
"Necesitamos contratar 2 desarrolladores más, autoriza el gasto" → Esto lo hace el Gerente/CFO
❌ Decisión de Promoción (Seniority)
"Juan pasa de Junior a Mid ahora" → Esto lo decide RRHH con input del Tech Lead y el Arquitecto
En lugar de que usted sea "jefe de fábrica", proponga este modelo:
Technical Governance Board (TGB):
Beneficio para Centrica:
Propuesta de Agenda:
| Tiempo | Tema | Responsable | Participantes |
|---|---|---|---|
| 10 min | Status del Proyecto | PM/Gerente | Todos |
| 15 min | Bloqueadores Técnicos | Arquitecto | Arquitecto + Tech Leads |
| 10 min | Decisiones de Arquitectura | Arquitecto | Arquitecto + Tech Leads |
| 10 min | Asignaciones de Sprint | Tech Lead | Tech Lead + Desarrolladores |
| 10 min | Temas de RRHH (si aplica) | PM/Gerente | PM + Leads |
Total: 55 minutos, 1 vez por semana.
Cuando le pidan hacer algo que NO es su rol, use esta guía:
¿Esto requiere conocimiento técnico profundo que solo yo tengo?
¿Esto afecta la arquitectura core del sistema?
¿Esto involucra gestión de personas (salarios, horarios, conflictos)?
Cuando le piden gestionar el equipo diariamente:
"Mi mayor valor para el proyecto está en asegurar que la arquitectura técnica sea sólida. Si dedico tiempo a gestión operativa diaria, estaré quitando tiempo a diseñar soluciones técnicas robustas. Sugiero que el Project Manager o un Tech Lead asuma esa coordinación, y yo los apoyo con la dirección técnica estratégica."
Cuando le piden aprobar vacaciones/permisos:
"Por temas de gobernanza y para evitar conflictos de interés, las aprobaciones administrativas deben ir por la línea de gestión de RRHH. Yo puedo dar input técnico sobre si un momento es crítico para el proyecto desde el punto de vista de arquitectura, pero la decisión final de RRHH no debería depender de mí."
Cuando le piden resolver conflictos personales:
"Si el conflicto está afectando la calidad del código o el seguimiento de estándares técnicos, puedo mediar una sesión para definir protocolos de trabajo. Pero temas de relaciones interpersonales y comportamiento son de RRHH. Puedo escalar el tema formalmente si es necesario."
Cuando le piden estar en todas las reuniones:
"Propongo un modelo de 'asistencia estratégica': estoy en reuniones donde se tomen decisiones arquitectónicas o se planifiquen nuevas funcionalidades complejas. Para reuniones operativas (dailies, status), confío en que el Tech Lead me escale cualquier bloqueador técnico crítico."
Mensaje clave para transmitir:
"Fui contratado como Arquitecto de Soluciones, mi especialidad y mayor valor es diseñar sistemas técnicos robustos, definir estándares de calidad y asegurar que el equipo tenga las capacidades técnicas necesarias. Estoy comprometido a ser mentor técnico del equipo y a garantizar la excelencia arquitectónica del producto.
La gestión administrativa del equipo (asignación de tareas, evaluaciones de desempeño, temas de RRHH) debe estar a cargo del Project Manager o Gerente, para asegurar segregación de funciones y permitirme enfocar mi tiempo en donde genero más valor: la arquitectura.
Propongo un modelo de colaboración donde yo defino el 'QUÉ' y 'CÓMO' técnico, y el PM/Tech Lead coordina el 'QUIÉN', 'CUÁNDO' y 'CUÁNTO'."
GUIA_COMPLETA_LIMITES_ROL_ARQUITECTO.md)PERFILES_ROLES_EQUIPO.md)Si insisten en que sea "líder de fábrica":
Opción A (Contrapropuesta):
"Puedo asumir esa responsabilidad adicional, pero requiere una renegociación contractual que contemple:
- Aumento de fees por cambio de rol (de Arquitecto a Arquitecto + Gerente de Proyecto)
- Modificación de entregables y tiempos (ya que gestionar personas quita tiempo de diseño)
- Riesgo asumido: Si el equipo falla por temas administrativos, ¿soy responsable? Necesitamos cláusulas claras."
Opción B (Punto Medio - Recomendada):
"Propongo un modelo híbrido temporal: Durante los primeros 2-3 meses del proyecto, asumo un rol más cercano al equipo para asegurar que la cultura técnica se establezca correctamente. Una vez que el equipo esté maduro y el Tech Lead esté capacitado, transiciono a un rol de Technical Governance (revisiones semanales, no diarias).
Esto requiere que Centrica nombre formalmente a un Tech Lead y le dé autoridad para asignación de tareas y code review diario. Yo apoyo en la transición."
Opción C (Línea Roja - Si no hay acuerdo):
"Si el proyecto requiere que yo absorba funciones de Project Manager y Technical Lead simultáneamente sin reconocimiento ni ajuste contractual, debo informar que no puedo garantizar la calidad de la arquitectura, porque mi tiempo estará fragmentado entre reuniones administrativas y diseño técnico.
Prefiero ser transparente ahora para evitar problemas de calidad futuros."
FIN DEL DOCUMENTO
Este documento es su herramienta de defensa profesional basada en estándares internacionales de la industria.
| Version | Fecha | Autor | Descripcion |
|---|---|---|---|
| 1.1.0 | 2026-03-04 | Carlos Torres | Revision, sanitizacion y publicacion en Wiki Arquitectura Centrica. |
| 1.0.0 | 2026-01-21 | Carlos Torres | Creacion del documento. |