Back to Blog

From Service Desk to Senior Data Engineer: The Unconventional Path

How I went from IT support to senior data engineer at Latin America's largest tech company — and why the unconventional path matters

CareerLearningData EngineeringPersonal Growth

The Starting Line: IT Infrastructure

I started my career in IT infrastructure — setting up networks in city facilities, configuring systems, troubleshooting hardware. The classic entry point for many tech careers.

My job was simple: install operating systems, configure network settings, troubleshoot printer connections, run cables through ceiling tiles.

I had no idea this would lead to over a decade at MercadoLibre, Latin America’s largest tech company, eventually becoming the senior data engineer responsible for an entire business unit’s data foundation.

This is the story of how I got there — and why the unconventional path might be better than you think.

The Service Desk Years: Learning to Debug Humans

After the infrastructure work, I moved into service desk roles. You know the drill:

“Have you tried restarting it?”

“Is it plugged in?”

“Can you describe what error message you’re seeing?”

Most people think service desk is entry-level grunt work. And it is. But it’s also the best training ground for a data career that no one talks about.

What Service Desk Taught Me

1. How to ask the right questions

Users rarely tell you what’s actually wrong. They tell you symptoms, assumptions, or what they think is wrong.

  • “The system is broken” → Actually, their browser cache is full
  • “Data is missing” → Actually, they’re looking at the wrong date range
  • “The report is wrong” → Actually, their expectations don’t match business logic

Lesson: The problem you’re told about is rarely the real problem. You have to ask clarifying questions, challenge assumptions, and investigate systematically.

2. How to explain technical concepts to non-technical people

You can’t just say “clear your DNS cache.” You need to explain why and what it does in terms they understand.

This skill becomes critical when you’re a data engineer explaining:

  • Why the report numbers don’t match Excel (aggregation logic, timezone differences)
  • Why real-time dashboards aren’t actually real-time (batch processing, CDC lag)
  • Why we can’t “just add this field” (schema migration, downstream dependencies)

3. How to prioritize under pressure

When you’re handling 20 tickets, 5 walk-ups, and 3 urgent escalations, you learn to triage fast:

  • What’s on fire right now?
  • What can wait an hour?
  • What can be delegated or automated?

This translates directly to data engineering:

  • Production pipeline down → Fix now
  • Dashboard is slow → Investigate today
  • Feature request from stakeholder → Prioritize with backlog

The Pivot: From Support to Data

In 2015, MercadoLibre acquired KPL Soluções, a Brazilian company specializing in e-commerce ERP and invoice solutions. I had just joined KPL a week earlier as a support assistant for a legacy system.

Suddenly, I was part of Latin America’s largest tech company.

The transition to data wasn’t immediate. For years, I did support work. But I noticed something:

I was naturally gravitating toward data problems.

When troubleshooting issues, I’d spend time in logs, databases, and system metrics. I’d write queries to investigate patterns. I’d build simple dashboards to track performance.

In 2018, I started creating KPI visualizations for my team. Nothing fancy — just charts that helped us understand what was happening. But those visualizations got noticed.

The transition wasn’t clean. I didn’t go from support → analyst → engineer in neat steps. I took lateral moves, hybrid roles, projects that “kind of” involved data but weren’t pure data roles.

And that’s okay.

MercadoLibre: 11+ Years of Learning at Scale

I’ve now spent over 11 years at MercadoLibre — and I’m still here. My journey:

  • 2015: Joined via KPL acquisition as support assistant
  • 2018: Started building KPI visualizations, transitioned to data
  • 2018-2024: Mercado Envios (Logistics) — data viz, pipelines, data science projects
  • 2024-Present: Internal Systems (Corporate Tech) — Senior Data Engineer

Key insight: Each domain taught me something different about data at scale.

The Organizational Shift That Shaped My Career

Something important was happening at MercadoLibre during my transition to data work. The company had centralized data teams, but as the data-driven culture accelerated, these teams became bottlenecks. They couldn’t scale fast enough, and more importantly — they lacked the domain expertise to deeply understand each business unit’s problems.

The solution was a shift toward embedded data teams — analysts and engineers working within business units rather than serving them from a central function. My move to Mercado Envios wasn’t just a career step; it was part of this broader organizational transformation.

This context matters because it explains why domain knowledge became so valuable. Being embedded in logistics meant I could understand the business deeply, not just process data requests.

What MercadoLibre Taught Me

1. Domain knowledge compounds

I spent most of my career in Mercado Envios (Logistics). Understanding how packages move, how carriers work, and where bottlenecks occur made me a better data engineer than any technical skill alone.

