The Lead Developer Berlin

Speakers & talks

The Lead Developer Berlin is programmed with a combination of invited speakers and successful applicants to the call for proposals. The content of the conference is based on the themes of teams, tech and tools: how to develop your team, new and emerging tech, and processes to improve the way you work.

All the talks at the conference will be delivered and live captioned in English.

The schedule will be announced closer to the conference. If you're booking travel in the meantime, we expect the conference to start around 9 AM and finish around 5:30 PM.

Conference chair

Meri Williams

Conference chair

About Meri Williams

Meri is a geek, a manager, and a manager of geeks. She’s a CTO and also runs micro-consultancy ChromeRose, helping digital & technical teams be brilliant. An alumna of Procter & Gamble and the Government Digital Service, she has had a career spanning development, project, programme & product management and more recently engineering & operations leadership. She’s led teams ranging in size from 30 to 300, mostly with folks spread across the world.

Making good trouble, or: how to affect change without losing your job

Duretti Hirpa

Senior Software Engineer

Mailchimp

Sometimes, we want to make changes to processes and habits our team has, but it’s not around the code itself. How can we do that? How do we make changes to the habits of hundreds? Moreover, how can we do this work as individual contributors?

Sometimes, we want to make changes to processes and habits our team has, but it’s not around the code itself. How can we do that? How do we make changes to the habits of hundreds? Moreover, how can we do this work as individual contributors?

Many times, debugging your organization is work that goes undone but can be an effective force-multiplier. This talk will act as a starting guide to making good trouble at work, culminating in tangible tips for how to rebrand troublemakers into change agents.

About Duretti Hirpa

Bio coming soon..

Scaling performance at Slack's scale

Aish Raj Dahal

Software Engineer

Slack

One of the major challenges faced by teams working on high growth product is of performance. Systems that are built for a given scale of users often fail to deliver the necessary throughput when run with orders of magnitude of load more than what they are built for. Software teams have historically resorted to a myriad set of ways in scaling performance.

One of the major challenges faced by teams working on high growth product is of performance. Systems that are built for a given scale of users often fail to deliver the necessary throughput when run with orders of magnitude of load more than what they are built for. Software teams have historically resorted to a myriad set of ways in scaling performance.

In this talk, I aim to shed some light on how Slack scales its performance to its millions of global users. I would cover the various aspects of Slack's performance scale, going in from the people aspect of it - where the focus would be on describing how several backend, frontend and SRE teams work in unison to solve scalability woes, to the implementation aspect of it - where the highlight would be on giving a technical picture of how it is done in a short example case study.

About Aish Raj Dahal

Aish is a software engineer at Slack where he helps Slack scale for its largest customers. In the past he has worked in high growth companies like PagerDuty where worked in building resilient real time data pipelines. Prior to that he had spent time at HackerRank and Goldman Sachs.

Not all leaders have titles

Amy Chen

Systems Software Engineer

VMware / Heptio

We all know that tech team leads and engineering managers are leaders. But can engineers without “Senior” or “Manager” tacked to their titles be leaders too?

We all know that tech team leads and engineering managers are leaders. But can engineers without “Senior” or “Manager” tacked to their titles be leaders too?

Technical leadership comes in different forms from all levels of seniority. You don’t need direct reports to be a leader at your technical organization. In this talk, I will share…

Personal anecdotes of leadership displayed by both myself and my teammates

Strategies I find effective to enable me to be a leader

Behaviors that discourage budding technical leaders

About Amy Chen

Amy Chen is a software engineer at VMware via the Heptio acquisition. She is passionate about distributed systems, containers, Kubernetes, and Go.

In her free time, Amy runs a youtube channel called Amy Codes where she talks about technical and non-technical aspects of being a software engineer. She aims to make the container and infrastructure industry more accessible by sharing her learning process and resources through video. Amy also frequents the conference speaking circuit at conferences like Kubecon, Open Source Summit, and Gophercon among others.

Writing effective documentation

Beth Aitman

Documentation Lead

Digital Asset

Documentation can make a big difference. Internal documentation can speed your team up and makes it easier for new engineers to get up and running. External documentation reduces time spent on support questions, and makes your product more usable.

Documentation can make a big difference. Internal documentation can speed your team up and makes it easier for new engineers to get up and running. External documentation reduces time spent on support questions, and makes your product more usable.

But we often don't get round to writing documentation, because it's kind of a pain, and we don't know where to begin. So in this talk, I'll give a primer on writing effective documentation, and on helping your team to write docs too. I'll cover:

