 I'm really excited to introduce our next speaker, Camille Fournier. She served as CTO of Rent the One Runway, which is an incredibly cool service that I've only come recently to know, but it is a very, very cool service. She serves on the National Technical Oversight Committee for the Technical Oversight Committee for the Cloud Native Computing Foundation. She's a PMC member of the Apache Zookeeper Project. But most importantly, she has just written a book called The Manager's Path, which is coming out in April. I strongly encourage you to pre-order it today. But her topic is something that I think I can't wait to hear. It's about how to effectively motivate engineering teams. And as you know, we have a small engineering team at the Linux Foundation. Linus Torvalds, Greg Ro-Harpen. And I gotta tell ya, I really struggle with this one. So I'm looking forward to your talk. Please welcome Camille Fournier. Thank you. All right, here we go. Excellent. Okay, building engaged teams in the year of our Lord 2017, hopefully not the last year that we have on this planet, although who knows the way things are going. In times of drastic change, it is the learners who inherit the future. Hopefully all of you are in tech because you like change. Because that's one of the cool things about being in tech is that things change all the time. Technology is always changing, always growing, always evolving. The tech industry has changed a lot since I joined and certainly has changed a lot in the last 10 years. In 2008, there was an academic study of open source projects that was looking for active open source projects. And they looked at SourceForge, which was the site that all the open source projects were in, at the time, and they found 18,000 active projects. For this talk, I used Google's BigQuery to query the records from GitHub to figure out how many active projects were in GitHub in 2016, and the answer was like 21.8 million. Now, even if you take a major haircut, we have an amazing, outstanding, kind of unbelievable growth in the amount of open source there is in the world in just the last eight years. The tech industry itself has grown quite a bit. We've added about a million hands-on, technical-related jobs, technical engineering or management, not just people at tech companies. And we all know there are a bunch of different companies out there in the world. When I moved to New York in 2005, you had about three options for your job. You could work in finance, which is what I did. You could work in media, or if you were really, really lucky, you could find one of the relatively small and few on-the-ground tech companies to go work for. If you fast forward to now, the Google office alone has thousands of engineers in New York City. We have offices from all the major tech companies in the city, and they all have quite a big presence. We have a ton of technical startups. So the landscape has changed. Oh, my God, is this doing autoplay? Well, this is gonna be fun. All right, about me. So, who am I? I am the former CTO over at the runway, as they said. I grew that engineering team from 15 to 65 in the course of my time there, and I learned a lot about hiring engineers and growing successful teams. It was not easy, so I wrote a book when I left to sort of get all of these thoughts out on paper about what it means to become an effective leader and effective manager, and that's coming out, and I hope you'll all buy it. But really what I learned is that building a team is really hard work, as I'm sure many of you know. Whether it's an open source team or a company employed team, it's really hard. I had a lot of challenges doing this. I thought it would be easy when I went in, because I was like, oh, look, I'm charming. This is a cool company, it'll be fine, no. Unfortunately, charm is not enough. In fact, my nickname at work apparently was the hammer. This is the fitness hammer that I was given as a going away gift from my team. So I had a lot of things that I had to learn about being an effective leader, and I had to learn about what engineers want. What do they want? I think they want three major things. I think they want rewards, which are the basis for contribution. I think they want respect, the stickiness of commitment. I think they want purpose, right? A sense of ownership. These three things are essential ingredients in creating effective and engaged teams. So let's dig in. Contribution, the promise of rewards. What is it that gets people in the door in the first place? There is a little bit of a myth, a no true Scotsman myth about engineers. Oh, they don't care that much about money. They care about working on cool tech. They care about learning and growing. These are all true, but let's be real. Economics, if you want to get people in the door, you need to be creating an economic incentive for them to join. If you are not paying people well, they're not going to want to come to your company. When people are making that first decision of whether to engage, economic incentives are a large part of what drives them. That can mean not just pay, but having a cool office, having good equipment, having the status of a cool company that people want to work for, and this applies to open source projects as well. If your project is cool, people, more people are going to work for it. We all know this, right? People go to open source projects largely because their employers are paying them to do it, so there's an economic incentive. They go into open source projects because they're using them at work. They go into open source projects because they think that having it on their resume, like Kubernetes mentioned earlier, right? Having it on their resume means that they will be able to get more jobs. So getting folks in the door, economics, really important. But once you've gotten them in the door, how do you continue to engage them? How do you continue to encourage them to contribute? Well, speed, speed, speed is important. Speed, getting able to get things done. People want to be able to say that I am able to do the thing that I do best every day. That is actually a really important thing to ask your employees at work, right? Can I do what I do best every day? One of the first major improvements I made to the engagement of the Rent the Runway Engineering team was I pushed them to move from deploying once a week to deploying once a day. That may sound boring to all of you, or I don't know, maybe that sounds very exciting. I realize open source projects have somewhat longer cycles. But it was amazing when we did it. We did some work, did some automation, made things easier, and when we turned that process on, it was like a flip switched, a switch flipped. Gosh, I always say that wrong. Turns out engineers like to ship. People were immediately more engaged. They were able to get more work done. They were able to check things off of their to-do lists. They were able to see their work go live into production in front of customers that much faster. Being able to move fast and being able to get things done is a reward, is a reward. Every day you get to solve a little piece of a puzzle. You feel good. This is part of why we all went into tech in the first place. All of you who are hands-on engineers or who were at one time, remember the joy of getting to write code in the fast feedback loop of writing code, which is in contrast to these slow, slow feedback loop of managing people. This applies to open source projects as well. Our open source projects can be very painful to contribute to when you don't get responses to your questions on mailing lists when nobody reviews your pull requests. Thinking about how we can make those processes easier means that people are gonna be more engaged. They're gonna be getting good feedback. They're gonna be having those feedback loops go. So they're shipping, they're getting things done. They're learning. Engineers like to learn. They like to be learning new things. And the faster you can get work done, the faster you can get feedback, the faster you can learn. So rewards are an important fundamental element to getting people in the door and getting them contributing in the first place. Okay, but beyond contribution, there is commitment. How do we get them beyond that first level of just contributing a little bit, just joining the team? We've all had the experience, probably, if you're a manager, you hire someone. They come in, they're great for six months or nine months. Maybe around 12 months, they start to kind of get distracted. They get a little bored. And they're out the door in 18 to 24 months. They're off to the next thing. So this company is offering me more money. This company, I get to learn new things. They are not committed. So how do you get them beyond the simple acts of contribution to actually being committed? I think this is all about respect, all about community. Safety is an important characteristic of effective teams. How do I feel around my team? Do I feel safe? Do I feel able to make mistakes, ask questions? Do I feel able to be vulnerable in front of the people I work with? This is not my insight. Google did a massive study of their teams. Now, we know it's Google. So we know they've got great engineers. They're working on interesting work. They've probably got tons of teams that should be performing incredibly well and yet some were performing better than others. What was the difference? One of the fundamental things they found was that psychological safety, that feeling of being able to take risks and be vulnerable in front of their colleagues. How well do we feel that we do this, especially in open source? Not that well, right? How do you develop this? Well, I think this all comes down to really a feeling of relatedness, a feeling of kinship, friendliness, community, feeling like you're part of a group that has your back, you're part of a tribe. This is ultimately what gives you that psychological safety element. I had to learn how to do this. I was not good at this. This is an image from Daniel Tiger, for any of you who are parents of toddlers, you might recognize this. When I first became a manager, I had been a senior staff level individual contributor for a long time. I was very much down to business, get it done, let's talk about the problems. I'm not interested in small chalk. I'm not interested in any of that stuff. And when I became a manager, that actually undermined my ability to create stickiness in my team. When I slowed down and just started asking people simple questions, how's your day? How's your weekend? How's your dog? How's your marathon? Just simple things. We're not coming and coming BFFs at work, just treating people like they are more than a cog in a machine, treating people like they are a human. All of a sudden, things started to change. I started to care about them more. They started to care about me more. We became a more effective team and a more effective community. When you get pride in your work, Kubernetes talked about this in their talk this morning. They announce when committers to the community do amazing things. And that means a lot to the committers and a lot to the community because they respect the other members of the community. It's very hard to get that feeling of pride and respect when you're around people that you don't really like. So building this relatedness is essential for getting this commitment. However, I'm gonna take it one step further. There are a lot of people that think that the best way to engage engineers is to put them off in a corner, give them hard problems and leave them alone. And I am sure that that is true to some extent for some problems and sometimes. But my experience in building a team that was building a consumer-facing product with a very complex business was that I had much better results when we created cross-functional teams, when my engineers worked very closely with marketing, with product management, with customer service in order to be part of the whole process of building great products. It turns out that that made them feel not just like they were part of the engineering team community, but they were part of the larger company, that they had the larger us that they were engaging with. I think this is very important. There is more to life than code. We see this in our open-source projects. Big, successful open-source projects need more than just software developers. They need people who are capable of answering questions on mailing lists, of getting up on stage like I'm doing right now and teaching people about how to use the project. That's how we develop these successful partnerships. So how can we treat all of the members of our communities like they are equal partners, like they are all important parts of the community? This is something that will help drive more respect and more commitment. And of course, the end game, the end goal here is creating a sense of purpose, giving people a sense of ownership. People who feel like they're part of a larger community will start to feel better about their jobs and ultimately we want them to have this sense of purpose and ownership. Swartly just got up here and talked about how hard it is to think about strategy and why and it is true. But we all know as managers, if any of you is in senior leadership positions, we really gotta have that mission, you gotta have that vision, you gotta have that why that you explain to people why this exists, why this team exists, why this company exists. And that's great and that is important, important element of leadership. But the challenge for most of us is not just the high level why. It is breaking the high level why down into today. Why this? Why am I working on this right now? Why am I solving this problem? If I can't answer that question, why I'm solving this problem? If I can't tie my work back to the larger whole, it's hard for me to take ownership and make good decisions. Some people will still try to do it, but you really want people to understand how their work fits into the larger whole so that when they start to take larger pieces of ownership, they can make decisions against the same set of values and the same set of concerns that you as the original owner would be making. This is about teaching people ownership. So going from why to why this and teaching people ownership is essential to getting those people to actually take it and become more engaged. However, mission-driven companies can hire people and pay them somewhat less money. I believe that is true. If you have a really strong mission that people feel like is for the common good, they will be more incentivized to come work for your company. But the challenge of those companies is that those people that you've hired because they love your mission want to have more decision-making power. They care so much about the why that they wanna be part of the deciding process. They wanna be helping to decide where we're going. When you teach people ownership, they wanna take ownership. That's good, but it can be very uncomfortable. If your whole goal is to keep all the ownership yourself, is to be the person who makes all the decisions, you're never gonna get a team that's fully engaged and bought in as owners themselves. They're never gonna be as engaged as you might want them to be. You have to learn how to give away your Legos. There's a good blog post by a woman named Molly Graham, you can Google it, called Giving Away Your Legos, and part of the value of teaching ownership is that you can do bigger things. You can give away some of the things that you were worrying about and do something else, and you can build something much larger, much more complex. Giving away ownership is how we scale. When we created those cross-functional teams at Rent the Runway, they were successful not just because we helped people see the larger context of the business, but also because we gave them high-level business goals and told them to figure out the steps that they wanted to take to achieve those. What features should we build? What products should we build to achieve those goals? And that was incredibly, incredibly engaging. So giving away ownership, figuring out how to engage people, not just by saying, here's what you're doing, go do it, but saying, hey, here's the goal, figure out how we think we should go do it. That is the true engagement that comes from a strong sense of purpose and a strong sense of ownership. So these three things are all interacting. Ultimately, it's not a series of steps. It's not a step ladder. Once you get people to ownership, it's not like they're just completely perfectly engaged and you're done. Unfortunately, that's not the way it works. You can undermine people by neglecting any one of these, no matter how engaged they are. If you have people who are very committed, but they feel like they can't get any work done, they just feel like it takes forever for them to write code to succeed, they're gonna feel less engaged, less and less engaged. Owners leave communities that they feel are unhealthy for them. They feel are not safe. People leave companies all the time because they are like, this is too political. I don't like my coworkers. And people in open source, famous people in open source have left communities because they feel like their communities are toxic for them. These are all things we need to think about all the time and we need to continue to work on in order to keep these teams completely engaged. So, the three factors of engagement. Rewards, economic status, getting things done. People need rewards to get that sort of contribution level, right? Engineers like to ship. Think about all the different ways that you can engage people and reward them. Respect, safety, relatedness, community, partnership, feeling like you're part of a whole. Treating your colleagues like they are humans because they are, they are not computers even if you mostly only interact with them on computers. And purpose, right? Why? Why this? How do I get part of this decision-making process? How do you give away your Legos? So, I don't have my notes in front of me so I'm gonna flubble this a little bit. This is a sign of change, right? I started this off with a quote about how in times of great change it is the learners who inherit the future. And the second part of that quote was something like the learned basically have skills that are no longer applicable to the current circumstances. So, we are always in great times of change in the tech industry. Keep learning. Keep asking yourself questions. And keep questioning yourself, how do I keep my teams engaged? And this is the secret to building great, motivated and engaged engineering teams. And with that, I thank you. And here's my book and, you know, all my contact info. So, that's it.