Agenda

Is that better or worse than having to be up half the night fixing an issue? Having an on-call rota is an integral part of providing a service that is available 24/7, so many of us are either on a rota, or responsible for running one. It’s fundamentally stressful: as the person on-call you’re responsible for debugging and resolving a wide variety of issues, often relating to things that you rarely touch in your day-to-day. There’s also a significant personal cost: not only the 2am wake-ups but the ‘bringing a laptop to the gym’ too. In this talk, we’ll discuss how to build a compassionate on-call rota, and how that can help build sustainable and high performing teams.

The talk will look at some of the problems the team faced in the years leading up to the transformation, and how the transformation addresses these.

How do you set up a leader, either a promoted employee or a new hire, to succeed? What are the long-term implications of how this happens? In this talk, I’ll share my four-week onboarding process for engineering leads that emphasizes peopleware, tech leadership, and delivery management. I’ll provide a behind-the-scenes look at this super adaptable process, which uses a framework of ‘sessions’ and ‘experiences’ - and share everything from my mistakes to my insights.

The code that we write or bug reports we create will be read and reviewed by people from diverse backgrounds and skill levels. It is within the realms of possibility for our code to stand the test of time and especially in open source, for it to be read by thousands of open source contributors many years into the future. It is our responsibility to write good, readable, legible code that abstracts away needless complexity and makes it a joy to be read and understood. Also, well written code serves as a good example for future contributors, and carries forward the culture of good code. The same goes for ticket descriptions that have well written titles and summaries and bug fix descriptions. In this talk, I will talk about how to write good readable code, ticket descriptions, bug patches et al in PHP and Javascript. I will quote many of the tips and best practices quoted in books like The Art of Readable Code, Clean Code by Robert C. Martin, Clean Code JS and Clean Code PHP and so on. This will cover things such as how to format code for readability, write good variables and functions, writing well-contained functions and so on. The take away for developers would be on how to write beautiful code that improves the quality of code contributions to open source. After all, code is poetry.

We’ve all heard horror stories about untangling spaghetti code and spending hours on self onboarding just to realize that you still have no idea on what areas require the most attention. This kind of experience creates hesitation and friction for new engineers to review code and requires more resources from engineering managers to onboard new engineers.

In this talk, I will be discussing the history and context of the problems that plague codebase onboarding. And with problems comes solutions such as tips and tools that make it easier for engineers to onboard a legacy codebase. My goal for more senior engineering leaders is to provide a solution that helps deliver more value and make engineering teams more efficient during the current economic reality that we’re facing.

As the saying goes, “What got you here won’t get you there.” What helped you thrive as an individual contributor may not carry you to success as an engineering lead. So, how can you pick up the new skills you’ll need while avoiding common pitfalls? In this talk, we’ll give you two perspectives on navigating this transition into leadership and share lessons learned from our own journeys. Some engineers’ pathway to leadership begins within their team, whereas others choose to seek out other teams for this opportunity. When taking on a new role in the same team, it can be challenging to shift the perspective of your peers as they become your reports overnight. You want to gain their trust as a leader and maintain the relationships you have spent years building. On the other hand, those joining a new team as a manager must start developing these relationships from scratch while learning a new technology stack and doing their new job effectively. From navigating how to step up as leaders to learning how to manage up to skip-leads, we’ll share insights into common pitfalls based on our personal experiences transitioning from software engineers to engineering leaders at Bloomberg. This talk, which will primarily focus on challenges involved with people leadership, will broadly cover: - How to rebrand yourself as a new engineering leader - How to build trust with a new team without prior experience or credibility - How to delegate effectively - How to balance proactive leadership without micromanaging

Realistically not everyone can or wants to be a Lead Engineer/Engineering Manager/Staff Engineer and nor should we be pushing people into roles they either have no interest in or have done before and not enjoyed. We should also appreciate that these people often tend to be high performing even if they’re not interested in upward growth and that they should be cultivated as domain experts or well rounded engineers. People can also go through cycles of ambition and may decide they want to seek promotion at different points in their life. We'll explore the idea of engineers who’re happy remaining an IC or similar, how best to support them and how to create a sense of progression without pushing them to be changing roles. If there’s a right situation to try and push them towards a new role and why it’s completely fine to not be seeking constant progression and that it isn’t a limiting factor to growing your skills.