What makes documentation useful

How to make it easier to get started

How to make writing clear and readable

About Beth Aitman

Beth Aitman is a documentation lead at Digital Asset, a fintech company in Zurich, where she works with engineers and product managers to improve the developer experience. She’s interested in the intersection between UX and writing, and is passionate about teaching developers to write good docs. Outside of work, she likes to run around, climb rocks, and solve cryptic crosswords.

Cultivating architecture

Birgitta Boeckeler

Principal Developer

ThoughtWorks

Many organizations today strive to establish autonomous development teams who can move as independently of each other as possible.

Many organizations today strive to establish autonomous development teams who can move as independently of each other as possible.

The goal is to achieve speed, scalability and motivation - but what does architecture governance look like in such a decentralised setup? I’ll discuss how to keep everybody aligned on a shared understanding of the architecture and avoid prescriptive standardisation without getting chaos.

About Birgitta Boeckeler

Birgitta is a Principal consultant and developer with ThoughtWorks. She has been building software across all layers for more than 15 years, mainly in the space of large custom-developed websites. At ThoughtWorks, she spends most of her time as a Lead Developer, splitting her days between coding, coaching, consulting and keeping things fun.

Breaking the (developer) silos

Elin Nilsson

Android developer

Spotify

Technology at Spotify is filled to the brim with talented, driven and passionate engineers, who together work to solve the challenges we face to reach our north star goals. One of our core beliefs is Collaboration, and one obstacle to be great at collaborating with each other are the silos that we sometimes unknowingly and unwillingly put ourselves in, where we restrict ourselves by disciplines and even by syntax.

This is a joint talk of Raul Herbster and Elin Nilsson.

Technology at Spotify is filled to the brim with talented, driven and passionate engineers, who together work to solve the challenges we face to reach our north star goals. One of our core beliefs is Collaboration, and one obstacle to be great at collaborating with each other are the silos that we sometimes unknowingly and unwillingly put ourselves in, where we restrict ourselves by disciplines and even by syntax.

In this talk, you’ll hear what happens when you break those silos, as Raul and Elin walk through what they’ve experienced and learned in the process of collaborating closely between mobile and backend development.

About Elin Nilsson

Elin is an Android developer at Spotify, working on platform and architecture, and master in cat gif communication.

Breaking the (developer) silos

Raul Herbster

Senior Software Engineer

Spotify

Technology at Spotify is filled to the brim with talented, driven and passionate engineers, who together work to solve the challenges we face to reach our north star goals. One of our core beliefs is Collaboration, and one obstacle to be great at collaborating with each other are the silos that we sometimes unknowingly and unwillingly put ourselves in, where we restrict ourselves by disciplines and even by syntax.

This is a joint talk of Raul Herbster and Elin Nilsson.

Technology at Spotify is filled to the brim with talented, driven and passionate engineers, who together work to solve the challenges we face to reach our north star goals. One of our core beliefs is Collaboration, and one obstacle to be great at collaborating with each other are the silos that we sometimes unknowingly and unwillingly put ourselves in, where we restrict ourselves by disciplines and even by syntax.

In this talk, you’ll hear what happens when you break those silos, as Raul and Elin walk through what they’ve experienced and learned in the process of collaborating closely between mobile and backend development.

About Raul Herbster

For a decade, Raul has been working with tools and infrastructure, providing support for developers with different backgrounds, and in companies with different sizes, including startups and Spotify. Initially with focus on mobile and embedded software engineering, Raul added more to his repertoire: backend, data and more recently management. He is an advocate for multidisciplinary on software teams, and has changed recently from a mobile-driven tribe, to a backend-driven tribe at Spotify. Working on blending the culture is a challenging and rewarding experience that he is proud to talk about.

Lessons for frontend development at scale

Hannes Obweger

Development Manager

Atlassian

Powered by technologies such as React and GraphQL, we see frontend applications reach a level of scale and complexity that was traditionally associated with backend engineering and service architectures. But the browser is also a unique execution environment: All parts of the system share the same runtime, and all parts of the system are not only supposed to provide meaningful APIs to each other, but also to expose a fast, delightful UI to the user. For engineering teams stepping into modern frontend development, it hence becomes critical to distinguish between patterns that can be transferred over from the backend, and patterns that need to be adapted, or dismissed altogether.

