Onboarding

In this episode, hosts Peter Maddison and David Sharrock delve into onboarding in organizations. They explore the challenges and best practices of integrating new team members, discussing everything from formal training methods to hands-on learning approaches. The conversation covers the importance of providing context, the value of apprenticeship-style learning, and the role of DevOps practices in facilitating smooth onboarding processes.

This week´s takeaways:

• Provide comprehensive organizational context to new hires
• Implement apprenticeship-style, hands-on learning
• Create easily digestible, on-demand learning content
• Develop robust DevOps practices for early engagement
• Balance formal training with informal learning opportunities
• Regularly validate learning progress and understanding
• Tailor onboarding approaches to different roles and experience levels

Don't miss this episode if you're looking to enhance your organization's onboarding processes and create a more agile and efficient workplace environment.

Chapters

• 0:04 Onboarding Challenges in Agile Organizations
• 7:19 Effective Onboarding Strategies for New Hires
• 17:52 Feedback Mechanisms in DevOps Pipeline

Transcript

Peter: 0:04

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello Dave, how are you doing?

Dave: 0:14

Peter, good to see you again. It feels like it's been a while, but you're looking well.

Peter: 0:21

Yeah, we're getting there. We're getting there. It's like it's getting a little chillier outside. So we have a couple of interesting topics that we came up with, and we're going to go through the first one of the ones that we thought would be interesting to our listeners about onboarding. So this is an interesting topic. So do you want to kick us off?

Dave: 0:42

Well, yes, let me kick things off, and I think this is an interesting one in the sense that we're always just having that chat about what are we experiencing at the moment? Are there things, common themes coming up, and I think both of us are working with organizations that are onboarding new people.

Dave: 0:58

Every organization always has turnover, even if they're not necessarily expanding. There's always that question of how do you onboard somebody, and where I was struck with it is we've got a sprint planning going on and they're trying to figure out at what point that individual is going to become a contributor to the work in the sprint and how do you accommodate that with the planning. And then, as you start exploring that, you suddenly find out or at least I was finding out that onboarding is. You need to read all of this documentation about what our technology stack looks like, and here's our technology guidelines, and here's this and here's that.

Dave: 1:37

And all of this, I would argue, stale and no longer relevant to the real world environment that they're going to be working in. Information is all of a sudden brought up, and onboarding means spend a number of days familiarizing yourself with our systems, with our approach, with our ways of working, whatever it is, and then we'll get you going and that that rarely works the way we think it's going to.

Peter: 2:05

Yeah, there's a couple of pieces there. So, from the way you're describing that too, it's on the person to go and do this work and there isn't necessarily the follow-up to validate that they have. They're just expected to go browse some videos, look through some Confluence sites and see what you can learn, and whereas there isn't the deliberateness that and if you actually want to compare companies, where they've got the culture is a bit more deliberate you would expect to see some of that onboarding. I know from an organization I worked at in the past.

Peter: 2:38

There was pretty much two days of mandatory in-session classes that you had to sit in and you got to. If you didn't get through them, your manager was coming to you and say, hey, you've still got these hour-long sessions that you have to go to and do, and it was very deliberate and it covered all different aspects of the business how the business operated, how the business made money, what all of that looked like. There was a little bit of a section on technology which covered just that, glossing over of what they needed to know and how to interact things or how to raise a service test ticket, and then typically that would be the usual sort of compliance type yes, please don't send our information to the competitors. Type introductions.

Dave: 3:21

Yeah, and I think what I'm hearing you say there, peter, is there's sort of two bits of information. One is and let's tackle this one right away which is that compliance side of and we can talk a bit more about compliance as we go through this, but the tick the box checklist approach you have learned about.

Dave: 3:39

X, learned about Y, learned about Z, whatever these key compliance issues are, so that I believe, quite frankly, the company can say we've done our due diligence and these people have seen information about these different aspects that we care about and I think there's there's a lot more that we could explore around that as well, because we also anybody who's been through that knows that's a sort of a feels so much like a checkbox ticking exercise rather than a how do I rethink how I interact or work piece.

Dave: 4:10

So that's the one side on compliance, but the other one is context that you're describing, which is how do I help people understand the business we're in, how we operate, how we differentiate? And I think that one actually works quite well. I mean it would be nice to talk to somebody, but actually a couple of days going through those basics. So we all have in the organization having a firm understanding of what these things mean like how the business operates.

Peter: 4:51

it's incredibly valuable. I mean, it helps you understand, like, what is important, what isn't important. It's just really sort of foundational to understanding what the organization does and how to tie that to the work. But one of the key pieces that wasn't in there, that I see as missing as well from some of the other organizations when we're talking to them, is there's very little about the actual ways of working and especially when we start to think about things like sort of agile practices and look at how we interact, how do we do things like estimation, prioritization, how are we expecting to work together? How do we sort of operate that part of it? That wasn't really a part of any of that sort of training. It was expected to happen as a part of interacting with the other members of the teams.

Dave: 5:49

