Agenda

That said, your role is to influence without exerting authority. This means people across the organizations from junior engineers in a team to Engineering Directors, VP of Engineering and CTO will need to trust you to actually have an impact.

An analogy I picked up in my early days of being a principal engineer that I have often followed is the one about how if you put sand in a jar first, you do not have room for rocks, where rocks represent life’s big priorities and sand the little things, whereas if you put the rocks in first you’ll still have room for some sand. (Here is a link to a version which includes beer).

In this talk I will be sharing some tips and tricks to identify rocks, pebbles and sand you can fill your jar with, ways they enable you to create impact and build trust across the organization and some common challenges you will face when you prioritize your work using this technique and ways to overcome those.

In this talk we will explore the journey our content takes through the many, many applications in our microservices architecture. I'll cover aspects of the system that are not ideal, and how we're working to fix it. Join me as I struggle to draw a compelling technical architecture diagram in Keynote and test the limits of the acceptable use of the FT digital colour scheme.

These projects usually take significant time and energy to get off the ground and delivered to success. This talk will go over strategies and principles to make large scale migrations less daunting, both from a technical and organisational point of view. We'll dive deep through examples discussing effective technological principles, convincing stakeholders, motivating teams and embracing both success and failure.

One way to achieve this is using tooling, but how can you implement this effectively without alienating people once it's introduced?

This talk will cover a case study of the problem "how do we ensure all our teams are meeting code quality standards", looking at approaches that are likely to (and have!) failed, vs. those which are much more likely to lead to results and long-lasting buy-in.

How can you communicate with your exec sponsors, peers and junior engineers and ensure that your vision for the future is reaching your audiences, without spending your days trying to get face-to-face time with each of them?

Once you've had your "big idea that you need to convey to everyone" it's daunting think of the time and effort that would be required from you to meet everyone face-to-face and then repeatedly (and reliably) convey this idea to the in order to reach a common understanding. It's also high stakes - there's lot riding on your personal brand and it's likely to be intimidating and on both sides. Documentation is the way forward. Not technical documentation per se, but artefacts such as guidelines, best practices, decision trees and even full-on white papers.

As an individual your reach might be limited to when and where you are present, but as an author of content you’re able to change hearts and minds while you sleep and reach your audience with your message in a format that endures, at a time and pace that is convenient for them.

In this talk I'm reflecting on my 2 year journey as a Staff Engineer, and how a mix of documentation and working groups has been a surprisingly effective strategy for influencing the opinions of the individual engineers as well as the non-technical stakeholders. We'll talk about the principles I use to determine 'good' and 'useful' documentation, some key guardrails to keep your content approachable, and the risks of falling to the dark side - using documentation as 'proof of work' or creating the dreaded wall of text.

Step into a staff plus role, where you find yourself working across teams or departments and leading initiatives that span much longer than the typical agile sprint. You have ambitious goals, but how do you adapt to this change? How do you take ownership of your time? How do you make sure you are spending the time on what you need to?

In this talk, we will start by looking at: How the expectations of your role imply changes in how you manage your time, strategies to avoid feeling like you are being stretched in multiple directions, understanding how you work best, and identifying which strategies apply to you.

Now, imagine agreeing on your own responsibilities, expectations and things you look after with the whole company. Together with a group of friends we took the challenge and defined the first "Staff Engineer Guide" at MongoDB. And wow, it was quite the trip.

During today's presentation, I will take you on a journey and tell you about all the adventures we've gone through writing this document. I will share the books and blogs we read, and the videos we watched while preparing the materials. I will highlight what discussions were crucial in the process, and finally, we will enter unexplored territory of new Staff Engineer Archetypes.

This presentation is mainly targeted for Staff Engineers who work on defining their own roles and responsibilities. Writing a Staff Engineer Guide, and agreeing on the expectations between the engineering and the management, is a great way to learn about your organization. Senior Engineers could also learn from it. Aligning with the explicit expectations from Staff Engineer roles is a great practical pointer to be promoted.

If you're anything like me, by the end of the day, you wonder where the time went (and if you got anything done at all). As engineering leaders, as our scope of influence grows, we're more likely to get pulled into ever-increasing directions, our calendars becoming neat little stacks of commitments. We can trim unnecessary meetings and block out dedicated focus time, but we can't outright eliminate periods of high-context switching. So, how do we make the most of these whirlwind blocks of time?

I've spent the last few years trialing a few different ways to sustainably maximize this time by balancing productivity with a bit of mindfulness. Come learn from my (many) mistakes, and hopefully we can all feel a bit less like a Dalí painting.

