A welcome from the host, David Yee.

Few people have better visibility into what is actually happening across the industry right now than Gergely Orosz. The author behind The Pragmatic Engineer – the No. 1 technology newsletter on Substack, with over 1.1 million subscribers – spends his time talking to engineers and leaders inside Big Tech and high-growth startups.

In this talk, Gergely will give his candid read on where software and AI engineering are heading: how the landscape is shifting, what it means for teams and careers, and what the signals actually suggest.

Camille Fournier has spent her career defining what great engineering leadership looks like. Nearly ten years after she published the seminal book The Manager’s Path, she’s now turning her attention to the question most managers are quietly wrestling with: what does AI actually change about the job?

In this talk, Camille cuts through the noise to look at where things are genuinely shifting, which skills stay non-negotiable regardless of the tooling around you, and how to tell the difference between changes worth paying attention to and the ones that probably aren’t.

The cost of software has always been about the cost of its maintenance. Until recently, code was so time-consuming and difficult to produce and maintain that all our research was focused on making code easier to understand, and all our practices and rituals were centered around a slow, steady drip of small changes to a baseline assumed to be good–the durable code model. That model has been upended in the past few months, since AI can now generate code approximately as good as that of the median software engineer. Does this mean all software can and should be replaced by disposable code? What lessons should we take from the immutable infrastructure revolution of the last decade, and how should they guide us today?

AI isn’t just making engineers faster—it’s shifting the bottlenecks upstream.

As the cost of implementation nears zero, the challenge lies in deciding what to build, how it all fits together, and how to trust what you ship.

The entire playbook as we know it is being actively rewritten as the software development lifecycle collapses. Planning and communication take on new weight. Engineers move closer to design. Expertise shifts from writing code to shaping intent and maintaining system integrity at scale.

This talk explores the second- and third-order effects of the AI adoption curve, and how teams at Figma are experimenting in real time, making decisions, and building products for the next chapter of the software development playbook.

The higher you climb, the quieter the feedback loop becomes. At the Director+ level, your technical output is no longer your currency—your brand, your influence, and your ability to reinvent yourself are. In an era of market volatility and GenAI disruption, coasting is the fastest way to become obsolete.

This session is a high-impact workshop on radical self-reclamation. We will explore:

• The Honest Audit: How to conduct a ruthless self-assessment when your directs and peers are too polite (or too scared) to tell you the truth.
• Strategic Connection: Moving beyond “networking” to building a cabinet of rivals and mentors who challenge your status quo.
• Executive Presence 2.0: Upleveling your personal brand and using GenAI as a force multiplier for your strategic thinking, not just your task list.
• The Coaching Mindset: How to seek out and leverage high-level coaching to navigate the psychological shifts of senior leadership.
• The Bottom Line: Don’t wait for the organization to grow you. Take command of your own leadership roadmap.

For many engineers, the traditional early-career path started with bug bashes and small fixes. In the new world of AI, that path isn’t as necessary or helpful to junior engineers. This talk reframes early-career skill development, in an era where AI can write a lot of code but still struggles with context, systems, and impact. We’ll explore three foundational capabilities engineers and leaders should intentionally cultivate: human-centered engineering (deeply understanding user problems and impact), systems thinking (owning how complex systems fit together across boundaries), and data modeling (designing and owning the data foundations of your product). Attendees will learn how to design work, coaching, and expectations so that engineers grow in the areas where humans provide enduring leverage over AI.

Technology is supposed to be the innovation engine of modern companies, but so often technical teams and business-oriented teams don’t speak each other’s language.

Engineering leaders end up sidelined and act as order-takers, instead of working hand in hand with other functions to come up with the best approach to the company’s greatest challenges.

This rarely a fundamental misalignment; it’s a translation problem. We just don’t speak each other’s language or focus on the same concerns.

What if we could incorporate the tool tools into our tool belts that help us understand and think like finance, operations, sales, and marketing leaders?

Emily will highlight the business fundamentals from her MBA program that have most helped her as an SVP of Engineering, helping audience members to recognize and engage with the business forces that invisibly shape our engineering work.

Key takeaways

• Time value of money: How to reason about interest rates and the time value of money and make smart business decisions in the post-ZIRP area
• Think like finance: how accounting and finance concerns invisibly shape our engineering practices, and how we can respond
• Negotiations: tested, ethical approaches to negotiating, for job offers, software contracts, and more
• The trust equation, and tips on building trust with cross-functional stakeholders you may not understand well

In the spring of 2002, Walter Murch, a three-time Oscar winner and the most respected film editor alive, got news he wasn’t expecting. He had just persuaded the producers of Cold Mountain to let him edit the film entirely on Apple’s Final Cut Pro, something no one had ever attempted on a major motion picture. Now Apple was telling him the software wasn’t up to the task, and they couldn’t support him if he proceeded.

