A fortnight ago I walked into a new job as an ETL developer, having spent the previous stretch of my career being the person other people asked about analytics. I went from "expert in the room" to "please be patient, I'm new to this" in the space of a weekend. If you've ever deliberately stepped down a rung to climb a better ladder, you'll recognise the particular vertigo of it. Here's what the first weeks actually feel like, since the tidy career-change articles never quite say.

The humbling is real, and it's fine

The first thing to make peace with: you will feel slow. I came in fluent in the language of data — I understood funnels, cohorts, what a good metric is, why definitions matter. What I did not have was the enterprise plumbing: SQL Server the way a serious shop runs it, ETL as a discipline rather than a Python script, the tooling, the conventions, the thousand small "obviously you'd do it this way" things that are only obvious once someone's shown you.

So I ask a lot of questions. I write things down that I'll be embarrassed to have written down in six months. And I've decided that's exactly right. The alternative — pretending to understand to protect my ego — is how you ship a quiet mistake that someone finds three weeks later. Being visibly a beginner is uncomfortable; being secretly lost is dangerous.

What transferred (more than I expected)

Here's the reassuring part, if you're contemplating a similar jump. A surprising amount came with me.

  • Knowing what "good data" means. I've spent years downstream, looking at numbers people didn't trust and working out why. That instinct — is this figure believable, and how would I know — turns out to be the whole job of ETL, just approached from the other end. I used to diagnose bad data. Now I'm upstream, trying not to create it.
  • Explaining things to humans. My background is corporate communication, and it keeps earning its keep in the least glamorous ways. When I don't understand something, I can at least ask a precise question. When I do understand something, I can explain it back to check I've got it right. Half of learning a new technical domain is being good at the conversation about it.
  • Comfort with being wrong out loud. Analytics teaches you that your first read of the data is often wrong and you correct it. That habit — hold it loosely, check it, adjust — is exactly what you need when you're learning a stack from scratch.

What did not transfer at all

And the honest other side: plenty didn't.

The sheer rigour of enterprise data work caught me off guard. In a start-up, "it works" is often good enough. Here, a load has to work every night, handle the row that breaks the pattern, fail safely when something upstream changes, and leave a trail someone can audit later. That's a different standard, and it's the right one for data people actually depend on — but it's a real adjustment from moving fast and fixing it Monday.

The tooling is deep. There are patterns and conventions that exist for hard-won reasons I don't yet know, and the temptation is to reinvent something badly because I can't yet see why the established way is the established way. So mostly I'm resisting the urge to be clever, and instead learning why things are the way they are before I have opinions about changing them.

The specific things that tripped me up

In case it saves you a week, here are the concrete things that confused me most — the ones nobody thinks to explain because they're "obvious" once you know them.

There's more than one way to deploy SSIS, and they're not interchangeable. The project deployment model, the SSIS catalog (SSISDB), environments and project parameters for pointing the same packages at dev versus production — this whole apparatus was a mystery to me at first, and it's central to how a serious shop runs its ETL. Worth learning deliberately rather than absorbing by osmosis.

Databases belong in source control too, and it's not obvious how. Coming from scripting, I thought version control just meant saving my .sql files somewhere. But the schema itself — tables, procedures, the shape of the database — needs to be versioned and deployable, and that's a discipline with its own tools and conventions I had to learn from scratch.

There's rarely one obvious "right" way. In a tutorial there's a single blessed path. In a real platform there are five ways to build the same load, and the best one depends on context I didn't yet have. Early on I found that paralysing. Now I suspect it is the skill: not knowing a way, but knowing which way this situation is asking for.

The pattern in all three: the hard part was never the concept. It was the accumulated conventions a real environment quietly runs on — the stuff that's invisible until someone points straight at it.

The plan from here

Two weeks in, my strategy is unglamorous: be useful at the small things, ask good questions, and go deep on the fundamentals before I try to be fast. I'd rather be the beginner who understands why than the beginner who's memorised a few clicks.

I'll write more as I actually learn things worth passing on — the first time a tool genuinely changes how I work, you'll hear about it here. For now I'm just glad I made the jump. The dials were a fine place to start. I want to build the machine, and you don't learn that from the outside.