Talks

In our work, we each have moments of saying some prepared words under a spotlight - whether it’s during team standups, giving a presentation to a client, or pitching your promotion to your boss - and yet we all have different fears about those moments. In this talk, we’ll walk through the spectrum of public speaking fears and learn tactics to address them, so you can feel confident and equipped to step into the spotlight.

uSwitch has a strong dev ops culture, we’ve learnt over time what should be handled by teams and what the organisation should provide. I want to tell you about why centralising knowledge and coordination, rather than ownership, empowers teams.

Managing people is hard. Managing people who aren’t like you is harder. As we push to build more diverse teams, how do we ensure everyone can succeed equally? Exceptional leaders use empathy to develop relationships with their teammates, don’t shy away from conversations that feel risky, and use a variety of tactics to bring out the best in their colleagues.

This talk will cover challenging situations using scenarios from both sides of the manager/direct report relationship, applicable to anyone who’s tasked with developing the careers of their teammates. You’ll leave with specific tips on how to ensure everyone gets the opportunity and support they need to perform.

Jenny Duckett ran a one-day web security workshop for developers at GDS recently with a colleague (they wrote a blog post about it). This was something she’d wanted to happen for a long time but hadn’t felt qualified or able to do herself. This talk covers Jenny's personal journey to get to the point where she was happy to run the workshop, tricks you can use to help you take on new challenges, and the importance of taking responsibility for improving the culture of your organisation. She’ll also explain why they wanted to focus on security in particular, how they planned the workshop to make it as useful as they could for the developers, what they learned from the experience and what happened next.

From the outrageous to the sad, hiring experiences in tech can be really ... bad! For the hiree and the hirer! From both sides of the table, Crystal has seen illegal and immoral behaviour -- choices that damage companies as much as they damage individuals. Let's do better. Please. We can improve this.

Our current methods for measuring a developer’s career progression are broken. At best, we count the number of days someone’s been paid to write code and massage that into a title. As a result, there’s no consensus as to what a given title means, leading to frustration for everyone.

Instead of judging a career via vague metrics like time, we’ll discuss focusing on a path centered around autonomy. Walk through the three stages of a developer’s life: The Implementer, who’s just learning the ropes and needs careful attention. The Solver, who tackles ever-bigger problems - and needs the responsibility to match. Finally, the Finder, who will revolutionize how you do work but only if you let them.

After this talk, you’ll have a new grasp on how to level up your team, no matter where they are in their careers.

Carly has a degree from Northwestern University in film and musical theater. After working in theater for a few years, she had a crazy idea that she might be able to teach herself how to code. To get her foot in the door, she had to convince very smart people that she could write software because she can do ballet. It took a few tries.

Today Carly is a software engineer at Slack and the tech lead for their international billing systems. In the year since she started working at Slack, not once has anyone made her feel stupid. Slack is empowering people to thrive. The fact that she still love what she's doing and has the confidence to take on challenging projects is a reflection of what her manager is doing right. Attendees will learn best practices they can apply to empower junior members on their teams.

Are you still testing accessibility by hand? Or worse, have a dedicated person doing so? Stop! Now! It's time to automate the hell out of a11y testing. Get a timeline of your improvements, report regressions as deployment blocking bugs and fix even more a11y problems with your saved time from testing.

There’s nothing more frustrating than not being able to deliver new features because of unnecessarily complicated code. You may decide it’s time to throw it all away and start over… and what starts off full of optimism, drags on for months and months, adding even more complexity and various levels of legacy.

It doesn’t have to be this way! In this presentation, you’ll hear a first-hand experience of how to approach technical debt at its worst, and how a rewrite project was successful in more ways than expected.

This talk will teach you lessons on how to start, and most importantly, finish a big rewrite project. You will learn how to approach the conversation with the “business”, avoid the most common pitfalls when changing the architecture of a complex codebase, and ensure the rewrite brings value from the start till the very happy end.