Murch did it anyway. His team packed up a rack of off-the-shelf Macs, shipped them to the set in Romania, and built an editing system from scratch in a country where nobody could help them if it broke.

Murch bet his reputation on a $999 tool that not even its maker thought was ready. But that didn’t matter, because Murch was ready. The way he pulled this off is a pretty good blueprint for anyone looking to ride a wave of disruption instead of getting swept aside by it.

I was at a podium in front of 30+ engineers, lighting up about everything we were building. If you had asked me whether my team knew what was important, I would have said absolutely.

A week later, an engineer two levels down booked my office hours and told me something that changed how I lead: people don’t know what you care about.

That moment made me rethink how I led. People don’t build connection to their work from what you say at all-hands. They build it from where you spend your time, what you ask about, what you celebrate. And that proof decays with time.

You draw the line on Monday and it’s fading by end of the week.

But some leaders got this right. In the years that followed, I watched it happen inside my own organization: a director who ran a workshop his leads were skeptical about, and it endured long after the roadmap changed. A manager who brought partner teams in to present what they’d built, then connected it live: “You’re able to do that because we piped through this data.”

Meaning was translated at every level, continuously, not as a message but as a practice.

I also learned that meaning didn’t require a noble mission. One leader I interviewed described making build automation feel urgent through radical honesty about competition, bonuses, and a concrete challenge: their system supported 70 branches. Could they get to 200? They hit 230.

Years earlier, she had watched a different team sleep at their desks, not because anyone pushed them, but because the stakes had become impossible to ignore.

This talk is about how leaders make meaning real for their teams, not once, but every week. Through stories from 17 years leading engineering teams at Google and interviews with leaders across the industry.

Key takeaways

1. Most leaders overestimate how well their team understands what matters, saying it from the front of the room isn’t enough.
2. People build meaning from where you spend your time, what you ask about, and what you celebrate. That understanding decays faster than you think.
3. Meaning doesn’t require a noble mission. Leaders who find what’s real and make it visible can make build automation feel as urgent as a moonshot.
4. The connection between daily work and why it matters has to be translated at every level: a director, a senior manager, and a front-line manager each do different but similar work to close the gap.
5. Making meaning land isn’t a one-time message: it’s a practice leaders maintain or it fades. It takes gardening.

Education researchers have spent a century figuring out how to build environments where complex, unpredictable systems self-correct through structured feedback. Software engineers building AI agents are solving the exact same problem from scratch and ignoring all of it.

This talk bridges that gap. I’m a former classroom teacher turned AI engineer, and I’ll walk you through five pedagogical frameworks that map directly to eval design patterns for AI agents: backward design (define success criteria before you build), formative assessment (eval continuously, not just at the end), rubric design (multi-dimensional scoring instead of pass/fail), error analysis (categorize failure modes because same symptom doesn’t mean same cause), and differentiated feedback (the agent, the user, and the knowledge base each need their own signal channel).

What ties them together is back pressure: each framework is a way to capture signal from problems and route it to where it drives change. That’s what makes a system self-correcting instead of just self-reporting.

Most engineering teams building AI agents design the system first and bolt on evaluation after. I think that’s backwards. The eval system should come first because it defines what “correct” looks like, and once you have that, you’ve given the system the ability to feel its own failures and iterate on them.

I’ve applied this methodology to production RAG agents and AI hackathons alike. The core insight is simple: the best eval systems aren’t tests, they’re environments. And nobody knows more about designing those environments than teachers.

This talk gives engineering leaders a concrete framework for building AI systems that steer themselves through structured feedback, drawn from a discipline most of us left behind after graduation.

Key takeaways

• Backward design from education theory gives you a concrete methodology for eval-first AI architecture: define success criteria before building the system.
• Pass/fail evaluation destroys information; multi-dimensional rubric design from pedagogy produces the granular signal agents need to self-correct.
• Back pressure is the connecting principle: every pedagogical framework in this talk is a mechanism for capturing signal from problems and routing it upstream before those problems harden into production incidents.
• AI agent interactions have three participants (agent, user, knowledge base) and each needs its own feedback channel; most teams only instrument the agent.
• The eval system isn’t a test suite you bolt on at the end; it’s the steering wheel, and it should be the first thing you build.

Engineering managers often manage what they can see: 1-1s, tickets, code reviews. But the systems that actually determine your team’s effectiveness are invisible until you learn to visualize them.

