TechPod Talks: Episode 5 Recap

How Engineering Leaders Balance Operational Excellence, Team Focus, and the AI-Native Future of Code: Lessons Learned from Meir Wasserman

Engineering leaders rarely talk openly about operational work today. The tickets, the firefighting, the toil that keeps the lights on, none of it is fun, but all of it matters as much as the platform work that recruits people in the first place lest it consume the team and the people who came to build start leaving.

TechPod Talks' most recent guest has spent more than a decade finding the balance between operational discipline and forward velocity in some of the most demanding environments in tech and gaming.

Meet Our Guest

In Episode 5 of TechPod Talks, EverOps' CEO Stephen Koza sits down with Meir Wasserman, Head of Engineering at 2K Technology, the technology arm of the publisher behind some of the biggest names in gaming today. 

Meir has spent his entire career in the games industry, starting as a software engineer building console football titles at Electronic Arts. He then spent years at EA Sports before moving to Amazon Games, where, over roughly four years, he led efforts to raise the bar for operational excellence across more than a dozen teams. 

Today at 2K, he leads engineering for the company's technology organization, which supports the studios producing AAA titles at scale. He writes regularly at meir.blog and speaks at industry events, including a recent appearance at the Pragma Online Services Summit, where he offered insights on AI and talent in games engineering.

Games as an industry have been bigger than music and movies combined for decades, a scale point Meir noted in passing and one most leaders outside the space underestimate. The technical problems get progressively harder as the audience grows, but that progression is the through line of his career, which he explores in detail in this episode. 

Episode 5: Key Takeaways

• A practical heuristic for deciding which operational debt to fix and which to acknowledge and move past
• Why most technical problems are really people problems, and what changes when you accept that
• The N-on-one structure that replaces unscalable skip-level one-on-ones once an organization grows past five to ten reports
• Why creating urgency is a defining leadership responsibility, and why most engineering leaders learn it the hard way
• The mindset shift from using AI to generate code faster to engineering for a world where humans never look at code at all
• A clear framework for evaluating AI investment when the economics are tilted in the customer's favor and likely to change

If you're an engineering leader or founder balancing platform debt against feature velocity, or trying to think clearly about where AI fits in a real production environment, this conversation is for you.

Most Technical Problems Are People Problems

Driving change in an organization is hard, but not because the change itself is hard to identify. Fresh eyes can spot the problem quickly, but the real work is everything that happens after the diagnosis.

Meir's core insight is that the problems technical leaders solve are almost always people problems. He's careful with his language, making it clear that people's problems do not make them bad people. 

“It's not like a person behaving badly. It's like just dealing with the kind of inertia and of human nature and the desire to stay the course more than to make a drastic change. So, you know, the first step is like identifying problems.”

The job of driving change starts with identifying the problem and then moves immediately into forming relationships, socializing the issue, and translating deep technical complexity into language that non-technical stakeholders can absorb without losing accuracy or urgency. Only once that charter exists can execution begin, and execution carries its own set of problems on top of the human ones.

Stephen affirmed this and named it the way most operators do by stating, “One of the things I find myself saying sometimes is most technical problems don't have a whole lot to do with the technology. They're more so people problems.”

In this case, he means they are more about process, organization, structure, and how people use the technology. Meir agreed and added that this work never ends. He did it that day, he did it the week before, and he'll do it the next day. But as a leader and a technical leader, you have to find a way through anyway and get people on board.

A Heuristic for Operational Debt

Engineering teams face two infinite backlogs. Operational work and customer-facing features. But a leader who picks neither defaults loses the team, whereas a leader who picks only one starves the other.

Meir's heuristic provides a clear test of which operational items deserve attention. Fix the ones that can be tied to demonstrable customer impact, either an outage that has already happened or a slowdown to innovation that can be quantified. Acknowledge the rest as “paper cuts” and keep moving on to customer value. This framework does two things at once:

