Continuous Delivery has been a cornerstone of high-performing engineering for over 15 years, yet many organizations still struggle to fully adopt its principles. Jez Humble, a pioneer in the field, revisits the fundamentals with updated insights for today’s complex landscape.

This talk will go beyond the buzzwords to provide actionable strategies and practical advice for overcoming common roadblocks, ensuring your teams can achieve rapid, reliable, and sustainable software releases. Whether you’re new to CD or looking to refine your existing practices, leave equipped to truly master the art of continuous delivery.

Migrations need to be fast and seamless. But at scale, they’re often anything but – especially when many teams are involved and coordination overhead balloons. What if you could make migrations self-serve, so they just happen, without endless follow-ups or hand-holding?

At Airbnb, we’ve been working AI into our migration toolkit to rethink migrations from the ground up, guided by two tenets: “Complete to 100%” and “Be a host” – taking responsibility for migrations on behalf of teams.

In this talk, I’ll share how we built tooling, infrastructure, and guidance to enable rapid, large-scale AI-driven migrations. Through some case studies, you’ll learn how these principles are letting us scale migrations across the company, the new challenges we faced (like review bottlenecks), and practical lessons for anyone looking to accelerate migrations in their own organization.

Key takeaways:

• How migration tenets like “be a host” and “complete to 100%” are foundational for accelerating migrations with AI by changing the planning, ownership, and tooling approach
• The specific tools and infrastructure we’ve built to scale AI-accelerated migrations and make them self-serve and repeable
• The key points we use to train our migration owners to help deliver successful AI-accelerated migrations
• And some of the bottlenecks and hurdles we’ve hit doing this (some we’ve addressed, some we haven’t yet)

You may have heard that rewriting code from scratch is a Thing You Should Never Do. We’ll critically examine the origins of that proverb and its applicability to modern software development, as well as share some stories and common patterns from successful rewrites.

Software engineering is a complex and contextual domain. Given any question, there’s a good chance that the best answer is “it depends.” Despite this, we still elevate some prescriptions to the level of “common sense” or even dogma. One such idea is “never rewrite the code from scratch,” which traces back at least as far as the year 2000.

I’ve had this proverb recited to me more than a few times by my superiors and peers. Sometimes, avoiding a rewrite has been the right call. But other times, eyes open to the potential issues and strategies to avoid them, I’ve pushed for a new system. Those projects have been some of the most rewarding and impactful of my career.

I’ll discuss the origins of the “never rewrite” idea and why the original reasoning doesn’t always apply to us today. I’ll also present my framework for planning a rewrite and how to capitalize on a successful one. Finally, I’ll share some stories of my successful rewrites and how they improved our engineering teams.

Key takeaways

• Why rewrites are sometimes (but not always) a terrible idea and how to tell the difference
• How to approach redesigning a system from scratch, from pitching the idea through to successfully landing your new system
• Examples of successful redesigns, their technical impact, and the effect they had on their engineering teams

As a Principal Engineer in Stripe’s Payment Intelligence org, I’m responsible for scaling real-time AI systems that detect and prevent fraud—without adding latency to Stripe’s most critical code path, known as the “charge path”.

At the heart of Stripe’s infrastructure, the “charge path” is a shared Ruby monolith that processes almost every transaction across the platform. In 2024 alone, it handled over $1.4 trillion in volume. It’s one of the most latency-sensitive and business-critical systems at Stripe, actively maintained by several engineering orgs and touched by hundreds of developers. Making changes here requires precision, coordination, and a deep understanding of systemic constraints.

Our org had a strong roadmap of AI innovations to improve fraud prevention and authorization rates. But executing that vision meant working through legacy architectural decisions and Ruby’s lack of native concurrency—all without exceeding strict latency constraints. To move forward, I brought together tech leads and domain experts from across Stripe for a virtual onsite. We ran an event storming workshop to surface shared constraints, uncover tribal knowledge, and identify architectural leverage points for introducing safe and meaningful parallelism. I proposed a series of deep but targeted architectural improvements to unlock more ML execution within the charge path, minimizing the risk. I then collaborated across teams to build a multi-quarter roadmap that aligned efforts, minimized conflicts, avoided throwaway work, and accelerated the landing of impact.

This talk is about what it takes to deliver AI innovation inside a high-stakes, real-time system—navigating legacy architecture, aligning across teams, and scaling machine learning under strict performance constraints.

Key takeaways:

• How to scale real-time AI in a latency-sensitive system
• How to introduce parallelism in a legacy Ruby monolith
• How to uncover system constraints through structured collaboration
• How to align multiple teams around architectural change