Powered by technologies such as React and GraphQL, we see frontend applications reach a level of scale and complexity that was traditionally associated with backend engineering and service architectures. But the browser is also a unique execution environment: All parts of the system share the same runtime, and all parts of the system are not only supposed to provide meaningful APIs to each other, but also to expose a fast, delightful UI to the user. For engineering teams stepping into modern frontend development, it hence becomes critical to distinguish between patterns that can be transferred over from the backend, and patterns that need to be adapted, or dismissed altogether.

About 2 years ago, Jira started its transition towards a modern, React-based Single Page Application. What began with one team of absolute React experts quickly turned into a multi-team, multi-geo program - and just as quickly, maintaining the health and scalability of our frontend codebase became a top priority, and one of the biggest challenges, of the Jira engineering team.

In this talk, we'll be sharing some of the lessons that Atlassian has learned over the past 2 years - many of them, the hard way - along with the tooling that we have developed. We'll be talking about our transition from an inside-out model to an outside-in model for integrating legacy and modern code, our approach to providing architectural guidance and consistency across 300 engineers, and our philosophy and tooling for managing a mono-repo of more than 1M lines of JavaScript code.

About Hannes Obweger

Hannes is the engineering manager responsible for Jira's frontend platform, which provides the build and deployment infrastructure, dev tooling, and application architecture for Jira's new, React-based UI. Today, the frontend platform powers a codebase of more than 1M LoC, with 300 individual contributors in total, and 200 contributors every month.

How does salary work?

Kevin Goldsmith

CTO

Onfido

You make a hire for your team. The person wants 20% more than anyone else. Should you give it to them?

You make a hire for your team. The person wants 20% more than anyone else. Should you give it to them?

Your manager gives you a 5% raise budget for your team. Do you give them all 5% or give one person 15% and the rest 1%?

You think you are giving a great raise to one of your top performers, but they let you know that they expected much more.

A person on your team approaches you because they got a job offer for 10% more than their current salary. Should you try to match it?

The management debt that gets accrued by poor decisions around salary is extremely painful to fix. In this talk, I will give you the tools and ideas that you can use to be well prepared for the next salary review. I will help you avoid accruing management debt around pay in your team.

How is the salary budget calculated? How you can argue for the extra budget to adjust someone that is not being paid well. Where you can find extra money to make a meaningful difference for someone. Why sometimes it is better to do no raise at all, then do a small one. How you handle the conversation when someone isn't happy with their increase. How do you decide what salary to offer a candidate? How can you make sure that you are not increasing pay disparity between different groups?

These are problems that Dev Leads face all the time. The impact of making a wrong decision is massive to an individual. The mistake of paying someone too little or too much can affect them for years.

Understanding how salary works helps you create a happier and healthier team.

About Kevin Goldsmith

Kevin Goldsmith has been a developer, software architect, technology manager, and senior technology executive for over 27 years. He is currently the Chief Technology Officer at Onfido in London, a machine learning and computer vision company helping users own their identities on the internet. Formerly, Kevin was the Chief Technology Officer at Avvo; the Vice President of Engineering, Consumer at Spotify; a Director of Engineering at Adobe Systems; and, development lead at Microsoft.

Becoming a team, one pixel at a time

Lena Reinhard

Director of Engineering

CircleCI

Psychological safety is one of the leading indicators of a high performing team. Yet, forging deep human relationships and building trust can be difficult when your team is distributed or largely interacts on screens.

Psychological safety is one of the leading indicators of a high performing team. Yet, forging deep human relationships and building trust can be difficult when your team is distributed or largely interacts on screens.

Beyond the practical considerations of time zones, remote isolation, cultural differences, and “can you hear me now?” connection issues, there are added, real barriers in our psychology and biology that make building strong teams over distances and screens harder than for teams all in one place. Yet, with the right conditions, distributed teams can be stronger, more deliberate, and produce better results than ones where everyone shares the same lunch table.

In this talk, I will share my learnings on how to hone connection, communication, and collaboration on distributed teams. We will dive into how you can utilise these three aspects to help your engineers shape their day-to-day interactions for relationship building, design processes for creating trust, and fostering an inclusive culture. Regardless if you’re managing teams across the world or within the same building, learning these approaches will help you become more strategic, communicate better, and build highly aligned, well-connected and strong teams that deliver great products.

About Lena Reinhard

Lena is currently Director of Engineering at CircleCI, the leader in continuous integration and delivery for developer teams. After a career in finance, arts, and media, Lena found herself working in tech and at age 26 co-founded her first software company and became a CEO. Ever since, she’s been supporting globally distributed engineering organisations, helping them deliver great products while continuously learning through inclusive cultures and growth-oriented feedback. Lena is convinced that only diverse teams in inclusive organisations can build appropriate solutions for the challenges that humanity is facing. She is also a proficient writer, photographer, and forever a learner.