The biggest project I worked on — Hunting Inteligente — was a classification model to optimize fulfillment conversion. It required deep understanding of how listings, customers, and logistics actually worked together.

Lesson: Technical skills get you in the door. Domain expertise makes you valuable. Embedded teams work because they combine both.

2. Stakeholder alignment is 80% of the job

Working across business units taught me that the hard part isn’t writing SQL. It’s:

  • Getting stakeholders to agree on definitions
  • Navigating conflicting priorities between teams
  • Explaining why “just add this field” isn’t simple
  • Building trust with teams who depend on your systems

Lesson: If stakeholders can’t agree on a spreadsheet, they won’t agree on a database.

3. Observability beats optimization

The most valuable work I did wasn’t building sophisticated models. It was building simple, clear dashboards that answered basic questions:

  • Where is this package right now?
  • Which routes are consistently late?
  • Where are the bottlenecks?

Lesson: You don’t need ML to create value. Sometimes you just need to help people see what’s happening.

What I’d Tell My Younger Self

1. The Unconventional Path Has Hidden Advantages

I didn’t study computer science. I didn’t go to a bootcamp. I didn’t follow the “junior → mid → senior” ladder neatly.

And that’s a feature, not a bug.

The support years taught me:

  • User empathy (you’re building systems for humans, not abstractions)
  • Communication skills (explaining technical concepts clearly)
  • Operations mindset (things break; plan for it)

These skills are rare in data engineering. Most engineers come from CS backgrounds with strong technical skills but weak communication. The unconventional path gave me differentiation.

2. You Don’t Need Permission to Learn

I didn’t wait for a company to train me. I didn’t wait for a mentor to guide me. I just started building things.

  • Wrote SQL queries to analyze service desk tickets
  • Built Excel dashboards before learning Python
  • Volunteered for “data-adjacent” projects at work
  • Read books, took free courses, experimented constantly

No one cares how you learned. They care what you can build.

3. Lateral Moves Aren’t Setbacks

Early in my career, I took roles that weren’t pure “data engineer.” Some were support-heavy. Some were operations-focused. Some were hybrid roles that didn’t fit neatly into any category.

At the time, I thought I was falling behind peers who took linear paths.

Looking back: Those lateral moves gave me breadth. I understand how data systems fit into broader operations. I can talk to business stakeholders. I’ve debugged production issues at 2 AM.

Depth matters. But breadth makes you valuable.

The Meta-Lesson: Data Engineering is a People Job

Here’s the thing no one tells you:

Data engineering is 20% technology and 80% people.

The hard part isn’t writing SQL. It’s:

  • Getting stakeholders to agree on definitions
  • Navigating organizational politics
  • Balancing technical debt vs. new features
  • Communicating trade-offs to non-technical leaders
  • Building trust with teams who depend on your systems

The service desk years prepared me for this better than any CS degree.

If You’re Starting Now

Maybe you’re in a support role, wondering how to break into data.

Maybe you’re in a non-technical role, curious about data but unsure where to start.

Maybe you’re mid-career, thinking it’s “too late” to pivot.

Here’s what I’d recommend:

1. Start Where You Are

  • Support role? Analyze ticket patterns in SQL
  • Operations role? Build dashboards for your team
  • Non-technical role? Learn Excel → SQL → Python in that order

2. Build Things People Can See

  • Internal dashboards
  • Automated reports
  • Data quality checks
  • Anything that creates tangible value

3. Ask for Data-Adjacent Projects

  • “Can I help analyze why customers are churning?”
  • “Can I build a dashboard for this team?”
  • “Can I investigate this data quality issue?“

4. Accept That It Won’t Be Linear

You’ll take lateral moves. You’ll work on “not quite data” projects. You’ll feel like you’re not progressing fast enough.

That’s normal. Keep building. Keep learning. Keep shipping.

The Punchline

I went from IT support to senior data engineer at Latin America’s largest tech company.

Not despite the unconventional path. Because of it.

The support years taught me empathy, communication, and operations.

The lateral moves gave me breadth and business context.

Over 11 years at MercadoLibre taught me how to build data systems that matter at scale.

Today, I’m the senior data engineer in a business unit that needed a data foundation built from scratch — a dozen ungoverned dashboards, a BigQuery sandbox no one understood, and three junior engineers looking for direction. Not a formal tech lead title, but the responsibilities that come with being the most experienced person in the room.

Your path doesn’t have to be conventional to be valuable.

This post reflects my personal journey. Your path will be different — and that’s the point. There’s no single “right way” to become a data engineer. Follow your curiosity, build things people care about, and the career will follow.