We're very excited to welcome this year's speakers! They'll share insights and experience on hiring diverse teams, fixing out-of-hours on-call, building security culture, guiding self-organising teams and so much more!
The schedule will be announced soon. If you're booking travel in the meantime, we expect the conference to start around 9 AM and finish around 5:30 PM.
Looking to make the most of your conference experience? Check out our training workshops on 7, 10 & 13 June.
There’s a lot of talk nowadays about the impact that artificial intelligence (AI) will have on testing. There’s a new generation of testing tools being developed that employ AI with promises of making testing much more efficient for us. This is very exciting, and I look forward to using these tools. However, the tester in me also realizes that testing tools aren’t the only products utilizing AI. Aspects of AI such as machine learning exist today in products that we’re using on a daily basis! I reject the common notion that AI is this omniscient black box that doesn’t require testing, and I’ll spend 2019 touring the world to spread this message.
If we want to truly encourage diversity in our industry, we are going to have to listen and respond to feedback from under-represented groups that challenges our assumptions. In 2015, my previous employer Bytemark built a fully-anonymous recruitment process in order to help address issues of hiring bias and to try and attract a diverse range of candidates. You might think problem solved.... but no! Despite introducing a supposedly better process, we still weren't receiving applications from a wide range of candidates. We realised that in order to diagnose the issue, we would need to conduct user research. Through speaking to these candidates, successful and unsuccessful, alongside undertaking research at conferences and with peers, we found that some aspects of our "ideal" process were actually put off certain candidates, especially women, from applying. In my 10 minute talk, I will present some of our learnings from this research and offer examples of how they can be applied to any hiring process. I will also argue that in order to be a truly inclusive industry, we need to start gathering and really listening to feedback that makes us uncomfortable with the status quo.
Uptime matters, but so do your people. At Intercom, keeping our product online and working well at all times is critical to the success of our business. Out-of-hours on-call is inherently disruptive to your life as an engineer. You need to be ready to respond quickly and competently to an alert about something being broken. This means having a decent Internet connection, a computer, power for the computer, whatever you’re using for 2FA, and passwords available. However, we realized that we had ended up with an on-call setup that we weren’t proud of, and had a number of problems to solve. There were too many people on-call at any one moment in time. The quality of alarms and runbooks was inconsistent across teams and there were ad-hoc review processes for new and existing alarms. We decided to attempt to solve these problems by creating a new virtual team that would take over all out-of-hours on-call work, consisting of volunteers, not conscripts, from teams across the engineering organization. This talk goes into the process we applied, the positive impact to our on-call, and lessons learned.
Security is an increasingly important aspect of software development, especially for services that process and store sensitive data. In rapidly growing and dynamic organizations, infrastructure teams need to balance building features to support product growth and business goals while maintaining a secure platform. At Stripe we believe that security is a collective responsibility, and it’s especially important to closely collaborate with security teams to continually improve the quality of decisions and changes that affect sensitive systems. In this talk, we’ll discuss strategies for building a culture of security so infrastructure and security teams can each play to their strengths while maintaining high development velocity. We’ll walk through some examples of both how we typically run security-sensitive projects at Stripe as well as processes that help to extend security awareness (and interest!) through the rest of your organization.
How many talks, articles, and podcasts have you seen about organizational change, and how to implement it? How many of them talked about what we can learn from non-human psychology? This is that talk. I'll give you concrete and actionable advice for how to make change happen in your organization, one person at a time, by being nice. Make it rewarding to do the right thing, and people will do the right thing more often. Understand that people are motivated by different things and you'll be able to talk to them more effectively. Inspirational leadership can only get us so far, and we can do the rest with hard work, consistency, and compassion.
Quantum computers are real and are starting to be used for some interesting applications. As well as many applications in finance, organic chemistry and complex dynamical systems there is an ugly elephant in the room. That elephant is Shor's algorithm. Given a sufficiently powerful quantum computer, Shor's algorithm can factorise numbers in polynomial time. I have implemented it on a quantum simulator and it has been used on real quantum computers. When quantum computers are powerful enough nearly all the encryption techniques that we currently rely on will be useless. The time is still far off when RSA will be useless but I will share some compelling reasons why we need to be taking action right now to avoid potential catastrophe in the not too distant future.
One of the challenges facing teams, particularly small ones, is having to balance the time spent on doing fun new things and having to support old (or antique!) systems and processes. These are the 'business as usual' (BAU) things which probably underpin the current revenue of your business. As such they are critically important but are almost certainly unloved and possibly even loathed by the teams responsible for them! BAU includes fixing bugs, handling support problems, running regular or ad hoc processes, and dealing with legacy systems amongst other things. Based on four years of experience at the Royal Pharmaceutical Society, this talk presents some of these challenges and suggest tactical options for dealing with them day-to-day as well as how to go about understanding and fixing the underlying problems. The problems and solutions are not just technical: dealing with the psychological impact of the problem and how it affects teams has been one of our biggest challenges - get it wrong and productivity and turnover are badly affected, further limiting the team's effectiveness. You will learn: how and when to say no; when to take time to fix and optimise; how to deal with a deluge of BAU; how to manage people working on BAU; and what we experienced when we were getting it wrong and finally when we got it right!
We’ve probably all been asked to come up with a set of software estimates for a project with very little detail, very little time to do it and plenty of quizzical looks when it’s given. Writing software is very rarely like painting a room, where a person can reasonably give an estimate to the nearest day. Between tech debt, lack of useful documentation and a new requirement never done before, it is very hard for a software team and the lead developer to come up with what the business often wants – an accurate estimate! (if such a thing were possible). So, what is the solution? Story pointing, MVPs, spikes and an iterative approach all help towards a goal of better software estimation and so the success of a project, but the best, single most important element I have seen is the existence of trust between a software team and product owner. On the product owner that they won't make promises to the business based on estimates and on the software team that they will give an honest assessment of the work involved and not inflate estimates. When it works it is a powerful thing and is a million times more effective than the ‘them’ and ‘us’ attitudes that exist in some places and that do nobody any good.
When bootstrapping new teams, they need to go through the standard process of forming, storming, norming and performing. And in the context of fast-growing companies, with their own level of uncertainty, how can we achieve high performance when teams and goals are constantly changing? How do teams deal with different degrees of uncertainty? And how can leaders support them in feeling safe and motivated? Throughout the years, I've found some ways to help teams achieve this. Some of those were a direct result of my experience, others were inspired by my peers and other companies, and others I was able to derive from coaching sports or teaching people. In this session, we’ll talk about some of the ideas leaders can implement to help teams move faster into high performance.
Over the past few years, I’ve gained expertise in front-end web architecture. I’ve done this work at Indiegogo, Headspace, for my open source mental health project if-me.org, and in my current role at Mailchimp. At Indiegogo, we evaluated frameworks in an effort to migrate from AngularJS. At Headspace, I architected an MVP in React and created best practices. With if-me.org, we migrated to React from jQuery. At Mailchimp, we are migrating from Dojo to React. This talk isn't about comparing frameworks, but rather the art of front-end architecture. Since I wouldn't be where I am today without the virtual pets site Neopets, I’ll be sharing the lessons I’ve learned in building out a sustainable team, prioritizing focus areas, evangelizing best practices, and advancing your career along the way. It’s like being a kid in the 2000s hustling for Neopoints and the coolest guild on the interwebs! I'll share insights on team communication, docs, testing, performance, accessibility, component design, and refactoring.
Everywhere we look, developers are working on side or ‘passion’ projects. While these projects are incredible ways to expand your knowledge faster, accelerate your career, and gain recognition in the developer community, the truth is that not everyone can or wants to spend extra time outside of work on coding. The result of this is a tech industry that is less diverse and inclusive when some people are able to progress further and faster while others aren’t. One way to help level the playing field while allowing your developers to grow and learn faster? Allow them to spend 10% of their time at work working on anything they want - no strings attached. By giving people trust, permission, and time to pursue what interests them the most, we found that our developers were more engaged with their work, took charge of their learning, and brought more passion and creativity into their everyday work lives -- all of which in turn benefits their actual projects. In this talk you’ll learn: how and why we embrace 10% time in Internal Product at the Financial Times; how it has helped me and the team I’m on; and how you can begin to implement this concept as well.
Friction is a common, and necessary, part of team growth—but when left unchecked, team friction is unhealthy for you, your coworkers, your company, and ultimately your end users.
In this presentation, I draw on my experiences at organizations large and small to illuminate the sources of team tension, how you can better understand and manage unexpected teammate reactions, and the best ways to give actionable feedback without escalating drama. Your coworkers, your organization, your users, and you will reap the benefits.
We’re 10 years into Android and iOS development and there are more ways to build an app than ever before. Let’s look at the options, be it native app development or cross-platform systems like Xamarin, ReactNative or Flutter: What is core to these frameworks? What implications do they bring to your product and your development team?
Creating or migrating to a microservices architecture might easily become a big mess, not only due to technical challenges but mostly because of human factors: it's a major change in the software culture of a company. In this talk, I'll share my past experience as the technical lead of an ambitious microservices-based product, I'll go through the parts we struggled with, and give you some advice on how to deal with what I call the six pitfalls:
We’ve all had that experience where we’ve planned the perfect discussion only to have it hijacked by a passionate side-person, lose focus halfway through, or produce the exact same takeaways as you had before you began the discussion. With a few tricks in your back pocket, you can recover from some of these tricky situations or even prevent them in the first place! I’ll share some of my best techniques and provide some yellow flags I’ve learned to recognize that signified needing to make a change.
When Gustave Eiffel built his namesake tower, it was nearly twice as tall as the tallest structure on Earth. His crews built it in an astounding 22 months, pioneering new construction techniques to deliver it in time for the opening of the 1889 Exposition Universelle. It was amazing then, and it’s just as captivating today. We all say we want to do groundbreaking work, just like Eiffel, but what does it actually take to push an organization forward? The answer starts long before the work itself. Let’s see what we can learn from how Gustave Eiffel went about building his record-shattering tower.
In my role as a VP of Engineering at a fast-growing startup, I spent hundreds of hours interviewing and sourcing candidates in the last year alone. The bar we set ourselves was high: not just hire people with excellent skills and culture add, but also maintain and improve our current diversity (33% women, 9% race) across experience levels. The result of that is an inclusive and effective hiring process that lets us successfully grow the team while providing a great candidate experience. Even candidates who reject our offers end up recommend us to their friends! This talk will take you through a step-by-step hands-on guide on improving your skills as an interviewer and setting up a better hiring process at your company - no matter how large or tiny. Learn about:
Over the many years, Patrick has trained, coached and mentored many engineers into Technical Leadership roles. He is delighted by the way that everyone has their own style and "flavour" of being a Technical Leader. In this talk, he will explore what technical leadership is and the impact people can have through their individual flavours of technical leadership.
When your team is wholly distributed it can be tough to develop a team spirit, strong culture and shared approach. This talk will highlight the difficulties we've seen and suggest tips and tricks that we have experimented with to improve this. In a recent internal company survey, we identified that one of the challenges our team experiences working remotely is the sense that we don't actually feel like we are part of a team. This has led us to consider how this impacts the work that we deliver as well as the detrimental effects on individuals within the team. Over the last few months, we have experimented with several different approaches to improve communication, grow trust and build team culture. In this talk, I will provide examples of the experiments that we have tried, describe the results that these have had and set the scene for where we might look to experiment further in the future.
It’s all well and good for the agile manifesto to recommend self-organising teams, but what does that actually mean in practice? What’s the best way to do it, how far should you take it? Total anarchy is probably not the answer here… right? After bouncing around leading a whole bunch of teams of different shapes and sizes over my career, I have some insights into how to guide effective self-organisation and create amazing teams. I’ll also share plenty of battle stories, including major re-organisations of entire engineering departments, structured completely by the developers in them. Whether your entire department needs shuffling, you’re starting a new team, or just adding a new team member, you should walk away with plenty of ideas of how to guide your team to make the best possible decisions - for themselves.
You’ve done it all: you programmed, scaled, managed clients, stayed calm in emergency situations, managed expectations, trained your team and mastered code reviews. But suddenly it all gets too much. You never reach the end of your todo list. You can't even see the end any longer! “It’s just much faster if you do this one tiny thing myself!” “Legacy code - I'm the only one left who knows it so I better do it myself, it's just a small thing anyway!” “A client who is so used to chat with me needs a meeting - I better meet them myself quickly!” “Yes no problem, I’ll do this little thing today” This is a quick tip guide on which techniques to use to transform from a busy leader to a brave expert in delegation, how to say no and getting stuff done while keeping your team and yourself happy and sane. A summary from someone who learned (and is still learning) it the hard way.
We’ve all read the articles and got excited by technologies such as machine learning, deep learning, Tensorflow, Panda and NumPy. A lot of us are also looking at how to incorporate these technologies into our toolset and in the software we are building. What we have not had a lot of discussion about yet is what exactly does it mean to build AI software? Do we need different concepts to communicate ideas and design systems? In this talk, we start by first answering the question of whether we should even care. Is AI going to be around long enough for this to be a concern or is it just another fad? (spoiler: it’s probably not a fad). Given that we should care then how should we think of software that incorporates AI? I will provide a conceptual framework that will help to identify where AI fits in a specific context, what type of AI makes sense and how you can begin to talk about it in systems architecture terms. This is the framework we use ourselves to design intelligent services and it follows an agent-based view of software development. Agent-based or agent-oriented development is the space within AI where the concerns of engineering AI architectures are most explicitly addressed. The best part of the talk is that by the end of it you will not need to use the term AI anymore. Instead, you can pinpoint and describe the actual thing you need to build in clear, unambiguous terminology. Going away from this talk you will have another perspective on:
How does time impact on your working day? Would you like to hack time and live outside the clock? The answer is likely to be yes. In October 2018, Sal and Clare took an all-female team to Hack Manchester, built a time machine and won Best in Show. They are now taking their time machine on tour: You too can press the button and stop time. Have a nap, play tricks on your friends, or force the trains to be on time. Seriously though, repeated research has suggested the straitjacket of standard working hours does us all no good at all. Nor does the “always on” culture perpetuated by the speed of innovation and delivery in the world of software development. Yet we are all still stuck in our rigid working cultures. This light-hearted talk has a serious message: Don’t assume your teams have to be imprisoned by time. Try a little experimentation and see what a difference you can make when you play with expectations and give your people some time-based freedom. Time travel for the win!
Ever experienced that unexpected and urgent crisis that needs immediate effort and expertise? No matter how agile we are I'm willing to bet every team/project/organisation experiences these interrupts - the 'Black Swan' events - on a surprisingly regular basis. So why don’t organisations plan for them? We can't predict what the interruption will be, so we can't put in place the right resources to deal with it, but a panic team pulled together at a moment's notice needs time to form before it can be effective - time we don't have. Are there any organisations out there that thrive on reacting to urgent interruptions? Yes. The Royal National Lifeboat Institution (RNLI), provides reactive Search and Rescue (SAR) response around the coast of the UK and Ireland. They respond to emergencies, launching state-of-the-art boats, with volunteer crews, into complex and evolving situations within minutes. So how do they manage to create a team from a pool of volunteers in that timeframe? How do they compress Tuckman's lifecycle into minutes? I've been a crewman on lifeboats for twenty years and through this talk will explore the culture of the crews, what we can learn from them and bring into the workplace.
In 2013, Google famously published a leading reference for establishing Objectives and Key Results as a way to align teams and set short-term goals. While some of the information is still relevant, it is time to take a fresh look at setting OKRs within your teams. This talk will help leaders abandon the dated, flawed approach to setting OKRs and enable organizational alignment in an exciting new way, suitable for 2019.
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.
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.