All hands on deck - handling security issues

Markus Holtermann

Engineer

Crate.io

In this talk, we will look into what it means for a company when there is a security issue in a piece of software. This talk will provide suggestions on who needs to get involved.

In this talk, we will look into what it means for a company when there is a security issue in a piece of software. This talk will provide suggestions on who needs to get involved.

We live in a world of technology and engineering. Almost everything around us requires software. Unfortunately, the software we use or build has bugs. While most bugs can be fixed, there are these other types of bugs, called vulnerabilities, that cause headaches and haunt us at night. Security issues can be found in our own infrastructure, on customers' infrastructure, or — worse — around user data. It is on us as engineers to do the best we can to not make security issues in the first place. But it is on everybody involved in a product to provide communication, guidance, and support when an issue exists.

About Markus Holtermann

Markus Holtermann works as a back-end and infrastructure engineer at Crate.io. For a decade, he has been a member of several Open Source communities and gained experience in communication, community management, engineering, and security by taking on various tasks. Markus has been a project lead at the German ubuntuusers.de community support platform, he is a member of the security team for the Django web framework, as well as an organizer and advisor for DjangoCon conferences. In his free time, Markus is a hobby photographer.

Learning from incidents: understanding how things went right

Nick Stenning

Site Reliability Engineer

Microsoft

When things go wrong, we tend to focus on mistakes, miscalculations, and deficiencies in design. By limiting our investigations to the details of what went wrong, we ignore a far richer and more interesting source of learning: how things went right.

When things go wrong, we tend to focus on mistakes, miscalculations, and deficiencies in design. By limiting our investigations to the details of what went wrong, we ignore a far richer and more interesting source of learning: how things went right.

Research across numerous safety-critical industries such as aviation and medicine is changing what we know about how to build systems and organizations which are resilient to failure. We will look into the findings of that research and discover how we can avoid falling into common traps of investigation which curtail our ability to learn. This research shows us that the best results come when we are able to answer questions such as:

How does the system normally work?

How did we recover?

How do teams adapt to surprising circumstances?

Where did we get lucky, and what worse outcomes did we avoid?

We will share stories from beyond the boundaries of our own industry in order to show how powerful some of these new investigative techniques can be. We will move beyond a shallow analysis of root causes and remediation items in an effort to build truly resilient engineered systems for the future. You'll leave this talk with some simple and practical steps you can take in your own team to help you learn not only "what went wrong?" but also "what went right?"

About Nick Stenning

Nick Stenning is a Site Reliability Engineer at Microsoft, working on Azure. He previously worked at the UK's Government Digital Service and the startup Travis CI. He's been talking his colleagues' ears off on the topic of post-incident review for close to a decade.

Nicky Thompson

Technical Manager

FutureLearn

As a new manager, your changed responsibility is not to build features, but to build systems to support the people building the features. It can be a challenge to figure out how to prioritise problems alongside the day to day pastoral care of your team.

As a new manager, your changed responsibility is not to build features, but to build systems to support the people building the features. It can be a challenge to figure out how to prioritise problems alongside the day to day pastoral care of your team.

In this talk, you’ll learn how to apply agile software engineering principles to your new career in engineering management. DRY, single responsibility, separation of concerns - how can you use these familiar tools and techniques from your time as a software engineer to help ease yourself into management?

This is a practical show & tell of how we organise engineering management work at FutureLearn, and a discussion of the good and bad things about it. After this talk you’ll be able to take advantage of all the familiar ways of working you learned about engineering as a developer.

About Nicky Thompson

Nicky is a Technical Manager at FutureLearn, providing management and support to the Technology Team.

She has spent more than two decades as a freelance and in-house developer (including an earlier four-year stint at FutureLearn) - delivering successful projects for clients ranging from global banks and major publishing houses to indie storytelling agencies. She’s worked with designers all over the world, making beautiful websites that work for everyone.

Levelling up: the way of the Lead Developer

Pat Kua

Chief Scientist

N26

The transition from a developer to a Lead Developer can be a rocky one.

The transition from a developer to a Lead Developer can be a rocky one.

Yesterday, you were working as a developer and today, suddenly, you find yourself in the role of the Lead Developer. What does this new role mean, and how do you make yourself successful? In this talk, Patrick will explore the ways in which a developer can level up and discover the way of the Lead Developer.

