Speakers & talks

Two days of technical leadership talks

We're thrilled to announce this year's program with more than two dozen hand-picked talks guaranteed to help you grow as a technical leader.

You can look forward to talks on code reviews, observability, hiring & developing juniors, technical debt, imposter syndrome, risk management, legacy systems, inclusive team building, and so much more!

Office Hours: Meet our speakers and get one-to-one advice. There's no need to pre-register, just drop in to say hi and ask your questions. Check the schedule for session times.

Leadership workshops: Join one of our practical workshops on April 6 & 9 for even more in-depth learning on mentorship, coaching, management, hiring and more. Find out more here.

A-Z speakers

Creating a Culture of Observability

Alyson van Hardenberg and Alaina Valenzuela

Senior Engineer | Software Engineer, Honeycomb

Alyson van Hardenberg and Alaina Valenzuela

As observability practitioners, we've witnessed how adding instrumentation allows us to ask questions of our system, and how this process has led to more reliable and robust systems. We know that observability is an important tool in any SRE's arsenal to help the team untangle tech debt and complexity.

As observability practitioners, we've witnessed how adding instrumentation allows us to ask questions of our system, and how this process has led to more reliable and robust systems. We know that observability is an important tool in any SRE's arsenal to help the team untangle tech debt and complexity.

Working at Honeycomb, we're constantly surprised to hear at least as many questions about the human side of observability as technical questions about its implementation. “How do I convince higher-ups that observability is important? How do I make observability be less of an afterthought?” At Honeycomb, we've developed processes and values to help us in this endeavor. We put all of our engineers on call, and onboard new team members in a fun and engaging way. We've developed tools that allow people to shoulder-surf asynchronously, and we've created spaces where people can share knowledge with both their future selves and the rest of their team. We've fostered a culture where failure is OK because everything is an experiment.

We will walk through a (tool-agnostic) case study of how we approach this at Honeycomb, both technically and culturally.

About Alyson van Hardenberg and Alaina Valenzuela

Alyson is a software engineer at Honeycomb with enthusiasm for charts and data visualizations. In her previous work, she has been everything from a registered nurse, to a customs officer, to working with kids with special needs. If you can think of a job, she's probably done it. She can often be found chasing her two little boys around, in the pottery studio or, baking sourdough.

Alaina is a software engineer at Honeycomb who has dabbled across the stack enough to know that CSS is way scarier than Ops. Before making the transition into tech, she was a marine biologist studying pinnipeds and birds. When she's not coding, she volunteers for the SF Latino Film Festival and seeks out art in all forms.

Refactoring: Managing technical debt before it blows up in your face

Amanda Sopkin

Software Engineer

BuildingConnected

Amanda Sopkin

Most engineering teams maintain their own balance between feature work and technical debt. This varies according to culture, funding phase, and even the product area. With little provocation, most engineers could probably rifle off a laundry list of items they’d like to tackle to improve their workflow, speed up processes, or just maintain their own sanity. However, work on technical debt for too long and you’ll lose sight of customer focus, neglect important features, and your engineers may begin to miss the shiny feature work that elevates their careers.

Most engineering teams maintain their own balance between feature work and technical debt. This varies according to culture, funding phase, and even the product area. With little provocation, most engineers could probably rifle off a laundry list of items they’d like to tackle to improve their workflow, speed up processes, or just maintain their own sanity. However, work on technical debt for too long and you’ll lose sight of customer focus, neglect important features, and your engineers may begin to miss the shiny feature work that elevates their careers.

So how do we decide when dealing with tech debt is worth it? On the ground, many developers struggle to find the balance between striving to improve existing code and letting good enough alone by accepting certain shortcomings. As a new developer to a team it can be difficult to understand existing strategies and patterns that are sometimes flat out bad (and often openly acknowledged as such). Often the result of tight deadlines or unclear specifications, even the best developers write code they later look back upon and shudder.

I will evaluate various approaches to balancing technical debt by going through a few case studies of successful technical debt projects. I will examine the scheduling and prioritization of these projects and how morale was impacted.

Come learn how to develop your own framework for addressing technical debt as a company. I will discuss strategies for refactoring with minimal impact, methods for working with bad code or systems you can’t change, and most importantly, frameworks for deciding the difference between what is fixable and what is better left alone. I will also point out warning signs of “exploding” technical debt that should be addressed sooner rather than later.

About Amanda Sopkin

Amanda is a San Francisco transplant from Denver, Colorado with a great love for coffee. She is a software engineer for BuildingConnected, which is a startup focused on connecting businesses in the preconstruction industry. She previously worked on the rentals team at Zillow. In her spare time she attends hackathons as a coach for Major League Hacking and does work for climate action advocacy groups. She enjoys writing, speaking, and obsessively reading about sharks.

Building inclusion through effective moderation

DeeDee Lavinder

Software Engineer

Spreedly

DeeDee Lavinder

Creating inclusive environments is an imperative for our industry at this time. One’s sense of belonging impacts productivity, company culture, and retention rates. While there are many important facets to fostering inclusivity, a few ways to help folks feel like they belong include asking for their opinion and input, acknowledging their contributions, and making safe spaces for differences to be seen, heard, and accepted.

Creating inclusive environments is an imperative for our industry at this time. One’s sense of belonging impacts productivity, company culture, and retention rates. While there are many important facets to fostering inclusivity, a few ways to help folks feel like they belong include asking for their opinion and input, acknowledging their contributions, and making safe spaces for differences to be seen, heard, and accepted.

The mere mention of a group discussion can have a polarizing effect on a team. There are those who love the opportunity to expound on any topic and there are those who do not say one word in an hour long meeting. Group discussions can be painfully awkward, sometimes seemingly pointless, sessions with low participation and little productivity. On the other end of the spectrum, with an effective moderator, a group discussion can be an invigorating experience. A committed moderator with a range of tools can elicit thoughtful and impactful feedback from all members of a team regardless of perceived seniority or personality.

