Agenda

Building a team culture requires time, care, attention, and intention. While we tend to treat the decisions we make with great care in relation to our team culture, communication is often the forgotten sibling, and can be treated as an afterthought, at best. But in a team where you're intentional about your culture, you treat the communication with as much attention as you do the decision itself.

All of us work with codebases which are at different stages of life and at different quality. We are in a world with ever changing business requirements and are constantly in a time crunch. This frequently leads to teams becoming feature workshops which typically comes at the expense of quality.

Software products are ever changing, so, it is paramount that the code that shapes this software remains supple. Clean, testable code provides us with maintainable code with fast and well understood tests. It ensures longevity of the software without having to do major refactors.

As leads we all understand the advantages of Clean Code. However, the adaptation is limited. In most organizations there is no clear champion to speak for Clean Code. Unspoken, this responsibility largely falls on all Lead Engineers. It is often a daunting task to introduce a new coding paradigm to an already chaotic and busy development cycle without a clean strategy. This talk focuses on providing simple and easy steps to aid in adopting clean code practices during a fast paced development environment without affecting velocity of the team.

Built-in quality is a natural outcome of a continuous improvement mindset. Even more, built-in quality is one of the SAFe core values and a core principle of the Lean-Agile Mindset. It states that quality is everyone’s job and must be preventive, not reactive.

How can we, as Technical Leaders, help our teams to understand that quality is not the QA’s work, and must be distilled in every action, every line of code, every single little commit the team does?

In this talk, Larissa will explain what is Built-in Quality, Lean and SAFe vision, give practical advice on the benefits of actually using the practices of built-in quality, and guide a team to adopt some practices and use the QA as a guide for the built-in quality, and not for its guardian, so the whole team can, together, instill quality, and make a better product and User Experience!

This talk will focus on how to create an effective observability system in microservice architectures. This talk focuses on which observability practices and microservice architecture patterns align well and set microservice organizations up for success.

One example of effective techniques includes having consistency across all services since this consistency can centralize the definition of observability & what it means to have an “observable” system, make it easier to set up observability for services, and enable engineers to troubleshoot production issues across their own services and service dependencies.

Another example is having SLOs that align well with microservice ownership. Much like any given team should not own more than a few services, any given team also should not own more than a few different SLOs. I will dive into the organizational benefits that microservices provides and SRE reinforces by implementing SLOs.

Thirdly, how the main units of an observable system (events) align well with event-driven microservices. I will go into specifics on how events, logs, metrics, and traces relate to one another.

Interviewing is often too subjective. Is it right to decide a candidate's suitability based on an interviewer’s opinion, from a general impression? Carta values data, and so we transformed our interviewers from decision makers into data gatherers. We wrote specific rubrics which objectively capture the attributes we value in a candidate profile, from technical architecture to organizational influence. Instead of simply giving their subjective opinion, interviewers consult the rubrics to measure a candidate's performance.

Our data-driven approach helps us reevaluate and continually improve our overall hiring process. Are candidates consistently scoring lower than expected on some attribute? We can improve that rubric to help us recognize their talent. Are some interviewers struggling to gather specific signals? We can offer training to sharpen their understanding of that topic. And we can now measure if interview outcomes actually correlate to performance outcomes and thereby improve both.

Our rubrics also help with leveling decisions, and the signals we gather help avoid particularly difficult and often arbitrary judgment calls when evaluating more senior engineers.

We would like to discuss how we created our rubrics and introduced them to our organization, and what we have discovered about how the process has affected our hiring outcomes.

Many teams depend on code review as a way to maintain code quality, share context across the team, and ensure compliance with organizational priorities such as security standards. When a new engineer joins a project team, they often hesitate to review code, because they feel like they’re too new to any value. But that fresh perspective is often the most valuable asset to an established team!

This talk, borne out of many 1:1 conversations with new engineers, will present a number of different lenses for reviewing code, so that even the newest graduate developer can jump in and contribute from day one. For more senior engineers, I hope to provide a critical framework for thinking about different types of contributions. Thinking about code review in terms of different lenses will help engineers of all experience levels build a vocabulary for seeking and providing feedback in a healthy, thoughtful, and collaborative way.

