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 which 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.

Maybe you want to hire a new engineer, PM, designer. Maybe you want to support that one person on your team who is from an underrepresented group in tech, maybe with a non-traditional background. But you don’t know-how - and you think diversity and inclusion are good.

Adobe is a company that values diversity and inclusion and we’ve both been part of leading the charge to improve the current landscape. Particularly, because we both took non-traditional paths to get to our (creative and engineering) roles within Adobe. We’re passionate about advocating for the value of people from non-traditional backgrounds, in all areas of the technical culture - engineering, art, design, and more!

We’ve noticed some areas with room to grow - across the tech industry, so we’ll provide concrete steps towards improvement. Both, how to take note of the current gaps and how to improve - in creating and sustaining spaces for people from non-traditional backgrounds, in our shared tech culture.

Overall we will explore how creative change and human empathy impacts career growth - particularly for folks from underrepresented and non-traditional backgrounds in tech.

Do you work at a company that is “difficult for juniors”? Do you care about diversity and inclusion of under-represented groups at your workplace? Do you ever stay awake at night with the gnawing feeling that these two ideas are somehow incompatible, but can’t put a finger on why or explain to your company how?

So often, the endeavors of hiring and mentoring junior engineers and of bolstering diversity and inclusion efforts are seen as “nice to haves” at best and “extraneous” (or even “impossible”!) at worst. But in reality, building diversity, inclusivity, and strong ability to incorporate and mentor junior engineers go hand-in-hand, and engineering teams might do well to begin thinking of each of these efforts in service of the other.

Together, we’ll articulate the intersections between on-boarding and leveling-up junior engineers and building a diverse and welcoming team, and learn low-cost tactics for incorporating mentorship and D&I processes at your place of work.
 

The Splice Engineering team grew almost ten times in eighteen months. The delivery practices that worked for us when we were five broke way before we got to fifty. We wanted our organization to learn faster than the market; to do this, we had to find a way to unlock our delivery. We used insights found on the State of DevOps Report and Accelerate, the book. With this knowledge and the help of metrics to visualize our delivery, we were able to get back on a high-performance track.

This talk tells the story of how we used data to engineer the performance of our engineering organization and gives you practical takeaways on how you can do it too.

Leslie will share a frank and personal journey to understand and overcome bias in her career and drive positive outcomes for herself, her team, and her organization. She will share with specific practices for reducing bias and improving inclusivity that were impactful for her team. Please join her as she discusses turning fear, uncertainty and doubt into positivity, inclusivity and courage.
 

The talk is about the most powerful tool developers have at their disposal: the human mind! Drawing from cognitive science, we'll explore how we can improve how we learn and store information about our systems in order to respond better to incidents and anomalies. Infused with practical examples of how to improve our memory and learning, this talk moves from advice for individuals to how we can form and develop learning teams. It's a talk broken into four parts: preparing to learn, gaining knowledge, building mental models, and enabling a team to learn well together.

The story you tell about your work is as important as the work itself. You can do great work, but if you talk about it the wrong way, you can destroy its impact. For example, the wrong story can diminish your work, hurt your team's credibility, and throw off project estimates. I know because I've messed this up many times.

In this talk, I'll share the hilarious and painful mistakes I've made as well as the strategies I've learned to avoid these mistakes. By the end, you'll hopefully have a better idea of how to talk about your work.

I believe high performing teams need four things to be effective:

- Mastery - The skills & knowledge needed to do a great job, and a clear path to get to the next level.
- Autonomy - The space to figure out their own solution to a problem & how they want to work
- Purpose - A clear sense of direction, and the knowledge of how what they’re working on fits into the big picture & helps their team succeed.
- Safety - A team that is afraid won’t take risks or experiment, a team that is afraid of finger-pointing won’t learn from mistakes.

In this talk, I’ll explain why those four things are key to teams being successful and give examples of how I’ve turned teams around by fixing the lack of one or more of them. Audience members will leave with practical examples of how to diagnose & improve the performance of their teams.

The first twelve months of your managerial career are the toughest. In this talk, Gemma will describe five of the techniques she has used to survive her multiple re-entries into engineering management - with real stories of the wins, mistakes and entertaining moments along the way.
 

We all hear about the benefits of continuous, rapid iteration for digital product development. But what about the people behind those products, and the processes they use to build great digital experiences? In this talk, Fernando speaks about our responsibility for continuous improvement and how it can be a rewarding approach. Adapting your processes for each team can yield higher morale and higher-quality products. From optimizing code reviews to escalating the number of codebase contributors, hear real examples of teamwork challenges and how custom solutions for these have worked to deliver products at Work & Co.

As technology leaders, we exist in an ever-changing ecosystem where the pace of change is continuously accelerating. The ability for organizations to thrive in a rapidly evolving industry environment depends on how effectively teams can scale learning curves for new technologies, skill sets, products and processes. But how can teams create a culture that embraces change and catalyzes learning?

This talk applies the learning zone model (Senninger 2000) as a framework for product and engineering teams, and discusses leadership strategies for building a sustainable culture of learning. We will explore the challenges and implications for technology and product leaders in cultivating cultures that enable teams to operate within the learning zone - the “sweet spot” between the comfort zone and the panic zone.

Whether it’s managing code ownership, managing who can change firewall rules, or monitoring spending on cloud services, engineering leaders spend a lot of time creating and running programs, but we rarely think of it that way. Having spent three years on SOX compliance, one of the most involved and complex programs you can imagine, I’ve learned a number of painful lessons and identified patterns that can be used to build programs of almost any kind.

This talk will help you recognize when you’re actually designing a program and create programs that engineers don’t hate.