Delivery is a key part of business growth, as EMs, TLs, PMs we want to ship more value and the quicker we can do that, the better. It's a simple equation: faster delivery = more value shipped to users. But what we often fall short on is pushing for better delivery and pace in our teams using the *right* approach. Typically, when we do try to push these two, it quickly becomes a game of productivity and gaming numbers. The problem with this approach is that, to put it bluntly—I've never seen it work. So what is the right approach to improve the delivery and pace of your team? Especially if you're a scrappy startup with limited resources? Obvious answers are working overtime, hiring more people or adapting process. And while those things may give you more output, your team isn’t actually shipping any faster, so you aren't solving the root problem. What does have impact is setting expectations with your team, finding leverage with well chosen tech investments, and a handful of other tactics that I'll highlight in my talk. By the end of the talk, folks will have received actionable advice that'll help them improve their teams' delivery and pace without a data-first approach. This will include advice on: - How to motivate their teams - How to encourage pace without turning everything into a number - What tradeoffs to make when pushing for delivery and pace - How to know when pace has improved without metrics

As well as how to enable engineering teams to build systems that will not be roadblocks, but instead multipliers for other teams' work and product goals overall. During her talk, Olena will share the on-hands experience of the Technical Design and Architecture Advisors (TDAA) group at Webflow. She was one of the seven engineers in the initial TDAA cohort and contributed to establishing its best practices. TDAA started functioning over one year ago as a way to start finding answers to these questions. During the talk, we'll make a deep dive from the principles based on which this group operates to the specific how-to that made its work beneficial for the company and share what we've learned from this whole experience so far.

But attempts to measure developer productivity can be risky, damaging, and downright misleading. From the infamous lines of code to brutal code reviews, every developer has a horror story of a time their authentic effort and problem-solving was mismeasured, or worse, even punished. In this talk, I want to propose a different, science-backed approach to productivity: let’s shift to thinking about developer thriving. As a social scientist who’s spent years studying how human beings achieve and maintain sustainable high performance, and the Director of the Developer Success Lab at Flow, I’ll share research evidence from our study with 1200+ developers.about how good problem-solving environments lead directly to higher quality work and collaborative productivity. Coupling validated, large-scale empirical measures of developers’ environments with rich qualitative focus groups and interviews, we’ll unpack the key concepts in developer thriving with examples like cycles of motivation, developer agency, and sense of belonging, and explore how developer thriving significantly predicts productivity. And what’s more, we find that these factors scale better across different teams and industries than measures of “productivity.” Finally, drawing from both rigorous social science and my lived experience spending years working with learners in complex environments, I’ll tackle why despite all this evidence, centering thriving remains a challenge. We’ll explore 7 myths about productivity that I believe hold our industry back, and think through better and more scientific ways of understanding productivity for engineering organizations, leaders, and developers.

It is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. The holy grail for platform engineering today is to achieve the most effective “Internal Developer Platform” that enables the rest of the developers in the company to be as effective as possible. Can this job be accomplished with engineering skills alone? In this session, We will discuss how to build an engineering platform that your engineers will actually want to use. We will go over common product practices to use when building the developer platform, and also the importance of making sure your IDP actually helps the developers to build the company’s products faster and better. We will define the role of the PPM (platform product manager), and the importance he plays in making sure our platform is not a glorified Rube Goldberg machine.

In this session you will learn:

- What is platform engineering? Isn’t it just a new name for DevOps?

- What makes an IDP and a platform team successful?

- Who is the platform PM (PPM)? why he is important? How do I convince my head of product we need one?

- Practices you can use to build a successful platform, and pitfalls to avoid.

Software engineers across various organizations have run into this same issue - but what’s the solution? Is it Big Design Up Front? Is it to be “agile” and let these things happen? OR ....... is there a better way, by which you can do *some* upfront work and save yourself a lot of thrash and a future headache. This process is usually called a spike, wherein the engineer(s) leading a project dive deep into figuring out the unknowns of a project before it begins. In this talk, I’ll go over what a spike is, how to successfully spike a project, and lessons that I’ve learned from leading several technically complex projects, across 3 different companies, and various different teams.

Key Takeaways:

- How to evaluate whether you need a spike or not.

- How to come up with the right assumptions you could validate/invalidate before writing the tech spec.

- How to find the technical scope of a project (Teams, Services, Key Stakeholders) that’d need to be involved.

To the operators at Fukushima Daiichi nuclear power plant, it seemed like the shaking would never stop. When it finally did, six minutes later, the operators fell automatically into the post-earthquake routine they had drilled on so many times. The reactors had automatically shut down, backup power had come online, and they were well on their way to having everything under control at the plant’s six reactors. And then the tsunami struck.

The operators at Fukushima Daiichi suddenly found themselves managing a situation well beyond any worst-case scenario they had imagined. The media's breathless coverage of the subsequent meltdowns and explosions at the plant make it easy to assume they failed, but the actual story is far more intriguing. The way their team operated during that fateful week has a lot to teach us about helping our own teams be at their best, both in crisis and out.