The current status quo in running and scaling out teams is to have everyone work in the same office or in offices across different locations. With the rise of open source, a different model of working and collaborating has emerged that is adopted by more and more companies, especially as they struggle to hire talent, build diverse teams and keep up with economies of scale that haven’t existed before.

In this talk I’d like to talk about how the team that’s running Travis CI, a continuous integration platform, and share some of our learnings as we grew our team and pushed our team’s distribution further. The talk will focus on how to structure communication in distributed and remote teams, the tools that are available today to increase collaboration while also increasing visibility, and on the challenges of working across multiple timezones and countries.

After this session you will be better equipped with tools that can help your team adopt a more asynchronous and inclusive culture of working, and you’ll walk away with ideas on how to structure communication and collaboration in distributed teams in a way that helps local teams as well.

We value “working software over comprehensive documentation”. That is, while there is value in documentation, we value working software more. This prioritisation helps us get things done and avoid waste. However, both extremes are very common out there in the wild, development teams who avoid documentation altogether (“our code is self-documenting”), and teams who create way too much documentation. This talk is about the spectrum between those two extremes - as a Lead Developer, how do you find ways to leverage documentation as a means to make communication in the team more efficient, and align everybody to a common picture of the system they are building, without creating too much waste?

Software development has been evolving. When I started in the industry, working at companies like Microsoft, we would bet many person-years of development and many millions of dollars into the development of products that would sometimes be hits and sometimes be total duds. We were building blind. This was partly due to our waterfall processes, but also to how software was distributed and marketed. A dud for a smaller company could mean the end of the line. The cost of failure was incredibly high. Over the years, we learned how to take some of that risk out by switching to agile software development and now Lean. Working this way we can learn quicker, and take smaller risks. However, there are other things we can do in how we architect our software or roll it out that can also reduce the technical and product risk and help us fail smarter and learn faster. In this talk, I speak about my experiences building waterfall products at Microsoft, building agile and lean at Adobe, Spotify and Avvo; and I give real architectural, cultural and organizational tools you can use to make your projects and team more failure-safe.

Long before Agile and Lean became buzzwords, a scrappy group of aerospace engineers at Lockheed's Skunk Works were using similar practices to produce some of the most amazing aircraft ever built. The famous U-2 spy plane, the SR-71 Blackbird, and the F-117A Stealth Fighter are among the incredible planes the engineers at Skunk Works produced under impossibly tight deadlines and very limited budgets.

What can we learn from the stories of these amazing planes and the engineers who built them? Let’s go back to our roots and let the original experts teach us about building awesome stuff together.

Have you ever been told you’re “too direct,” or feel like you don’t understand what others want? Or on the other side, do you think others are often too confrontational? These are Ask vs Guess Culture differences. Ask folks believe it’s ok to ask anything, because it’s ok to say no, while Guess folks prioritise not imposing on others. It’s a culture clash that isn’t often recognised, yet causes quite a bit of tension and frustration. This talk will cover the nuances of these different communication styles, as well as strategies for bridging the gap. Gaining an understanding of these differences and learning specific tactics for a professional context will make you a drastically more effective communicator.

Microservices are the next hype. Websites are full of introductory posts, books are being written and conferences organized. There are big promises of scalability and flexibility. However, when you are knee deep in mud as an architect, developer or tester, it’s hard to find out how to get there. Sander Hoogendoorn, independent craftsman and recently CTO of Klaverblad Insurances, discusses the long and winding road his projects, both greenfield and brownfield, have travelled. Sander will e.g. address polyglot persistence, DDD, bounded contexts, modeling HTTP/REST, continuous delivery and many lessons learned, using many real-life examples.

Organisations often worry about their mobile teams. Sometimes they are a bit separate. There's often this inexplicable hostility to mentions of "React Native". Why do bug fixes take so long to get to production, and what are all these certificates for, anyway?

In this talk we'll cover the realities of shipping compiled code, the woes of the app stores, and the infrastructure challenges we haven't figured out yet. You'll leave with a better understanding of the realities your mobile teams may be struggling with, and some strategies for how to help them - and your organisation - build an effective mobile team that ships regularly. And yes, you'll finally understand the React Native argument, too.

