Explore what’s happening at StaffPlus London

In this talk, Viktor challenges this approach by advocating for adaptability and a return to basics in system design. Drawing from his experiences, he explores the pitfalls of over-engineering and the importance of simplicity and evolvability in scalable architectures. Through concrete examples, including challenges faced at Personio, Viktor will discuss the need to prioritise correctness, ease of reasoning, and understanding of trade-offs when architecting systems for sustainable growth.

Takeaways:

• Prioritising for correctness and simplicity and how to avoid unnecessary complexity that hinders scalability and resource efficiency.
• Understanding how inherent trade-offs and their implications can support the creation of scalable and informed architectural decisions.
• How to optimise systems not just for technology but also for real-world understanding, enabling smoother onboarding of new team members and scalable growth.

In this talk, we'll delve into how Staff+ Engineers can embody Deming's timeless wisdom to enhance quality, productivity, and both employee and customer satisfaction within the modern engineering landscape.

Prepare to dive into Deming’s System of Profound Knowledge, focusing on the aspects that are most relevant and impactful in today's engineering organisations. We will learn how to interpret Deming’s 14 Points for Management as a framework to optimise modern engineering work and discuss actionable strategies for weaving Deming's philosophy into your daily work by exploring real-world examples that bring these concepts to life.

By the conclusion of this talk, you will leave with a richer understanding of Deming's legacy and practical insights on how to implement his principles for improved outcomes. I aim to equip Staff+ Engineers with the tools and knowledge to drive significant process enhancements, fostering a culture of continuous improvement and excellence in their organisations.

While strong leadership, organisational awareness, and versatility are typical traits of a good Staff Engineer, exercising them effectively, in the right places and at the right times can become critical to the survival of the group.

At Back Market, a few of us Staff Engineers found ourselves in this situation over multiple quarters. The absence of a leader manifested at times through missed target dates, teams struggling with alignment and collaboration, organisational restructures being delayed, a general decrease in morale and more. All the while, high-value projects and migrations were ongoing and failure was not an option.

While our technical expertise and ability to contribute more directly to architecture and technical initiatives is what differentiates us from our manager peers, the gaping management hole forced us to sharpen our organisational skills and focus more on the "Tech Lead" and (paradoxically) "Right Hand" archetypes, than on the "Architect" and "Solver" ones. While previously we would jump in to help teams “solve” their issues, we found ourselves unable to take our eye off the day-to-day operations of the whole group and, at times, consciously steered clear of tackling emerging fires to maintain our focus on the group as a whole.

In this talk, we will detail our experiences as Staff Engineers functioning as Tech Leads, Glues and Facilitators in a leaderless role. We’ll discuss the real-world problems we faced, our solutions, and the lessons learned that allowed us to grow as leaders and as an organisation.

But sometimes “the most important thing” isn’t the thing that you should be doing - you’re a part of a broader team, remember! And maybe, just maybe, someone else should be doing the thing instead. It’s especially tough to remember this when companies and teams are changing; when you lose those key individuals and roles which keep the machinery working and processes flowing, but it’s a slippery slope to ending up doing the essential things, but not your responsibility, and never being able to find time for the critical IC Leadership stuff that only you can provide.

It’s about learning to say No - but not even to others, to ourselves. Yes, that work needs doing and yes, it has a big impact and it’s super important. But no, I don’t have to be the one who does it and no, I’m not going to do it because I should be doing something else that’s unique to my role that’ll pay off in another way.

This talk is little about why you need to say 'No' to people more, and how things can go wrong when you don’t learn to do it enough.

I’m an engineering leader with a few years experience of providing technical leadership to multiple teams, and my biggest weakness is a tendency to evangelise my great ideas to teams before they’ve even had a chance to consider the problem I’m trying to solve.

In my talk I will explain that this is generally a pretty bad idea; it won’t surface the best ideas and it doesn’t let more junior engineers develop their skills. Instead, I introduce some steps you can take to make sure that the idea adopted to solve a problem is the best idea available, even if you aren’t the one who came up with it. Perhaps counter-intuitively I will show how this increases your influence in your organisation and sets everyone up for success.

You will come away from this talk aware of some natural behaviours that you may not even be aware that you are doing that, rather than bringing out the best ideas, unconsciously serves to suppress them by biasing people to your solution.

In this talk, I'll share the strategies used to disassemble our legacy data pipelines responsible for managing merchant eligibility on the Shop apps. Join me on a journey through our successes, challenges, and invaluable learnings in the meticulous orchestration of terminating our legacy data pipelines.