Whether it's dealing with a difficult team member, a missed deadline, or a major setback, leaders are constantly faced with situations that can trigger a symphony of emotions. Emotional intelligence is the key to effectively managing emotions as a leader. By developing self-awareness, empathy, and the ability to regulate emotions, leaders can become experts at navigating the emotional landscape of leadership. Ultimately, understanding your emotions and those of your team members, and responding in supportive and constructive ways, will lead to a harmonious work environment. This talk covers key topics such as understanding and managing emotions, reflecting on them, developing emotional intelligence, and being in control of our thoughts. Through relatable examples and a light-hearted tone, I will offer practical tips and strategies for mastering the ride and leading effectively.

The meeting ended awkwardly and without resolution. Soon after, everyone was sending direct messages to each other trying to process what happened. The day didn’t recover; it finished with an already scheduled retrospective where people were full of thoughts and questions but nothing was shared aloud. Two people left for the weekend questioning whether they were at the right company, and everyone spent time and energy thinking and worrying. For our startup, this was a fundamental system failure. In the same way that a severe service outage, database failure, or code defect can grind a team to a halt, the impact of what transpired was massive, and we needed to find a fix. Unlike a problem with a database, there wasn’t a magic patch or update to solve the issue. In this talk, we’ll share how we planned and executed recovery work. We needed to apply systems thinking to people problems and navigate discussions that helped us each feel heard and understood. Our aim is to inspire you to consider a systems approach when something with your team goes wrong, and we’ll provide a template for what we think worked well.

To be a successful female engineer you have to be strategic about your career which is something we are not taught in computer science and/or engineering academia. It may be tough, but it’s not impossible to find a company where women’s voices are important. Make that your goal. Build relationships with colleagues, upper management, and across departments early in your career. Look for mentors. Pair with senior and diverse engineers who are open to teaching. Take each opportunity as a learning lesson. Direct your career towards your own interests; you will thrive when you are doing what you enjoy. Though you may face challenges, and at times failures, if you are confident on your path you will persevere.

If I had to build a new project or company, they would be one of the first things I would implement. And not just technically but on the development culture. Let me give you a glimpse of the reasons why. If you don't even know what a feature flag is, it's simply a boolean that tells you if a feature is enabled or not. Doesn't sound like a big deal, right? But what if I told you that we currently use more than 100 feature flags, and even more have been used and removed in the past? The most basic use of a feature flag is to allow for the development of one feature while keeping the current behavior. But this is just the surface! Especially if you're building a SaaS project or a multi-tenant app. In this talk, I'll show you how you can use feature flags to run complex data migrations, enable canary releases, easily build plans on top of your product, customize for specific clients, and much more. Once you master feature flags, they become like a superpower. You can't live without them. Let's unleash that power together!

While the on-call process depends on each team setup, the on-call pain is the same for everyone. To keep your systems healthy is to invest the same amount in keeping your team healthy. This is a mantra we, as a team, have been keeping each other accountable for. And we have learned that the best way to start addressing this is to first look at the data and then build healthy team habits to act upon it. This talk will walk you through a data-driven on-call framework, clearly derived from first principles. You will get the WHY, our journey towards adoption and the results after more than 2 years of implementation. If you are responsible for systems in production, then this is for you!

Several feelings can arise, such as insecurity, anxiety and fear, in my teams it was no different. In this presentation I will discuss how we can support and care for the team and then move forward, based on what I experienced at Loggi, where it was possible to overcome in a healthy way. I will approach from the pre-event, passing through the communication afterwards, identification of critical cases and the elaboration of a retention plan.

How about over the last month? Have you changed the way you do code reviews? Changed your branching structure? Reorganised your entire delivery strategy from waterfall to agile? How many mistakes would you make in a single week, or even a single day if you tried to work without knowledge of these changes?

For example, if you were returning from parental leave. The fast-paced nature of the tech industry can cause large knowledge gaps to develop in those taking extended leave. This impacts people’s mental health and wellbeing, intensifies imposter’s syndrome, and further promotes poor stereotypes of what a real developer looks like. As an industry we are working hard to encourage more diversity into technical roles, but for many (myself included) being a part of that diversity can result in a painful mismatch between our personal and professional goals.

For women and diverse genders that chose to be parents, we work hard to get where we are, to prove ourselves in an industry that historically prioritises long hours, years of experience and the ability to keep up with the cutting edge of the industry. None of that aligns with taking a 6–12-month career break where your main concerns are nappies, bottles, and the last time you had a shower.

