Scaling DevOps and CI/CD pipelines can be challenging, especially as engineering teams grow and systems become more complex. Without the right approach, your internal tools and deployment workflows can become bottlenecks instead of boosters.
In this episode of the Scaling Tech Podcast, Arin sits down with Tom Elliott, founder of Ocuroot and former Engineering Productivity Lead at Yext, to unpack the real-world challenges of scaling DevOps in fast-growing engineering teams. Tom shares invaluable lessons from managing complex deployment challenges and evolving legacy systems, along with practical advice on internal tooling, feature flags, and shifting the perception of DevOps within organizations.
Listen to the full episode to learn how to manage deployments and DevOps at scale!
Listen to the full episode on Spotify
Listen to the full episode on Apple Podcasts
Or, watch the video!
About Our Guest
Where to find Tom: LinkedIn | Website | Ocuroot
Links from the episode:
- Why I’m not using feature flags…yet
- Zero-access debugging
- Why would I need more production environments, anyway?
Key Insights
⚡Best practices are context-dependent. When it comes to software development, what works best isn’t always set in stone. Tom highlights why context matters and why staying adaptable is key to managing legacy systems effectively, “It’s interesting because a 10-year system that starts today is going to be very different from a 10-year-old system that started 10 years ago. Even now, we’re a few years out from this project that I was talking about, and someone who’s got that same level of legacy now, things are different because technology is moving along so fast. […] I think you’ve got to be vigilant and always thinking about what’s coming next and how you need to prepare for it, which is a really difficult thing.”
⚡Internal platforms need clear ownership and boundaries. The difference between a high-performing internal platform and one that becomes a bottleneck often comes down to clear, accountable ownership. Tom shares his experience, “I have a somewhat strong opinion about the idea of community-led efforts. So when I was at Yext, we toyed around with the idea of having sort of the official internal tools, […] Then we had community tools, which just maybe came out of a hackathon or someone had an idea for something they wanted to have. And because there was no official ownership of that, those things sort of atrophied, and they didn’t get improvements, and you end up with a couple of competing tools, and that could become a problem. That’s not to say that you should never have community-supported tools internally or sort of hobby tools, but when you have a dedicated team and you also have community stuff that can create a lot of confusion and people not understanding who is actually responsible for what.”
⚡DevOps should be seen as a value driver, not a cost center. Changing this mindset starts with building strong relationships with the people who rely on DevOps the most, the product-facing engineers who directly impact the company’s revenue. As Tom explains, “I think it’s really important to maintain a good relationship with your customers. And those customers are the product-facing engineers, the people who are building the stuff that’s generating the revenue. If they feel like your presence is a benefit rather than a hindrance, they’re going to go to bat for you. And if you can point to any evidence that basically says that our being here is making everyone else more productive and more effective, then that’s going to kind of help smooth that broken line to revenue.“
Episode Highlights
Is your CI/CD pipeline quietly heading for disaster?
When CI/CD pipelines start slowing teams down instead of speeding them up, it’s usually not sudden; it’s a slow buildup of fragile processes and hidden complexity. Tom breaks down the subtle red flags that signal your deployment system is about to buckle under pressure,
“It’s a good question because I think these are the sorts of things that do sneak up on you pretty quickly. A lot of the time, you won’t realize that your pipelines aren’t really going to scale until you have to scale them, and it just doesn’t work, and then you have to spend a ton of time working on it. I think that some of the key indicators from my experience have been where you’ve got a bunch of environments, and they’re all explicitly manually referenced in your configuration, if you are running off of templates that you haven’t updated in a while, if your teams are frequently having to make very bespoke changes.”
One size doesn’t fit all in DevOps tooling.
As engineering teams grow, so do the differences in how developers work. Tom recommends focusing on building for the majority while still empowering power users with the flexibility they need. He explains,
“I think that a big misconception is that everyone needs the same kind of tools. If you’ve got a team that’s of any size, you’re going to have people with wildly different preferences, wildly different levels of experience, and a very different approach to the day-to-day. This manifested for me in that any time I was suggesting a new tool, suggesting a new feature or something like that for internal tools, you would have very senior members of the team complaining that it didn’t do this very specific thing. That I’d have to go back to them and say, well, you are the only person that ever does this. I am happy to create an escape hatch so that you can do this yourself. I’m not going to lock this down so you don’t have access to the underlying thing that you, as a very skilled person needs. But there’s 80% of the engineering team who just want something simple where they can do the same thing every day.”
Use feature flags intentionally.
Feature flags are a powerful way to manage releases and experiments, but if overused, they can create complexity and technical debt. Tom highlights the hidden risks,
“Where I think feature flags can be a hindrance is if you overuse them, you’ve got a lot of logic in your application that is purely branching around feature flags, and you have to keep track of all of these feature flags. And then you inevitably get, and as we were talking about people wanting to get rid of tech debt, get rid of legacy, you’ll get the person who’s like, ‘We need to clean up these feature flags.’ So then you have another big project to clean up the old feature flags. And that can cause a huge amount of slowdown, it can confuse people when they’re trying to get used to the codebase. I don’t think that feature flags are a bad thing, but I think you have to be very careful about how you apply them, and you need to have a plan and sort of a policy around how they should be used and when it’s appropriate to use them.”