We will discuss what an effective moderator does before, during, and after a group discussion. We will cover explicit strategies to creatively engage all members of your team. Learning how to successfully steer difficult conversations, how to handle conflicts with empathy and grace, and how to adapt your strategies on the fly will all be covered. These easy-to-implement strategies will improve your group discussions and tip the balance towards an inclusive environment where everyone feels heard.

About DeeDee Lavinder

DeeDee is a Software Engineer working in the payments landscape and a Director with Women Who Code. The intersection of analytical thinking and creative problem solving is where she is happiest and is thrilled about finding that sweet spot in technology. Previously DeeDee led the life of an entrepreneur and small business owner managing a community-focused store for new families. Over the past nine years, she has spent hundreds of hours as a teacher and facilitator for comprehensive sexuality education for young people. When not working or volunteering, you can find her listening to audiobooks, driving small people around, or coordinating something somewhere.

Stop playing detective: Use observability to tell a better story

Elizabeth Carretto

Senior Software Engineer

Netflix

Elizabeth Carretto

Investigating production issues in a microservice architecture can make you feel like Sherlock Holmes, searching through evidence and gathering sources to recreate the scene of a crime. Many times, this investigation involves digging into multiple log stores and dashboards to try to piece together a clear understanding of what led to your issue. This is costly, for engineering teams as well as customers --- the time spent sifting through clues while trying to find a root cause only further delays the resolution of the root cause.

Investigating production issues in a microservice architecture can make you feel like Sherlock Holmes, searching through evidence and gathering sources to recreate the scene of a crime. Many times, this investigation involves digging into multiple log stores and dashboards to try to piece together a clear understanding of what led to your issue. This is costly, for engineering teams as well as customers --- the time spent sifting through clues while trying to find a root cause only further delays the resolution of the root cause.

Distributed tracing can help. With distributed tracing, we can understand a request’s path through a complex system. But is that enough? At Netflix, we have taken distributed tracing, added in log correlation (with high-quality, detailed logs), and layered analysis on top. Not only does this reduce time for engineers to understand the root cause of an issue, we’ve been able to provide this tool to our customer operations, empowering them to understand the root cause and escalate with clarity, when necessary.

You’ll leave this talk with an understanding of distributed tracing and how to supplement traces with logs. You’ll see examples of how to shape your logs to clarify the business logic underneath a microservice’s response, and you’ll understand how tracing is the lynchpin to the type of detailed insights that will cut down on the cost of your teams operational burden.

About Elizabeth Carretto

Elizabeth Carretto is a Senior Software Engineer at Netflix on the Platform Experiences team, where she builds UIs for the observability space. She enjoys building tools that help engineers quickly understand the root cause when they get paged in the middle of the night.

Commit Messages vs. Release Notes: they’re important, they’re not the same, and they’re not for you

Eva Parish

Senior Technical Writer

Squarespace

Eva Parish

Commit messages are often treated as an afterthought, when they’re one of the most powerfully enduring ways to communicate to future developers – including yourself. Release notes are respected even less, often generated from commit history and generally unreadable.

Commit messages are often treated as an afterthought, when they’re one of the most powerfully enduring ways to communicate to future developers – including yourself. Release notes are respected even less, often generated from commit history and generally unreadable.

I’m going to show you why both are important, why they’re not at all the same, and why you should never generate one from the other.

We’ll go through the hallmarks of a good commit message and a good release note, including the audience for each and the appropriate level of detail. We’ll then write a commit message and a release note for the same change and compare them. And I’ll show you how to produce a set of great release notes with ease.

About Eva Parish

Eva Parish is a Senior Technical Writer at Squarespace. She has previously spoken at DevOpsDays NYC, and writes about tech-writing-related topics at evaparish.com.

Patching the hiring pipeline

Genevieve L'Esperance

Engineering Manager & Staff Software Engineer

Pivotal

Genevieve L'Esperance

Under-represented minorities are the elusive unicorns that every tech company publicly decrees wanting and needing for their business to succeed. The trouble is—minorities fall out of the pipeline at different stages and in large numbers. For a hiring manager, knowing that most of the pipeline is out of their immediate control can make patching it a daunting challenge.

Under-represented minorities are the elusive unicorns that every tech company publicly decrees wanting and needing for their business to succeed. The trouble is—minorities fall out of the pipeline at different stages and in large numbers. For a hiring manager, knowing that most of the pipeline is out of their immediate control can make patching it a daunting challenge.

It is safe to say that there is no silver-bullet for fixing the “pipeline problem”. It will take time and it will require effort - but patching the pipeline is critical to building a more inclusive industry and society. So where can you start?

This talk is a report on an approach to patching the leaks in a hiring pipeline. It includes a critical evaluation of the pipeline:

  • What leaks were found?
  • How were patches prioritized?
  • How were individuals selected to patch leaks?
  • How was feedback collected?
  • How were solutions iterated upon?

What was found is that if the “pipeline problem” is treated like any other engineering problem (by breaking it down into small parts and continuously improving on solutions to each) it can get everyone on the team—not just managers—to lean in and patch the leaks.

About Genevieve L'Esperance

Genevieve is an Engineering Manager & Staff Software Engineer at Pivotal. She has a B.Sc in Computer Science & Molecular Biology from McGill University. She has presented at the United Nations Social Innovation Summit and the United Nations Economic and Social Council’s Youth Forum on teaching young women test-driven development in a pair programming environment to inspire them to consider a career in tech. Currently, Genevieve is working to achieve pragmatic parity for windows containers with their Linux counterparts in Cloud Foundry.

