Nuestra Cultura
Manifiesto de Bienestar y Autonomía
No nos importa cuántas horas trabajás. Nos importa que el sistema esté arriba, que el código sea mantenible y que el ingeniero que lo escribió haya dormido bien.
No contratamos personas para llenar sillas. Contratamos ingenieros para resolver problemas complejos. Y los problemas complejos se resuelven mejor con autonomía, enfoque y descanso.
Cuatro principios que no negociamos
No son ideales aspiracionales. Son decisiones operativas que tomamos todos los días y que definen cómo se trabaja en Digital Axios.
Resultados > Horas Despliegues exitosos y procesos estables.
No medimos el éxito en horas sentado frente a una pantalla. Lo medimos en despliegues sin rollback, en pipelines de automatización que procesan miles de documentos sin intervención, y en clientes que duermen tranquilos porque su sistema no se cae.
Un ingeniero que resuelve un bug crítico en 45 minutos y se va a caminar es más valioso que uno que pasa 8 horas simulando productividad.Los KPIs que importan: uptime del sistema, tasa de errores en producción, tiempo de resolución de incidentes. No el reloj de entrada.Si tu código pasa los tests, supera el code review y se integra limpio en el pipeline de CI/CD, hiciste tu trabajo. El horario en que lo hiciste es irrelevante.
Cultura Asíncrona Deep Work sin interrupciones.
La programación de sistemas complejos requiere concentración profunda. Un ingeniero al que interrumpen cada 20 minutos no escribe arquitectura sólida: escribe parches. Diseñamos nuestra operación para proteger los bloques de trabajo concentrado.
Comunicación escrita primero. Si algo puede ser un mensaje en Slack con contexto, no es una reunión de 30 minutos.Reuniones con agenda previa y duración fija. Sin "calls rápidas" que se convierten en una hora de divagación.Documentación como fuente de verdad. Los ADRs (Architecture Decision Records) y los runbooks reemplazan el "preguntale a Fulano, él sabe".Respetamos los estados "No molestar". Cuando un ingeniero está en modo Deep Work resolviendo un problema de concurrencia o diseñando un flujo de microservicios, esa concentración es sagrada.
Respeto al Ingeniero Tu crecimiento profesional no es un obstáculo.
Nuestros ingenieros cursan carreras en la UTN, toman certificaciones de AWS, contribuyen a proyectos open-source. Esto no es algo que "toleramos" a pesar del trabajo: es algo que fomentamos porque nos hace mejores.
Horarios flexibles diseñados para que la formación académica nunca compita con el trabajo. Si tenés cursada, tu agenda se adapta.Presupuesto anual para capacitación: certificaciones cloud, conferencias técnicas, cursos especializados. Sin burocracia para solicitarlo.Tiempo de investigación protegido. No es un beneficio decorativo: es la razón por la que podemos ofrecer a nuestros clientes soluciones que usan lo último en IA y procesamiento de documentos.Mentorías internas entre ingenieros senior y junior. El conocimiento compartido escala; el conocimiento acumulado en una sola persona es un punto de fallo.
Salud Mental Código limpio requiere mentes descansadas.
No existe la ingeniería heroica. Un ingeniero que trabaja 14 horas para "salvar" un despliegue es un síntoma de un sistema mal diseñado, no un acto de dedicación. Diseñamos nuestros procesos para que el heroísmo no sea necesario.
Los incidentes de producción tienen postmortems sin culpables. Buscamos causas sistémicas, no cabezas que cortar.Rotación de on-call con límites claros. Nadie está "siempre disponible". Si estás de guardia, la semana siguiente descansás.Carga de trabajo sustentable. Los sprints imposibles producen deuda técnica que termina costando más que el deadline que intentaban cumplir.Un ingeniero descansado detecta race conditions, anticipa edge cases y escribe tests que cubren los escenarios que un ingeniero agotado ignora.
Cómo se ve esto en la práctica
No son solo palabras. Así operamos concretamente cada semana.
Sprints sustentables
Planificamos capacidad real, no fantasías. Incluimos buffer para investigación, deuda técnica y lo inesperado. Un sprint que requiere heroísmo para completarse es un sprint mal planificado.
Documentación sobre meetings
Cada decisión arquitectónica queda documentada en un ADR. Las especificaciones de APIs están en Swagger. Los runbooks son la primera línea de respuesta ante incidentes. No dependemos de la memoria de nadie.
Code reviews como mentoría
Los code reviews no son un trámite burocrático. Son la oportunidad de compartir conocimiento, detectar problemas antes de que lleguen a producción y elevar el nivel técnico de todo el equipo.
Postmortems blameless
Cuando algo falla en producción, no buscamos culpables. Buscamos qué permitió que el error llegara hasta ahí. ¿Faltó un test? ¿El monitoring no alertó a tiempo? ¿La documentación era ambigua? Arreglamos el sistema, no señalamos personas.
¿Querés trabajar en un equipo que respeta tu tiempo?
Si sos ingeniero/a y valorás la autonomía, el código limpio y los desafíos técnicos reales, hablemos.
Contactanos