This talk shares the visualization techniques I use to lead teams more effectively. A scatter plot exercise across multiple teams that revealed each had a different PR cycle time problem. Some cross-team reviews, some internal, some process misalignment. An investment report that showed support work was quietly consuming far more capacity than anyone realized, and how we reduced it. A value stream map that showed one team where their work was stuck in review, leading to changes that improved delivery within two weeks.

In each case, the picture told a story that opinions alone couldn’t. I’ll walk through each technique: what to look for, how to build the visual, and how to turn what you see into action.

These examples come from teams at startups and public companies, but the principle is the same: fix how work flows, not push people harder. I’ll also show how these visuals become tools for conversation: with your team, with leadership, and with partner teams who may not realize they’re part of the bottleneck.

You’ll leave with:

• Visualization techniques you can use with your team.
• How to spot the difference between people problems and system problems.
• A systematic approach to diagnosis before intervention.
• How to use visuals as conversation tools with leadership and partner teams

This talk is for engineering managers who want to see their systems clearly before trying to fix them.

Engineering teams don’t lose neurodivergent talent through hostile environments. They lose them through invisible ones.

According to the Tech Talent Charter’s survey of 230,000 tech workers, up to 50% of tech employees identify as neurodivergent when asked directly, while their employers estimate just 3%.

That gap isn’t a measurement problem. It’s a disclosure problem. Over half of neurodivergent workers have never told anyone at their company, because they’ve learned the environment wasn’t built for them.

When I built BRYGE AI, an award-winning AI communication assistant featured in Fast Company, I analysed the messages that 60 people sent to ADHD colleagues before and after using the tool.

The same patterns appeared repeatedly: urgency ambiguity, context-buried action items, and implicit tone that reads as passive aggression. None of the senders knew. All of the ADHD recipients experienced them as exhausting, anxiety-inducing, and sometimes career-threatening.

I call these Invisible Exclusion Patterns: communication habits so deeply embedded in neurotypical professional norms that the people generating them are structurally unable to see them without external help.

Research calls the underlying dynamic the Double Empathy Problem: the communication gap runs both ways, but the burden of bridging it falls almost entirely on neurodivergent workers.

That asymmetry is what this talk addresses.

The consequences for engineering teams are concrete. Neurodivergent engineers are misread as disengaged. High performers quietly labelled difficult. Retention conversations that should have been communication conversations.

And the cruel irony: the engineers most likely to be losing this battle are often the most technically exceptional members of your team, the ones whose cognitive difference is inseparable from their ability to solve problems nobody else can.

This talk introduces the Communication Burden Audit: a one-sprint framework that identifies where your team’s communication is placing disproportionate cognitive load on neurodivergent colleagues and gives you three specific rewrites you can deploy immediately.

No DEI training. No sensitivity workshops.

Just a systematic change to how your team writes to each other, with measurable impact on retention, velocity, and psychological safety.

Key takeaways

1. The 3 Invisible Exclusion Patterns found repeatedly in neurotypical engineering communications, and the specific rewrites that eliminate them
2. How to run a Communication Burden Audit in one sprint without disrupting delivery
3. Why “action-first” message structure improves velocity for your whole team, not just neurodivergent members
4. How to reopen retention conversations that were actually communication problems in disguise
5. The leadership mindset shift from “they need to adapt” to “I need to design”, and why it’s the highest-leverage inclusion investment you can make

The evening of Friday December 12, 2025, I got the call. Great Nonprofits had a critical donation-flow failure. Donations had been collected from donors all year but since August had not reached the charities. They’d only recently discovered it.

I knew what reputational risk this was. I also knew that there were tax implications since the calendar year was ending in a little over two weeks, with the holidays bearing down on top of it.

I started work that Monday (December 15th). I had no prior relationship with the team, no context on the systems, and multiple people who had holiday plans coming up, including a founder who was going out of the country shortly.

What followed was two weeks of crisis leadership under every possible external pressure: globally distributed teams across time zones, holiday schedules, multiple external vendors, and an organization that needed both a technical fix and a steady hand at the wheel.

This talk is about what actually works when you’re leading in crisis without the foundation most leaders expect to have or build first: relationships, context, and time.

I’ll walk through the specific leadership moves that made the difference: onboarding through people rather than documentation, clarifying ownership in a multi-party environment where everyone assumed someone else was responsible, separating signal from noise under time pressure, and keeping technical reality aligned with what leadership was communicating externally.

The incident was resolved before the end of the year. Donation flow was restored without additional disruption. And the organization came out the other side with greater clarity on its systems and its own resilience.

You don’t need a running start to lead well in a crisis. But you do need a different playbook.

Key takeaways