Self-portraits in JavaScript

George Mandis

Lead Developer & Founder

SnapTortoise

George Mandis

In this talk we'll explore three different approaches to facial recognition in the browser to help us "draw" a self-portrait using JavaScript. We'll explore approaches that run entirely on the client-side using TensorFlow.js & other libraries, via web-based services (AWS, Google Cloud & Azure) and using the experimental Shape Detection API.

In this talk we'll explore three different approaches to facial recognition in the browser to help us "draw" a self-portrait using JavaScript. We'll explore approaches that run entirely on the client-side using TensorFlow.js & other libraries, via web-based services (AWS, Google Cloud & Azure) and using the experimental Shape Detection API.

We'll explore what it's like to work with each approach and what the advantages and trade-offs are. Finally, we'll discuss long-term security implications and ramifications we should consider as we introduce ourselves to basic machine-learning concepts through this creative exploration.

About George Mandis

George Mandis is a Google Developer Expert in Web Technologies and senior developer/consultant at SnapTortoise based out of Portland, Oregon. He speaks all over the world on JavaScript, programming & creativity through code. He's spent time living as a digital nomad, once inadvertently cheated running a marathon in North Korea and has spoken and led workshops at a number of conferences including Microsoft Build, Halfstack, FrontMania, C'T WebDev, FullStack London and HolyJS.

What Capuchin Monkeys Know that Engineering Leaders Don't 🐒

Jared Silver

Engineering Lead

DataCamp

Jared Silver

In a study popularized by Frans de Waal's 2014 TED Talk, two monkeys were given a simple task: take a rock from a researcher, give it back, and then collect their reward. For the monkeys, it was a pretty good gig: in exchange for a few seconds of minimal effort, they would each receive a delicious snack. But there was a catch. One monkey received a cucumber, while the other received a much-preferred grape. Mere minutes into the exercise, the monkey receiving the cucumber began to protest this perceived inequity. Rather than accept the cucumber reward, the monkey responded by throwing it back at the researcher.

In a study popularized by Frans de Waal's 2014 TED Talk, two monkeys were given a simple task: take a rock from a researcher, give it back, and then collect their reward. For the monkeys, it was a pretty good gig: in exchange for a few seconds of minimal effort, they would each receive a delicious snack. But there was a catch. One monkey received a cucumber, while the other received a much-preferred grape. Mere minutes into the exercise, the monkey receiving the cucumber began to protest this perceived inequity. Rather than accept the cucumber reward, the monkey responded by throwing it back at the researcher.

Just a few moments earlier, this monkey was perfectly content to receive a delicious cucumber in exchange for this minimal effort task. However, after seeing his companion receive an even better reward in exchange for the same effort, he resigned in protest. Why would this monkey give up a perfectly good reward  -- at his own expense  -- just because the other was receiving a slightly better one? And what can this anecdote teach us about building effective engineering teams?

This talk will cover the basics of equity theory, a theory of motivation which argues that both monkeys and software engineers match their level of effort with their perceived reward. We'll explore how to discover your team's grapes and cucumbers, what the best managers do to retain their top talent, and ways you can make your team both happier and more productive.

About Jared Silver

Jared Silver builds educational software with the goal of scaling access to effective, equitable learning experiences. Jared has worked for edtech companies such as DataCamp and Quill.org, and he studied organizational behavior and operations management at Babson College. Jared lives in NYC where you can catch him making cheese boards, sampling an unhealthy number of interesting dessert spots, and spending too much time on Twitter when he's not working. You can follow him @JaredSilver.

Blame, shame & panic - how not to respond when things go wrong

Jemma Bolland

COO

The Scale Factory

Jemma Bolland

No matter how much you plan or mitigate the risks, people are going to make mistakes. How you react to that as a manager is one of the most important things you can work on to increase the health, performance, and resilience of your team.

No matter how much you plan or mitigate the risks, people are going to make mistakes. How you react to that as a manager is one of the most important things you can work on to increase the health, performance, and resilience of your team.

And it's hard. Much harder than all the shiny policies you can introduce when things are going well. Because in the heat of the moment we often react emotionally rather than with practicality, measure and kindness.

We're getting better at this as an industry. Blameless post mortems are more common and the days of wearing the hat of shame or buy the beers when you mess up have, thankfully, mostly gone. But how much better are we in our interactions when one of our team does something that will reflect badly on us as a manager? Do those old feelings of shame, or panic, or the avoidance of blame rear their heads? Does that have an impact on how you respond to people?

Most of us have weathered a few moments when our blood has run cold as we realise we've done something that feels catastrophically bad. Whether it was damaging or a learning experience was almost definitely shaped by the reaction of the people around us, especially managers. This is the difference between being able to fix the problem as quickly as possible and learn from it and the situation spiraling.

By exploring our own reactions to being in the chain of responsibility of an error we can build our own resilience to absorb the fallout, protect our team and help them to feel safe enough to take responsibility and grow from these experiences.

About Jemma Bolland

Jemma is in charge of operations, marketing, people and finance at The Scale Factory. Her 15+ years’ experience in operational, strategic and marketing roles with start-ups and SMEs in the UK and Australia brings a wealth of insight to her role. Jemma's experience in the start-up world provides a distinct lens on the topics of people management, cultivating culture and championing D&I during periods of growth.

Scaling your leadership mindset

Jessie Link and Joy Su

Senior Directors of Engineering, Twitter

Jessie Link and Joy Su

As your area of responsibility scales, how do you scale yourself as a leader?

As your area of responsibility scales, how do you scale yourself as a leader?