1. It gives engineers feeling the pain a clear path to advocacy. 
2. It gives leaders cover to deflect the long tail of cosmetic toil that would otherwise consume the team's capacity.

Spotting the moment a team is sliding too far toward toil takes a mix of data and instinct. The data side is the delivery pace relative to prior experience, whereas the instinct side is anecdotes from senior ICs, who can usually tell a leader which systems are constantly breaking long before that pattern appears in any dashboard. The advice flies in the face of "don't let engineers complain about everything," and that tension is the point. The job requires high judgment to pick through the signal, weigh it against the data, and trust that the longer you spend in the work, the cleaner the pattern recognition gets.

AI agents are starting to change the math here, Meir noted. The ability to give an agent an operational problem and have it solved autonomously may mean the bar for "worth fixing" drops substantially over the next few cycles.

“We talk about it right now in terms of we can build more features and deliver more value, but we can also fix more operational debt, and that's pretty exciting and cool. We are not there yet, but I am very excited to start leveraging AI agents for that.”

For now, that future is still arriving. The heuristic holds.

The Scaling Problem No One Addresses

A new manager running five to ten people can know everything happening on the team. That mental model breaks somewhere between managing one team and managing several, and the transition occurs without notice.

There is no moment where a leader feels released from the expectation of knowing every detail. Meir states: 

"There's not one moment in time where it's like, ah-ha, I am free from that burden." 

The risk for leaders at that inflection is staying compelled to know every detail when the org has grown past the point where that's possible. Two failure modes follow. Either the leader recognizes the shift and builds new mechanisms, or they keep trying to operate at the previous depth and become ineffective at the current scope. Meir built three mechanisms to handle it:

1. Constant broad knowledge fed up from across the organization. 
2. The trust and norms to dive deep into any part of it without disrupting the people closest to the work. 
3. Comfort translating that broader picture into non-technical language while going deep on a topic he hasn't personally explored end-to-end.

The most useful concrete tool is what he calls the “N-on-one.” Early in his tenure as manager-of-managers, he held monthly one-on-ones with every senior engineer in the org. The volume eventually became impossible, but canceling them entirely would have cost him something real. "I'm missing a key element of organizational leadership, which is actually being connected to the people in the organization, not just your directs." 

The replacement is a single monthly session with each direct and their directs together, the manager not in the room. Three people, eight people, whatever the cluster size. When a deep-dive conversation does need to happen later, the relationship already exists, and nothing about the interaction feels threatening.

Stephen pointed to Jensen Huang and Mark Zuckerberg as counterexamples, and both have spoken openly about not running one-on-ones at their scale. Meir's take was straightforward.  

"When I hear 'I don't do one-on-ones,' I don't think that's wrong. I just think, okay, that's a different way to lead." 

For him, at the scale at which he operates, they still deliver too much value to drop.

A Leader Is Required to Create Urgency

Most leadership lessons get learned the hard way, when the stove gets touched, so to speak. Blog posts and books carry the information forward, but the lesson lands only after the burn.

Meir's hardest-learned lesson is one that most engineering leadership advice skips. Organizational inertia is constant, and the leader is the source of urgency. 

The patterns are familiar to anyone who has worked in a corporate environment. A meeting gets set. A Slack goes unanswered. The polite human move is to wait a few days before following up. The move that actually advances the priority is to check back the next day, advocate for the work, and make sure the friction does not become a multi-day delay. Good leaders recognize the dynamic, accept the responsibility, and use it carefully. Not everything is urgent, and manufacturing fake deadlines on lower-priority work erodes the tool.

"A leader is required to create urgency. And I feel like no one told me that."

Top priorities only move as fast as the leader chooses to move them.

What Strong Leaders Do With Complexity

The leaders who travel furthest can take a complex problem and boil it down to something simple. Not oversimplified. Simple in a way that the audience can deeply feel and understand. Meir watched several leaders early in his career do this well and recognized it as a skill worth building deliberately.