We had a hard, three-month deadline to migrate all our package hosting from Bintray (which was shutting down) to something else. We had several options, no full-time engineers and no explicit agreement on how we should move forward.

In this talk, I’ll discuss the following:

- the key factors we evaluated to decide between the options available

- how compromises were made within and between Homebrew and GitHub (my employer)

- what techniques we used to implement the migration by the hard deadline with zero downtime

- how to use “soft power” to affect change in your organisation without “hard power” to decide what any individual works on

Join me as I discuss the importance of balancing assertiveness and adaptability in your interactions in these projects. 

If you are working at a startup you are likely writing code from scratch, failing fast and breaking things, all while enjoying the ride. However, that is not always the case at other companies where you could be working with code that is older than you or your colleagues -- you can still enjoy the ride though.

In this talk, Sally will share her views on working on an older codebase. She will share her experience watching the codebase evolve from incorporating acquired startups to consolidating code branches. She will share pain points that she found to be repeated after joining a younger company.

By their very nature, complex systems are very difficult to reason about. But there are structured methods that can help us to understand our systems better, to design more robust software, and to learn more when things do go wrong.

In this talk, Laura will cover methods such as EAST-BL, System Dynamics, and the Energy Barrier perspective, with a specific focus on how these methods can be applied to the development and operation of distributed software systems. 

She will also share how she focused her career towards being a Distinguished Engineer by combining continuous learning, solving tricky problems at large scale and engaging the engineering culture of the organisation.

In this captivating and insightful talk, BobbyD a seasoned engineer and motivational speaker takes inspiration from the popular game "Among Us" to address the challenges engineers face in understanding their value and the importance of developing team awareness to support one another.

Shifting the focus from individuals overcoming imposter syndrome to the collective mindset of teams creating an inclusive and supportive environment, BobbyD shares practical strategies for embracing individual strengths, fostering team collaboration, and building bridges through empathy and inclusivity.

Having worked at the intersection between Product, Delivery, Architecture and Engineering, this talk will explore what is key to continuously evolve the stack, the org, and ways of working.

This is no easy feat, as you'll be working with various stakeholders with competing priorities for new features , modernisation and tackling technical debt.

In this talk, we will discuss the role of a technical vision in creating a roadmap for your organisation's technology evolution. We will cover how to assess your current technology architecture, defining your target state and identify next best steps for getting closer to your goal.

We will also delve into the process of aligning your technical vision with your product roadmap, ensuring that the technologies and platforms you invest in will support the development and growth of your product offerings. Through a combination of real-world examples and practical guidance, this talk will provide attendees with the tools they need to define a technical vision that drives modernisation and supports the long-term success of their organisation.

However, over time my role had become almost completely managerial. There was no space for me to get into the weeds of the code. I missed the code. I thought I may have missed the chance to be senior and immersed in the technical. I worried I couldn’t do it any more. It was by ‘good luck’ that I discovered the options I had. Perhaps I shouldn’t have left this up to luck!

I think the path I followed is not uncommon. It can be unclear how to make the transition back to a technical role (aka Individual Contributor, or IC). It’s hard to find out what options you have and what path is ‘best’ for you. Our career path is often led by the needs of the structure we’re working in. This is useful, but it's important to question at what point a change of path might be right.

This talk should help you crystallise what options there are. It will clarify what actions can be taken to find out more. Whether you decide to ‘put down line management’ or not, you can make that decision in a more informed way and be more confident in your choices.

Our products and systems weren’t built to be multi-country. Rapid growth and scaling challenges drove rethinking cloud infrastructure, building a technical strategy and vision for hundreds of engineers and dozens of different teams, leading change, getting projects funded, and finally enabling product launches in new countries.

However, this can also lead to silos, duplicated efforts and differing “standards”.

This talk will explore how to overcome these challenges, get buy-in from engineers to promote cross-team collaboration and alignment, all while establishing and refining shared standards and working towards a shared vision.

At the same time, they’re also expected to work with engineering and product leaders in building effective solutions for their customers.

In the past years, the industry has created some very good material about how to do both of these. In addition to working with early to mid career engineers, product managers, designers and other cross functional partners, the engineers at Staff level are also expected to work with other Staff engineers. Often, such working peer relationships span organizational boundaries.

In this talk, I wanted to touch upon this slightly less talked about aspect of the job as a technical IC leader, which is creating peer relationships and working with other Staff engineers in shaping an organization’s technical roadmap. I’ll be sharing two case studies from my current and previous jobs and go into the details of what strong peer relationships between Staff+ engineers could look like and how they helped influence the organization’s technical decisions.