Joy and Jessie will break down what it means to lead teams of teams, how your approach needs to evolve and what you need to focus on to be successful at the next level. We'll cover how to think about wrangling orgs of large size (100+ people) across multiple offices, from organizational design to communication patterns. We'll also cover how to coach your managers into becoming senior leaders themselves.

About Jessie Link and Joy Su

Jessie Link is a Sr Director of Engineering at Twitter where she currently oversees part of the Consumer engineering group. She is based in the UK, where she also serves as the Engineering Site Lead. Previously she was a Sr Director of Engineering at LivingSocial and a Director of Engineering at Lookingglass Cyber Solutions. She is a military veteran and served as a Captain in the US Air Force. She is passionate about building high performing diverse teams and frequently speaks on leadership topics. In her spare time, she enjoys gaming, movies and working on coding side projects.

Joy Su leads the Consumer Foundation & Health engineering team at Twitter, responsible for the core systems that power the consumer experience. She has extensive experience treating dysfunctional teams and helping them get healthy. In her spare time, she enjoys drinking tea, travel, and eating all the things.

Game-changing: grassroots diversity in action

Jennie Lees

Engineering Manager

Riot Games

Jennie Lees

You don't have to be the head of D&I to make diversity and inclusion a priority, but how do you avoid taking on a second job if you do? Speaking from personal experience as an engineer and manager, Jennie will walk through ways that individuals can effect change in their organizations, and how to manage and mentor others who want to do the same.

You don't have to be the head of D&I to make diversity and inclusion a priority, but how do you avoid taking on a second job if you do? Speaking from personal experience as an engineer and manager, Jennie will walk through ways that individuals can effect change in their organizations, and how to manage and mentor others who want to do the same.

Sounds straightforward? Being a grassroots diversity activist is not always easy, especially when company culture is a moving target. Jennie experienced this firsthand when Riot was the subject of a damning press exposé in 2018, an event which caused the entire company to question its culture. During the explosion of activity that followed, many brave individuals stepped up to drive diversity-focused efforts while the company itself took time to introspect and change. As one of the company's few female engineering leaders, Jennie found herself caught in the middle of this explosion of cultural change. This talk will examine the factors that helped some of these efforts succeed and the lessons learned along the way.

Attendees will take away actionable steps to empower emergent leaders and create systems that do the same, while avoiding common traps along the way.

About Jennie Lees

Jennie is an engineering manager at Riot Games in Los Angeles, where she supports teams building game features for the unreleased tactical FPS ""Project A"" and programs in Go when she can find time. Her background includes wearing many hats at startups, product management at Google, and a year spent as a tour guide.

Growing junior engineers

Johnny Austin

VP Engineering

Till, Inc

Johnny Austin

Let’s face it; good senior engineers are rarely available, always expensive, and never as good as you think. The good news is, you don’t always need to hire from the top. There’s a case to be made that more junior engineers can provide a solid foundation for a strong technology platform. I don’t mean to indicate that you don’t need any senior engineers, only that you should reconsider team composition.

Let’s face it; good senior engineers are rarely available, always expensive, and never as good as you think. The good news is, you don’t always need to hire from the top. There’s a case to be made that more junior engineers can provide a solid foundation for a strong technology platform. I don’t mean to indicate that you don’t need any senior engineers, only that you should reconsider team composition.

Under the right mentorship, cultural norms and intentional steps, you can quickly get engineers with two years of experience, contributing at the near-senior-level quality. It won’t be easy, and it’ll take a lot of groundwork from you, and the rest of your team. However, if you follow this roadmap, you’ll find that you can get much further with less experience on your team. Furthermore, by investing in your eary-career individuals, you are uniquely positioned to create your type of senior engineer - not the ones you inherit from your competition, or from unrelated industries.

About Johnny Austin

Johnny is an experienced engineering executive focused on shipping world-class products. He has built and led high-performing, globally-distributed engineering teams and is a strong advocate for engineering operational excellence. Johnny is also an international public speaker - speaking on topics such as engineering leadership, system design, and the JavaScript programming language.

He is the former Curriculum Development Lead for the DC chapter of Black Girls Code - an organization dedicated to teaching young women of color how to program. He is also an educator - having taught various courses through General Assembly. Johnny is currently helping people attain financial stability as VP of Engineering at Till in Washington, DC.

Good technical debt

Jon Thornton

Engineering Manager

Squarespace

Jon Thornton

“Technical debt” is a dirty word in the software engineering field, but financial debt isn’t universally reviled in the same way. The difference is intention. What if tech debt wasn’t always an accident, caused by incorrect assumptions and unexpected circumstances? How would you spend a tech debt mortgage?

“Technical debt” is a dirty word in the software engineering field, but financial debt isn’t universally reviled in the same way. The difference is intention. What if tech debt wasn’t always an accident, caused by incorrect assumptions and unexpected circumstances? How would you spend a tech debt mortgage?

This talk presents an investment-based approach to thinking about software development. Time is our currency; we can spend it now, and we can also take on technical debt that commits us to spend time later. Project tasks are investments that cost time and return something of value, like user-facing features or learnings for the development team. But watch out—most investments aren't a sure thing, so you need to spend wisely.

By taking risk into account and prioritizing creating value sooner, you can reduce wasted effort and improve your project's odds for success. We'll discuss how this framework was used to rapidly build and ship Squarespace's Email Campaigns platform in less than 15 months. Along the way you'll get several practical guidelines for how tech debt can supercharge your technical investments, with real examples from inside Squarespace.

About Jon Thornton

Jon is an engineering manager at Squarespace in New York City, where he recently led the team that built Squarespace's new email marketing platform. Previously he led product engineering teams at Blink Health and Knewton, and cofounded Arrive. Jon likes public transit, rock concerts, and NYC's beaches.

Imposter strategies

Keiran King

Product Designer

Thoughtbot

Keiran King