It's expected for the structure of your teams and organization to change as you grow. This is also true for the processes and communication channels you need in place so that everyone remains highly effective. What works well for a team of ten engineers falls short once you have thirty. You adapt and then feel some friction again when you get to a hundred. Rinse and repeat. At Intercom we’ve iterated and been through this process a few times having grown engineering from one team of four engineers sitting together in the same room to 160 people in 30 teams across three countries and two time-zones.

I’ll share how we’ve been successful at empowering engineers to drive organizational change. Their uniquely positioned being the vast majority of the org and at the same time closest to some problems. This allows them to identify, solve and own solutions to the challenges they face. When is it important to iterate? How do you identify when you've outgrown your current setup? How do you set yourself, and the org, up for success? This talk should give you some ideas and answers to these and apply them to existing or future problems your teams might face.

Every single person is bad at predicting the future, and yet we are still expected to answer questions like: What will I get? When will I get it? How much will it cost? Answering these questions off-the-cuff can have dire consequences and can be a source of anxiety, frustration, and distrust among teams.

Software estimation is often an overlooked and maligned process, but when used effectively it is an essential tool for organizations solving complex problems. In this primer on software estimation, you will learn about sources of estimation errors, techniques to mitigate them, and approaches to communicate your estimates. Learn to embrace nuance, control chaos, and begin to confidently deliver on your commitments.

In any organization, there will be people who behave inappropriately, sometimes grievously so. Here’s the paradox: the more senior the role you’re in, and the more power you have to help coworkers who are facing awful behavior like harassment or bullying, the less likely you are to see those things.

Personally, when I was younger and in junior roles, I dealt with harassment all the time. Now? I rarely see it directly. That's not because it happens less now. Instead, it's because harassment and bullying are functions of power, and people who behave in those ways tend to perceive me as having relative power. So they're generally very, very nice to me. If you’re in a position of power--say, as a manager or tech lead--they’re probably very nice to you, too. So how can you become aware of harassment and bullying that happens when you’re not in the room? And what can you do about it? This talk will look at techniques for surfacing and addressing bad behavior.

You may be convinced that your team “isn’t equipped to support junior developers right now” but that's no reason not to work towards it! You can prepare yourself, your team, and your organization to welcome juniors. In fact, doing so is an important investment in the sustainability and scalability of your team. In this talk, we’ll discuss actionable steps for building junior-inclusive practices through active reflection, sustainable processes, and a focus on empathetic communication.

We’ll cover: 

• Getting buy-in
• Documenting team knowledge and processes
• Writing an approachable job description
• Setting clear expectations
• Scoping work
• Giving and receiving feedback
• Recognizing achievement and growth
• Acting as a sponsor

Most people are visual learners who absorb information from visual aides (diagrams, images, compositions, charts) which helps us map that content in our minds. Everyone can benefit from seeing the ‘grand vision’ as a starting point for product launches. The problem is our conventional methods of learning are usually focused on text which may not resonate with people trying to get a sense of what they will be getting into.

One way to address the need to convey critical information to a group who may be visually biased in their learning is to use illustrations like Roadmaps. A Roadmap is a great way to showcase ideas, products and resonate with your team what the big plans are. Beyond just a simple chart or diagram they can be useful as communication documents to align all stakeholders and get ready to dive into the details. Learn what is possible with using an illustrative Roadmap to tell a story and inform your team on all the critical details in an intuitive and fun way.

In the late 1950’s, a woman named Jane Jacobs changed the course of New York City’s history. In fact, if it wasn't for her, there would be a highway cutting straight through Greenwich Village today. Jane Jacobs shaped the trajectory of how modern-day cities are designed and organized. Her revolutionary book, The Death and Life of Great American Cities, continues to be a cornerstone of urban planning.

Cities and codebases have a lot in common. In the real world, we inhabit and interact with other people within the framework of a city; in software, we inhabit and interact with one another within the context of our codebases. So what can we learn from Jane’s observations of what makes for a lively and healthy city? And how can we apply the principles of a vibrant city to a vibrant codebase?

As it turns out, the answer to these questions lie, not in the code, but rather, in the people who build it. Let’s see how we can apply Jane’s principles to our own software teams.

As a technologist, you have the power to create, to change, to destroy, and to sustain. With this, you have responsibilities for the success of your organization and long-term impacts on society. What are techniques to assess the landscape and to evaluate the impact of your work? We’ll survey a few tools for making strategic decisions (wardley map), architectural decisions (domain-driven design), team decisions (hypothesized problem statements, feedback-driven-development), and social decisions (carbon footprint, DEI-centricity). Be empowered for your responsibilities.