• Gain insights into the rationale behind opting for the strangler pattern over the quick-and-easy rip-and-replace strategy, and understand the trade-offs we accepted with this intentional decision.
• Explore the implementation of the factory method pattern to seamlessly integrate the numerous new data pipelines we built, unveiling the practical advantages it brought to the process of phasing out the legacy pipelines.
• Learn the art of keeping track of communications with numerous teams and the strategies employed to ensure seamless collaboration.
• Dive into the intricacies of stakeholder communication, understanding the different needs of various areas. 

Join me as I discuss the importance of finding a balance between assertiveness and adaptability of your interactions in these projects. This talk offers practical insights for fostering better team dynamics.

We revise our mental models of how the system works, repair the outage if one occurs, and pick up with our change where we left off.

One useful tool can be a dashboard that captures the scope of the whole system, with links to monitoring and other information about each component. This becomes the interactive blueprint model for the system, reducing confusion, cognitive load and improving the success rate of interactions with the system. The jumping-off point for all debugging and change planning.

This talk will look at some examples of these dashboards that represent scopes of the system. Highlight how navigating between related scopes, or components, can be more powerful than standard documentation. Finally, will end with some discussion on challenges particular to multi-tenant systems.

In this case study, I will walk you through the technical journey of building Atlas - the first open-source, cloud-hosted, genetic matching algorithm - comparing the genetics of patients and donors, and returning a list of donors who could be a match for transplantation.

We’ll take a brief tour of the history of matching stem cell donors, and walk through the algorithm that uses genes to determine the best genetic match between a patient with blood cancer and a stem cell donor. Then we’ll analyse the technical challenges that come with taking that to a global scale:

• How much is enough memory to store nonillions (yes, this a real number!) of possible genotypes?
• What are the scaling needs of an algorithm where the number of required computations can differ by multiple orders of magnitude?
• What cloud services can we use to run billions of genetic comparisons within minutes?

Whether or not lives are on the line when developing software, domain expertise is essential. Without it, you can never be sure if your next best step is actually a technical optimisation, or whether you weren’t asking the right question all along.

All of us are motivated by different things, but there is a common set that tends to apply to most people. By understanding which of these are coming into play in a situation and finding ways to align the project, behaviour, or change that you want to see with the incentives people already have, you can find convincing them significantly easier.

In this talk, I will go through some of the common incentives and motivators as well as real examples that I’ve encountered. I will talk through some cases where the incentive structure backfired, cases where we consciously put in place incentives, and cases where we just found better ways to compromise to meet everyone’s goals. Finally, I will talk about my strategies for nudging these incentives to work to my advantage. A lot can be accomplished through a little careful carrot placement.

Fitness functions are a way to codify these guidelines into a set of automated tests that can be run against your services.

In this talk, I will show the different ways we employ fitness functions at Jimdo to keep track of the state of our over 200 services. I will talk about the technical aspects as well as the organisational challenges we faced. I'll also provide insights on how you can implement fitness functions in your own organisations to improve consistency, non-functional requirements and developer experience.

What happened?

Waterloo was just a temporary solution for a cash-strapped British Rail looking to provide an international service. The government had made it clear they would not pay for a dedicated new railway line and Waterloo could connect to existing lines into Kent and accommodate the extra trains and platforms.

It was a far from ideal solution, but it allowed Eurostar trains to start running with the opening of the channel tunnel. Eurostar proved to be a massive success and later on, the case for building a proper high-speed line was successfully made. This came at a cost of over £7.5 billion.

As software engineers, we’re reluctant to build short-term tactical solutions that subsequently need to be torn down and replaced with a ‘proper’ solution. The short-term solution is often heavily criticised (and often rightly so) because of the pain of the migration and cleanup. However tactical tech has an important part to play and can inform much bigger and more expensive decisions. A ‘hacky’ solution can mean you’re getting data from real customers much sooner and unearthing details would have otherwise remained unknown.

Don't despair - I've found a way to deal with them efficiently. A mix of methods and habits used by scientists is the way out of debugging horror. It's a loop of observation, hypotheses and experiments, enhanced with practices used by scholars. It makes debugging more predictable, less frustrating and much faster. I'll share how they helped me in three case studies: fixing a non-deterministic test, stabilising CI infrastructure and resolving a recurring production downtime.