70% of us will suffer from Imposter Syndrome at some point in our careers — the idea that we're professional frauds, faking a competence that will surely be found out one day. Maybe today! Maybe tomorrow! What will happen when we're revealed to be... a normal human being?! (Cue 1950s horror-movie screams.)

70% of us will suffer from Imposter Syndrome at some point in our careers — the idea that we're professional frauds, faking a competence that will surely be found out one day. Maybe today! Maybe tomorrow! What will happen when we're revealed to be... a normal human being?! (Cue 1950s horror-movie screams.)

Most advice about overcoming Imposter Syndrome — Amy Cuddy's power poses, Sheryl Sandberg's 'lean in' movement — boils down to one maxim: be confident. Not feeling it? Be confident-er. Raise your hand. Stand like Superman. As Elle and Cosmopolitan editor Farrah Storr says, "Say yes to everything." It's true — we could all use better posture, more poise and a little pluck. But confidence is just an attitude; it's not a strategy. Useful, maybe even necessary, but not sufficient. "Alright, I'm confident. Now what?"

This talk answers that question. It provides the *how* — concrete, actionable steps to uncover the source of our anxiety and systematically learn our way out of it. It draws from a wide range of texts (from Mihaly Csikszentmihalyi's "Flow" to Taiichi Ohno's "Toyota Production System"), as well as my own experience in consulting and the tech industry, to help us all — even you! — peel off our alien Imposter skins and do well at work.

About Keiran King

Keiran is a product designer, helping clients make accessible, intuitive digital tools. He's spoken at NYC Design Week, BrooklynJS and across countless restaurant tables about how to find new markets, solve meaningful problems and build tools that include, empower and delight people. He lives in New York and likes crosswords, soup and his wife, not necessarily in that order.

Sunsetting legacy systems: a story by Netflix

Marek Kiszkis

Senior Software Engineer

Netflix

Marek Kiszkis

Legacy systems are like wisdom teeth. You know you’ll need to address the problem at some point, but unless it’s bothering you all day and keeping you awake all night, sometimes we just keep delaying it. When setting priorities, deprecation efforts often end up not making the cut.

Legacy systems are like wisdom teeth. You know you’ll need to address the problem at some point, but unless it’s bothering you all day and keeping you awake all night, sometimes we just keep delaying it. When setting priorities, deprecation efforts often end up not making the cut.

Only more pain comes once you start working on actual deprecation: having to understand obscure and untested code, reverse-engineering the contract, weeks of testing and debugging, ensuring minimal disruption when actually flipping the switch.

This is a story of a 2-year-long deprecation of a legacy system that used to support several crucial parts in Netflix’s signup and account management space. Come and learn:

  • The 3 most important skills for deprecating legacy systems: inquisitiveness, proactiveness and simplification mindset
  • A few technical approaches we took which proved extremely useful, eg. retrofitting end-to-end tests or using A/B experiments - and a few which we wish we didn’t take
  • How Netflix culture of freedom and responsibility enabled the project to move forward, despite the usual prioritization caveats - and how to apply this in your team
  • What principles (both technical and people-oriented) we established for the new system, with the hope of giving it a longer shelf life

About Marek Kiszkis

Marek Kiszkis has been developing software for the last 10+ years, at companies like IBM, Google, and most recently, Netflix. His experience has taught him to always look for simple solutions to complicated problems. To that end, he searches for and contributes to efforts related to software quality, clean code and reducing technical debt. He actually, sincerely enjoys working with legacy code.

No engineer left behind: How to build a strong and synchronized engineering team

Malini Valliath and Garima Sharma

Software Engineer, Pivotal

Engineering Manager, Pivotal

Malini Valliath and Garima Sharma

Software teams can often be siloed - there will always be differing levels of familiarity with the codebase, varying levels of engineering experience, and deep pockets of expertise within a team. This can create an environment where new engineers feel hesitant in their abilities to contribute as individuals, while other engineers may feel burdened with the context they carry. This slows team growth, productivity, and health.

Software teams can often be siloed - there will always be differing levels of familiarity with the codebase, varying levels of engineering experience, and deep pockets of expertise within a team. This can create an environment where new engineers feel hesitant in their abilities to contribute as individuals, while other engineers may feel burdened with the context they carry. This slows team growth, productivity, and health.

How can you create an environment where all team members - newcomers, experienced engineers, and expert “superhero” engineers - can work in harmony when their experiences and skillsets vary so greatly?

Our team at Pivotal started adding various practices to our team rhythms to help spread context and responsibility. These practices have helped our team share expertise and build a collective vision. Our team went from a siloed team with concentrated expertise, to a team with a renewed sense of confidence, context-sharing, and individual empowerment. Our favorite techniques include weekly Learn & Shares, team mobbing exercises, and Dungeon & Dragon scenarios. In this talk, we will go over the practices we used on our team, how they work, and how they can make your team stronger and more effective.

About Malini Valliath and Garima Sharma

Malini is a Software Engineer at Pivotal New York. In her time at Pivotal, she has contributed to the open-source project BOSH, for Windows support, as well as contributing to the .NET Developer Experience team. She is passionate about user-centered design, creating healthy, fun teams, and fostering an environment of learning.

Garima Sharma is a DevOps Engineer at Pivotal, New York. Coming from a developer background, she has been working in DevOps for more than 6 years with various agile teams. She has worked on cloud providers like GCP, AWS, DigitalOcean along with private data centers. She has been part of devops for large enterprise client, startup and now PaaS. She holds experience of planning and conducting migrations of various environments, ensuring security and minimum downtime. She is passionate about using the pragmatic approaches of agile methodologies to DevOps world.

The Test Pyramid demystified

Marilene Lourenço and Thayse Onofrio