• Onboarding through people AND documentation accelerates trust and situational awareness faster than working in isolation.
• Clarifying ownership in multi-party environments is often the most critical unblocking move a crisis leader can make.
• Separating signal from noise under time pressure requires active filtering, not just faster analysis.
• Keeping technical reality and external communications aligned prevents the second crisis that often follows the first.
• In a crisis, you can’t wait to build relationships and trust. You have to build them at a speed that matches the urgency.

A junior engineer on my team shipped a feature in a day that would once have taken much longer. The code looked great.

Then I asked them to explain a few decisions, and things got quiet.

They could describe what the code did. They struggled to explain why it had been written that way, or how they would debug it if it failed in production.

The output looked senior. The understanding was still junior.

That gap is easy to miss because the usual signals, clean PRs, good test coverage, fast delivery, all look healthy. I call this the Confidence Gap.

AI helps people ship better-looking code before they have built the judgment behind it. That is not a reason to ban the tools. It is a reason to rethink mentoring.

I will share three exercises I am using with junior engineers: AI-off sessions, Explain the Machine, and Break It challenges.

The point is not to slow people down or catch them out. The point is to rebuild debugging, explanation, and critical thinking so we do not confuse polished output with engineering growth.

This talk is for leads and managers who want to keep AI in the workflow without losing the apprenticeship part of the job.

Key takeaways

• The Confidence Gap: how AI can hide understanding gaps in junior engineers.
• A practical mentoring toolkit: AI-off sessions, Explain the Machine, and Break It challenges.
• How to reintroduce real learning without making AI use feel punitive.
• Better ways to think about growth when output no longer tells the whole story.

A welcome from the host, Maude Lemaire.

In the era of harnessing swarms of long running, autonomous agents, how can we improve agents’ ability to craft high quality outputs instead of overwhelming our codebases with almost-good-but not-quite-there PRs?

Many startups have had to build upwards – planning, building, and maintaining products for teams much bigger than their own. AI has enabled this more than ever before. How do comparatively small teams ship enterprise-ready features to production, and how has that changed in the age of AI? We’ll chat honestly about the journey to the present, what we’ve changed along the way, and how we prepare for an ever-changing future.

There’s an overwhelming echo chamber telling you you’re not AI-pilled enough: Oh, you still have humans writing software? Oh, you are still having humans review things before merging them?

It’s easy to feel judged, and easy to dismiss the changes as propaganda.

This talk will dig into the technical and social details of Imprint’s migration to safely transition from manual deploys to continuous deployment with substantial agent-written PRs in under six months.

From our specifics, we’ll expand to a repeatable recipe others can take to include agents in their workflows without resorting to the banality of tracking token usage or other veneers of Ai transformation.

If I had only 30m to distill what I’d learned over the years, this is the talk I’d give. Most of the lessons will be about teams (the real distributed systems). I can’t guarantee consistency, but I will strive to be both available and tolerant.

When Fetch aired its Super Bowl commercial, we had one chance to get it right.

We ran a live $1.2M sweepstakes during the final two minutes of the game: anyone who opened the app entered automatically, and 120 winners were drawn and announced in-app in real time.

Our normal signup load was ~1 RPS. Our target: 150,000.

There was no rehearsal, and the sweepstakes carried legal obligations that meant certain operations had to be both fast and provably correct.

This talk focuses on the engineering leadership decisions that made this survivable.

I’ll share how we decomposed the signup critical path into three buckets (must be synchronous, can be deferred, can be dropped) and how that framework shifted when a legally binding lottery meant some operations couldn’t be deferred or dropped.

I’ll cover the architectural trade-offs: stripping the signup flow with feature flags, moving deferred work off the critical path with Kafka and SQS, and shifting verification to dedicated Redis clusters.

Then I’ll explain how we decided which safety checks to temporarily relax, how we bounded that risk, and how we built confidence when our stress environment couldn’t replicate production.

Our stress testing caught some surprises early: Redis became CPU-bound at 150K RPS while DynamoDB held steady, the opposite of what we expected.

But game day brought its own. Postgres connection limits quietly became a scaling ceiling, and an SMS rate limit we knew about still cost us valuable minutes of cross-team coordination during the live broadcast.

Each surprise required real-time judgment calls, and our ability to respond came down to how we’d structured launch-day operations: defined roles, communication channels, and escalation paths designed with the same redundancy we’d built into the architecture.

If you’re preparing for a traffic spike with an immovable deadline, you’ll leave with a practical framework for decomposing a critical path, launch levers for controlling risk in real time, and hard-earned lessons about the gap between knowing a risk and being ready for it.

Key takeaways

