Every network engineer has a first on-call night they never forget. Mine happened more than twenty years ago, and I haven't really stopped since — I just traded the terminal console for a management seat, without ever straying far from a cable, a router, or, more recently, the AWS console.
This post opens the blog, so it felt right to start by telling you who I am and why I decided to write. No formal résumé here — LinkedIn already covers that. The idea here is to tell the story behind the titles.
Where I come from
Before any diploma, there was an uncle. Everything started next to him — me sitting nearby, curious, watching that 486 DX4-100 (and later the first Pentiums) come alive in his hands. He'd assemble machines, format drives, install the operating system, and fix the strangest problems like it was nothing. I'd get home wanting to redo it all myself, always break something, and he'd come over — without a word of complaint — and fix the damage. It was there, with no ceremony at all, that I decided that when I grew up, I wanted to do exactly that.
Years later I enrolled in a technical program in Data Processing, and school brought my first internship in the field along with it. From then on, I never really stopped — not studying, not working with technology.
One of my first real leaps was head-first into the Windows world, where I earned my MCSA (the classic 70-270, 70-271, 70-290 and 70-291 exams). It was also during that stage of discovery that I made a friend for life — we still talk regularly to this day — who introduced me to networking: he told me about Linux, about FOCA Linux, about Cisco's CCNA, and pointed me toward training at Fundação Bradesco. That's where I learned networking for real — what a subnet is, what a routing table is, and, above all, that pretty theory on a slide is one thing; production networking, arguing with a switch that won't bring up a VLAN at two in the morning, is something else entirely.
In the years that followed, that foundation got more solid in practice: structured cabling, routing, on-premise datacenters. It's the kind of work that teaches humility — the network always finds a way to remind you that you don't know everything.
From there came a string of good, hard-earned battles: I passed through the largest web hosting provider in Latin America, worked with SAP Basis, handled backups — with robots running more than five drives non-stop — and got fully into Kubernetes and the clouds (AWS, Azure, GCP and OCI), without ever letting go of on-premise. That mix of hard knocks and curiosity is what brought me here, leading a network engineering team today.
When management entered the picture
At some point in my career, I realized what energized me most wasn't just resolving the incident — it was building the team that resolved incidents well, and without unnecessary suffering. That interest is what led me to a postgraduate degree in Leadership and Innovation at FGV, one of the most important decisions I've made: trading part of my time studying protocols for time studying people.
Today I work as Tech Manager for the Network Engineering team at one of Brazil's largest fintechs. It's a genuinely mission-critical environment: any network instability turns, within minutes, into a business problem, a transaction problem, a customer-trust problem. Leading a high-performance team in that context is a daily exercise in balancing two things that seem opposed — giving technical autonomy while maintaining the operational rigor the environment demands.
Traditional networking, cloud, and the journey that continues
Along the way, I've built up certifications that mark this journey between two worlds well: CCNACCNP in progress on the traditional Cisco networking side, Fortinet NSE 1 to 4 on the network security side, and AWS Solutions Architect Associate on the cloud side. I've operated on-premise networks as well as architectures on AWS, Azure, OCI and GCP — enough to have formed opinions on where each model shines and where each one hurts.
Right now I'm continuing that dual journey: preparing for the CCNP, the AWS Solutions Architect Professional, and the CKA, and studying Infrastructure as Code heavily — because it's increasingly clear that the future of network engineering means treating networks the way we treat software.
Why this blog
The idea behind this space is simple: exchange experience. I want to bring, every week, a bit of what I see day-to-day — whether it's a real network problem, a cloud architecture decision, an IaC lesson, or a reflection on leading technical teams under pressure. Light on the fluff, backed by the scars of more than twenty years on the road.
If you're a network engineer moving into cloud, a technical manager trying to balance delivery with taking care of your team, or just someone curious about what day-to-day life behind a fintech looks like — this space is for you. New post next week.
Next post: behind the scenes of cloud, and my first steps with IaC.
See all posts