Quality Analyst Consultant, ThoughtWorks

Software Engineer, ThoughtWorks

Marilene Lourenço and Thayse Onofrio

In an agile environment, it is impossible not to talk about testing. The "fail fast" principle also applies to test driven development and continuous delivery. We no longer wait for software to be deployed in a test environment to have someone responsible for clicking buttons and discovering that it doesn't work as expected. We now have pipelines that allow us to run automated testing before getting to production, with less need for manual testing, and making developers equally responsible for the quality of the software they are building.

In an agile environment, it is impossible not to talk about testing. The "fail fast" principle also applies to test driven development and continuous delivery. We no longer wait for software to be deployed in a test environment to have someone responsible for clicking buttons and discovering that it doesn't work as expected. We now have pipelines that allow us to run automated testing before getting to production, with less need for manual testing, and making developers equally responsible for the quality of the software they are building.

However, there are a lot of questions on how and what to test. With so many different types of tests, how are we supposed to know which ones we should apply to our software? How many tests are enough? If the metrics show our code has 100% coverage, does it mean we don't have any bugs?

That's why in our talk, we will talk about the original test pyramid and expanded versions of it, anti-patterns, as well as present case studies, and touch on important matters such as continuous delivery and test coverage. Together, we will understand how to balance out the test pyramid, improving the quality strategies of technology teams.

About Marilene Lourenço and Thayse Onofrio

Marilene has worked at ThoughtWorks Brasil since 2018 as a Quality Analyst Consultant, and she is always interested in learning more about the entire software development process. She actively participates in the Quality community and has been interested in jointly building Quality strategies for teams as well as writing on strategic issues such as Test Pyramid and Cross Functional Requirements. She is in love with dogs and chips.

Thayse is a black LGBTQ+ woman trying to make the world a better place. She is also a Software Engineer at ThoughtWorks Brazil. She loves writing code and is enthusiastic about best practices. She is passionate about making technology more inclusive and diverse, and is a co-organizer at AfroPython.

Calling out a terrible on-call system

Molly Struve

Lead Site Reliability Engineer

DEV

Molly Struve

Back when our team was small, all the devs participated in a single on-call rotation. As our team started to grow, that single rotation became problematic. Eventually, the team was so big that people were going on-call every 2-3 months. This may seem like a dream come true, but in reality, it was far from it. Because shifts were so infrequent, devs did not get the on-call experience they needed to know how to handle on-call issues confidently. Morale began to suffer and on-call became something everyone dreaded.

Back when our team was small, all the devs participated in a single on-call rotation. As our team started to grow, that single rotation became problematic. Eventually, the team was so big that people were going on-call every 2-3 months. This may seem like a dream come true, but in reality, it was far from it. Because shifts were so infrequent, devs did not get the on-call experience they needed to know how to handle on-call issues confidently. Morale began to suffer and on-call became something everyone dreaded.

We knew the system had to change if we wanted to continue growing and not lose our developer talent, but the question was how? Despite all of the developers working across a single application with no clearly defined lines of ownership, we devised a plan that broke our single rotation into 3 separate rotations. This allowed teams to take on-call ownership over smaller pieces of the application while still working across all of it. These individual rotations paid off in many different ways.

With a new sense of on-call ownership, the dev teams began improving alerting and monitoring for their respective systems. The improved alerting led to faster incident response because the monitoring was better and each team was more focused on a smaller piece of the system. In addition, having 3 devs on-call at once means no one ever feels alone because there are always 2 other people who are on-call with you. Finally, cross-team communication and awareness also drastically improved with the new system.

About Molly Struve

Molly Struve is a Lead Site Reliability Engineer. During her time working in software the industry, she has had the opportunity to work on some challenging problems. These include scaling Elasticsearch, sharding MySQL databases, and creating an infrastructure that can grow as fast as a booming business. When not making systems run faster, she can be found fulfilling her need for speed by riding and jumping her show horses.

Leading through rapid change and turnaround

Rachana Kumar

Senior Director of Engineering

Etsy

Rachana Kumar

These days, large organizational shifts are the norm, especially in the tech industry. Sometimes that change is driven by innovation. Sometimes it is driven by growth and scale. Sometimes that change is driven by a fundamental shift and reorganization in the way a company must continue to do business.

These days, large organizational shifts are the norm, especially in the tech industry. Sometimes that change is driven by innovation. Sometimes it is driven by growth and scale. Sometimes that change is driven by a fundamental shift and reorganization in the way a company must continue to do business.

In late 2017, my company was undergoing a lot of changes - changes in leadership, changes to structure, and changes that directly impacted myself and my team. As a result of these changes, both myself, my colleagues, and my team were faced with a number of challenges. I was faced with a question that many people find themselves asking in similar situations: Should I still be here?

If the answer is “Yes, I want to stick around” (believe me it pays off), Are you prepared to lead through change? During this discussion I will share three important tools to equip lead developers to lead their teams through significant organizational change, enabling them to stay afloat and make a positive impact amidst the chaos.

After attending this session, attendees will learn:

  • The 3 most important tools for leading through significant change ( - Communication and Transparency, Resiliency, Effectively managing up and down)
  • The career benefits of staying at a company going through significant organizational change
  • Role of technical leadership during rapid changes
  • An understanding of how to build these tools amongst your team and your organization

About Rachana Kumar

Rachana Kumar is an award winning, global minded industry leader with a passion for using innovative technology to help others. In her current role as Senior Engineering Director at Etsy, she leads several product engineering teams, directing engineering initiatives that impact over 2 million creative entrepreneurs and 36 million active buyers. Rachana is driven by the intersection of technology, social impact and helping everyone do their best work. Her passion is technical product development - building and leading diverse product and engineering teams to solve hard problems, drive business impact and have fun doing so. Her experience spans multiple countries and industries ranging from media and ecommerce in the US, the sociopolitical space in India, and international development in Cambodia.

