Nossa Cultura
Manifesto de Bem-estar e Autonomia
Nao nos importa quantas horas voce trabalha. Nos importa que o sistema esteja no ar, que o codigo seja mantenivel e que o engenheiro que o escreveu tenha dormido bem.
Nao contratamos pessoas para ocupar cadeiras. Contratamos engenheiros para resolver problemas complexos. E problemas complexos se resolvem melhor com autonomia, foco e descanso.
Quatro principios que nao negociamos
Nao sao ideais aspiracionais. Sao decisoes operacionais que tomamos todos os dias e que definem como se trabalha na Digital Axios.
Resultados > Horas Deploys bem-sucedidos e processos estaveis.
Nao medimos o sucesso em horas sentado em frente a uma tela. Medimos em deploys sem rollback, em pipelines de automacao que processam milhares de documentos sem intervencao, e em clientes que dormem tranquilos porque seu sistema nao cai.
Um engenheiro que resolve um bug critico em 45 minutos e sai para caminhar e mais valioso que um que passa 8 horas simulando produtividade.Os KPIs que importam: uptime do sistema, taxa de erros em producao, tempo de resolucao de incidentes. Nao o relogio de ponto.Se seu codigo passa nos testes, supera o code review e se integra limpo no pipeline de CI/CD, voce fez seu trabalho. O horario em que fez e irrelevante.
Cultura Assincrona Deep Work sem interrupcoes.
A programacao de sistemas complexos exige concentracao profunda. Um engenheiro que e interrompido a cada 20 minutos nao escreve arquitetura solida: escreve patches. Projetamos nossa operacao para proteger os blocos de trabalho concentrado.
Comunicacao escrita primeiro. Se algo pode ser uma mensagem no Slack com contexto, nao e uma reuniao de 30 minutos.Reunioes com agenda previa e duracao fixa. Sem "calls rapidas" que se transformam em uma hora de divagacao.Documentacao como fonte de verdade. Os ADRs (Architecture Decision Records) e os runbooks substituem o "pergunta para o Fulano, ele sabe".Respeitamos os status "Nao Perturbe". Quando um engenheiro esta em modo Deep Work resolvendo um problema de concorrencia ou projetando um fluxo de microsservicos, essa concentracao e sagrada.
Respeito ao Engenheiro Seu crescimento profissional nao e um obstaculo.
Nossos engenheiros cursam graduacoes na UTN, tiram certificacoes da AWS, contribuem para projetos open-source. Isso nao e algo que "toleramos" apesar do trabalho: e algo que incentivamos porque nos torna melhores.
Horarios flexiveis projetados para que a formacao academica nunca compita com o trabalho. Se voce tem aula, sua agenda se adapta.Orcamento anual para capacitacao: certificacoes cloud, conferencias tecnicas, cursos especializados. Sem burocracia para solicitar.Tempo de pesquisa protegido. Nao e um beneficio decorativo: e a razao pela qual podemos oferecer aos nossos clientes solucoes que usam o que ha de mais recente em IA e processamento de documentos.Mentorias internas entre engenheiros senior e junior. Conhecimento compartilhado escala; conhecimento acumulado em uma unica pessoa e um ponto de falha.
Saude Mental Codigo limpo requer mentes descansadas.
Nao existe engenharia heroica. Um engenheiro que trabalha 14 horas para "salvar" um deploy e um sintoma de um sistema mal projetado, nao um ato de dedicacao. Projetamos nossos processos para que o heroismo nao seja necessario.
Os incidentes de producao tem postmortems sem culpados. Buscamos causas sistemicas, nao cabecas para cortar.Rotacao de on-call com limites claros. Ninguem esta "sempre disponivel". Se voce esta de plantao, na semana seguinte descansa.Carga de trabalho sustentavel. Sprints impossiveis produzem divida tecnica que acaba custando mais do que o prazo que tentavam cumprir.Um engenheiro descansado detecta race conditions, antecipa edge cases e escreve testes que cobrem os cenarios que um engenheiro esgotado ignora.
Como isso se parece na pratica
Nao sao apenas palavras. E assim que operamos concretamente toda semana.
Sprints sustentaveis
Planejamos capacidade real, nao fantasias. Incluimos buffer para pesquisa, divida tecnica e o inesperado. Um sprint que requer heroismo para ser concluido e um sprint mal planejado.
Documentacao acima de reunioes
Cada decisao arquitetonica fica documentada em um ADR. As especificacoes de APIs estao no Swagger. Os runbooks sao a primeira linha de resposta diante de incidentes. Nao dependemos da memoria de ninguem.
Code reviews como mentoria
Os code reviews nao sao um tramite burocratico. Sao a oportunidade de compartilhar conhecimento, detectar problemas antes que cheguem a producao e elevar o nivel tecnico de toda a equipe.
Postmortems sem culpados
Quando algo falha em producao, nao buscamos culpados. Buscamos o que permitiu que o erro chegasse ate la. Faltou um teste? O monitoramento nao alertou a tempo? A documentacao era ambigua? Corrigimos o sistema, nao apontamos pessoas.
Quer trabalhar em uma equipe que respeita seu tempo?
Se voce e engenheiro(a) e valoriza autonomia, codigo limpo e desafios tecnicos reais, vamos conversar.
Fale conosco