• How to decompose a critical path into synchronous, deferred, and droppable work using feature flags and queues as scaling levers.
• How stress testing at 150K RPS revealed counterintuitive bottlenecks (Redis, not DynamoDB, became the ceiling) and why preparing to be wrong mattered more than trying to be right.
• How in-memory static assets and gradual rollout patterns can shield backend services when millions of users transition from a live event back into the regular app.
• How to structure launch-day team operations (roles, comms, escalation) with the same redundancy you design into your architecture.

As large language models move from research to production, engineering leaders are facing a new kind of challenge: how do you test, deploy, and govern systems that can behave unpredictably?

At GitHub, we found that reliability wasn’t enough — trust became the core metric.

Building our internal coding agents required rethinking how we validated AI output, handled uncertainty, and collaborated across disciplines.

This talk explores that journey: how we built testing pipelines for non-deterministic systems, defined “ethical success criteria,” and aligned engineers, product managers, and legal teams around shared principles for responsible AI.

I’ll share the technical patterns that worked — like controlled prompt experiments, sandboxed agent evaluation, and feedback loops — as well as the cultural lessons from introducing ethical review processes into fast-moving engineering work.

Attendees will leave with concrete tools for building trustworthy AI systems, a playbook for leading cross-functional conversations about safety and ethics, and practical insights for balancing innovation with accountability.

In a world where AI capabilities evolve faster than our processes, this story is a reminder that trust is built, not assumed — and that engineering leaders have a critical role in making it real.

Key takeaways

• Learn how to test and evaluate non-deterministic LLM behavior in production systems.
• See frameworks for defining and measuring “ethical success” beyond accuracy.
• Understand how to align engineers, PMs, and legal on responsible AI principles.
• Apply lessons for balancing speed, experimentation, and accountability in AI projects.

At Netflix, catalog metadata is mission-critical. It defines what titles exist, whether they can be played, and where they’re available, powering the experience for millions of members.

When a production incident revealed that corrupted data could break streaming while every code canary showed green, we recognized a fundamental gap: we had rigorous deployment validation for code, but none for data.

This talk tells the story of how we built the Data Canary: an automated system that validates data transformations using real production traffic, detects regressions in 2.5–4 minutes, and blocks bad data from publishing, all within a 10-minute window.

We’ll cover three core innovations:

1. The Orchestrator Pattern: a dedicated cluster architecture that separates baseline from canary, avoids self-testing, and provides a generic integration point extensible to other data sources at Netflix.
2. Extending Our Chaos Platform: customizing experiment thresholds for tight time constraints, using sticky canaries to prevent cross-contamination, and discovering that behavioral metrics (Starts Per Second) detect catalog corruption far more reliably than latency or error rates.
3. Production-Hardened Engineering: handling in-flight experiments during redeployment, leader election across concurrent orchestrator instances, and running controlled failure injection experiments to validate the validator before going live.

The patterns we landed on aren’t Netflix-specific. Any team running high-velocity data pipelines that directly impact customers should be asking: what’s your MTTD for data corruption? Can you validate with production traffic safely? How do you detect emergent issues in transformed data?

This talk offers a practical, replicable blueprint for bringing code deployment rigor to data.

Key takeaways

• Data deployments carry the same production risk as code deployments and deserve equivalent validation rigor
• Behavioral metrics like Starts Per Second can be more reliable signals for data corruption than latency or error rates
• The orchestrator pattern, with permanent baseline and canary clusters, provides a reusable, extensible architecture for data pipeline validation
• Sticky canaries and real production traffic are essential for detecting emergent failures that shadow traffic cannot surface
• Chaos experiments can be tuned for tight time windows by prioritizing speed of detection over statistical confidence

Human-written code died in 2025. Code review is dying in 2026.

Teams with high AI adoption are merging 98% more pull requests, but PR review time has surged 91%. There is no way we win this fight with manual code reviews, and AI code review tools are just buying us time.

This talk makes the case that the traditional code review is a historical approval gate that no longer fits the shape of modern software development.

We’ll walk through a practical five-layer trust model: from multi-agent competition and deterministic guardrails to spec-driven BDD and adversarial verification that lets engineering teams ship faster without sacrificing quality or control.

Key takeaways

• Review time goes up 91%, manual code review cannot scale, and pretending otherwise leads to organizational debt.
• AI code review is just kicking the can. If an AI writes the code and an AI reviews it, the post-PR review stage adds ceremony without real value. The review loop needs to move earlier in the development cycle.
• Shift the human checkpoint upstream from code to intent. The most valuable human judgment is applied before the first line is generated: reviewing specs, constraints, and acceptance criteria, not 500-line diffs.
• Trust is layered, not binary. A practical five-layer model for agentic safety: (1) multi-agent competition, (2) deterministic guardrails and linters, (3) human-authored acceptance criteria via BDD, (4) scoped permission systems, and (5) adversarial verification agents.
• Bring back behavior-driven development. Code is an artifact of the spec. Behavior-Driven Development (BDD), once impractical overhead, becomes the primary workflow when agents handle implementation.

