From product manager to DevOps evangelist: my Salesforce career journey

At DevOps Launchpad, we’re passionate about spotlighting real career journeys that show how DevOps can unlock new opportunities in the Salesforce ecosystem. In our latest “Careers in DevOps” webinar, we heard from Eric Kintzer — Salesforce Architect, Stack Exchange top contributor, and long-time DevOps advocate — who shared how learning Salesforce hands-on, embracing DevOps best practices, and giving back to the community transformed his career. Whether you’re a solo admin or a developer in a growing team, Eric’s story is full of insights that can help you scale your skills and build a stronger, more rewarding Salesforce career.

You can watch a recording of the webinar on demand here.

Getting my hands dirty: the unexpected shift from exec to builder

I didn’t begin my Salesforce journey as a developer or admin. I was a tech exec, mostly managing people, budgets, and product direction. But when my last startup folded in 2007, I ended up taking a role at Yahoo! that involved — to my surprise — building a Salesforce app hands-on. I thought I’d be managing the project. Instead, I was told, “You’re building this yourself.”

There was no Trailhead then. No step-by-step modules. Just books, documentation, and whatever you could find online. So that’s where I started — from scratch, figuring things out as I went.

One of the first lightbulb moments for me was realizing that I could deploy my own work directly to production. That was totally different from my previous experience in traditional software companies, where shipping code often meant coordinating across multiple teams until 3am. Being able to deliver changes myself, in hours instead of weeks, was a breath of fresh air — even if it was just change sets.

Realizing there’s a better way

As I got deeper into development, I started seeing parallels between what I was doing and what engineering teams outside of Salesforce were already doing: version control, CI/CD, automated testing, proper release processes. And frankly, the way we did things in Salesforce felt a bit behind.

I started learning about DevOps concepts and trying to apply them to my own work. At Yahoo!, that meant wrangling the Ant Migration Tool and some homegrown scripts, which wasn’t ideal. The learning curve was steep, and it was frustrating not to have more intuitive tools. That frustration is part of what led me to Gearset a few years later — but more on that in a bit.

Around the same time, I came across a couple of books that really shaped the way I think about building in Salesforce. Advanced Apex Programming by Dan Appleman and Salesforce Platform Enterprise Architecture by Andrew Fawcett both helped me level up from “getting things done” to “building things well.” Those resources showed me what maintainable, scalable Salesforce development could look like — and I’ve been trying to stick to those principles ever since.

Giving back to the community

At some point, I realized that I’d learned a lot from the community, and it felt right to give something back. I started answering questions on Salesforce Stack Exchange — mostly because I liked helping people, but also because it helped me think more clearly about the problems I was solving in my day job.

If you’re just starting out or looking to solidify your knowledge, I can’t recommend this enough. Teaching others — even just through forum posts — sharpens your understanding and helps you avoid tunnel vision.

Finding the right DevOps tools (and shaping them, too)

Eventually, I got introduced to Gearset at Dreamforce, and it changed how I approached deployments. The tool itself was intuitive and genuinely helpful — especially compared to what I’d been dealing with — but what impressed me even more was that their team actually listened. I gave feedback, and they implemented it. That kind of collaboration between vendor and user isn’t common.

Since then, I’ve helped advise on a couple of features, like Pipelines (which helps with release automation) and Precision Deployments (which lets you avoid deploying a whole metadata file when you only changed part of it). Both came from real-world pain points and were built to solve the problems that Salesforce teams actually deal with — especially when you’re collaborating with other team members.

The big lessons: what I wish I’d known sooner

Looking back, here are some things that I think are worth knowing — especially if you’re earlier in your journey or trying to bring more DevOps thinking into your work:

1. Do things properly the first time

It’s tempting to hack something together to meet a deadline, but you’ll end up revisiting it again and again. I still work in orgs I touched back in 2009, and I’ve had to clean up a lot of my own early work. Use good naming conventions. Think through the architecture. You’ll thank yourself later.

2. Testing matters

You can’t trust an org that doesn’t have a good regression test suite. I spend more time writing tests than I do writing the initial feature code. If something breaks, I want to know before it reaches production — not after a user reports it.

3. You don’t need to build everything yourself

There are great community tools out there — ApexMocks, fflib, Declarative Lookup Rollup Summaries, you name it. Use them. Don’t reinvent the wheel when someone else has already solved the problem well.

4. DevOps is for everyone

You don’t need to be an engineer or work on a massive team to start using DevOps principles. Even if you’re a solo admin, having version control, a clean release pipeline, and reliable tests will make your life easier and your org safer.

5. The best tools are the ones that fit your workflow

When we evaluated DevOps tools, we found that some (like Copado and AutoRABIT) were a bit heavy-handed for our team size and needed a lot of setup. Gearset worked out of the box, and the support has always been great. It’s been a constant in my DevOps journey ever since.

Final thoughts

I didn’t set out to become a Salesforce architect. I just needed a job. But along the way, I found a platform I enjoyed building on, a community I learned a lot from, and a set of DevOps practices that helped me deliver better work.

DevOps isn’t a buzzword — it’s a mindset. It’s about building with quality, collaborating well, and making sure your work is sustainable. That applies whether you’re building Apex, configuring Flows, or just trying to keep your org from turning into spaghetti.

Next steps

If any of this resonates with you, and you’re thinking about where to go next in your career, I’d suggest spending some time learning the fundamentals of DevOps. You’ll build better systems, and you’ll grow as a professional. If you want to get started, DevOps Launchpad has free Salesforce-specific courses and certifications to help you take that next step.

You can also have a go at using Gearset’s DevOps solution for free with their 30-day trial, or have a chat with one of their team about your Salesforce struggles, and get advice from the friendly industry pioneers of Salesforce DevOps.