Carreira e Trabalho
Construindo sistemas que escalam. Quebrando coisas que não deveriam quebrar. Aprendendo com os dois.
Capítulo 0: Por Que TI?
Acho que tinha uns quatro anos quando vi um computador Atari pela primeira vez. Foram os cliques do teclado que me fisgaram.
Lembro do meu primeiro programa: 10 PRINT "Hello World!" em MS BASIC. Não lembro quantos anos eu tinha, mas adorei cada
minuto do meu tempo com o computador.
No início dos anos 90, meu pai comprou um IBM 386 PC. Eu tinha desmontado ele uma semana depois procurando como fazer upgrade do disco rígido — para total desespero da minha mãe.
Meu primeiro trabalho pago foi configurar T602, um aplicativo DOS, para uma cooperativa agrícola local. No ensino médio, consegui meu primeiro modem 56k, descobri a Internet, e comecei a pegar trabalhos de tradução de manuais técnicos do alemão para o eslovaco. Depois disso, a economia gig de TI abriu ainda mais.
Costumava acompanhar meu pai em feiras de computadores, que eram incríveis — conheci muita gente legal que compartilhava minha obsessão. Sem falar em todas as LAN parties e jogos que ocupavam a maior parte do meu tempo livre nos meses frios. No verão, quando não estava dormindo, estava na minha bicicleta.
Capítulo 1: Onde Tudo Começou
Me sinto muito sortudo por ter conhecido pessoas em Praga que literalmente apostaram em mim para meu primeiro trabalho "de verdade". Meus professores tinham sido incríveis e forneceram referências, o que acho que foi o fator principal. Sou um passarinho estranho, mas sortudo.
O banco era incrível — tantas pessoas querendo compartilhar sua experiência. Administrei o banco de dados MIDAS DB2 e servidores IBM AS/400, aprendendo sistemas enterprise com pessoas que realmente sabiam o que estavam fazendo.
A Noite em Que Quase Acabei com Minha Carreira
Seis meses depois de ser contratado, causei um incidente grave.
Estava desenvolvendo no sistema DEV AS/400 e cometi o erro de usar as variáveis erradas que apontavam para o sistema de produção. Quando executei um teste e quis deletar tabelas no banco de dados SQL, travou depois de 30 tabelas.
Levei alguns minutos para perceber que tinha deletado tabelas de banco de dados de produção.
Os operadores já tinham iniciado os processos de fim do dia, então rollback não era uma opção. Liguei para meu chefe, e ele me disse para abrir um ticket de emergência com o suporte MIDAS no Reino Unido. Vale notar que meu inglês na época era tão bom quanto você esperaria de alguém que o aprendeu com cassetes e livros.
Por sorte, encontrei um programador que falava tcheco. Embora eu achasse que seria a última coisa que faria pelo banco, acabou se tornando uma das melhores experiências da minha vida. Aprendi tanto com ele naquela noite. Trabalhamos a noite toda e consertamos a situação uma hora depois do banco abrir.
Fui mandado para casa para dormir um pouco. No dia seguinte, eu esperava totalmente ser demitido.
Em vez disso, me disseram que eu iria participar de duas semanas de treinamento personalizado em AS/400.
Todo mundo foi duro e acolhedor ao mesmo tempo. Isso me deixou uma impressão que dura até hoje. Não entendi na época por que as pessoas foram tão tolerantes e gentis comigo. Só clicou muito, muito tempo depois.
Guardo boas lembranças de todos os meus colegas e de tudo que me ensinaram em tão pouco tempo.
Recomeçando em Nova York
Quando nossa família se mudou para Nova York e saí do banco, tive que pegar trabalhos de construção e cuidador por curtos períodos — era o que meus pais podiam ajudar a facilitar até eu me estabilizar. Foi uma transição difícil, mas com um futuro brilhante pela frente.
Comecei a fazer consultoria tentando estudar na faculdade. Não durou muito porque subestimei quanto tudo custava. Entrevistas de emprego se transformavam em trabalhos onde as empresas só queriam algo programado ou consertado. Comecei a competir com desenvolvedores da Índia por projetos de software, e não tinha como competir com os preços deles.
Então pivotei.
Capítulo 2: Os Anos de Consultoria
Foi quando descobri os Provedores de Serviços Gerenciados. O dinheiro era bom, e com meu conjunto de habilidades, parecia bem manejável — pelo menos no começo.
Então comecei a descobrir minhas limitações.
Minha energia estava se esgotando. O estresse se tornou mais um companheiro do que algo que visitava ocasionalmente. Criar scripts, configurar ambientes e resolver problemas diariamente sem suporte de equipe ou orçamento real — fazer tudo com muito pouco — era um quebra-cabeça sem solução.
Trocar de contexto constantemente. Trabalhar com colegas tão estressados quanto eu, ou pior. Não era agradável. Eu compararia a beber de uma mangueira de incêndio quando você só quer um gole de água.
Adorava os desafios técnicos. Clientes estressados eram como anchovas numa pizza — ninguém quer elas lá.
O Que Aprendi (Às Vezes do Jeito Difícil)
Durante esse capítulo, aprendi o que não fazer. Algumas lições demoraram muito mais do que deveriam.
Acabei cuidando da maior parte do trabalho de plataformas de email para praticamente todos os principais fornecedores de software, incluindo soluções hospedadas na nuvem. Você também encontra muita perda de dados no negócio MSP, então se tornar especialista em backup e recuperação de desastres foi inevitável.
Minha mente estava sempre procurando automação, então nunca parei de programar — especialmente quando se tratava de administrar muitos computadores. Acho que isso me ajudou a encontrar meu nicho no mundo MSP.
O que não percebi é que o estresse estava me segurando, tornando-me mais burro, mais doente e mais desconectado. Perdi muitas oportunidades por causa disso.
Habilidades-chave desenvolvidas: Plataformas de email (Exchange, O365, Google Workspace), backup e recuperação de desastres, automação PowerShell, e a arte de fazer mais com menos.
Capítulo 3: Transição para Enterprise
Quando comecei na Cervalis, a equipe era ótima. Nos divertimos muito e fizemos projetos incríveis juntos.
Mergulhei mais fundo em virtualização e soluções de armazenamento de dados em escala enterprise. Fazer trabalho de rack em hardware que custa milhões de dólares era empolgante. Mas descobri que gostava muito mais do lado de software do que executar implantações físicas.
O Projeto Que Mudou Minha Forma de Pensar
A primeira vez que trabalhei com um cliente e sete fornecedores diferentes em uma implantação, algo clicou. Percebi que realmente aprecio esse tipo de complexidade — o desafio de configurar uma camada de hardware totalmente nova e preenchê-la com todas as cargas de trabalho e arquitetura que o negócio precisa para gerar lucros.
Um projeto do qual lembro com carinho: precisei descobrir como dividir bancos de dados Microsoft Exchange que estavam atingindo limites de armazenamento e causando degradação de desempenho.
Isso exigiu orquestração complexa — migrar para uma nova versão enquanto criava uma estratégia de migração para caixas de correio que as equilibraria uniformemente em múltiplos bancos de dados em diferentes volumes de desempenho.
Usei OptaPlanner (agora Timefold) e projetei um software que executava lógica de bin-packing para criar scripts de migração alcançando uma distribuição de caixas de correio perfeitamente equilibrada. Depois automatizei todo o processo de migração.
Levou algumas semanas de planejamento e codificação, e um mês de monitoramento. Ver milhares de caixas de correio fluindo para suas novas casas exatamente como planejado? Foi profundamente satisfatório.
O Ano do Tédio (E o Que Veio Depois)
Uma vez que CyrusOne adquiriu Cervalis, lembro de um ano de "tédio" que me forçou a reavaliar muitas coisas. No final desse tédio, a cultura mudou significativamente para uma mentalidade de escassez. Começou a parecer meus velhos tempos de MSP.
Tive problemas de saúde significativos devido ao aumento repentino de estresse quando tudo começou a vir de uma vez só. CyrusOne foi ótima sobre isso e fez acomodações significativas para mim. Uma vez recuperado, queria terminar todos os meus projetos abertos, mas sabia que era hora de seguir em frente.
Habilidades-chave desenvolvidas: Infraestrutura VMware em escala, arquitetura Exchange enterprise, planejamento de recuperação de desastres, maestria em PowerShell, e gerenciar projetos multimilionários.
Capítulo 4: Tornando-se o Arquiteto
Quando comecei, Axiom era uma operação muito promissora em modo startup. As pessoas eram incríveis de se conviver.
Foi aqui que descobri que realmente gostava de mentorear meus colegas mais jovens.
Infelizmente, alguns meses depois que entrei, o COVID chegou. Como esse negócio tinha muitos clientes cujo resultado final foi impactado, não parecia mais tão promissor. O CEO foi incrível e fez tudo para minimizar o impacto nos funcionários. Ele fez um esforço enorme para manter as coisas, mas acabamos fundindo com Proxios.
O Trabalho Que Importou
Pude usar muito da minha experiência e conhecimento durante essas transições:
- Projetei e entreguei soluções de infraestrutura complexas cloud, on-premise e híbridas
- Liderei migrações em grande escala — conversões completas de infraestrutura de servidores on-premise para Azure e AWS, migrações de arquivos para SharePoint
- Assumi documentação PowerShell, vídeos educacionais e mentoria para a equipe de engenharia
- Projetei soluções de segurança multicamadas integrando controle de identidade moderno (Okta, DUO), proteção de endpoint (CrowdStrike) e segurança de rede
Trabalhei com clientes incríveis, o que produziu amizades muito boas que duram até hoje. Ganhei experiência significativa em Gestão de Identidade trabalhando em várias plataformas que precisavam de automação e consolidação — o que também me envolveu mais em segurança.
Quando a empresa estava prestes a ser adquirida novamente, um dos meus clientes existentes expressou interesse em me contratar diretamente. Decidi dar o salto.
Curiosamente, não estava sozinho. Vários dos meus colegas começaram meu próximo capítulo comigo.
Capítulo 5: A Aventura Atual
Quando comecei na Olaplex, tive um flashback do meu primeiro chefe em Praga.
Trabalhando com meu chefe atual, temos uma forma muito similar de pensar sobre problemas e soluções — apenas em domínios diferentes. É uma das melhores experiências profissionais que se pode ter. É raro para mim; geralmente tenho esses encontros com fornecedores que fazem desenvolvimento de software, então não dura. Mas ter alguém na mesma sintonia? Aprecio isso imensamente.
Praticamente todas as minhas habilidades foram usadas aqui. Levou cerca de seis meses para aprender todos os processos e sistemas.
O Projeto de Identidade (18 Meses em Andamento)
Depois de me estabelecer, comecei um dos projetos mais longos da minha carreira.
Precisávamos de uma solução para gerenciar funcionários em tempo integral — não apenas nos EUA, mas globalmente — e não tínhamos o mesmo sistema HRIS para todos. Além disso, há uma população de contratados e fornecedores tão grande quanto o número combinado de funcionários em tempo integral e parcial.
Havia fricção significativa com onboarding e offboarding para todos os tipos de trabalhadores.
Arquitetei uma solução interna e começamos com uma abordagem simples. Levou algumas tentativas para encontrar o desenvolvedor de software certo porque foi um desafio e tanto.
Depois de 18 meses, tínhamos uma solução totalmente funcional que abordou todos os pontos de fricção relatados pelo negócio. Estou muito feliz com como a equipe conseguiu — especialmente considerando que eu estava trabalhando em outros projetos e gerenciando infraestrutura simultaneamente.
Se a equipe Olaplex não fosse tão incrível, isso nunca teria sido possível com a abordagem MVP que escolhi devido às restrições financeiras.
Encontrando Dinheiro nas Contas Cloud
Há uma alegria especial em encontrar economias escondidas nas contas AWS.
Fazer revisões de infraestrutura e descobrir otimizações de custos é um prazer real que tiro deste trabalho. Como os tempos são difíceis, cada dólar conta.
A equipe e eu trabalhamos para reduzir nossos gastos AWS — uma besta que consome um valor de cinco dígitos todo mês e que geralmente só sobe. Conseguimos reduzi-la e manter a trajetória indo para baixo em vez de para cima, sem impactar nenhuma operação do negócio.
Trabalhando com parceiros como Insight e Archera, identificamos ineficiências e implementamos ajustes estratégicos.
O Capítulo IA
2025 foi o ano em que a IA entrou no negócio de forma significativa.
Usá-la como descarregador cognitivo, explicador, rastreador de projetos, codificador e agente que processa grandes quantidades de dados e faz sentido deles agora faz parte da minha rotina diária. Olaplex adotou IA cedo e fez um esforço para que a força de trabalho a use diariamente.
Adoro usar VS Code com os agentes de IA Gemini e Claude.
Aqui está a coisa: a forma como tendo a trabalhar — contexto entra, problema sai, mas memória como uma peneira — acontece que combina bem com IA. Me dê contexto e um problema para resolver, e estou como um peixe na água. Mas porque processo tanta informação, minha memória não consegue reter tudo — então, muitas notas.
Para minha surpresa, a IA pode ser levada a pensar de quase exatamente a mesma forma, mas melhor. Quando trago minha experiência e conhecimento de casos extremos, quando sei o que perguntar — e mais importante, o que verificar depois de ter uma resposta — essa ferramenta se torna inestimável. Economiza tempo e reduz o estresse dramaticamente.
Acredito que a IA tornará pessoas que querem ser melhores, melhores — e pessoas que querem ser preguiçosas, expertamente mais preguiçosas. Como qualquer ferramenta, é uma espada de dois gumes onde os gumes nem sempre são óbvios.
Caixa de Ferramentas Técnica
Em mais de 20 anos, acumulei experiência em:
Plataformas Cloud
AWS, Microsoft Azure, Google Cloud Platform, VMware
Identidade & Segurança
Governança de Identidade, SailPoint, JumpCloud, Okta, SentinelOne, SSO, DLP, MDM
DevOps & Automação
PowerShell, Workflows de IA, CI/CD, Infrastructure as Code
Rede
VPN, DNS, DFS, Stack de Rede Completo
Sistemas
Microsoft Server, iSeries, Active Directory, Exchange (todas versões, todos problemas)
Desenvolvimento
Java, Python, PowerShell, Arquitetura de Aplicações Customizadas
Filosofia
A tecnologia deveria servir as pessoas, não o contrário. Os melhores sistemas são aqueles que ninguém percebe porque eles simplesmente funcionam. E as melhores equipes são aquelas onde alguém pode deletar um banco de dados de produção aos 6 meses e ainda ser mandado para treinamento em vez de para a porta.
Eu fui a pessoa que causou o desastre. Eu fui a pessoa que consertou o desastre de outra pessoa às 3h da manhã. Ambas as experiências me ensinaram que como você trata as pessoas importa mais do que o código que você escreve.
Vamos nos Conectar
Se você está escalando infraestrutura, implementando governança de segurança, otimizando gastos cloud, ou só quer trocar histórias de guerra sobre migrações Exchange — adoraria conversar.