She has received Digital Diversity Network’s Innovation and Inclusion Code Breakers Award, Innovators & Disrupters Award from New York on Tech and Future CIO Award at Women in IT Awards.

Reliability and More, Prevent a 737max Crisis in Production

Ricardo Aravena

Infrastructure Manager

Rakuten

Ricardo Aravena

The maneuvering characteristics augmentation system (MCAS) is a software system that typically allows a 737max to automatically adjust its pitch in low-speed and high angle of attack situations. The Boeing 737max crisis is one of the most recent examples of software checks and controls going wrong.

The maneuvering characteristics augmentation system (MCAS) is a software system that typically allows a 737max to automatically adjust its pitch in low-speed and high angle of attack situations. The Boeing 737max crisis is one of the most recent examples of software checks and controls going wrong.

Your software is not perfect like the MCAS, so it's essential to keep customers and users abreast of its pitfalls, along with having an awareness of the aspects that need to be monitored, secured, and tested in your organization. How do you make sure your customers are getting the right documentation about any possible flaws? What security controls does your team have to avoid skipping critical steps before delivery? What mechanism do you have in place to monitor its usage after delivery?

This talk explores some of the new patterns in cloud software - covering terms of security, observability, and reliability, together with a side story of what to prevent before a '737max' type of predicament arises. We'll discuss what can help keep software systems happy, increase customer satisfaction and avoid catastrophic results.

About Ricardo Aravena

Ricardo currently works at Rakuten as an Infrastructure Manager, automating everything in containers using open source and lately contributing to the Kata Containers project. He has been working in tech for more than 20 years and comes from a diverse professional background, having been in different roles at large companies such as Cisco and VMware as well as startups such as Coupa, Hytrust, Exablox, and SnapLogic. Most recently he was at Branch Metrics where he spent 2 years working on automating their cloud infrastructure to handle millions of requests and petabytes of data on a daily basis.

Harassers are nice to me

Sarah Milstein

Senior Director of Engineering

Mailchimp

Sarah Milstein

In any organization, there will be people who behave inappropriately, sometimes grievously so. Here’s the paradox: the more senior the role you’re in, and the more power you have to help coworkers who are facing awful behavior like harassment or bullying, the less likely you are to see those things.

In any organization, there will be people who behave inappropriately, sometimes grievously so. Here’s the paradox: the more senior the role you’re in, and the more power you have to help coworkers who are facing awful behavior like harassment or bullying, the less likely you are to see those things.

Personally, when I was younger and in junior roles, I dealt with harassment all the time. Now? I rarely see it directly. That's not because it happens less now. Instead, it's because harassment and bullying are functions of power, and people who behave in those ways tend to perceive me as having relative power. So they're generally very, very nice to me. If you’re in a position of power--say, as a manager or tech lead--they’re probably very nice to you, too. So how can you become aware of harassment and bullying that happens when you’re not in the room? And what can you do about it? This talk will look at techniques for surfacing and addressing bad behavior.

About Sarah Milstein

Sarah Milstein is a Senior Director of Engineering at Mailchimp. Previous roles include Head of Sales & Marketing for 18F.gov; VP of Programs for indie.vc; CEO and co-founder of Lean Startup Productions; and co-author of The Twitter Book. She's also held senior management positions at O’Reilly Media, UBM TechWeb, and several startups. Earlier, she was a freelance journalist writing regularly for The New York Times, she co-founded a record label with children’s musician Laurie Berkner, and she started Just Food's CSA program. She holds an MBA from UC Berkeley and a BA from Rutgers University. Bonus fact: She was the 21st user of Twitter.

Why most technology migrations fail (and what we’ve learned along the way)

Saunak 'Jai' Chakrabarti and Jenni Lee

Director of Engineering (Core Infrastructure), Spotify

Global Head of Technical Product Marketing, Spotify

Saunak 'Jai' Chakrabarti and Jenni Lee

Migrations, often seen as a necessary evil and bain of existence for engineers. Spotify is no exception to the laws (and pitfalls) of migrations that pay down debt and help advance tech strategy. While we share common problems with every other tech org, because of our scale and organizational structures and decisions, we have iterated on a set of principles and processes to ease the pain of transitioning from one tech stack - whether it be as low level as OS or language version - to higher level product features.

Migrations, often seen as a necessary evil and bain of existence for engineers. Spotify is no exception to the laws (and pitfalls) of migrations that pay down debt and help advance tech strategy. While we share common problems with every other tech org, because of our scale and organizational structures and decisions, we have iterated on a set of principles and processes to ease the pain of transitioning from one tech stack - whether it be as low level as OS or language version - to higher level product features.

Spotify is a globally distributed company with 280+ engineering teams and 1200+ microservices. We’ve had a strong focus on engineering autonomy, and, as such, within our Platform (infrastructure) org, have had to cultivate ways to drive migrations with carrots over sticks. We’ve achieved this through a strong focus on product and product marketing techniques, quantitative insights, and driving a clear value proposition for engineers. We’ll share our learnings (and misses) about how we were able to move molehills and, in some cases, mountains while preserving engineering velocity and a sense of ownership and autonomy.

About Saunak 'Jai' Chakrabarti and Jenni Lee

Saunak "Jai" Chakrabarti is the Global Head of Core Infrastructure at Spotify, where he is responsible for many dimensions of Spotify's service ecosystem - from idea to deployment to operating and troubleshooting services at scale.

Jenni Lee is the Global Head of Technical Product Marketing for the infrastructure and developer platform team at Spotify. She is responsible for driving migrations and product adoption within Spotify’s engineering teams, and for the development of Spotify’s R&D presence and brand (outside of Spotify).