Today I am going to talk through how you, as Development Leaders, can provide visibility of key decisions to those who have been on leave, ensure they aren’t overlooked during their period of absence and how you can prevent cognitive overload when they return, guaranteeing your best and brightest return feeling empowered, valued, and ready to code.

However, getting the right framework in place for your business and team members can be challenging, and can actually do more harm than good if factors around diversity, equity, and inclusion aren’t well-considered. In this talk we’ll cover some common pitfalls, and will go through a practical set of prompts to help you make sure your career ladder can work well for everyone. I’ll use some real world examples that have come out of my work creating progression frameworks for both engineers and engineering managers in different types of companies.

While unencumbered experimentation is not uncommon, and even rewarded in tech - a field synonymous with innovation- the speed and efficiency with which we demand, require or expect new tools, apps, libraries and everything in between to be delivered often comes at a cost to the end user, majority of which is shouldered by underserved groups - people with disabilities, people that speak languages that are not mainstream, people in poor connectivity and low-bandwidth environments, you name it.

With a focus on the topics of accessibility and internationalisation, this talk will remind us about the levels and weight of responsibility we carry as builders and leads in tech, zero in on the need for prioritising people-centric approaches in the design and development decisions we make everyday and implore us to move beyond only employing best practices in our work and to start packaging and sharing our best practices more broadly as a way to bring about meaningful, long-term and inclusive culture shifts in tech.

Very often, they are considered just a redundant process before terminating the employee's contract. But they shouldn't have to end with a negative outcome! This talk describes an approach to PIPs in which the manager helps to set the employee up for success. It starts from even before the beginning, with what can be done to avoid reaching this point. Assuming it can't be avoided, it moves into how to start the process with a clear conversation about objectives. It continues with practices to follow during the whole process, showing explicit support, building a network of peers while preserving confidentiality, etc. Finally, it covers the wrap up (with a positive or negative outcome) and follow ups to avoid repeating the situation. As a wrap, we will cover some feedback received during and after real cases, which can help to reflect on how to conduct better future ones.

This talk covers why the answer to that question is important, how to set up the culture to enable the conversation, how to actually have the conversations once the foundation is laid, and the benefits that both employees and the company get out of it. Beyond just talking about it in the abstract, I will detail my process of setting up a team culture so that (almost) everyone is comfortable talking about what their exit plans are, and enabling line managers to have those conversations. I’ll also run through personal examples of places where this has worked, and places where it has fallen short. I will also talk through my process of getting leadership buy-in to address the topic head-on. This is highly relevant for our industry because the reality is that people change jobs on a regular basis. Yet so many companies still behave as if we were in an environment where people signed onto a job, stayed there for 40 years, and retired. It’d be much better for everyone involved if we acknowledged reality and talked about what’s going to drive each individual to the point where they decide to move on.

We now provide an end-to-end platform for smart online grocery to some of the world’s largest grocery retailers. At the heart of our model are automated warehouses which are the most advanced of their kind. Thousands of bots collaborate seamlessly on 3D grids to fulfil customer orders.

The bots are orchestrated by our proprietary control system and communications technology. Historically, our orchestration system was hosted on premise at each of our sites.

In 2020, we took the radical decision to migrate the proprietary real-time orchestration of the bots to the Cloud. Moving one of our most critical systems to the Cloud was a huge decision for us. We had to be confident that the low latency and high predictability that we had achieved on premise could be replicated or exceeded in the Cloud. Compromising either would impact the throughput of our sites and the profitability of our retail partners. Nothing less. It was a team effort across the business; here are just a few examples: - The teams building our bots had to rework all of their applications and modify their deployment pipelines and other processes. - Our Engineering Productivity teams added support for features such as Keyspaces and Network Load Balancers to support low latency comms between the orchestration system and our Bots - The Cloud team helped to facilitate a smooth migration from on-premise VPNs to the cloud. Piece by piece, our team was able to move all applications and data to an aggressive timetable.

Since the migration, there have been no significant outages or incidents – a testament to the planning and execution of the teams involved.

When we have control over the deployment and release of our own products, we can use several techniques to maximise the feedback loop, minimise risk and give us every opportunity to innovate and pivot. Continuous integration, Minimum Viable Product, automated testing, user research… these are all techniques we can use when experimenting with a new product. They allow us to prioritise user needs and maximise agility and flexibility.

But when building a brand new iOS app, developers are at the whim of the Apple app store… and this can prevent them from using many – or even any – of the aforementioned techniques.

This talk is a dramatic tale of ups and downs, tears and triumph, and the very sharp end of the sunk cost fallacy. Via the rollercoaster ride of a failed iOS app, Clare uses the experience to highlight several key components that contribute to successful software development… and offer understanding to those facing obstacles beyond their control.

Warning: Contains mild peril.