The level-up is pattern matching across human, technical, and organizational problems, then framing the underlying pattern in language that gets people behind solving it. That capacity is what scales leadership beyond the team-of-five mode, where the leader is the deepest expert on every detail. 

Stephen described an identical lesson from his own early career. Building a new business inside a larger company required selling product teams on what to build, marketing teams on what to support, and stakeholders across the company on a shared direction. Vision-casting carried that effort more than anything else.

Meir pointed to educational content on difficult subjects as a useful parallel. The presenters who resonate aren't the ones who know the most. They're the ones willing to shoulder the full complexity so the audience doesn't have to. That labor is invisible to the listener, and that's exactly the point. People rally around content that lets them feel they understand the problem they are being asked to solve.

From Skeptical to Pragmatic on AI

In November 2022, Meir was skeptical of generative AI, though not about whether it would change the world. The skepticism focused on whether society would adapt without damage and whether two specific harms would compound: a hollowed-out junior pipeline and a population losing the ability to reason about systems they no longer touch directly.

The junior concern has not played out as he initially feared. New engineers coming out of school are using AI fluently and showing the same capacity for critical thinking as previous cohorts. The gaps are the same gaps every junior has had, and the training mental models still work. The deeper concern is whether obfuscating layers of abstraction eventually erodes the population's ability to debug when systems fail, and this question remains open. 

AI sits atop decades of accumulated abstraction in software, and the underlying reasoning skills can advance if leaders invest deliberately in them. What changed Meir's posture is what he watched teams actually do with AI. From this, two adoption patterns emerged. Some people incorporated AI into existing workflows, the slower path. Others asked a different question: what would I do if I never had a current workflow? Those teams move faster and produce more interesting outcomes, and the framing shift maps directly to where AI in software engineering is heading.

"What if I never have to look at code again? AI generates it, AI reviews it, AI tests it, and if it all passes, I feel good about that outcome, and I never once looked at it."

The mental model is the work. Upfront thinking matters more than before, because the cost of imprecise prompting compounds across token usage and wasted iterations. The job is changing from "write better code" to "create the conditions for a system to produce reliable code without human inspection."

Vibe Coding, Production Code, and the Gap Between

Conversational coding gets a lot of attention right now. The shorthand for it is vibe coding. The output ships with little friction in the right environments, and not at all in others.

Meir's view is direct. Vibe coding alone falls short of producing production-grade code at enterprise scale. The systems aren't structured for it yet, and the rigor required to scale, secure, and operate the output exceeds what conversational prompting produces today. 

Closing the gap is the active problem space for engineering leaders trying to incorporate AI into real delivery. The economics push in the same direction. Models charge for tokens. Rapid conversational iteration is expensive. A few well-thought-out prompts that produce larger directed changes trade upfront thinking for downstream cost and usually win on aggregate speed. The work is still upstream judgment, now compressed into the prompt itself.

"People say vibe coding is kind of shorthand for conversational coding. That's not generally sufficient to create production code. What's the bridge between vibe coding and enterprise-level code? I think there are answers out there. We're kind of trying some out now."

The bridge is the live question Meir is most focused on over the next 12 months, and the answer will shape what shipping software looks like at scale by the end of that period.

Evaluating AI Investment When the Economics Are Subsidized

The current AI moment sits in a try-everything window. The economics for frontier model companies are not yet positive, meaning the prices customers see today are subsidized. Investment frameworks become more important the moment that changes.

For now, the practical guidance is to experiment broadly and notice what produces real value rather than interesting demos. The longer game requires more rigor. As Meir put it:

"If I put a lot of thought up front and then direct my AI to make a bunch of well-thought-out changes…it's still faster than it would have been before if I had just manually done it." 