Bottom-up org change and evolution

Sebastian Duque

Senior Engineer

Intercom

Sebastian Duque

It's expected for the structure of your teams and organization to change as you grow. This is also true for the processes and communication channels you need in place so that everyone remains highly effective. What works well for a team of ten engineers falls short once you have thirty. You adapt and then feel some friction again when you get to a hundred. Rinse and repeat. At Intercom we’ve iterated and been through this process a few times having grown engineering from one team of four engineers sitting together in the same room to 160 people in 30 teams across three countries and two time-zones.

It's expected for the structure of your teams and organization to change as you grow. This is also true for the processes and communication channels you need in place so that everyone remains highly effective. What works well for a team of ten engineers falls short once you have thirty. You adapt and then feel some friction again when you get to a hundred. Rinse and repeat. At Intercom we’ve iterated and been through this process a few times having grown engineering from one team of four engineers sitting together in the same room to 160 people in 30 teams across three countries and two time-zones.

I’ll share how we’ve been successful at empowering engineers to drive organizational change. They're uniquely positioned being the vast majority of the org and at the same time closest to some problems. This allows them to identify, solve and own solutions to the challenges they face. When is it important to iterate? How do you identify when you've outgrown your current setup? How do you set yourself, and the org, up for success? This talk should give you some ideas and answers to these and apply them to existing or future problems your teams might face.

About Sebastian Duque

Sebastian works as an Engineer at Intercom in San Francisco. He enjoys seeking impact and growth wherever he is. Outside of work, you can find him having mexican food or planning his next snowboarding adventure.

On remaining an Individual Contributor

Suz Hinton

Senior Software Engineer

Stripe

Suz Hinton

At a certain point in a lot of coder's careers, the inevitable "have you considered becoming a manager?" rears its head. Perhaps your people skills are being confused with a desire to switch careers. Maybe the company you work at doesn't have a career ladder beyond "senior" unless you start taking on direct reports. What does this all mean for your growth and longevity at this point in your career?

At a certain point in a lot of coder's careers, the inevitable "have you considered becoming a manager?" rears its head. Perhaps your people skills are being confused with a desire to switch careers. Maybe the company you work at doesn't have a career ladder beyond "senior" unless you start taking on direct reports. What does this all mean for your growth and longevity at this point in your career?

How do you keep doing what you love while having more influence on important decisions made by leadership? Having been in this situation personally many times, I've tried a number of tactics to navigate the desire to stay an individual contributor. This talk proposes strategies and new attitudes to help ensure enrichment for individual contributors in their daily work lives, including how people managers can support them best.

About Suz Hinton

Suz Hinton is a programmer at Stripe working on making Terminal easier to use. She is experienced in many layers of the stack from embedded development and security all the way up to frontend development, accessibility, and cloud computing. Previous to Stripe, Suz has worked as a programmer at companies including Microsoft, Kickstarter, Zappos, and The National Gallery of Victoria. In her spare time, she likes to stay ahead of new technologies by maintaining open source libraries and streaming herself doing so live for viewers around the world to watch online.

Nurturing a cross-cultural code review culture

Swati Swoboda

Senior Software Developer

Shopify

Swati Swoboda

As technical folk, there is plenty of talk about "how to do business with other cultures" -- but what about "how to code with other cultures?" How do you trust a code review from someone whose upbringing of "never publicly correct" prevents them from providing important feedback on your code review? Or is it "what happens when B is deleted?" versus "this will blow up on production when B is deleted"? At least for Canadians it's the former because that's the polite thing to do and nearly all Western, English media will tell you so. But what if that isn't...polite? What if politeness varies across cultures? What happens to code and code reviews then?

As technical folk, there is plenty of talk about "how to do business with other cultures" -- but what about "how to code with other cultures?" How do you trust a code review from someone whose upbringing of "never publicly correct" prevents them from providing important feedback on your code review? Or is it "what happens when B is deleted?" versus "this will blow up on production when B is deleted"? At least for Canadians it's the former because that's the polite thing to do and nearly all Western, English media will tell you so. But what if that isn't...polite? What if politeness varies across cultures? What happens to code and code reviews then?

Increasingly, companies make a great deal of effort in hiring for diversity, and especially diversity of thought. Most can avoid day-to-day conflict and learn to work with different cultures. But code reviews are different...code reviews are often an invitation for negative feedback and conflict. Different still, code reviews are almost always a written and devoid of any verbal cues. This talk aims to highlight how different cultures review code and how a healthier communication culture can be established for teams.

About Swati Swoboda

Swati attended Elementary School in India, Middle School in UAE, High School in USA, and University in Canada. Aside from the cultural identity crisis brought up by the varying, immersive childhood experiences, the travels also place her in a situation to have an empathetic understanding of communication across cultures. Today, Swati is happily married to a Polish-German Canadian with three culturally confused kids of her own. She has been writing code since the age of 11, and continues to do so at Shopify as a Developer.

Sponsors

Thank you to all our fantastic partners who help make our event happen.

Would you like to join the community and align your brand with The Lead Developer? Contact us for our 2020 sponsorship prospectus.

Premier Sponsor

Twitter

Platinum Sponsor

LaunchDarkly

Platinum Sponsor

Big Nerd Ranch

Talent Partner

Hired

Industry Partner

PepsiCo

Industry Partner

Target

Industry Partner

Work & Co

Gold Sponsors

Silver Sponsors

D&I Partner

Salesforce

Office Hours Sponsor

Intercom

Bronze Sponsors

Never miss another update

Want to be the first to hear about the ticket launch or CFP? Sign up to our newsletter so you never miss an important update! To find out more about our newsletter content and how the data is handled check out our Data Promise.