About Pat Kua

Patrick Kua is the Chief Scientist and former CTO of the mobile bank N26 (Berlin, Germany), where he is building the engineering group that will change modern retail banking for people like you and me. Formerly a Principal Technical Consultant at ThoughtWorks, he is the author of three books, The Retrospective Handbook, Talking with Tech Leads and most recently, Building Evolutionary Architectures. Patrick is a frequent conference speaker, blogger and is passionate about bringing a balanced focus between people, organisations and technology.

Making impossible decisions one step at a time

Scott Triglia

Ads Group Tech Lead

Yelp

Being faced with an important choice that feels impossible to know the answer to is stressful! This comes up a lot when making business decisions, but also applies to technical choices (e.g. "should my company run 100% on AWS" or "is serverless a fad or a great idea?"). The decision can feel impossible, but the reality is you still have to choose, even if the right choice can't be known a priori!

Being faced with an important choice that feels impossible to know the answer to is stressful! This comes up a lot when making business decisions, but also applies to technical choices (e.g. "should my company run 100% on AWS" or "is serverless a fad or a great idea?"). The decision can feel impossible, but the reality is you still have to choose, even if the right choice can't be known a priori!

Challenges include:

Making decisions where we have little to no experience with one of the options

Best and worst case outcomes are either unknown or have a scary amount of variance.

Sufficiently new ideas often imply unknown challenges lurking. What if those unknown challenges are really bad and make it unappealing in hindsight?

New ideas might imply major architecture changes that are outright dangerous!

Come learn strategies for tackling impossibly large decisions by breaking them down, making iterative bets, and creating feedback loops that guide you through the unknown. We’ll ground discussion in case studies from my own experience and point out various failure modes you should avoid along the way.

About Scott Triglia

Scott Triglia is a Tech Lead at Yelp and loves making large backend systems reliable and effective. He helped architect Yelp's nearby recommendation engine, was the lead maintainer of business and search geocoding, and lead Yelp's Commerce Platform group for payments and billing. Currently he is technical lead Yelp's advertising group.

Leading engineering teams through rapid change

Yvette Pasqua

CTO

Meetup

As an engineering leader, there will likely come a time when you need to manage your team through change. Sometimes it will be a lot of change all at once and sometimes it will be a series of changes over time. Change can also manifest in many forms like technical and architecture change, cultural change, and organizational change. For example, in just the past year I've worked at a company that has re-architected our platform, been acquired, grown by 75%, and hired a new CEO. Through all types of change, your team will need you to support and lead them through it.

As an engineering leader, there will likely come a time when you need to manage your team through change. Sometimes it will be a lot of change all at once and sometimes it will be a series of changes over time. Change can also manifest in many forms like technical and architecture change, cultural change, and organizational change. For example, in just the past year I've worked at a company that has re-architected our platform, been acquired, grown by 75%, and hired a new CEO. Through all types of change, your team will need you to support and lead them through it.

In this talk, I will walk through a framework for leading engineering teams through change, using real examples and things I've learned as an engineering leader during times of rapid change and growth. Some experiences I'll draw from include: working at five different companies who have been acquired, re-architecting dozens different products and platforms, and spearheading several culture changes and re-orgs. The framework will pivot around two important centers: what you can do to support your team and what you can do to support yourself.

About Yvette Pasqua

Yvette is the CTO of Meetup. She leads the engineering team with a focus on continuous learning, iteration, and using data to launch software that brings people together around the world to do what they love. Her team's work enables 40 million members in over 190 countries to organize and build communities in real life. Prior to joining Meetup, Yvette’s career included engineering leadership roles at startups and product development firms like Schematic, Possible, and AKQA. Yvette led the engineering team who built Grindr during the first few years of Grindr’s most rapid growth.

Sponsors

Are you looking to grow your engineering team, engage with the community and gain brand exposure?

The Lead Developer is the perfect opportunity to connect with hundreds of technicals leaders and senior developers. If you'd like to get involved in supporting the conference, please get in touch to request a sponsor pack.

Premier Sponsor

Gold Sponsor

All Other Sponsors

Keep up to date

Sign up to our newsletter to receive news and updates. To find out more about our newsletter content and how the data is handled check out our Data Promise.

Previous events

Upcoming events

Meetups

17 October, BerlinOther upcoming meetups
We organize regular meetups in London, Berlin, Austin and New York, and San Francisco! We're looking forward to getting together with the community of technical leads in more cities soon.