TechPod Talks: Episode 1 Recap

Why the Best Platform Engineering Leaders Think Like MBAs: Lessons Learned from Mark Sass

What actually changes when engineering leaders start thinking like business owners? For most teams, cloud costs, team performance, and long-term planning are treated as separate problems. In reality, they’re actually tightly connected, and solving them requires a different way of thinking about ownership, accountability, and value creation.

Meet Our Guest

In the debut episode of TechPod Talks, EverOps’ CEO Stephen Koza sits down with Mark Sass, a platform engineering leader who has spent his career transitioning between lean startups and some of today's largest enterprises.

Mark is now the Senior Director of Platform Engineering at SolarWinds, where he leads engineering teams through significant company-wide transformations. He has built and scaled infrastructure at some of the most recognized names in the industry, including Home Depot, Meta, Indeed, and 2K Games, across retail, social, gaming, and tech. Mark also holds an MBA from Texas A&M, a degree he pursued deliberately after hitting a glass ceiling without one, and chose management over computer science because he recognized early that the skill gaps limiting his career weren't technical. That combination of deep infrastructure experience and business fluency is the through line of everything he shares in this episode.

Episode 1: Key Takeaways 

• How to push cloud cost ownership to the teams that control the spend and make savings stick long term
• The two metrics (utilization and application saturation) that make cost conversations data-driven
• Why an MBA changed how Mark talks to finance, product, and executives within the companies he works with
• How servant leadership works in platform engineering, including when you still need to make the final call
• Why communicating the business context behind the work is one of the most underleveraged tools in an engineering leader's playbook
• A simple framework for mapping your next 10 years in engineering leadership

So, if you or your team have ever watched your cloud bill climb back to where it started six months after an optimization push, Mark has a very specific explanation for why that happens and what to do to prevent it from happening again. Every insight in this episode comes from an expert who has actually lived through real problems across some of the most demanding environments in the industry to date.

Cloud Cost Optimization Requires Distributed Ownership

Sustainable cloud cost management depends on more than one team running periodic audits. It requires the right financial vocabulary, a strong tagging strategy, and budget ownership that lives with the people who actually control the spend.

Mark's first move at any new company is to understand how the finance team categorizes cloud spend. Learning the COGS vs. R&D split, how forecasting works, and what the expected numbers are gives engineering leaders the vocabulary to have real conversations with the business side.

At 2K Games, Mark was handed ownership of the cloud and immediately went to work, identifying untagged resources, on-demand spend that should have been on savings plans, and over-provisioned infrastructure without demand-curve analysis. The savings were real, and they came quickly. Then six months later, the bill was right back where it started.

The reason was straightforward once he saw it. The people spending the money weren't on his teams. They were on other teams, making infrastructure decisions he had no direct line to. So instead of continuing to chase the bill himself, Mark pushed budgets down to the service teams running the spend. He gave them visibility into what they were consuming and made it their numbers to own. If the roll-up stays in bounds, nobody intervenes. If it doesn't, the conversation starts at the team level with the people closest to the decisions.

"I realized I was doing it wrong to a certain extent…The people who were spending the money weren't my teams, they were other teams. So I started pushing budgets onto the teams for the services they run. Now they have a budget that's been established, and it's their responsibility." 

That model only works with a real tagging strategy underneath it. Without proper tags, you can't attribute costs, you can't build per-team budgets, and you can't hold anyone accountable. Mark notes that retroactive tagging is painful because the older the company, the harder it gets, and that resources without a clean owner often end up in a catch-all bucket that gets revisited later. Those are exactly the areas where organizations quietly lose 5–10% of their bill. He considers a strong tagging foundation non-negotiable regardless of how long it takes to get there.

Two Metrics That Make Cloud Cost Conversations Actionable

Data removes the politics from cost optimization, and Mark emphasizes two specific metrics to give teams clear visibility into their own efficiency, empowering them to make informed decisions about their infrastructure spend.

1. Cluster utilization rate: This metric measures the percentage of your provisioned Kubernetes capacity that you're actually using. If your target is 80% and you're sitting at 60%, you're wasting 20% of your spend. That's a concrete number teams can act on now.
2. Application saturation: This measures how much of your provisioned capacity a service actually consumes. If you've provisioned 1,000 TPS and you're using 300, you're at 30%. Mark surfaces the data and lets the product team decide where they want to be. A 30% saturation rate might be exactly right for a service that needs significant headroom.