This talk will enhance your programming toolbox for the hardest bugs. Not only this - but you'll see how to scale effective debugging to the entire team. Last but not least - you'll leave with a set of habits to share with your fellow engineers to help them step up their debugging game.

The term normally refers to technical skills, but a lot of comparisons can be made with leadership skills in a Staff+ role: you'll normally know one area, and the people within it, very well, but you often have to adapt and work outside of this depending on what the situation requires.

In this talk Michael will talk through lessons and tips he's learnt when working on a project that pushed him outside of his comfort zone, and how you can effectively utilise the skills and knowledge of those around you to build alignment when leading across a broad set of teams who are often using very different technologies.

This becomes even more complex when you find yourself as the only one with your role, that your role has a transversal exposure and is unknown by most: Staff Technical Program Manager.

Lucky Staff Engineers have benchmarks and expectations outlined in recognised books, aligning with well-established practices in software engineering. However, in the realm of Program Management, we find ourselves in a stage where the function varies significantly across companies, with diverse approaches and operational methods from one organisation to another.

One challenge faced by Technical Program Managers in the industry is to convince the value they bring to their roles, inherently positioned cross-functionally to ensure successful delivery and goal attainment. Staff Engineers contend with comparable ambiguities in their daily tasks, resulting in a convergence of job title trajectories.

This talk offers the perspective of a Staff Technical Program manager as the first one hired in a company, deconstructing the evolutionary journey that paved the way for hiring more of them. This provides an opportunity to explore the essential elements in crafting your leadership journey incrementally, culminating in the ability to influence at scale without formal authority. The format will feature practical tips and tricks gleaned from a two-year experience at Back Market.

Learning by trial and error is not ideal, so how do you create inclusive diagrams and visuals that successfully communicate to your audience? 

Apply communication design patterns and recognise antipatterns.

The purpose of a diagram is to successfully communicate with the audience, which sounds deceptively simple. Communication design patterns can be applied to guide you towards this ultimate goal of successful communication, and maximum inclusion for your audience.

In this session, learn from a hands-on solution architect - and thought leader in communication design and documentation - how to tailor your visuals to your audience, choose the most appropriate standards (or not) and level of detail, and apply patterns to improve accessibility for all audiences.

Typically, there is an abundance of issues, projects, and people that ask for and benefit from technical leadership. At first, this is exciting, opportunities are everywhere. But as you grow in your role, your exposure increases, but your time does not. How can you avoid turning into a bottleneck? This is the time when you need to scale yourself. But scaling yourself goes beyond delegating tasks to others. To multiply yourself effectively, you have to teach your skills to others, turning your colleagues into technical leaders themselves.

In this talk, I will share different techniques that help you grow your colleagues to a level where they can do a part of your job. I will explain the difference between delegating, mentoring, and teaching, and demonstrate with examples how little effort it takes to turn your everyday tasks into teaching moments, improving your understanding of your own skills in the process.

Passing on your skills and knowledge might be the biggest long-term impact you can have. And most of all, it is a win-win-win situation: your company benefits, your colleagues grow, and you gain the capacity to take the next step yourself.

To me, innovation is the process of creating novel meaningful impact through intentional learning. In this talk, I will share this model of the innovation pipeline and strategies I developed to classify and efficiently scale up innovations.

I'll start by introducing three types of innovations: disruptovations, sustainovations, and maintainovations. Each has its playbook for how to get it off the ground and prioritize it. I'll also share examples from my own experiences, both the wins and the losses, and the takeaways you can grab from them. Finally, I'll dive into a few projects that started as a passion project and grew into major patented initiatives stretching across multiple teams and domains.

Join me as we embark on a journey to dissect the anatomy of innovation, uncover strategies to unlock the full potential of ideas, and transform them into impactful realities. Let's build a strong culture of innovation, and make sure that it is not just a buzzword but a tangible outcome.

In Staff+ circles and conferences like this, you’ll hear a lot about scaling up, handling large numbers of people, and expanding influence - all important skills at large enterprises. But what about scaling down? Are Staff Engineers still useful on a smaller scale? How and where can the same sorts of skills be applied when there are only 10-50 total engineers?

In this post-zero-interest-rate world perhaps there’ll be more organisations not getting on the hyper-growth train and sticking to a more modest headcount - will there still be room for people at those companies to grow into Staff and beyond?

I’ll share some of my experiences from moving to a much smaller company and taking my Staff+ experience with me and share some of the things which are very effective but only possible at a smaller scale. 