Autonomous AI agents are transforming software delivery from scripted automation to systems that make decisions without human approval.

Your agent decides which tests to run, whether to approve deployments, and how to prioritize risks. But when it gets it wrong, who’s accountable?

Our testing agent auto-approved a broken build that affected 10,000 users for four hours. The agent prioritized velocity over safety because we hadn’t defined clear trust boundaries for autonomous decisions.

Traditional “”human-in-the-loop”” governance doesn’t scale—you can’t manually review every agent decision when you’re processing thousands daily.

This session introduces the engineering framework we built for accountable autonomy: a three-tier trust model that categorizes decisions by blast radius (impact and reversibility), governance architecture using Model Context Protocol for instrumentation, and circuit breakers that prevent AI from causing more harm than the bugs it’s designed to catch.

Engineering leaders will see how to design systems where agents can operate autonomously for low-risk decisions (running unit tests, analyzing logs) while requiring human approval for high-impact changes (production deployments, infrastructure modifications, user data access).

You’ll learn observability patterns using OpenTelemetry that make agent reasoning transparent enough to audit, and governance templates that satisfy legal and security stakeholders without slowing engineering.

This isn’t about saying “”no”” to agentic AI—it’s about building the guardrails that let your team confidently say “”yes.””

The organizations winning with autonomous AI aren’t the ones with the most capable agents; they’re the ones with the best governance architecture.

You’ll leave with a decision matrix for automation versus human approval, observability patterns for auditing agent behavior, and communication frameworks for introducing agentic systems to skeptical stakeholders.

The accountability gap is solvable. This is how you engineer trust at scale.

Key takeaways

1. Three-tier trust model: Decision matrix categorizing which agent actions can be fully automated (low blast radius, reversible) versus requiring human approval (high impact, irreversible)
2. Observability architecture: Concrete patterns using OpenTelemetry Semantic Conventions to trace agent reasoning chains and build audit trails legal teams trust
3. Circuit breaker implementation: Programmatic governance gates that prevent autonomous AI from cascading failures beyond defined risk thresholds
4. Stakeholder communication framework: Templates for explaining agentic governance to legal, security, and executive stakeholders who demand accountability without understanding the technology

One of the core goals of platform engineering is to reduce developer toil and accelerate delivery across the entire development lifecycle.

While many organizations focus these efforts on CI/CD and tooling, other platform surfaces such as service connectivity and networking often remain fragmented and owned by individual teams.

This fragmentation creates significant hidden friction that is rarely visible in traditional productivity metrics.

At Databricks, product teams building services across the control plane and data plane routinely spent multiple weeks setting up basic connectivity.

Engineers had to configure proxies, manage DNS entries, provision load balancers, and reason about environment-specific constraints such as intra-cluster, inter-cluster, and cross-region communication.

Despite extensive documentation and shared standards, this work remained slow, error-prone, and highly dependent on senior engineers.

The result was persistent “shadow toil” that distracted teams from delivering product value.

In this talk, I will share how our platform engineering team made a deliberate investment to simplify service-to-service connectivity by introducing uniform platform abstractions and out-of-the-box discovery.

Working cross-functionally with networking, compute, service framework, and authentication teams, we replaced bespoke, team-owned solutions with a consistent connectivity model that worked across deployment environments.

I will walk through the developer pain that motivated this decision, why documentation and standards alone were insufficient, the architectural and organizational trade-offs involved, and how we rolled this out incrementally without breaking existing systems.

The results included reducing service onboarding time from weeks to minutes and achieving over 70% latency improvements on certain inter-cluster paths.

While this talk focuses on service-to-service connectivity, the lessons apply broadly to other platform domains where inconsistent abstractions quietly slow teams down as organizations scale.

Key takeaways

1. Why investing in platform engineering can deliver disproportionate gains in developer productivity
2. How consistent platform abstractions simplify architecture while improving latency, cost, and maintainability
3. How to identify and quantify “shadow toil” in areas like networking that often escape traditional metrics
4. How a developer-first mindset helped align multiple teams around a shared platform abstraction

Legacy systems are often treated as a necessary evil: work to be endured before moving on to more “real, strategic” projects.

Early in my career, I spent several years working in brownfield systems before transitioning to large-scale microservices. At the time, that move felt like a step up.

But looking back, the most valuable skills I relied on, judgment, prioritization, and trade-off thinking, were developed in those earlier environments.

Legacy systems force engineers to work with incomplete context, fragile dependencies, production risk, and hard trade-offs.

Small changes matter, assumptions break, and second-order effects are everywhere.