"When I surface these metrics, it's not my job to say this is good or bad. It's the product team's decision on where they want to be."

The platform engineering team's role in this model is to provide the instruments, not to issue verdicts. When the data is visible, and the decision rests with the team closest to the service, cost conversations stop being a negotiation between departments and become a function of the work itself.

The MBA Advantage in Engineering Leadership

Business fluency is one of the most valuable and underappreciated skills a technical leader can develop today. Mark's own journey to an MBA illustrates why, and his advice for engineers who want similar benefits offers a practical path forward.

Early in his career, Mark applied for a role at EA (Electronic Arts) and was passed over, not because of his technical ability, but because he didn't have a degree. That experience revealed a glass ceiling he hadn't initially known existed. He started by earning an undergraduate degree at an online university while working at Dell, deliberately choosing to study management rather than computer science. The technical foundation was already there. What he needed was a different lens entirely.

The MBA delivered it. Mark came out of the program with the ability to articulate where value comes from when requesting a budget, to frame ROI, to explain how product marketing works, and to position infrastructure as a product with real customers and measurable outcomes, rather than as a service that engineering delivers in isolation.

"The MBA really opened that lens up to me. It started making me think about things like a return on investment for what we wanted to do, and allowed me to understand how product marketing works."

For engineers who want business fluency without grad school, Mark's advice is this: start with the reading list. Books like The Five Dysfunctions of a Team, The Five Levels of Leadership, and Extreme Ownership help build leadership and business thinking muscles. Beyond reading, Mark encourages others to intentionally define a leadership ethos rather than defaulting to whatever felt wrong when they were an IC. Then, go have the conversations with finance peers, product peers, marketing peers, not to simply network, but to genuinely understand how they see the business. That perspective is what the MBA formalized for Mark, and it's accessible without one.

The 10-Year Career Plan That Gives Engineers Real Direction

Career planning in engineering is often vague. However, Mark shared a framework that makes it concrete, and he uses it with every direct report he gives, one he arrived at through his own career rather than a business school curriculum.

The prompt came from a mentor at Dell, an executive director who pulled Mark aside early in his tenure and asked him a simple question: What do you want to do with your life? Mark was already in his early 40s at the time and didn't have a real answer. That conversation changed how he thought about his own trajectory and eventually became the framework he now shares with everyone who reports to him.

The mechanics are straightforward. Decide where you want to be in 10 years, then work backward. If the goal is to be Director of Software Engineering in 10 years, where do you need to be in five? In three? In one? This stair-step forces realistic annual milestones and surfaces a critical decision: Do you want to stay on the technical IC track toward principal engineer, or move into management?

Mark is direct that companies should offer both paths with equal growth potential. Too many organizations funnel engineers into management as the only route to career advancement, and he considers that a mistake. For those who do choose leadership, the required skill set expands significantly. Learning how to have hard conversations, how to motivate people, and how to explain the business context behind the work all become essential.

"What got you promoted, what got you into that engineering leadership role, is not what makes you successful there. That's the big misconception a lot of people have."

Mark's own career arc illustrates exactly this, which began with a 10-year plan and C-suite ambitions. As he progressed, those goals evolved. Today, as a Senior Director, he's content to focus on enabling teams and solving complex problems. He encourages engineers to revisit their plans regularly, because what you value at 30 may look very different at 45.

Fixing On-Call Morale and Addressing Underperformance

Finally, Mark explains that team health comes down to two responsibilities that pull in opposite directions: reducing the friction that quietly drains people and maintaining the standards that keep everyone accountable. Mark shared real examples of both from his time at SolarWinds.

On the friction side, on-call shifts at SolarWinds were generating hundreds of alerts per rotation. Most were noise, but that didn't make them harmless. Engineers were tethered to their laptops throughout every shift, and morale suffered as a result. Mark applied the same blameless postmortem approach to the morale problem that engineering teams typically reserve for outages, asking why repeatedly until he reached the actual root causes driving the alert volume. The problem wasn't the engineers, though. It was the system they were working inside.

"It's not what you demand from your team. It's more about what you accept."