Whether you’re a Tech Lead, Engineering Manager, or Project Manager for an engineering team, you probably weren’t handed a leadership instruction manual when you were given your first team to lead. Even experienced technical leaders usually operate from a set of instincts and the hard lessons learned from painful mistakes. However, leadership is a skill that you can learn and maintain if you know where to look. You don't have to be born a leader, but you do need a set of principles to guide the leader within you. This session will teach you how to apply the principles in the Manifesto for Agile Software Development to becoming a better technical leader.

Outline

• Remembering the Revolution
• Individuals and Interactions: Beyond Gantt Charts, Org Charts, and Toys
• Working Software: Achieving Outcomes
• Customer Collaboration: Kill the Lawyers
• Responding to Change: Leading through Chaos

Everyone is writing APIs from micro-services through to full applications, but what makes a good one? In this session we’ll look at five of the more important features that you should think about when creating an API. These are the features that ensure that your API plays well with HTTP and, more importantly, make your API a delight to maintain and work with. I want you to ensure that your API is a good HTTP citizen, while also providing developer-friendly features like thoughtful error handling and documentation. Give your API a competitive edge by making it sane so developers will want to work with it.

What should I focus on to become a better leader and to better support my team? Where do I find the time to keep my technical skills relevant? How do I learn more about the business so I can understand the needs of the organisation better?

If you are attending this conference you already understand the importance of investing in your development. But what should you do the rest of the year? In this talk we will explore ways to plan and find the focus you need to better support your team and prepare for your next career challenge. We will discuss techniques I have found useful over the years to prioritise my goals and manage the overwhelming amounts of content we are exposed to every day in this ever-changing industry and come up with a plan that fits your ambitions and availability constraints.

The feedback loop is easily the most effective way to improve individual and team performance. When it is given well and received willingly, feedback can be a powerful ally in growing happy teams who work together effectively to deliver great software. Here's the challenge: giving and receiving feedback are skills, and many of us haven't had the chance to develop those skills. Maybe we find giving feedback intimidating. Maybe receiving feedback makes us feel defensive. Maybe we simply haven't had much positive experience with open, honest conversations about performance. It's not easy to do feedback "right", and when it is given badly or received poorly, feedback can cause a team's relationships to disintegrate. This talk will introduce the fundamentals of effective feedback; provide strategies for giving, receiving, and processing feedback; and discuss the challenges and rewards of using feedback as a tool to improve team performance.

To build great teams you need to understand people. One of your core skills as a leader should be the ability to have effective conversations with your team, the rest of your organisation, and your customers.

Unfortunately the ability to have an effective conversation is often seen as an innate skill that cannot be improved — and I see people making the same easily fixed mistakes again and again.

This session will help you get the most from your conversations. We’ll demonstrate common mistakes, and introduce you to simple proven techniques used by user researchers, therapists, salespeople, and others.

You’ll come away with a new way to look at conversations, along with practices you can use everywhere from retrospectives to interviewing job candidates.

Estimating time is like packing for a long holiday. No matter how hard you try, you always feel like you forgot something important.

We all know how hard it is to estimate time and amount of work needed to complete a project. We’ve all been there - our teams missed deadlines, and not because they didn’t work hard enough.

With experience we get better in estimating, but most often we need to rely on our team to do that. Let’s explore some factors that may not be obvious to developers. We’ll talk about how much we really work during a month, why research takes more than anyone expects and how Chinese New Year may destroy your plans.

As a developer you are used to certain constants in your life such as battling with a compiler/interpreter or debugging a production issue only to discover a single, tiny error. You know, for certain, there will always be more problems to solve, usually moving bits from one system to another regardless of which language, or product you work with.

Your transition to a Tech Lead will surprise you as you discover new and different constants for the first time. In this talk, we will explore the Constant Life of a Tech Lead where you will hear advice, learn strategies and stories to prepare with these new constants.