The Lead Developer is programmed with a combination of invited speakers and successful applicants from our call for proposals.
Find out more about our fantastic speakers and their talks below.
Containers have been the future for five years now, featured on the stage of every major distributed systems conference in the world. But beyond the hype and the swag is a real technical solution, with real technical challenges, used for real problems at scale. And for the companies and engineers looking to adopt this solution, there’s little content on what awaits them.
In this talk, we’ll discuss some of the advantages and disadvantages of running containers, in production, at scale. We’ll address why to use containers, why not to, and the tradeoffs required at both the technical and human levels for implementing them. You will walk away with a better understanding of how containers could fit into your own architecture and what you’ll need to do to make that rollout a reality. Containers can be a great infrastructure solution, but no one should drive them without a manual.
Building psychological safety in your teams is critical if you want them to perform at their best. The challenge is how to develop and encourage the trust and collaboration and to make sure that all voices are heard.
The agile community has developed facilitation exercises and tools that make conversations more democratic and inclusive. I have used some of these techniques with my teams for years and have found them incredibly valuable. I will teach you some of the agile methods that I use for large and small team meetings, brainstorms, and one-on-ones that encourage all team members to participate. These tools also help make sure that all voices are respected and valued.
Often when we talk about goals, they’re from the perspective of the individual: how do you come up with goals for yourself? How do you achieve those goals? It’s often framed as activities for you to reflect and consider on your own. Goal setting is presented as something you go off and do on your own, and then present back to your manager or team.
As a manager though, I noticed that often people don’t know where to start when examining their own goals and they need help and encouragement to take the time to consider on what their goals should be. This talk will focus on how to create custom goal-setting workshops to use during your 1-on-1s, which questions to ask and how to help your reports achieve and stay on top of those goals.
On March 28, 1979, at exactly 4 o’clock in the morning, control rods slammed into the reactor core of Three Mile Island Unit #2, halting the nuclear reaction because of a fault in the reactor cooling system. At 4:02, the automated emergency cooling system activated as the reactor core temperature continued to rise. At 4:04, one of the plant operators made the befuddling decision to switch off the emergency cooling system, dooming the reactor to partial meltdown. Why?
When something bad happens, it’s easy to just blame someone and move on. Taking the time to find the systemic causes, though, will not only help keep the problem from repeating, it will enable you to build the psychological safety necessary for your team to truly collaborate. Let’s let the story of Three Mile Island teach us how to make our teams stronger through systems thinking and just culture.
It takes time and trust for a team to learn to work together well, and if you’ve achieved that it’s not surprising that you want to keep it that way. But unexpected events can disrupt your team’s equilibrium: people leave to take up other opportunities, wider priorities and strategies shift, and organisations restructure themselves. Change is guaranteed, so how do you handle its impact on your team?
You can equip your team with an understanding of their context and empower them to work productively in times of uncertainty. In this talk you’ll learn some practical steps you can take as a leader to build an open, outward-facing team who take ownership of their work, help each other learn and embrace new challenges.
The hard thing about being promoted to manager, or a manager of managers, is that each step is a completely different job – one you have not trained for. On top of that, it’s both harder to know _what_ to do and _how_ you’re doing, since your new manager is farther from your day-to-day work. Being promoted to a new management role, even though it’s a good thing, usually involves a steep learning curve on a set of brand new challenges, and the associated stress can contribute to a decline in mental health.
This talk is about applied learnings from my experience handling these challenges, as I made the transition from IC to an engineering manager to VP of Engineering of a 40-person team – working on improving government services for millions of people – in the span of a year. I draw upon my experience building technology to help people build habits and change behavior, as well as mistakes I’ve made as a startup founder.
Are you sick of seeing your team treated as a sausage machine for turning user stories into code? Can your developers only talk about how long something will take, or how exactly it will be built?
In this talk, I’ll explore how to get your team focused on delivering customer value instead by:
You’ll take home practices that will help your team start talking about customer value first.
It’s easy to forget what it felt like when you were a beginner. This lively dog-based* talk is about the rewards and pitfalls involved in introducing pair programming, TDD and an agile development approach to experienced developers who are used to working in a different way. It includes several practical suggestions of how to help and convince less agile-experienced colleagues.
Based on my experience as a consultant technical lead, the aim is to help you to move your team members to a state of childlike fearlessness where learning is fun; is embedded in everything you do; and applies to all team members regardless of experience.
*It turns out that images of dogs can be used to illustrate an astonishing variety of concepts!
Deploying website code might seem like dark magic to anyone not well versed in the specific tools and commands that go into orchestrating such complex systems, and crippling fear of breaking the website can be a real thing. However, it's possible to make the deployment process clear, easy and, dare I say, enjoyable for all involved!
Initially developed by a small team within Behance, and eventually growing into its own team and product, we've developed a continuous integration and deployment platform that places an emphasis on both deployment integrity and user (in this case, engineers deploying their code) happiness.
This talk will cover how we designed a process that empowers every engineer to manage their deploy from start to finish, from day 1, safely, effectively and quickly, and how our team structure and company culture allow us to quickly identify and iterate on improvements to the platform itself.
When Single Page Apps (SPAs) started becoming a standard approach for web applications around five years ago, it seemed like web-based products had a way to rival the interactivity and performance of corresponding native apps.
Modern browsers are incredibly capable, and open-source tools and frameworks promise to put slick web apps within reach of even the smallest teams.
And yet many product teams are already struggling with the SPA they have. They can be slow, buggy, hard to use and extremely resistant to change. The kind of thing that can kill a business. What happened?
In this talk, I'll explore some home truths about developing and maintaining SPAs in small- and medium-sized companies, and suggest some approaches technology leaders can take to haul their own products out of the mire. Spoiler: most of the challenges are not technical.
You've built websites that scaled to millions of users, indexed terabytes of data, and created automatic deployments to thousands of nodes - but now you’re struggling to manage a handful of people. You’re in meetings all day, deadlines are looming, a Board presentation is approaching, your top engineer just disappeared to "find themselves" and annual performance reviews are due! How did this spiral out of control so fast? Don’t Panic!
After mentoring and managing many tech leads & managers and interviewing top engineering leaders on my podcast, I have found that one of the biggest challenges they face is transitioning to properly scaling themselves.
Being a successful leader involves utilizing all of the resources available to you and becoming a force multiplier for your team. Learn how to expertly use prioritization, delegation, communication and time management to take control, build confidence, and scale to be a successful software engineering leader.
Companies more and more embrace working in a distributed environment. While it allows for attracting talent and working with great people around the world, it also means it comes with new challenges.
Based on my experience as an engineer manager at GitHub for a team of 20 people across 3 continents in 7 countries, 6 states in the US and 7 time zones I would love to share the things we do to build a strong and cohesive team. I'll also share how we embrace asynchronous workflows where we can effectively use the synchronous time we do have and regularly meet up in person.
The Continuous Delivery (CD) team at Spotify knows all about build pipelines. We run thousands of them every day. We were doing a lot of things right, but we still wanted to go faster and smarter.
Continuous delivery promises speed to production, but there are some prerequisites to working CD and craftsmanship practices. In this talk I will look at the team and the individuals as key components of CD. CD is built by teams of people, so let's look at how to improve that foundation.
You will hear about how techniques like “giving up the creme brulee” helped us get the talking going. You will also hear how we took feedback to a new level by using the transparency model from the non-violent communication movement. It’s the king of feedback, but buckle up, it’s a challenging ride but worth the effort. Finally, I will share how we successfully used OKRs to grow teams that continuously deliver.
Code reviews are critiques of a person's work. If they are invested in that work, then that critique feels personal. We rarely acknowledge that we or our peers might be taking code review comments personally, but we should! We can leverage that understanding to make our code review process more effective, and foster better working relationships. This talk will draw on conflict resolution theory as well as personal experience to help you talk honestly with your collaborators about how code reviews make you feel.
So you decided to become a lead, or you just became one! Now what?
In this talk, Dan walks you through his journey of switching roles, from a Senior Software Engineer to an Engineering Lead. He will also share his experiences, learnings and challenges during his first year as a lead.
He’ll talk about the reasons he decided to take this new role, his first steps and initial impressions about being a lead and about how this role helped him grow. He’ll share his mistakes, learnings and early wins. He’ll provide hints to people who plan to take the leading path, to help them smoothen their way. He'll also present the most impactful things new leads can do in order to keep their teams motivated, happy and to drive them towards a culture of high performance.
How do companies hire? And how does a manager build out a hiring process from the ground up? In this talk, you'll learn how one product & UX hiring manager used insights from behavioural science research and human-centered design principles to:
Whether you're looking to lead and build out your own hiring process, or you're job searching and want to hear a hiring manager's perspective, this session will help you learn how to conduct user interviews with new hires, and leverage those insights to improve interview resources, job descriptions, onboarding calendars, and partner with HR to scale the resources you built to help other departments with their hiring.
WARNING: Making the transition from developer to lead is not without risks. Side effects include (but are not limited to): diminished sense of purpose, constant lingering doubt and feelings of inadequacy. These symptoms may disappear over time. If not, consult a professional or watch this talk.
I was excited to become a lead developer when the chance presented itself but that excitement quickly faded when confronted with reality. Nobody told me what to do and as a result, I had no idea what I was supposed to be doing. I was unproductive as a developer, ineffective as a leader and considered giving up many times. In this talk, I will discuss how I overcame this situation and found what makes this job at least as rewarding as being a developer.
If we want to renew a big legacy system we have to choose between a big rewrite or a progressive code rejuvenation. People love to complain about their legacy systems, but they are successful systems which deliver real value to the business, and this is definitely a good thing. Still, the usual approach to legacy pain is a kind of take on the chin. I think we can do better than this
The first step to improve legacy code seems a catch 22. You cannot refactor or rewrite without tests and you cannot test without refactoring first. We will explore how can we solve this deadlock. I'll present my experience in working on a big system in the finance industry, how to choose between rewriting or rejuvenating and some refactoring techniques I developed specifically. The goal is to be able to work in a TDD fashion on a big legacy application without risky rewrites or big refactoring. Instead, we will see how to split the monolithic in modules easy to maintain and then disentangle small bits of code at time.
At some point, we all find ourselves at a SQL prompt making edits to the production database. We know it's a bad practice and we always intend to put in place safer infrastructure before we need to do it again — what does a better system actually look like?
This talk progresses through 5 strategies for teams using a Python stack to do SQL writes against a database, to achieve increasing safety and auditability:
We’ll talk about the pros and cons of each strategy and help you determine which one is right for your specific needs.
By the end of this talk you’ll be ready to start upgrading your infrastructure for making changes to your production database safely!
Functional programming makes it easier to write concurrent, testable and expressive code. Even if you’re working in the object-oriented or imperative paradigm, you can benefit a lot by learning functional programming.
For me, programming in functional languages greatly impacted how I write object-oriented and imperative code, and how I think about problems. My code is better structured, clearer and easier to reason about.
As a completely different paradigm, FP teaches you new ways to think. It helps appreciate benefits of immutability, lack of side effects and decomposition. You get used to expressing desired outcome of code, instead of steps to achieving a goal. This perspective is invaluable in traditional paradigms. And you may as well end up deciding that functional approach is the best fit for your next project.
If you haven’t tried FP yet, you’ll see how you can become a better engineer by learning it. If you have, you’ll get ideas how to encourage developers in your team to benefit from learning functional programming.
The tech industry has a lot of hiring to do. According to the Tech City 2017 report, “the digital sector is creating jobs 2X faster than the non-digital sector”. At the same time, the tech industry is lacking ways of helping those in underrepresented groups get their first tech role. A possible solution to both of these issues? More internships!
There are lots of things to consider with internships; how, what, who and where do I advertise? Where do I start? It can be a bit daunting. So as a seasoned intern and very active participant in the diversity in tech movement, Beverley has a lot of advice and tips to share with you all on how to go about internship success.
If you'd like to get involved in supporting the conference, please get in touch to request a sponsor pack.
Sign up to receive updates about The Lead Developer Conferences, including speaker previews, ticket launches, Call for Proposal details and other exclusive content. We won’t spam you and will only send you emails we genuinely think you’ll find interesting. You can unsubscribe at any time and you can find more information in our Data Promise.