Yeah Well, I look at this one as so. At Increment One we do a lot of training, facilitation and training, so we have this sort of deep appreciation of what training means, and I feel that in many organizations there's this misunderstanding that training is a video, powerpoint deck, a bunch of information. I have the information you don't. Let me tell you this information and convert it from being over here to being over there.

Dave: 6:17

And what you're describing now in things like what is our culture? How do we operate around estimation, what is good enough, planning and what's not good enough planning, what does a commitment look like? And you could actually extend that to what are our technology practices, development practices, what do we expect of one another as teammates? What does working remotely mean? All of these things are you can put a PowerPoint together, but we don't hear it. We, quite frankly, see a bunch of bullets in our head, we recognize the words and then we move on because it's not something that it doesn't kind of connect. So the other aspect of this is what's often referred to as apprenticeship style of training. That is where you've got that general base of knowledge. But now the fastest way we as human beings are going to learn is let me follow you around and mirror that you know and learn from what you do, versus what is written down, and I have to somehow convert into what I do.

Peter: 7:19

Yeah, and I think that piece is important, but it's got to be deliberate, right. It's like if we don't have something that says, okay, this is how you're going to partner up with somebody to do this, is what's expected of it and this is how we're going to check in that it's actually happening, you actually you need to make sure that, if you're going to use this as a model of doing that communication, that it's actually happening. The other piece that I always found interesting in that was it was encouraged that you go and sit with like a call center agent or somebody who was dealing directly with the customers. But it's encouraged, it's not mandatory.

Peter: 7:55

I always felt like the value of that is tremendous, like going and sitting and hearing how do the customers interact with the company, what does that look like? That's so, so valuable that having new people be able to go through that is going to give them such a greater appreciation for what the organization does. I mean, these are the kind of things that really do help, even where there are. So we've been talking a lot about that kind of deliberate piece, right, and all the things we need to do to make sure they happen. There can be follow-on pieces that you do, but it's good to make sure that those pieces aren't delivered as like. Here's a two-hour video to watch.

Dave: 8:40

Or at least not without understanding why. Because if I turn around and say here's a two hour video, this is the 30,000 view of how the organization has got to where it is and how we get to the market, and here's an hour on what your department is, how they fit into the engine of growth that we have, now I'm plugged in and I'm actually maybe going to get off my phone and listen to it.

Peter: 9:03

Yes, yeah, so yeah. Putting the why in there is going to help with that. Making sure that this there's some value essentially, is what we're looking for. It's like what's? I'm going to exchange two hours of my life to watch that video. What am I getting in return?

Dave: 9:17

Well, and if I come back to that apprenticeship piece, one of the things I find interesting working with delivery teams software delivery teams is there seems to be this idea that onboarding is an activity that somebody's going to go away and do when they come in. Now they can start working on the team and it's some sort of a step function. Now they can get up and going and yet we also know now they're just going to be the most clueless person on the team. So in that know now they're just going to be the most clueless person on the team.

Peter: 9:45

So in that step function.

Dave: 9:46

They're now going to ask dark questions, like every time. I try and check new code and it seems to be rejecting it. What am I missing?

Peter: 9:52

And all of the other things.

Dave: 9:54

There's loads of implicit, informal ways of working that have to be picked up, and the best example I've ever seen of a new person coming onto a team was a contractor some years ago who obviously they had seniority, they had experience so they could come in. They're not a junior member joining their team at the beginning of their career progression. They've done this a few times, but they happened to join the day of the sprint planning, so they came in we just asked them to observe.

Dave: 10:24

We didn't expect anything of them, because they literally got their machine up and running within 24 hours, something like that.

Dave: 10:31

And this individual went up to the storyboard and picked out a story, up to the backlog, picked out a story and said am I understanding this correctly? This is whatever it is, it's a some change. Did I understand what you probably need to do here correctly? If I did, when they got the nod, they then said right, I'm going to take this in. I'm going to need help because I have no idea what your systems look like and where it goes, but I kind of get what this is about. And so they took that on, they brought it into the backlog and immediately laid out the expectation that they're not doing it on their own, which is what we want. We want people swarming around stories. So it's not anything that was unusual. It's just they were very direct and clear about what it was. So they did that.

Dave: 11:12

With a couple of the stories that got pulled in, they would take another one, or the team would take one, and they would say let me lead that so that you can show me how to get through it. So they're not like piggybacking and observing. This comes back to pair programming, right? They're not the ones who are observing, they're the ones who are saying look, I'm going to put my hands on the keyboard. I'm going to try and make this change happen. I need somebody to say, yeah, that's not the way we work here, or let me show you where that library is or how we do this, and all of a sudden you've got this rapid acceleration and adoption of practices Within the second sprint. You can imagine they're already pretty self-sufficient by the third sprint. They were rocking and rolling, basically.

Peter: 11:58

Yeah, I think that's a great example. It's that ability to come in, make sure they're immediately involved in the process, similar to your. Can you commit code to production on day one? Yeah, in very advanced situations or if you have to have very solid pipelines you can trust and rely on, and make it a very small change. Yes.

Dave: 12:23