You might be the first engineering leader at a startup, you might inherit a mess from a predecessor, or you might just experience catastrophic organizational change and now you have too many fires to put out at once. As an engineering leader you must balance day to day process, people and performance management, organizational growth, strategic product planning, technical debt, and your own mental health. If everything is a priority and everything is on fire it is a huge challenge to keep your work inside work hours while delivering results.

How do you decide what to focus on? How much time do you dedicate to that problem? We’ll discuss the deliberate steps you can take to help you and your team put out the fires, rebuild morale, and plan for a better future. This talk offers some practical advice for triaging, prioritizing, and taking effective action to pay down your management debt while honoring your work/life balance, even if it feels like the sky is falling.

Migrations- often seen as a necessary evil and bain of existence for engineers. Spotify is no exception to the laws (and pitfalls) of migrations that pay down debt and help advance tech strategy. While we share common problems with every other tech org, because of our scale and organizational structures and decisions, we have iterated on a set of principles and processes to ease the pain of transitioning from one tech stack - whether it be as low level as OS or language version - to higher level product features.

Spotify is a globally distributed company with 280+ engineering teams and 1200+ microservices. We’ve had a strong focus on engineering autonomy, and, as such, within our Platform (infrastructure) org, have had to cultivate ways to drive migrations with carrots over sticks. We’ve achieved this through a strong focus on product and product marketing techniques, quantitative insights, and driving a clear value proposition for engineers. We’ll share our learnings (and misses) about how we were able to move molehills and, in some cases, mountains while preserving engineering velocity and a sense of ownership and autonomy.

No matter how much you plan or mitigate the risks, people are going to make mistakes. How you react to that as a manager is one of the most important things you can work on to increase the health, performance, and resilience of your team.

And it's hard. Much harder than all the shiny policies you can introduce when things are going well. Because in the heat of the moment we often react emotionally rather than with practicality, measure and kindness.

We're getting better at this as an industry. Blameless post mortems are more common and the days of wearing the hat of shame or buy the beers when you mess up have, thankfully, mostly gone. But how much better are we in our interactions when one of our team does something that will reflect badly on us as a manager? Do those old feelings of shame, or panic, or the avoidance of blame rear their heads? Does that have an impact on how you respond to people?

Most of us have weathered a few moments when our blood has run cold as we realise we've done something that feels catastrophically bad. Whether it was damaging or a learning experience was almost definitely shaped by the reaction of the people around us, especially managers. This is the difference between being able to fix the problem as quickly as possible and learn from it and the situation spiraling.

By exploring our own reactions to being in the chain of responsibility of an error we can build our own resilience to absorb the fallout, protect our team and help them to feel safe enough to take responsibility and grow from these experiences.

Most engineering teams maintain their own balance between feature work and technical debt. This varies according to culture, funding phase, and even the product area. With little provocation, most engineers could probably rifle off a laundry list of items they’d like to tackle to improve their workflow, speed up processes, or just maintain their own sanity. However, work on technical debt for too long and you’ll lose sight of customer focus, neglect important features, and your engineers may begin to miss the shiny feature work that elevates their careers.

So how do we decide when dealing with tech debt is worth it? On the ground, many developers struggle to find the balance between striving to improve existing code and letting good enough alone by accepting certain shortcomings. As a new developer to a team it can be difficult to understand existing strategies and patterns that are sometimes flat out bad (and often openly acknowledged as such). Often the result of tight deadlines or unclear specifications, even the best developers write code they later look back upon and shudder.

Come learn how to develop your own framework for addressing technical debt as a company. I will discuss strategies for prioritizing technical debt, ways to “stop the bleeding” of bad practices, and potential complicating factors. 

Back when our team was small, all the devs participated in a single on-call rotation. As our team started to grow, that single rotation became problematic. Eventually, the team was so big that people were going on-call every 2-3 months. This may seem like a dream come true, but in reality, it was far from it. Because shifts were so infrequent, devs did not get the on-call experience they needed to know how to handle on-call issues confidently. Morale began to suffer and on-call became something everyone dreaded.