Learn how to effectively mentor aspiring technical leaders, focusing on cultivating the unique blend of technical mastery, broad impact, and organizational influence required for a Distinguished Engineer role.

This talk introduces hypothesis-driven development as a method for validating architectural choices. We’ll explore how to design experiments that provide actionable data, allowing teams to make informed decisions and adapt to changing requirements.

As a Staff+ engineer, you’re expected to lead complex, cross-functional initiatives, align teams around technical direction, and deliver meaningful outcomes – all in the face of ambiguity and rapid change. Yet the most important architectural decisions often happen early in a project – precisely when knowledge is limited and uncertainty is highest.

To lead effectively in this environment, you need a mindset shift: embrace the role of a lean architect and treat architecture as a series of testable hypotheses. Validate decisions early – while changes are still inexpensive and easy to make. Start small. Build steel threads: thin, end-to-end slices that deliver value and surface insight. Use them to ask sharper questions:

• Will this pattern scale in production?
• Are our boundaries enabling speed or creating new bottlenecks?
• What is real-world usage telling us about our assumptions?

By experimenting your way to better decisions, you create space for smarter choices and generate the feedback needed to shape architecture. As successful patterns emerge, your team can invest with confidence – steadily building scalable, resilient systems one iteration at a time.

“Splitting the monolith” is often treated as a bold technical goal, but in reality it is usually a high-risk and unsustainable effort.

This talk introduces a different path focused on creating coherent impact – a meaningful outcome that emerges from many small, well-aligned projects rather than one massive initiative.

Hazel will explore how to select and organize work that builds toward larger architectural goals, how to turn incremental progress into system-level change, and how to guide the effort while allowing others to lead key pieces. The talk also covers how to recognize and communicate your role in shaping the outcome, especially when your contributions are spread across many efforts.

Making the leap from team-focused engineer to org-level technical leader can feel like freefall. Suddenly, your old ways of working and measuring success no longer apply. You’re overwhelmed, directionless, and wondering if you even belong in this role. Sound familiar? You’re not alone.

This talk introduces the concept of the Performance Cliff, a psychological shift that explains why highly capable engineers often feel lost when stepping into broader influence. Drawing on years of mentoring and hard-won lessons, the speaker will explore practical strategies to reframe your mindset, build new systems of success, and thrive in the ambiguity of Staff+ org leadership.

Over the last several years of mentoring other Staff+ engineers, the speaker has had many conversations that follow a similar pattern:

“I recently moved from being a team leader to being an org leader, and I have no idea what I’m supposed to be doing / I feel like I’m failing / I’m overwhelmed by all of the work on my plate / I’m lost and confused / maybe this isn’t the right role for me / I feel so alone.”

If this resonates, you’re not alone. The speaker experienced the same thing when moving from a Staff Engineer role on a team to an Architect role with broad responsibility across many teams. Despite working toward this transition for years, the shift felt disorienting. It created a sense of failure, uncertainty, and fear of being found out. But that reaction is not a sign of inadequacy – it’s a normal response to a major change.

This talk is for anyone who has stepped into a larger role and quietly wondered if they’re the only one struggling.

A crisis is a transformative moment for an organization. If you’re prepared, and with a little luck, it can be an ideal moment to make big technical changes.

All organizations experience crises. An existential threat from a competitor, a highly visible outage, or a disruptive reorg can all land you in the same place. The organization has to adapt to continue to exist. New habits and coordination structures are required. Team members have to perform at their best, and do it while stressed and short of time.

In such conditions, change is coming to your organization. As a Staff+ engineer, you have a key role to play. I’ll show how listeners can direct and shape the changes, leaving systems and structures that are stronger than before.

Key takeaways

• How to identify a useful crisis conditions
• What can staff+ leaders contribute in a crisis?
• Technical capabilities you might want before a crisis

Practical cues and rituals that help senior ICs oscillate between architectural vision and hands-on execution.

Discover how to sustain your core staff engineering qualities and impact, regardless of your evolving job title or leadership responsibilities.

This talk will describe the process of building one of the flagship new feature areas that Figma launched at its annual conference this year (May 2025). I’ll talk through how I turned a small team, a lot of passions, and a large mandate into a successful product launch.

For the past year I’ve been the lead engineer and de facto product manager for a large new product area at Figma. In just a few months, armed with only a handful of engineers and a huge product mandate, our team had to be efficient, resourceful, and most importantly, needed to have a lot of fun in order to deliver such an expansive feature set. Follow along our journey to unlock entirely new ways of being creative with Figma: our successes, our mistakes, and unexpected experiences all the while navigating a highly performance-sensitive front-end C++ stack.