On the accountability side, Mark is equally direct. When an underperformer coasts while the people around them put in full effort, the damage isn't confined to that one individual, and it often spreads to the entire team's trust in leadership. Ignoring it is itself a decision, and the team notices.

His framework for evaluating performance issues comes down to two questions: 

1. Does this person have the motivation (will) to do the job? 
2. Do they have the capability (skill)? 

He has found that the answers to these determine whether the path forward involves coaching, training, or a harder conversation, while also shaping how he thinks about the team around that person and what support or recalibration they might need as a result.

How to Apply These Insights Today 

Here's a practical playbook based on what Mark shared, with steps you can start this quarter:

1. Audit your tagging strategy this week: If you don't have one, start with a simple ownership tag (team, service, environment) and enforce it on all new resources. Retroactive tagging is painful but foundational, and everything else in cost optimization depends on it.
   
   
2. Push budgets to service teams: Work with finance to divide your cloud spend into per-team or per-service budgets. Give teams visibility through dashboards and roll-ups. Let them own the number.
   
   
3. Surface utilization and saturation metrics: Stand up two dashboards: cluster utilization (provisioned vs. used infrastructure) and application saturation (provisioned capacity vs. actual demand). Share them and let product and engineering teams decide their own targets.
   
   
4. Map your 10-year career plan: Block 30 minutes, decide where you want to be in a decade, and work backward to a 1-year milestone. Share it with your manager or mentor. If you manage people, ask your direct reports to do the same.
   
   
5. Identify the most influential person on your team: Invest in that relationship first. If you're new to a leadership role, this is your highest-leverage move in the first 90 days.

Keep Up with TechPod Talks

If you found this episode useful, we have good news because TechPod Talks is just getting started! We highly encourage you to subscribe now so you don't miss what's coming next. Every episode features a practitioner who's actually in the arena, sharing what works in platform engineering, cloud, DevOps, and technical leadership today.

Subscribe to any of these to tune in: 

Apple Podcasts | Spotify | YouTube | EverOps Podcast Page

Follow for additional clips, behind-the-scenes content, and future episode announcements:

• https://www.linkedin.com/in/stephenkoza/ 
• https://www.linkedin.com/company/everops/   

Books and resources mentioned:

• Extreme Ownership by Jocko Willink and Leif Babin: Leadership principles from Navy SEALs, applied to engineering teams
• The Five Dysfunctions of a Team by Patrick Lencioni: Diagnosing and fixing team dysfunction
• The Five Levels of Leadership by John C. Maxwell: Understanding leadership as a progression

Connect with our guest Mark on LinkedIn today: https://www.linkedin.com/in/mark-sass/ 

Frequently Asked Questions

What is TechPod Talks? 

TechPod Talks is a podcast hosted by EverOps CEO Stephen Koza, featuring candid conversations with technology leaders, engineers, and operators. Each episode explores how real teams build, scale, and operate modern systems, with a focus on practical takeaways.

Who is this podcast for? 

The podcast is designed for CTOs, engineering managers, DevOps and SRE professionals, platform engineers, and technical operators, especially those at companies navigating cloud optimization, modernization, and AI adoption.

Where can I listen to TechPod Talks? 

TechPod Talks is available on Apple Podcasts, Spotify, YouTube, and the EverOps website. Episodes are released in both audio and video formats.

What topics does Episode 1 cover? 

Episode 1 features a candid conversation with Mark Sass, who covers popular topics for todays organizations, such as cloud cost optimization (including budget ownership and tagging strategies), two key infrastructure metrics, the value of an MBA in engineering leadership, the 10-year career planning framework, servant leadership, and how to fix on-call morale.

Who is Mark Sass? 

Mark Sass is Senior Director of Platform Engineering at SolarWinds. He has led engineering teams at Home Depot, Meta, Indeed, and 2K Games, and holds an MBA from Texas A&M.

How often are new episodes released? 

After launch week, TechPod Talks follows a consistent every two-week release cadence. Follow EverOps and Stephen Koza on LinkedIn or subscribe on your preferred podcast platform to stay updated on new episodes.

Can I suggest topics or be a guest on the podcast? 

Yes. You can share topic suggestions by reaching out on LinkedIn and on the EverOps website, which includes a guest request form for speakers interested in joining future episodes.