 Hi everyone, welcome to a talk about onboarding. So I'm Andrew, I'm a software engineer at Pivotal. I've been a core contributor on Bosch for about two and a half years. My name's Denise. I drew all of the slides, in case you were wondering. So sit back and relax. This is not going to be like a super deep technical deep dive or anything like that. It's literally just going to be like Pokemon using technology drawings for the next 20 minutes of your life. So enjoy. I am also a software engineer at Pivotal. Oops, went a little bit too early. It's OK. I also work as a software engineer at Pivotal. We're both based in the Toronto office. I really like Vim. I don't know, that's my defining characteristic as an engineer. So I want to begin by framing this talk a little bit. So Andrew and I both work at Pivotal. We've both only ever been Cloud Foundry contributors at Pivotal. So of course, our own experiences are informed by having worked for Pivotal. So one thing about R&D in Pivotal is that there is a open source team in almost every single office, which means that if you join R&D as an engineer, there's a very high likelihood that you'll be contributing to open source full time at some point in your career. Because of this, the onboarding program is designed to facilitate and to promote fast development and fast onboarding as an open source contributor. Of course, the thing we want to call out is because we have never ever worked at another company, the things we're about to talk about in this talk are not prescriptive. It's not like, we're the best. This is the only way to do things. These are just our experiences and what we've seen to work, what we and other individual contributors within the Cloud Foundry branch of Pivotal. So. Cool. Let's start with a brief history about our onboarding journey. So back in 2015, we didn't have any real onboarding process. So our new colleagues were expected to just learn through pairing, and we just kind of hope that by rotating through different teams that they'll be able to ramp up quickly and become more productive. So what we kind of noticed was this wasn't really working. People weren't ramping up as quickly, and their managers were receiving feedback that, hey, we're kind of confused about what we're supposed to be learning, like what are the different core domains. So moving to 2016, we started our first onboarding week. So new joiners were given a backlog of tasks designed to get them off the ground with deploying Bosch, Cloud Foundry, using the different CLIs, and experimenting with deploying things to these systems. And between 2016 and 2018, we started adding some facilitation to help guide the onboardees and collect feedback. So during this time, we recognized that this one week process was very valuable, and people were able to understand and be more productive when they returned to the projects. So during this time, we started having more deliberate cross-office collaboration. And this was initially started by San Francisco and the New York office's management teams. But this is now something that's organized between multiple of our offices, and it's done at both the management and the engineering level. So what about today? So today, we're still learning. And we hope that by sharing what we've learned, that maybe you'll be able to go over some of these mistakes that we've had. So before Andrew takes you through the actual tasks of onboarding, I want to spend a few minutes talking about the North Star. So what are the goals that we're trying to achieve? What are the outcomes we want to see? We think that this is an incredibly important part of designing any kind of process. If you don't know what you're working towards, then how do you iterate? How do you course correct? So here are our goals. For the person being onboarded, we really, really want them to leave onboarding week with a strong understanding of who their support network is. So of course, this means within the company, you understand what other teams in your office are working on. But also in the broader Cloud Foundry community, you understand what the main projects are, you understand where the Slack channels are, you understand who to talk to you if you have questions about Knative, for example, or Irene. Building this high-level lay of the land and understanding who to go to to ask questions is going to fast-track you seriously when you start to work in this ecosystem. So within Pivotal, some of you might know that we're quite opinionated about what we use and how we use it. Chances are your company also has some opinions about what backlog tracker, what backlog tool you want to use. I'm just like, slip tracker in there. Sorry, that was accidental. And maybe like whether you pair a program, whether you do TDD. Ultimately, it doesn't really matter. Your culture is the culture that you want to build. But we think that onboarding week is a really great time to allow people to explore the tools that they're going to be using for a really long time. So normally during your day-to-day work as an engineer, you sort of learn just enough about get or tracker so that you can get unblocked and get the feature done. During onboarding week, we really want to create the space for people to grow and for people to explore at their own pace. So there's no requirement of like get the thing done and move on. And another incredibly important outcome is a lot of us are going to be contributing in an engineering capacity. So building a mental model of the Cloud Foundry ecosystem is really, really important. Of course, like for anyone who's worked in Cloud Foundry, you probably know that this ecosystem is huge. Like there are so many projects and just when you think you've learned them all, you discover one more. And you're like, oh, that's weird. I didn't know that that existed. So one of the things that we really tried to design onboarding week for is to allow people to explore the technical side of the system at any pace that they want and to any abstraction level that they want. So if you're learning about Bosch and you realize, whoa, like I'm really interested in the Bosch agent. I really want to learn how to build my own stem cells. You can do that during onboarding week if you really want to. I actually have never heard anyone say that. But it's a hypothetical example. Maybe honest. So the final goal that we have is to try to cultivate psychological safety as early as possible. I'm really glad that I've seen a few other talks at this summit so far that have talked about psychological safety. Just a real quick definition, psychological safety is the belief that you will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes. And that's from Amy Edmondson. So we value psychological safety. We happen to think that this is an incredibly important part of building product teams that can respond to changes in the world and build better products that ultimately better serve the end users. So we try to build psychological safety into onboarding week. We have conversations about this and we have feedback mechanisms that we use to constantly try to improve. All right, so what actually happens during onboarding week? So during onboarding week, we usually assign one to two facilitators who work with our onboardees. So we have onboardees that come from different teams, different disciplines. So for us, we've had people from product manager, from design and even some doc writers. So although our onboarding material is very focused on the engineering aspect of things, we found that we've gotten a lot of very valuable feedback from having these other teams, other people from different disciplines work on this onboarding week process as well. So we found that we've gotten feedback on usability and sort of interesting discussions between the onboardees that kind of talk about like, hey, how does this actually all work? And it forces them to sort of explore and elaborate on things. So something else that we also do is we have a space allocated specifically for our onboardees. So they're usually seated very close to each other so and they're like workstations are set up for pair programming. So this allows them to sort of just turn around and be like, hey, I'm stuck on this part. Did you get through this? How can you help me with this? So it lets them sort of build this fellowship with each other so that they can have someone that they can grow with while they're at the company. So what do they work on? So each pair is given a task, like a list of tasks that they can do throughout this week. There's no strict order in it. And it's opened up for you to pick anything that you want. So if you find something that's beneficial or that you find interesting, like go for it. You don't want to CF push an app, that's okay. And you want to dive right into creating your Bosch release. That's all right too. There's a track for that. So within each of these tasks, there's usually a big description about what it is and how you can accomplish it. There's also a lot of links that provide further readings. So if you want to dive deeper, go for it. It's all up to you. This onboarding week is about you learning and exploring Cloud Foundry. So throughout the week, one of the regular process that we do at Pivotal is having daily stand-ups. So this is a place where you can share context on what you've learned. Ask for help whenever you're stuck. And it allows you to, again, have this feedback that you can constantly have with the rest of the teams or the members that you're working with. And something else that happens throughout the week, our onboarding week, is whiteboarding. So whiteboarding and tech talks happen usually either throughout the week or sometimes it'll even happen sporadically throughout the year. So this usually goes over the CF architecture at a really high level, talking about the different components and how they interact with each other. So sometimes you'll have teams even talk about their projects, and this gives insight to new onboardees about, hey, what's going on in the office? Is there something that I'm very interested in and I should explore and go talk to these people about? So something else that we also do is at the end of each week, we have retrospectives. So how many of you actually do retrospectives each week? Most of you? Okay, so for those of you who don't know, so retrospective is a time for you to reflect on what went well, not so well, or just okay about the week. And this lets you sort of talk to each other and express how you were feeling. And this helps us provide feedback on both your experience and what we can improve for the next onboardees that comes along. So I'm gonna just jump a little bit into sort of the tools that we use. So we use Pivotal Tracker for our backlog management and stuff like that. And we use Git and GitHub for version control and Slack for our messaging. So let's just skip over to our GitHub. So on GitHub, we actually use this to keep track of our onboarding material as well. So we use a tool to export our markdown snippets into our actual backlog and then we load this into our task management system. This has a few benefits. So it provides us with faster feedback loop. So if something's going wrong or anyone can just open an issue, actually submit a PR to fix it. It also supports organized discussions. So people can talk about things in the GitHub issues and this lets people across the different time zones because we have offices in multiple places to sort of have these issues just easily accessible by other people. And another thing is really easy to find because all our work is already on GitHub. It's really one click away. So this allows us to essentially continuously improve and deliver on our onboarding experience. So essentially we have applied CICD to our onboarding process. If you're interested in looking at our repo, all our material are open source at Pivotal slash CF onboarding. So here's just a screenshot of it. Cool, so aside from learning extremely important things during onboarding week such as how do all my app logs get aggregated into one place, we think that another really valuable outcome of onboarding week is for participants to pick up some familiarity with not just how we work but why we've chosen to work that way because culture and processes are things that are constantly evolving and growing. And if you're not getting feedback from people who are seeing it for the first time, you're seriously missing out on an opportunity to improve. Before I get into this section, I just wanna say that your company's rituals and values might be different and that's totally okay. The reason why we wanna mention this is because your onboarding week is going to set the tone for your engineering culture. So it's really important to think about what kind of culture you wanna build, what kind of message you wanna send and figure out ways to design that into your onboarding week. So one thing that we think, we spent a lot of time thinking about is empathy and user-centric design. So we think that we always try to design both open source and closed source products with a strong focus on the user. We encourage people to get out of the office for engineers to join customer calls. So we think that having onboarding week run on a monthly cadence does two really important things. The first is for the people who go through onboarding week, that's basically the end user experience, right? They are application developers and platform operators for that one week. When you go back into R&D and you're building like the logger gate or Bosch release or whatever, you're a little bit further from that experience. So going through it yourself is really, really important. But the second thing is, for people who have been in R&D for a little bit longer, maybe for the folks who are facilitating onboarding week, watching new users go through cloud foundry is also so valuable because you almost never get the opportunity to observe a new user. If you take onboarding seriously, that is the new user experience every single month. And that's such a valuable learning opportunity. The second thing is that we really value pairing and collaboration by default. So some of you may know that Pivotal does pair programming by default. We have a lot of things that, a lot of processes that are designed to put a lot of people in the same room together. We try to build this value into our onboarding process as well. So we encourage onboarding to come from different disciplines and different experiences. We also spend a lot of time trying to build a healthy feedback culture. Building feedback into your culture is really, really hard. The framework that we like to use is that feedback should be timely, it should be actionable, it should be specific, and it should be kind or the task model. We think by building feedback early and often into our processes, we're more likely to encourage individuals to speak up when they see something wrong or when they see that something could be improved, not necessarily wrong. If you don't have a feedback culture, you're missing out on learning opportunities. So what have we learned over the past three years? So we learned that generally onboarding is actually better in pairs, it's better together than alone. So sometimes in an office, you'll only have one person who joins in a given month. We've actually seen that it's better to have that person wait until the next month when another person joins so that they can do the process together. Onboarding on your own is kind of lonely, but moreover, it doesn't give you the opportunity to learn and to push yourself and to have conversations. We think that's a really important part of reinforcing the learning process. We also, Andrew touched on this a bit, we also really think that even if your engineering process is designed for engineering, you should still have an open door policy for people who don't have software engineer in their job title. We've had some really valuable conversations about the value of our existing processes by letting people who are docs writers or designers or product managers or program managers or anything in between take part in this process. I think a common default that a lot of people fall into is, well, this is like a new process, like there's a lot of responsibility, maybe only senior devs should facilitate onboarding week. We disagree with that. We think that once you've been through onboarding yourself and been in R&D for a little while, you're probably capable of facilitating and we think that the facilitation role should be open and people who are junior developers or mid-level developers should be encouraged to do it because it's a great leadership opportunity. And finally, like anything else we do, we're very product oriented about everything that we do. So we, Andrew talked a little bit about CICD for your onboarding. Another way to also think about it is you should treat your onboarding process like it's a product where your end users are your new joiners, but maybe your end users are also ultimately cloud foundry end users. So by always having the mindset of do an experiment, evaluate how well that experiment went and then learn from it, we think this is generally a healthy feedback loop to apply to any process experiment and onboarding should be no different. So a quick thank you to Mark and Lyle and Claudia and of course all of our colleagues in the Toronto office, many of which are here, for listening to this talk and giving us feedback. I saw a lot of you taking pictures of slides, so if you want high resolution versions of these slides, they're gonna be at that link and I'll also tweet out a deck on the conference hashtag, whatever, later. So if you have any questions, Andrew and I are gonna be off to the side of the stage for a few minutes, so feel free to come up and ask us anything. There's also a big blob of pivots here who can also answer questions about how we do onboarding. So that's it. Thank you so much for coming. Thank you.