Key takeaways

• How having a strong technical perspective from the start is key to building an efficient roadmap
• How building partnerships with other engineering teams can stretch your headcount a long way
• How to continually prioritize, adapt, and communicate about product decisions
• How to continually develop buy-in with leadership and give your team space in doing so
• How to build a happy team, and how to delegate, trust, and build leaders within your team

This talk explores the engineering challenges and key decisions involved in scaling LinkedIn’s search infrastructure, focusing on architecture, scalability, and resilience at massive scale.

In this talk, I’ll walk through the journey of scaling LinkedIn’s search infrastructure, highlighting the key engineering decisions and challenges faced along the way. As one of the largest and most complex search systems in the world, LinkedIn’s infrastructure supports millions of users and billions of queries each day – while maintaining low latency, high availability, and scalability.

I’ll cover the technical decisions made in designing and evolving the system, including tool selection, framework choices, and architectural patterns that enabled LinkedIn to scale its search capabilities in response to growing data and user demands. From designing distributed systems to optimizing indexing, query handling, and storage, I’ll share the trade-offs involved in ensuring reliability and performance at scale.

Beyond the technical aspects, I’ll also discuss the organizational and team dynamics that come with scaling such a large system. This includes aligning cross-functional teams, coordinating across engineering groups, and making decisions that balance immediate execution with long-term vision for the platform.

Key takeaways

• Key engineering decisions and challenges when scaling large-scale search infrastructure.
• Best practices for designing and optimizing distributed search systems.
• How to balance performance, scalability, and reliability in high-demand platforms.
• Strategies for aligning cross-functional teams in large-scale infrastructure projects.
• Lessons learned from building and evolving search systems to support millions of users.

Over a 5–7 year journey at Siemens Healthineers, I had the privilege of leading core software development for a next-generation SPECT/CT scanner—designed to perform a wide range of nuclear medicine examinations. As a staff software engineer, I oversaw the delivery of a mission-critical software platform that acquired and reconstructed diagnostic images, guiding a team of 20 engineers across the US and India.

The urgency to build this NextGen system came from looming end-of-life constraints on critical hardware—turning the project into a race against time. With multiple parallel tracks across product, UX, system, and hardware design, I focused our team on foundational software components that could move independently, helping us avoid bottlenecks and maintain momentum.

Designing architecture for a medical device meant optimizing for long-term maintainability. We chose to build our own platform over adopting off-the-shelf frameworks, giving us greater control and stability over a multi-decade lifecycle. We also set a strong engineering culture across distributed teams, grounded in collaboration and shared ownership. Our vision—to deliver a reliable, invisible platform—helped align and motivate teams across time zones.

Testing was a core part of our success strategy. We built a custom simulator to catch early issues, implemented an automated test suite covering 75% of functionality, and partnered closely with system testers. Our “DEAD” mindset—Drop Everything And Debug—ensured we prioritized quality where it mattered most.

The project culminated in clinical trials launched at the height of COVID-19. Despite the extraordinary challenges, seeing our work translate into real-world impact for patients was humbling, and remains one of the most meaningful experiences of my career.

Key takeaways:

• Fostering a culture of collaboration, open communication, and equal partnership across distributed teams is essential for leveraging global strengths, maintaining engagement, and ensuring product quality through real-time testing.
• Technical leadership in the medical device industry demands a strategic focus on long-term planning, maintainability, regulatory compliance, and resource management, balancing innovation with the significant upfront investment and extended product lifecycles.
• A multi-level testing approach—combining simulators, automated testing, and real-world system validation—along with fostering a culture of collaboration between development and system test, ensures comprehensive defect detection and guarantees software reliability and quality.
• Understanding regulatory guidelines early in the development process and testing critical requirements separately are essential for managing compliance efficiently, preventing delays, and overcoming the unique challenges of new product development in a highly regulated industry.
• While the challenges of long development cycles and unexpected obstacles, like the COVID-19 pandemic during clinical trials, can create uncertainty, the ultimate satisfaction of seeing your work positively impact users’ lives offers invaluable lessons that shape future leadership and decision-making.

As a Staff Engineer, uncertainty is a given. But sometimes, it lands right where it stings the most—on the expectation that you’re the technical expert. This talk is about my own experience leading initiatives where I didn’t have expertise in the tech at hand and how, despite that, a team can still be inspired, empowered, and deliver great results. I’ll share what worked, what didn’t, and the lessons I’ve carried forward about leading without always being “the expert.” Whether you’ve been in this position before or just want to be ready when it happens, this session will give you a candid look at turning uncertainty into strength.