Upfront thinking in how prompts are constructed reduces token waste, and the discipline compounds as pricing models shift toward true consumption or value-derived models. SaaS companies have a similar history. Customers have historically resisted paying for experimental use on data platforms, even when usage-based pricing made sense in principle. AI-native pricing models, such as Sierra's customer service pricing or Palantir's value-based approach, hint at the shape of what's coming. Engineering leaders who develop the discipline of rigorous, intentional AI use now will be positioned to operate efficiently when prices climb.

How to Apply These Insights Today

Concrete actions engineering leaders can take after reading or listening to this week’s episode:

1. Codify your operational debt heuristic: Write down the bar your team uses to decide which operational issues to fix and which to acknowledge. Tie it to demonstrable customer impact or measurable slowdown to innovation. Share it with the team so they know how to advocate for fixes that meet the bar.
2. Replace unscalable skip-levels with N-on-ones: If you manage managers and want to stay connected to the layer beneath, schedule monthly group sessions with each manager's direct reports as a cluster. Three to eight people, manager not in the room, peer format. The relationships scale with the organization.
3. Audit where you are or aren't creating urgency: Identify the top two or three priorities you most want to advance. Pressure-test whether your follow-up cadence matches the priority you've assigned. If a Slack message to a stakeholder has been sitting for two days without a reply, the urgency is yours to create.
4. Run an AI experiment with explicit upstream rigor: Pick one engineering workflow and rerun it with significantly more upfront thinking before any AI prompting begins. Compare the aggregate speed and quality against your typical conversational approach. The economics push every team toward this discipline within twelve months.
5. Engineer for the post-code workflow: Ask your senior engineers what they would design if they never had to look at generated code again. The answer reveals what your testing, observability, and review systems actually need to become for AI-native delivery to work.

Keeping Up with TechPod Talks

TechPod Talks is going to keep things rolling. Subscribe today so you don't miss what's coming next. Every episode features a practitioner who has built and operated at scale, sharing what works in present-day engineering leadership, platform engineering, cloud, AI adoption, and modern technical operations.

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/ 

Reading and resources mentioned:

• Meir's blog at meir.blog: Where Meir writes monthly about engineering leadership lessons he's actively learning. Posts get shared internally first, then to the broader audience that has found the writing over time.
• Frank Slootman, Amp It Up: Mentioned by Stephen as a useful read on operating with urgency, written by the former Snowflake CEO. Worth reading specifically for engineering leaders who recognize they may be the bottleneck on their own top priorities.
• Google's NotebookLM: Mentioned by Stephen as an effective tool for distilling complex source material into accessible summaries, slide decks, and AI-generated audio briefings. Useful for engineering leaders who need to translate technical depth into language a broader audience can absorb.

Connect with our guest Meir Wasserman on LinkedIn today:

https://www.linkedin.com/in/meir-wasserman/ 

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 navigating engineering scale, operational excellence, 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 5 cover?

Episode 5 features a candid conversation with Meir Wasserman on driving change through organizational inertia, a practical heuristic for operational debt, the N-on-one structure for staying connected as orgs scale, why creating urgency is a defining leadership responsibility, the mindset shift toward AI-native engineering workflows, and the gap between vibe coding and production-grade code.

Who is Meir Wasserman?

Meir Wasserman is the Head of Engineering at 2K Technology, the technology arm of 2K Games. He has spent his entire career in the games industry, with previous roles at Electronic Arts on EA Sports titles and at Amazon Games, where he led operational excellence work across more than a dozen teams over roughly four years. He also writes his insights at meir.blog and speaks at industry events.

How often are new episodes released?

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 or through the EverOps website, which includes a guest request form for speakers interested in joining future episodes.

How does this episode connect to EverOps' work?

EverOps helps engineering leaders navigate the same questions Meir covers in this episode, including operational excellence programs, AI adoption strategies, and the structural work that enables engineering teams to ship faster without compounding technical debt. Services like AI Opportunity Assessment, Cost Optimization, and embedded operations map directly to the work Meir and his teams have run across multiple companies in the gaming industry.