A DevOps Engineer's Day: How Juan Tejeria Keeps 100-Plus Developers Shipping at Scale

Some mornings, Juan Tejeria's workday starts before he's even out of bed. A global client means global incident windows, and when a flag goes up overnight, a Lead DevOps Engineer in Uruguay doesn't wait for business hours.

Most mornings, though, the first hour belongs to his two-year-old son and his wife — breakfast, conversation and a cup of maté before the laptop opens. That rhythm matters to Tejeria, and it shapes the discipline he brings to everything that follows. Juan Tejeria is a Lead DevOps Engineer at X-Team, and in this story he walks through what a day in that role actually looks like, which technologies anchor his stack and what a year of building infrastructure for hundreds of developers taught him about process, scale and the difference between a startup and a multinational client.

Maté First, Then Jira

When a regular day begins, Tejeria prepares his maté — a South American drink with more caffeine than tea but less than coffee — and opens Jira before anything else. The scan is deliberate: urgent flags, anomalies that surfaced during overnight shifts, anything that might need attention before the development teams on the other side of the world spin up for the day.

The broader context is Beachbody's digital transformation, a migration initiative that had been underway for roughly 18 months at the time of this interview. Tejeria serves as Technical Lead on the DevOps team there, and the mandate is straightforward even when the execution isn't: migrate each piece of infrastructure toward what the team believes it should look like for 2020 and beyond.

From that foundation, the day rarely looks the same twice. "As a DevOps engineer, my day-to-day changes often, because we always try to keep moving forward and get things done," he says. That might mean designing and implementing a full CI/CD pipeline for a new service. It might mean building proofs of concept with new AWS features to test whether they complement the client's existing stack. It always means being available when developers need support — automation for their setups, faster deployments, cleaner environments.

The Stack: AWS, Kubernetes and Python

Tejeria's core toolkit starts with AWS. The appeal, he says, is its breadth and documentation. "I can do anything I need with it. It's well-documented and there are plenty of use cases that make it easy to adopt and implement new features or services."

The DevOps team's primary AWS service is EKS, Amazon's managed Kubernetes offering. Kubernetes lets the team define cloud-native applications and deploy them into a cluster quickly — a capability that pays dividends when the pipeline is supporting dozens of developers simultaneously.

Alongside EKS, the team leans heavily on Serverless to automate and define services and resources. It is the framework that, as Tejeria would discover during one of the year's biggest initiatives, could be pushed to spin up and tear down infrastructure at a scale most engineers don't encounter in a single project.

For scripting, he reaches for Python. "It helps me automate and process certain tasks," he says. Bash handles some jobs, but Python is the first tool he tries — a preference that reflects how central automation thinking is to the role. When you're responsible for the velocity of more than a hundred developers, the scripts that save 10 minutes each day compound fast.

500 Resources, 4 Days and a Kinesis Bug That Took Both

The year's hardest challenge arrived in April, tied to a major initiative at Beachbody. For any large release, the DevOps team's goal is to build full infrastructure for every branch a developer creates — so that each one is independently testable as a live service.

In this case, that meant a Serverless deployment generating over 500 AWS resources: more than a hundred Lambda functions, plus the SQS queues, S3 events and databases required to tie it all together. The constraint was that 30-plus developers needed their active branches available as services simultaneously, each one accessible to an independent QA team — all while a full CI/CD pipeline with automated tests kept running alongside them.

"It was challenging to set everything up in such a way that 30+ developers could have their active branch available as a service while giving different QA teams the ability to test each independent story," Tejeria says. The solution combined GitHub events, TravisCI for builds, Harness for continuous delivery and Serverless as the unifying framework. The team built pipelines with unique domains for each branch and automated the teardown once a developer finished a story — so infrastructure never accumulated. They also designed multiple CloudFormation stacks for the dependencies they kept outside Serverless, such as databases and S3 buckets. Data migrations ran from MySQL RDS instances to DynamoDB to move photos and files from the old infrastructure to the new.

Then, separately, a quieter bug nearly caused lasting damage. One of Beachbody's projects consumed from a Kinesis stream that held data used in stakeholder BI reports. The stream stopped working. Tejeria hadn't worked with Kinesis before. His first move, once he understood the service, was to extend the data retention policy so the team would have enough time to find the fix without losing records. That decision proved critical — it took four days to catch up with the data. The root cause was a combination of memory constraints on older instances, misconfigured consumer metrics and resharding on the stream itself: the pipeline had been sending far more data than when it was first set up years earlier, and it had quietly hit its limits.

The year's lessons distilled to two things. The first was technical: Serverless at that scale — spinning up and defining more than 500 AWS resources at once via the API, including all the events and infrastructure dependencies — was new territory, and navigating it built fluency he hadn't had before. The second was organizational. "Having to support more than a hundred developers with different projects and requirements made me realize how important it is to have clear processes that you can replicate and that people can adopt easily," he says.

Before X-Team, most of Tejeria's experience came from startups where he built projects from scratch with a small team. Supporting a large multinational client demanded a different mode of thinking: not just solving the problem in front of you, but automating the solve so the next developer who hits the same wall doesn't need to wait for you.

Ready to build work you're proud of? Apply for an open role at X-Team.