Key takeaways:

• Confidence that effective leadership doesn’t require mastering every technical detail.
• Strategies to empower teams and foster collaboration in unfamiliar technical domains.
• Techniques to turn uncertainty into an opportunity for growth and innovation.
• Insights into building trust and credibility while navigating new challenges.

Alignment is one of the most used and least understood concepts in engineering leadership. We say it’s critical, we hold meetings to get it, and we celebrate it in performance reviews. But if we’re really aligned, why do we keep needing more “alignment” meetings?

After a year of obsessing over this concept, I’ve come to believe that most alignment work is actually just anti-misalignment: a reactive attempt to avoid conflict, surprises, or churn. It’s alignment by damage control.

In this talk, I’ll reframe alignment as a form of group flow, a state where everyone knows where we are, where we’re going, and how we’ll navigate tradeoffs along the way. I’ll share a simple model that explains why misalignment feels so painful (and so obvious), and why real alignment isn’t a meeting, it’s a shared sense of direction, context, and trust. We’ll look at the difference between alignment and agreement, explore some dangerously common anti-misalignment patterns, and walk through lightweight strategies you can use today to improve clarity and autonomy across your team.

Whether you’re a Staff+ IC, a manager, or a tech lead, this talk offers a vocabulary and lens for the invisible cultural friction that slows teams down and a more proactive way forward

Key takeaways:

• “Alignment” is a rarely useful concept as it can mean everything and nothing all at the same time
• Misalignment is one of the most painful and visceral forces in an organization
• Most “”alignment”” work is actually driven by the fear of misalignment
• What true proactive and productive alignment looks like
• Strategies to tease out true alignment against the background of “Anti-misalignment”

An essential challenge for senior individual contributors (ICs) such as architects and staff+ engineers is guiding engineering teams towards well-informed technology decisions at scale. This can be a daunting task, often frustrating and at times feels impossible.

Software engineering is inherently creative, much like painting, where no two artists would create the same artwork. This creativity leads to strongly held opinions, often resulting in spirited debates that can feel like arguing and conflict rather than collaborative brainstorming. These debates, though difficult and uncomfortable, are extremely important and critical to our overall success.

This talk delves into the unique challenges faced by senior ICs who wield influence but lack direct authority, emphasizing the importance of presenting choices over solutions and engaging early in the decision-making process. We will explore techniques to make these debates more constructive, collaborative, less driven by ego and conflict, and more likely to result in decisive, well-informed decisions.

Key takeaways:

• Harnessing Conflict for Progress: Embrace the chaos and recognize that conflict, when managed well, can drive innovation and better outcomes.
• Effective Decision-Making: Learn how to present choices over solutions to foster collaboration and reduce conflict.
• Early Engagement: Understand the importance of influencing decisions early to avoid entrenched solutions and defensiveness.

“It’s me– Hi. I’m the problem, it’s me,” croons Taylor Swift on her iconic track, “Anti-hero.” When it comes to the growth of those around us, this also applies to Staff+ Engineers.

Simply put, experienced ICs are often the largest barrier to growth of those around them. Leadership will turn to you when something mission critical has to get done fast. Leadership will turn to you to save someone else’s project that has run off the rails. Playing the hero feels really good in the short run. But it’s not sustainable in the long-run for you, or for the organization. Even if you don’t burn out, you slow or stunt the growth of others.

Think about when you grew most as an engineer. Some people will say, “it was when this really experienced person took me under their wing.” But most will say something like, “it was when that really experienced member of the team left, and I had no other choice but to step up.” By default, others grow more in our absence than in our presence. And, we struggle with this problem quite a bit. Our median tenure is quite high, which means the most common growth opportunity in the industry (“a senior IC leaves”) happens less often than elsewhere. This pushes us to experiment with different ways to grow others.

In this talk, I reflect on the ways I’ve tried (and often failed) to cultivate other engineers. Conventional wisdom says we should “scale” ourselves by focusing on “org wide impact”. But I’ve discovered the power of doing what doesn’t scale. When I’ve carved out time each week to invest in the three most capable engineers around me, something remarkable happens: the whole team sings.

Key takeaways:

• By default, others grow more in your absence than in your presence.
• Identifying and investing in 2-3 key people is super impactful
• Push your best people regularly out of their comfort zone