We knew the system had to change if we wanted to continue growing and not lose our developer talent, but the question was how? Despite all of the developers working across a single application with no clearly defined lines of ownership, we devised a plan that broke our single rotation into 3 separate rotations. This allowed teams to take on-call ownership over smaller pieces of the application while still working across all of it. These individual rotations paid off in many different ways.

With a new sense of on-call ownership, the dev teams began improving alerting and monitoring for their respective systems. The improved alerting led to faster incident response because the monitoring was better and each team was more focused on a smaller piece of the system. In addition, having 3 devs on-call at once means no one ever feels alone because there are always 2 other people who are on-call with you. Finally, cross-team communication and awareness also drastically improved with the new system.

One of the outcomes of The Great Resignation, The Great Reshuffle, or whatever you want to call it, is that many leaders have taken this time as an opportunity to pursue opportunities with new companies. In many cases, a brand-new leadership role doesn’t mean a brand-new team. Most of the time you “inherit” a group of people who have been there a while --- and on whom you will greatly rely if you want this new role to be a success. In this talk, we will show you how to do just that.

As support engineering and success leaders at companies like Humio, Nylas, Wistia, and CrowdStrike, we've frequently been called on to lead, reform, and scale-up existing teams. In this session, we will talk through our experiences, challenges, and best practices. We will also share the strategies and resources we used in the cases where we had to "turn the ship around".

Over the last few years, we have seen organizations gravitate towards implementing the DevOps methodology: Breaking down silos, introducing efficient incident management, releasing faster and improving collaboration between development, operations and quality teams. However, many teams struggle with how to tackle the problem. Blameless postmortems or retrospectives are the most effective ways to grow, learn from mistakes, improve transparency and increase service ownership.

This session will showcase successfully proven postmortem best practices that modern teams, tribes or squads can follow. The audience will come away with a better understanding of how to run effective postmortems consistently to mature DevOps in the organization.

Legacy systems are like wisdom teeth. You know you’ll need to address the problem at some point, but unless it’s bothering you all day and keeping you awake all night, sometimes we just keep delaying it. When setting priorities, deprecation efforts often end up not making the cut.

Only more pain comes once you start working on actual deprecation: having to understand obscure and untested code, reverse-engineering the contract, weeks of testing and debugging, ensuring minimal disruption when actually flipping the switch.

This is a story of a 2-year-long deprecation of a legacy system that used to support several crucial parts in Netflix’s signup and account management space. Come and learn:

• The 3 most important skills for deprecating legacy systems: inquisitiveness, proactiveness and simplification mindset 
• A few technical approaches we took which proved extremely useful, eg. retrofitting end-to-end tests or using A/B experiments - and a few which we wish we didn’t take 
• How Netflix culture of freedom and responsibility enabled the project to move forward, despite the usual prioritization caveats - and how to apply this in your team 
• What principles (both technical and people-oriented) we established for the new system, with the hope of giving it a longer shelf life

In a study popularized by Frans de Waal's 2014 TED Talk, two monkeys were given a simple task: take a rock from a researcher, give it back, and then collect their reward. For the monkeys, it was a pretty good gig: in exchange for a few seconds of minimal effort, they would each receive a delicious snack. But there was a catch. One monkey received a cucumber, while the other received a much-preferred grape. Mere minutes into the exercise, the monkey receiving the cucumber began to protest this perceived inequity. Rather than accept the cucumber reward, the monkey responded by throwing it back at the researcher.

Just a few moments earlier, this monkey was perfectly content to receive a delicious cucumber in exchange for this minimal effort task. However, after seeing his companion receive an even better reward in exchange for the same effort, he resigned in protest. Why would this monkey give up a perfectly good reward  -- at his own expense  -- just because the other was receiving a slightly better one? And what can this anecdote teach us about building effective engineering teams?

This talk will cover the basics of equity theory, a theory of motivation that argues that both monkeys and software engineers match their level of effort with their perceived reward. We'll explore how to discover your team's grapes and cucumbers, what the best managers do to retain their top talent and ways you can make your team both happier and more productive.

The past two years have forced many teams to swiftly learn how to work in distributed teams. The transition hasn't always been an easy one, but since remote work is here to stay, it would be in our best interest to find the most effective ways to keep our teams happy, in sync, and productive. In this talk, I will dive into how you can do your best to ensure your team has psychological safety and the proper processes to set yourselves up for success in a remote-first world.