When we open them for others to see, however, they could help with making sound decisions for future software projects. In this talk, we will look at lessons learned, not learned and forgotten from past “failures”. Although, interestingly, not everyone deem them as failures.

Past lessons are scattered in different documentations or in people’s heads. To reap the benefits, we rely on someone who oversees many projects to jump in and share those lessons. We also broadcast to other teams when we are at a decision making point on our current project, to catch any useful lessons other teams have learned. It could also happen serendipitously when the right person is in the right place and the right time to share those lessons. Think of overheard water-cooler conversations! Those actions do not always work. To boost the power of lessons learned from past projects and from other teams, we need a tool. A lightweight tool that pools the wisdom from past lessons and makes them available for all teams in the organization. In this talk, I will also share a way to keep and refer to those lessons when we need them the most.

In this talk, I’ll reflect on my journey to Staff Engineer and discuss some of the personal pitfalls and unexpected challenges I encountered while moving through roles and the personal skills and strategies I’ve developed to address them.

Incremental changes become cheaper, the cognitive load required to reason about system behavior is less, solving a problem for one more often means solving it for everyone; the list goes on. But not all is rosier, and while some problems go away, new ones are sure to replace them.

You should leave this talk better equipped to decide whether embarking on a standardization project is right for your stack or organization, and how to do it in a way that avoids common pitfalls along the way.

Improve technical decision-making by fostering a culture of documentation excellence and inspiring clear, effective written communication with a few simple practices.

This makes it difficult both to be a good influence – modeling behaviors and approaches for aspiring engineers – and to manage expectations around our roles.

In this talk, I explain why it’s valuable to show our work as Staff engineers. I offer concrete ways to behave transparently and give examples of how each has helped me and my colleagues.

As staff+ engineers, can we really make a difference when it comes to increasing diversity? More importantly, is diversity the right target to aim for?

This is Liem’s story, a France-born developer with Asian heritage, finding his space in the London tech scene. You will hear about his journey, from being the first frontend engineer at Accurx, to building a diverse and inclusive guild of 20+ members in two years.

He will explain why focusing on diversity was not the right approach for his team. Liem will share with you his view on inclusion and how he changed the company’s hiring process to adapt to the needs of his team. He will walk through the guild structure, communication between members, team up-skilling, the psychological safety in the team, the group decision making, the impact on the daily jobs of all the developers, and the challenges from the wider organisation.

The evolution of Accurx’s frontend guild is a clear example of why investing in diversity and inclusion is a powerful step to make everyone feel safer and more comfortable. This is an achievable goal that we can all take on as leaders in the tech industry.

Recursion scientists perform CRISPR-Cas9 mediated knockout to understand the activity level of every gene in a specific disease model, which allows new discoveries to be made. These maps are specific to a cell-type.

New experiments run on Recursion’s platform generate novel insights that have to be periodically incorporated into new versions of the map. Generating an updated map version was manual and involved running scripts on development machines that filtered and aggregated new experiment data, uploading it to the cache that housed the map. Due to the manual intervention, the maps were updated as and when engineers or data scientists carved out time resulting in scientists having no guarantees for when to expect updates to the map.

Embedding on a team that built and maintained these maps of biology, we approached this problem systematically. We worked with our experiment operations team to ensure new experiments added to the map were ready on a specific day/time of the week. Next, we built infrastructure as code to execute the map building processes on cloud compute instances that were triggered after the experiments were ready. Finally, we improved the reliability of the underlying API that transferred the data from the cloud instances into the cache that housed the map. Making these improvements iteratively, we ensured that our scientists have novel insights at a weekly cadence. Additionally, we repurposed this infrastructure to build multiple maps (different cell types) thus creating an atlas of biology for Recursion.

More and more, companies are investing in senior individual contributor tracks to support engineers as they grow. But once you get that staff+ role, the way you work changes a lot:

* You are working across multiple teams, so your goals are not a team’s goals anymore. How do you know what they are?

* You’re not “on the ground” working day-to-day within a team. How do you keep track of what’s going on?

* Coding is just one of the ways you deliver value. What else should you be doing? Your role now is to gather context and evaluate opportunities to help shape what you and other teams should focus on.

In this talk, you’ll learn how to define your development journey as a staff+ engineer, figuring out what you should be working on, how to set your goals, and how to you define your backlog of work. You’ll also learn how to track your progress so you can keep growing as an engineering leader in the individual contributor track.