But I mean, there was this sort of I have no idea if it's rumors or true, because it never happened to me, but I'd certainly heard there are a number of companies that say, hey, you've got eight hours, you've got to commit something by the end of day one. I think that's a brilliant idea for a couple of reasons. One is you need your systems to be robust, and how many organizations really have that?

Peter: 12:44

how many?

Dave: 12:45

organizations could really say look you can, you know, pull in some code, make some changes, hit submit and you'll get feedback. We'll find out what happens.

Peter: 12:54

We'll find out what happens, yes and uh. So yeah, from a from a devops perspective, I'm always looking at that going yep, as long as you put the right, all of the right pieces into place, there's no reason you can't do. As long as you put all of the right pieces into place, there's no reason you can't do that. But you've got to have the right pieces in place to make that possible. And if you do, that's phenomenal, because that means you've built a level of trust in your pipeline's delivery, the way that things are built out, the architecture of the underlying systems all of that is true, so that you can feel comfortable that when I hit go this, if this is good, it's going to go.

Dave: 13:28

Yeah, yeah, yeah, I couldn't agree more, and I think so. I'm just looking. I think we've kind of covered quite an interesting spread of things and and I I wanted to pull one more piece in which I was realizing, as you were talking about those two hour videos and that that there's, there's the formal think of that. Maybe in my head at least, I'm thinking of that as this formal educational step that is needed as part of onboarding. I think many organizations now try and create these snippets of information that are available, and all I can think of there is this is so.

Dave: 14:03

Here's where my generational thing comes in. What I see with my kids is they learn through YouTube, and YouTube is exactly that snippets of information. I can't go to my kids and say you need to look at these videos. They learn because they're curious, because they have a need right now to learn about a particular thing, and YouTube has this way of providing short videos that focus on a very tiny thing and give you that little snippet of information. I think there's something that, as organizations, we can really take away and give you that little snippet of information. I think there's something that, as organizations, we can really take away and learn from that.

Peter: 14:41

Yeah, and I mean an example of that is. So LinkedIn learning, for example, breaks up the courses into like three to five minute chunks, and so you, if you have a an hour long course, it'll be in three to five minute chunks. You can just dive in and watch the little bit of the video and move on to the next bit. So I, having recorded a LinkedIn learning video which is on value stream management, if anyone wants to go watch it, and it sort of gives you a good overview of the whole value stream management space, it is a much more consumable. It does make it much easier to just like listen to this and to like take these little chunks. So I mean I'd encourage that too. If you're looking at how do I sort of create on-demand consumable content for people who are onboarding into my organization, do it in small pieces, do it in little bits that they can consume, and so they're not sort of trapped into having to find the bit that they need in a much larger body of content.

Dave: 15:40

Well, and also now I can say look, you're just new on the team, but here's a small change that we want to do. We're making, whatever it is, A defect, pretty straightforward change. You've got to find a way of pushing it all the way through our pipeline. Here's the information Pick. What you need Now I've got a problem. It's right in front of me. It's pretty clear To your point that you've stressed this several times as we've talked about this is how do you validate that those steps are being followed? Well, in many ways we can validate it, because that defect, that small change, gets published. And now I don't have to sit down and say which videos did you go and see watch? I can just say, okay, you know how to get a small change live.

Peter: 16:23

Yeah, very much so. So I think we've covered a lot of great topics here. How would you sum all of this up into three points for our listeners? So?

Dave: 16:31

yeah, we've some really interesting topics. A couple of things Onboarding is not.

Peter: 16:37

let's try and not say what it isn't but maybe I'll try and define what I think we came to terms being a really good way of onboarding, so number one is providing context like that you mentioned a few hours video or a few days worth of understand what it is we do, why we do it so well and so on.

Dave: 16:54

So that context is critical. Number two recognize that probably the day-to-day work is much more of an so on. So that context is critical. Number two recognize that probably the day-to-day work is much more of an apprenticeship model. So meet them where they're at, small bits of information, get them involved, solving problems as fast as possible with support, so that you can see that tracking through. So first, one context possibly you know one-on-ones or videos or whatever the pros or group you know, introductions. Secondly is more like piecemeal, small short video support get small problems that people can follow through so they begin learning by doing as they're going through. And actually the final thing I talk about is the feedback. So we and I think we're talking about a couple of ways One is feedback is are you making progress? Because we can we all know that within 10 days.

Dave: 17:42

We've forgotten what happened 10 days ago because in most organizations there's a tsunami of stuff. So are we validating that they've got the foundations that they need as they're onboarding? Number one and number two is the feedback mechanisms in your DevOps pipeline. Those provide feedback. They're designed for safety, for robustness to changes, to allow people who maybe don't know their way around and would normally be overly cautious to take risks and get useful feedback.

Peter: 18:13

Yeah, I think that's a really good point. That last one like starting to think about the criticality of having that automation built into the delivery system so that it can give that feedback and understand and using it that way, which is, I think, very valuable. Well, thank you for the conversation, as always, dave, and I look forward to next time. Don't forget to hit subscribe to all our listeners and we'll talk soon. Thanks again. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.