It is important for a Staff Engineer to delegate some of the work to fellow engineers. Not only to get stuff done but also to empower and elevate our colleagues.

This is easier said than done. Without direct authority, you need to rely on trust, vision, clear communication and finding the right people. You also want to make sure, you delegate authority and make sure fellow engineers feel ownership.

In my talk, I will explore this common challenge and share some of the tips I find useful in my day-to-day to help influence and inspire fellow engineers to get stuff done together.

While the straightforward answer might be no, this talk ventures beyond the surface to offer a compelling deep dive into the nuances of working with large language models (LLMs). In this presentation, I will share 8 prompting techniques designed to leverage LLMs towards crafting first drafts that meet the quality of Financial Times journalism. 

This presentation sheds light on one of such biases: the misconception that software engineering focused on mobile app development is inherently less complex or on a smaller scale compared to backend and infrastructure engineering. This bias persists despite over 17 years since the introduction of the first modern smartphones. Its prevalence holds back mobile app engineers from accessing Staff+ and significant leadership positions.

This talk aims to benefit both, those who unconsciously carry this bias and those who suffer from its effects. For the former, it provides insights into identifying its root causes and pragmatically deciding whether to keep carrying it or not - hopefully not! For the latter, it offers strategies to overcome the impact of this bias and break free from its constraints once and for all!

Our modern cloud native applications have tiny footprints. Our infrastructure is now code. Everything is automated, even creative endeavours like writing and artwork. And yet. Despite all the optimisation, despite all the automation, many of us feel unproductive - and it’s worse than that. Busywork hasn’t gone away, our systems are stretched so thin any disturbance destabilises them, our people are burning out, and IT consumes more resources than ever before. What’s going on? Was efficiency the wrong goal, or are we just doing it wrong? 

Sometimes individual contributors are promoted to leadership positions and worry that they won’t be as hands-on as they used to be. Sometimes they worry that they no longer have time to stay up to date with modern technology and/or the state of their team’s code base(s). Sometimes it’s the other way around: Somebody who has never been hands-on in the technical realm is given a leadership position, and worries they’re “not technical enough”.

Whatever your position, this workshop will help you overcome your worries and figure out the best attitude and approach for you and your circumstances. 

Takeaways: 

• How to embrace the difference between individual contributor and technical leader
• How to take a step back from “knowing all the things”
• How to make the most of the knowledge and experience of your team
• How to identify when technical knowledge matters and when it doesn’t
• How to learn the things you need to know

But with so many variables that contribute to how successful a team is - how can you work out what to change to move the needle? And what should you be measuring in the first place?

Ready to go beyond theory and get practical? This workshop dives deep into DORA, showing you exactly how to apply data-driven insights in your real-world environment to identify bottlenecks, measure progress, and drive continuous improvement. From selecting key performance indicators to fostering a culture of learning, you'll walk away with actionable strategies to boost your team's velocity, reduce time to market, and achieve your goals.

However, many developers are still struggling to adopt AI tools in their day-to-day development process - partially due to AI Skill  Threat: when developers fear that the skills that have contributed to their success as code writers may become obsolete, thus threatening their identities as software practitioners.

In our research, 45% of developers reported AI skill threats. We also found that developers are poised and eager to address the threat they’re feeling, with 74% of developers reporting that they plan to actively upskill in AI-assisted coding tools and technologies.

In this workshop, we’ll tackle AI adoption inside engineering organisations head-on and help today’s technology leaders adopt AI-assisted coding tools and practices in a human-centred and evidence-based way. We’ll walk you through our Generative AI Adoption Toolkit – which comes complete with a benchmarking assessment adapted from our research – that allows organisations and teams to first benchmark their AI adoption readiness, and then respond appropriately to it with tools that allow you to meet your teams and engineers where they’re at in their AI adoption journey.

By the end of the session, you’ll walk away with an understanding of how your  engineering organisation can adapt to this new world of AI-assisted knowledge work in a way that protects the human intelligence of your organisation while preserving it.

We have to know how to prioritize, manage work to deadlines and perhaps the hardest - lead others. Our role means a shift from doing to guiding and supporting. We must know when to manage, mentor or coach. When we use these modalities well we build capacity in the team, increasing our ability to meet organisational goals. Along with it, people feel valued, we strengthen our culture and create a workplace where people want to come to work.

In this mini-workshop, we'll talk about the difference between each of these skills and how to know when to use them. You'll learn three key coaching skills and have the opportunity to practice deciding which modality to use. You'll walk away more confident in your ability to lead others.