You learn to think carefully about blast radius, release order, rollback, and what “good enough” really means.

In this talk, I’ll share how brownfield work builds engineering judgment in ways greenfield environments often do not.

Through examples from legacy and microservice systems, I’ll show how constrained environments sharpen prioritization, change management, and technical decision-making.

I’ll also explore what leaders can do with this insight: how to identify high-leverage legacy work, assign it intentionally, and make its value visible as a growth path rather than a punishment.

You’ll leave with a new way to think about legacy systems: not as a career compromise, but as one of the best training grounds for stronger engineers and more resilient technical leaders.

Key takeaways

• Understand how legacy systems develop engineering judgment and decision-making
• Identify high-leverage improvements within complex, constrained systems
• Apply legacy lessons to architecture, scaling, and production risk
• Recognize and communicate the strategic value of brownfield work
• Use legacy work intentionally to grow senior engineers and strengthen systems

Have you ever inherited a technical decision that went sideways? Where teams were running their own experiments, trust was eroded, and every conversation felt like “my tool vs your tool”?

Last year, I took over an AI code review tool evaluation that was heading in exactly that direction.

An enthusiastic rollout had backfired, developers had lost trust, and teams were championing different tools with no shared criteria for success.

Six weeks later, we had a clear winner that exceeded our targets by 300%.

More importantly, we had buy-in from developers who’d been skeptical that any AI tool could work, including those whose preferred tools didn’t make the cut.

The evaluation process was featured in The Pragmatic Engineer newsletter, but this talk goes deeper into the framework that made it work.

I’ll share the methodology we used to turn a contentious tool evaluation into a process everyone could trust.

You’ll leave with a reusable framework for evaluating AI developer tools, or any technical decision where stakeholder buy-in matters as much as the metrics.

Key takeaways

• How to define success criteria before testing (and why this is the most critical step)
• What to measure: quantitative metrics (time savings) and qualitative signals (developer satisfaction, signal-to-noise ratio)
• How to structure fair comparisons when testing multiple tools in production
• When to drop tools early vs. giving them more time
• How transparency and maker-owner culture rebuild trust after failed rollouts

“Do I fall behind and risk obsolescence, or keep up and risk burnout?”

This is how I felt as new AI models, frameworks, editors, and existential proclamations arrived daily, all while I was leading multiple projects and raising a young child.

I eventually recognized this false dichotomy: obsessively following AI news is not required to be effective. This epiphany was rooted in the Diffusion of Innovation model.

Innovators and Early Adopters exhaustively study every new development, and we need them. But being an Early Adopter doesn’t have to be your job! You can belong to the pragmatic Early Majority and capture most of the benefits by learning from your Early Adopter peers.

And these roles aren’t fixed: you might upshift to Early Adopter for the right opportunity, or downshift to Early Majority when personal circumstances arise.

Your superpower as a leader is determining which advancements do matter – through experience and institutional knowledge – and fast-tracking their adoption.

At my company, four strategies had the biggest impact: (1) gave Early Adopters a dedicated space to share and discuss headlines, (2) ran show-and-tells to bridge Early Adopters and the Early Majority, (3) facilitated mob programming sessions for contextualized knowledge transfer, and (4) removed bureaucratic friction so promising technologies could spread quickly.

Based on DX metrics, 85% of our engineers are now “heavy” users of AI tools and DX True Throughput has increased by 25%.

This talk is for overwhelmed engineering leaders and senior ICs who feel quietly guilty about not experimenting with every AI trend.

I’ll share how I recalibrated my relationship with the AI news cycle – not by disengaging, but by becoming more deliberate about how I deliver value to my organization.

Key takeaways

• Why you won’t miss the boat: truly revolutionary AI advancements will gain enough mindshare to become standard practice without having to follow every headline.
• Why being in the Early Majority of AI adoption is a legitimate and sustainable baseline, and the exceptional cases when you might shift to Early Adopter.
• Four specific strategies to transform Early Adopter insights into real productivity gains for everyone along the adoption curve.
• How to apply your hard-won institutional knowledge and seniority to identify the most impactful AI technologies without becoming an “”AI obsessive”” yourself.

Tackle tough leadership challenges with your peers

An essential part of the conference experience is networking and learning new things. However, opportunities for problem-solving can be limited. Join our Director+ roundtables and engage with your peers, learn from one another, and collaboratively address some of the most pressing challenges you face in your roles.

Hear what strategies have been effective and which ones have not, and gain valuable insights and knowledge that aid your decision-making.

Go deeper on the leadership challenges that matter most right now.