Inspired by the book The Phoenix Project and by DevOps principles, we worked to close the gap between Development and Operations, to come together and collaborate for the good of the organization. We even invited security into the fold and embraced DevSecOps.

Granted, if you’re like me, you’re still shaking your fist at somebody on the regular. You know who I mean. But they deserve it. Look at how much they mess everything up! They’re the ones who need to wise up and change, right? Right? The divides we encounter might be between teams, between geographical locations, between IT and “the business,” and more.

Join this session for an examination of why “us vs. them” thinking arises and how we can spot it in action. You’ll gain tips for why and how to bridge the divide – and why the effort can be worthwhile, even if “they” seem unmoved and unmovable.

Key takeaways:

• How to spot “us vs. them” thinking in action
• Tips for how to bridge the divide
• Why the effort is worthwhile

Many organizations run POCs to validate new technologies, enhance data infrastructure, or improve decision-making, but these efforts often fail due to unclear goals, lack of stakeholder alignment, or execution challenges.

This talk presents a structured approach to leading successful POCs that scale beyond the experimental phase and drive meaningful impact. I will share a practical, repeatable framework covering:

• Defining success criteria to align technical efforts with business needs
• Scoping and structuring POCs for rapid iteration without sacrificing long-term scalability
• Engaging stakeholders early to secure buy-in and resources
• Implementing in phases to gather feedback, reduce risks, and optimize for production readiness
• Transitioning validated POCs into production environments with minimal disruption
• Attendees will leave with actionable strategies to execute and scale POCs effectively, ensuring they deliver measurable value and do not remain proof-of-concepts forever.

Key takeaways:

• A structured approach to defining, scoping, and executing POCs effectively.
• Strategies for securing stakeholder buy-in and ensuring alignment.
• Techniques for phased implementation and iterative improvements.
• Common pitfalls to avoid when transitioning POCs to production.
• Practical insights from real-world case studies.

As a Staff+ engineer, your role isn’t just about scaling systems—it’s about scaling influence across the organization.

Interestingly, distributed systems principles offer a powerful mental model for leadership. This talk explores how fault tolerance, redundancy, service contracts, and eventual consistency apply to leading large-scale engineering efforts.

Learn how to design for autonomy without chaos, how to create decision-making guardrails without bottlenecks, and how to recover from failure—both technically and organizationally. Whether you’re shaping technical strategy, aligning teams, or driving long-term change, this talk provides actionable insights to amplify your technical impact.

Key takeaways:

• Apply distributed systems principles to scale your technical influence.
• Design decision-making frameworks that prevent bottlenecks in large organizations.
• Use fault-tolerance strategies to navigate organizational misalignment.
• Build technical strategies that are resilient to leadership and system failures.

How do you build something magical, fast?

In creating a new feature, engineering leaders have a lot to balance. Designs could be constantly in flux. Sharp pivots could be made weekly. There could be pressure to cut corners to hit deadlines. Despite all of this, engineering leaders are still expected to deliver.

To ensure that the team is spending their time in the right places, it’s essential to understand different approaches to prioritizing work to minimize risk and maximize impact. Engineering leads must also allow for balance timelines and flexibility, enabling the product to change as new insights come in, without letting development drag on. Making decisions in a fast moving environment can be overwhelming – it’s easy to get analysis paralysis. That’s why knowing when a decision needs to be made, and having a framework for making that decision, is crucial.

Key takeaways:

• How to know what aspects of a new system to build out first
• How to make decisions, while dealing with a lot of unknowns and pivots
• How to deal with changes in scope, especially when dealing with strict deadlines

Closing thoughts from the host.

Join facilitated conversations and dive into key issues facing engineering teams.

Chat with the speakers face-to-face in a relaxed, conversational environment.

Inspired by Lara Hogan’s Manager Voltron, meet other leaders to build your peer network at StaffPlus New York.

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?

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?

Join facilitated conversations and dive into key issues facing engineering teams.

Join facilitated conversations and dive into key issues facing engineering teams.

Explore solutions for your technical issues.

Watch or participate in free 1:1 coaching.

Dedicated sessions on how to take the next step in your career for stepping into the role of a Staff Engineer.

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?

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?

Join facilitated conversations and dive into key issues facing engineering teams.

Join facilitated conversations and dive into key issues facing engineering teams.

Join our relaxed sessions where you can meet peers working in similar domains to share ideas, collaborate on challenges and exchange solutions.

Learn how real engineering teams turn ideas into practice.

Dedicated sessions on how to take the next step in your career for preparing for the role of a Principal Engineer

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?

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?

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

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

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

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