DirectorPlus workshops are designed for senior engineering leaders who want more than surface-level discussion. In these focused, highly interactive sessions, you will work alongside peers facing similar organizational, technical, and people challenges. Together, you will pressure-test ideas, explore real-world scenarios, and exchange candid perspectives drawn from lived experience.

Guided by seasoned engineering leaders, these workshops create space for practical problem-solving, honest reflection, and shared learning. You will leave with concrete takeaways, sharper decision-making frameworks, and strategies you can confidently apply back at work.

Some of the biggest questions in engineering leadership don’t have easy answers.

In this Big Debate session, industry leaders will explore one of the most urgent unresolved challenges facing engineering teams today. Expect a thoughtful, high-level discussion on what’s changing, what’s still uncertain, and how leaders are thinking through the decisions that will shape what comes next.

If you’re inspired by a talk, want to learn more, or just want to chat about it with other folks, head to our Office Hours area where our speakers will be waiting for you.

Watch or participate in free 1:1 coaching.

Find out the secrets to success in your next career move

A huge part of LeadDev is helping people advance in their career – but understanding the expectations of the role above you isn’t always easy. 

As such, Next Steps AMAs bring together groups of leaders who can help answer the fundamental questions that folks have relating to their role; how do I advocate for my promotion, what will my new responsibilities be; how will I know that I’m successful?

Bring a book to get signed, ask a question, or have an informal chat with the author.

Meet the Author sessions are informal opportunities to connect one on one with authors shaping conversations in software engineering.

Bring a book to get signed, ask a question, or just stop by for a chat about their work, ideas, and perspectives on the latest in tech.

Trade tactics for tackling everyday challenges

Sometimes it can feel like every problem has only one answer – but the truth is, in leadership there’s never a single solution. But when you’re in the thick of a problem, it can be hard to get the headspace to see other ways to tackle a challenge. 

In our solution swap sessions, attendees will get the chance to say how they’d tackle a common issue and compare their ideas with how other leaders would confront the same problem. Our coaches will give direct feedback about the possible consequences (both positive and negative) of the ideas – and will ask the key question – if you were to do this, and then this happened – what would you do next?

Dive into some of the key issues facing engineering teams.

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in our Table Talk sessions, hosted by a group of engineering leaders who are on hand to help guide the conversation.

Everyone’s journey into leadership is tough, but folks who are underrepresented in tech often face their own unique set of challenges. And that can lead to people feeling isolated in their experiences. 

Come to the community representation groups, where you’ll be able to connect with folks who might have similar backgrounds and experiences to you, and where you’ll be able to build a peer network for support throughout your journey. 

Connect with folks over shared experiences

Building great software comes with unique challenges in every industry and often, the best insights come from others who are in the same boat. Join our relaxed sessions where you can meet peers working in similar domains to share ideas, collaborate on challenges and exchange solutions. 

Comparing notes on shared challenges that come with your role has never been easier. Peer Hangouts are 30-minute, casual networking sessions for folks to talk through their experiences and challenges with peers who understand the context they’re working in. Drop in and join a conversation!

The best solutions don’t come from isolated thinking – they come from candid conversations with people who’ve been there. Join fellow senior ICs, throw your challenge into the mix, learn from each other’s experiences, and leave with perspectives you couldn’t have found on your own.

Curious about how LeadDev meet-ups run around the world, or thinking about starting one where you live?

Join current LeadDev meetup organisers for a live AMA on how the meetup programme works, what it’s really like to run a local community, and how you can get involved.

Whether you’re interested in launching a meet-up, speaking, sponsoring, or supporting local organisers, this session will show you how the LeadDev community comes to life, and how you can be part of it.

Find out how you can get involved:

• Become an organizing host
• Deliver a talk
• Sponsor a venue
• Volunteer to support

Want to contribute to LeadDev but not sure where to start?

Join the LeadDev content team for a relaxed AMA session where you can ask questions about getting involved.

Whether you are interested in speaking on stage, writing an article, or hosting a meetup, this session will guide you through the process. You will learn how to create strong speaker submissions and engaging article proposals, and discover how to take your first step toward becoming a LeadDev contributor.

Join one of seven 80-minute workshops included as part of your conference pass. Check back soon for full details. Topics will include:

• Team development in the age of AI
• Systems thinking to drive software delivery excellence
• Decision-making techniques for engineering leaders
• Metrics to improve developer productivity

Explore solutions for your technical issues.

Sponsor-led talks highlighting tools and solutions for real-world engineering problems.

Join these 10-minute talks to explore how our partners are helping teams tackle real-world engineering challenges. Each session shares practical examples, lessons learned, and insights into the decisions behind the solutions — giving you ideas you can take back to your own teams and systems. 

Hands-on Labs are guided, interactive sessions where you can explore new tools, solutions, and approaches in a practical setting.