Sourcegraph Podcast

Conversations, stories, and insights from dev tool creators

Developer onboarding with Ryan Djurovich, DevOps Manager, Xero

Ryan Djurovich, Beyang Liu

We're kicking off a new season of the Sourcegraph podcast with a three-part series discussing how engineering leaders onboard new teammates.

First up is a guest from season one, Ryan Djurovich, DevOps Manager at Xero, one of the largest accounting software companies in the world. He talks about how to strike the right balance between autonomy and consistency, the importance of tools in the process, and how to foster a high-trust environment.

Show Notes

Ryan Djurovich:



Team Typologies book:

Accelerate book:

Ruby on Rails:




Beyang Liu: So I'm here with Ryan Djurovich, who is a DevOps manager at Xero, and we're talking with engineering leaders about how they do technical onboarding, and this is a big, hairy topic. So, I wanted to start out with kind of a very concrete question, which is if I'm a new software engineer or DevOps engineer onboarding into your team, what is that like from my perspective?

Ryan Djurovich: Yeah, so thanks for having me. In terms of at the company, we have a really fantastic people team who's continuously improving our onboarding experience, but in terms of specifics for engineers on the more technical side of onboarding, there's a lot more autonomy in terms of making sure that experience is optimized for the specific systems that each team is working on. So, depending on which team you're joining, obviously the technical onboarding is going to differ. For example, on my team, we have a pretty broad set of things that we work across with our internal customers, and we have some internal tools as well. So, one of the things that we've found works really well is making improvements to our internal Slack bot as a first project.

Beyang Liu: Cool. So your team, would you say that you're in kind of an internal facing team, so your main customers are other engineering teams at Xero, is that right?

Ryan Djurovich: Yeah, so if you've, I'm not sure if you've read the book Team Typologies, but it talks about the concept of an enabling team, or enablement team. So that's how we see ourselves is really to work with other teams to get uplift in engineering practices, to help employees improve deployment frequency, and kind of the four key metrics that I guess the accelerate book references. So yeah, that's kind of the approach of our team is really to work with those internal engineering teams.

Beyang Liu: So this Slack bot, does it just become this magnet for people's first contributions? If you look at all the features it has, can you point to members of your team and say like, "That was so-and-so's first feature push"?

Ryan Djurovich: We don't kind of mandate it as being the first thing. We definitely want to cater to each individual as we onboard them, but just has worked out such that in recent times, the last three or four people we've onboarded have decided that, "Hey, this feature, yeah, I can see the utility of it. That'd be really cool thing to work on." And it's not a huge amount of work, but it's a really good way to kind of dip your toes in, and get a feel for how all the tooling, CI/CD, and everything works. And yeah, I think it's one of those things, it's like a badge of honor in a sense with the team, like, "Ah, yeah," someone just added a help feature, because we got to a point where there was so many bits and pieces to it, that someone just wanted to query and say, "Hey, how does this command work?" or whatnot.

Beyang Liu: I love that kind of immediate focus on shipping something. I guess one question I have there is, how do you determine what issues are appropriate for someone to work on as their first project?

Ryan Djurovich: Yeah, so I guess that comes to down to more of a product management perspective, or even though it's an internal tool, a Slack bot, I still try to apply that philosophy. And the good thing there is that because it's an internal tool that our team uses, our team is the customer. So, when you're onboarding someone, it's a good way to establish that rapport in the team and to talk directly with the customer of the Slack bot and say, "Hey, this feature that we wanted to implement, how would this work for you?" So, it's kind of a combination of things, it's not just the technical side with the onboarding. It's really nice to see how that kind of builds that team up, and builds the rapport.

Beyang Liu: Got it. And how much, for lack of a better term, handholding, is there on that first issue? On the one end of the spectrum, it could be like very, "Hey, I'm going to walk you through every step of this process, and be in the room when you meet with your users," etc, etc. And on the other end, I could see sink or swim: here's the objective, go figure out how to do it. Where do you fall along that spectrum?

Ryan Djurovich: I would say that we are trying to cater for the individual. So, we want to make sure that people are supported, but we don't want to prescribe how much hand holding might go on, to use that phrase. So, yeah, I think the funny thing is, and this isn't just specific to the Slack bot, right? But onboarding in general. I think COVID really forced remote work, threw a spanner in the works for this stuff. So, I think my team actually came out stronger on this particular front, and as a company we got feedback that everyone's more productive in kind of the new era of remote work, and we're being very flexible in terms of working arrangements. I mean it was before, but now even more so, because we've seen that increase in productivity. But in terms of how it's affected this, you think you're new in a company and you're in the office, you would just kind of rely on shoulder taps, and those encounters in the office, maybe you go into the kitchen and you just grab someone quickly and ask them a question.

Ryan Djurovich: But now we really need to make a habit of scheduling time with our new hires. So, as a manager, there's a regular sync, as an engineer on the team, we kind of buddy people up and make sure that they have regular times in the calendar. And some of those times we set an expectation that, "Hey, we're going to meet every time." But other times we set an expectation that, "Hey, this is actually us making our time available to you, but you choose if you want to have this or not." And some people have opted for a lot of sessions, and come with a list of questions, and that's the way they prefer to learn. Other people, they find information kind of asynchronously through Slack or Confluence or whatnot. And then they find that they have less of those meetings, but that model has been working really well.

Ryan Djurovich: And I've personally really enjoyed it as a means for getting to know my new hires better. And when you can't go to a nice Melbourne cafe or something like that, like we used to, doing a bit of a Google Meet in the mornings is a great way to chat over a coffee or whatnot.

Beyang Liu: So, you kind of have these scheduled meetings with new hires that I guess it's up to their discretion, but by default, they're on. But, depending on whether they feel like those are necessary, they can opt out of those as they see fit. Is that kind of the idea?

Ryan Djurovich: Yeah, exactly. And I think that that really just caters for the individual, and makes sure that they feel supported, but they're not like, "Oh yeah, I have to go and meet with the boss. I don't know what I'm going to chat about." If it gets to that situation where they don't actually have anything to chat about, that's fine. We'll just skip that and see how we go tomorrow.

Beyang Liu: Yeah, that makes sense. Apart from the kind of one-on-one face time, are there other onboarding specific, or maybe just general resources that you invest in that people end up leaning on during onboarding? And I'm thinking documentation or tutorials or other tools that kind of help someone spin up on a codebase.

Ryan Djurovich: I guess just talking on tools, certainly early on in the process getting access to the various tools and platforms at the company, that's a thing, but thankfully our IT team's done a pretty great job in making sure the access to tools that are appropriate to your role are kind of pre-provisioned when you join. Things like SSO directory servers, zero trust security. I think that's really improved the way that people get access to the tools, because we're using cloud-based tools, it's easier to work remotely. It's easier to work with teams in different time zones, and you get that kind of access pretty early on, but then there's things in terms of the developer experience, that I think getting people to work on code earlier, really helps with. So things like GitHub, CI/CD, AWS, shipping a change to production, kind of exposes you to that full set of tools and even everything, Jira or Confluence or whatnot, it's just that full kind of stack.

Ryan Djurovich: So that kind of approach, we have a pretty robust onboarding guide in my team that walks you through that process. And, here's the tool that we use for this, links you to a repository for say the Slack bot and says, "Here, check out the previous PRs, you can kind of trace the flow from development through to production". And yeah, I think that that's kind of, you explore that journey and you get exposed to the docs, you get exposed to the tools through that journey.

Beyang Liu: Yeah, that makes a ton of sense. But that first issue by the way, I think is really important because it kind of drives focus in the process. So when we were emailing earlier back and forth, we were talking about the different stages of onboarding, and you'd mentioned that there's kind of the immediate issue of setting up your dev environment and going through the cycle of shipping something at first, but then there's kind of this later stage, which is acquiring a high-level understanding of the codebase, and the technical architecture and all that extra context that makes you really powerful. I would say we don't really have a good solution to ensure that people get that understanding. It's mostly just osmosis and hope a bit. Do you have thoughts on that second stage?

Ryan Djurovich: Yeah, for sure. Like contributing to that codebase in that first stage, doesn't cater for the complexity of the system that you're working on, right? It's just really the tooling aspect getting a PR up. But that second part that you're talking about, if there is a very complex system that you're expecting someone to work on, how do you get them across that architecture? How do they understand that the way the code is structured? And I think that's probably one of the things that Ruby on Rails, and those kinds of frameworks reduce the cognitive load of, because you had these conventions in place and people could jump into these types of systems quickly. But when you're talking about kind of lower level things in Go or Rust or whatnot, it's a much more varied code structure. And then in terms of architecture, yeah, I think this is kind of a poorly solved problem in the industry, because the thing that people tend to lean on is documentation, which often becomes stale quite fast. And that's where things that I've seen recently, tools like the code tool plugin for VS Code.

Beyang Liu: Yeah, that's awesome.

Ryan Djurovich: Yeah, it's such a great way to kind of annotate the code. I mean, I haven't seen how it plays out over a long period of time, the initial kind of demos of it and trials of it look good, but how is that going to age over time? I'm not really across that, I'm keen to see how that goes. And the other thing is to give Sourcegraph a bit of a plug, when I last used it in the setting of onboarding, I think that that was really helpful, because you can, particularly with those very complex, cross-team systems where maybe you have a shared code library and you are exploring a codebase, and then you need to jump to some other repository that you might not have cloned locally.

Ryan Djurovich: You can kind of jump across the code throughout the company very quickly, and drill down and use those things, it made sense if you cloned everything locally and you wanted to go to a function definition, but when it's a huge company and tons of different repositories, it gets much harder. So, I think that that's really good for getting across the codebase quickly.

Beyang Liu: Yeah, well, thank you for that plug. I appreciate it. I think there's kind of an element of onboarding that maybe bleeds or blends into just overall developer experience. Because I think a lot of what you do as a developer is you have your kind of initial onboarding when you first joined the team. But then after that, let's say you hop into another part of the codebase or you're asked to work on a feature that touches a substantially different part of code than what you're familiar with. It's kind of this continual onboarding to new parts of the code and acquisition of context over time, I guess.

Ryan Djurovich: Yeah. I think most people look at onboarding in the same way we kind of look at education where it's like, you go to school, you graduate and you're done with learning, but the reality is you should never be done with learning. And in the same way, when it comes to onboarding onto code bases and infrastructure and that kind of thing, you should never be done with learning there because those systems aren't in a consistent state or hopefully aren't in a consistent state, they're evolving over time as the business evolves and being across those changes. I mean, sometimes it's once you hit a certain scale, it doesn't even make sense to try and keep up with the change as well. You want to have a high level idea of what's changing, but the expectation that you're going to be across everything is just not a tractable problem for an individual to solve.

Ryan Djurovich: So, I think having those tools and methods of finding the information you need as you need it, is a good thing. It's a good skill to develop, it's a good tool belt to develop. So not just for onboarding, but also for your time at a company and people at larger companies tend to move around after a bit of time to get exposure to different things. And so you find when you shift into a new team, it's like, "Okay, there's a whole set of different services here that I'm going to be across. Now. I need to apply those methods and use those tools to get across those quickly". And yeah, it's interesting, I think once you've been at a company a while, when you do make a shift into a new team, because you have that familiarity with what tools you're using, how things tend to be set up, what the conventions are for that company, it becomes easier to onboard on to other teams because you don't have that initial hurdle to get over of adjusting to the new environment, new tools, new conventions.

Beyang Liu: Yeah, there's kind of this like common knowledge base that firms up over time. And then the thing that you layer on top is the more team specific, or maybe project specific knowledge. So you touched upon earlier about how things are often fluid and evolve very quickly, especially inside fast moving software organizations. I think that presents a challenge for good onboarding or for good developer education in general, because it's like, "How do you design a curriculum for something that hasn't solidified yet"? You can do the general development environment, that's probably not going to change drastically, but then for the newer parts of the code base, is it worth investing in any sort of process there at all? Or is it just a skill that people have to acquire over time? Just get good at figuring out stuff yourself.

Ryan Djurovich: I mean, that's definitely a good skill to have, but that level of detail tends not to be the point of friction with onboarding that I've seen. It's more things like understanding the tech stack. Particularly for onboarding, a lot of people join a company and they've got experience using a set of tools. They want to understand how that maps onto the tools that our company are using. So just having a good understanding of the tech stack, and it might not just be for the tools that are being used currently, but it's also, if I need to make a decision, say I'm implementing some new thing and I need SMTP, how am I going to send email? What platform are we using for sending email? And having that awareness of what the tools are, or where to find the information about what the preferences are for the company.

Ryan Djurovich: And obviously the larger a company gets, the more important this becomes, because when a lot of startups, what you find I think is when you join a company, that's made a quick transition from a scrappy startup into a bigger company, you tend to find this a very large number of tools. And then a company tends to go through that stage of, "Okay, how do we consolidate all of these different tools? Because this is not going to scale. This is not efficient". And they ended up going through that consolidation phase. But at the start, it's a bit of a scatter of all these different things, because there might not be that guidance. There might not be that structure in place to say, "Hey, we want to use this". And kind of, that's probably a good thing actually, from an innovation perspective, you want people to be able to just solve the problem in front of them, not get bogged down in process or anything and try out different things to see what's going to work well, and what's going to work the best.

Ryan Djurovich: But yeah, that's part of the onboarding education challenge, I think is just making sure that there's that clarity. And I think that's something that I think Xero does particularly well is we have like an internal tech radar that identifies the technologies and even that itself, and that format is evolving over time, which is really, really exciting to see. It's a really solid piece of guidance from the company, which helps engineers make decisions.

Beyang Liu: That's awesome. Is that something just tracks every new technology or framework or thing that gets adopted inside the company?

Ryan Djurovich: Yeah, I mean there's a bit to this, but yes, essentially. Yes. I guess the thing that I think is quite interesting with, on this kind of related note, is understanding the distribution of tools, languages, frameworks, that kind of thing. Large companies have thousands of repositories and it's, at multiple companies I've worked at now, you're talking about thousands of repositories, right? And they're all in different states of the life cycle. Some of these things get marked as deprecated or retired, and some of them kind of per service repositories, some might be small mono repos. You can have kind of a state where you have multiple mono repos and have multiple monolists as a company. Some things are shared libraries, this and that. And then they could all be using different languages, different frameworks. And a thing that we have that's really cool is an internal service catalog, and I'd actually built or prototype, I would say a similar tool at Cloudflare and companies have talked about this kind of Spotify open source their backstage tool, which is And that's a service catalog as well.

Ryan Djurovich: And the idea is kind of capturing that service ownership. But once you catalog all of your different components, that provides a means to start to analyze what languages is, what framework are we using, what dependencies get pulled in, who owns this, where are the relevant links to docs? And things like that. But then you can start to do analysis on that data as well, and understand the distribution of things, which is really cool when you get to that scale and being able to use that to inform decisions about particular technologies, and then provide guidance based on that. So, going back to that earlier question about helping to inform the engineers when they're picking up something and want to run with it, if they can see that like, "Hey, this is the technology that 80% of our systems are using". They can have that confidence that is going to be a large kind of amount of expertise at the company to provide support if you get into a bit of a pickle with that technology, or just want to ask them questions.

Beyang Liu: That sounds awesome. Before I let you go here, if I could ask you for a moment, if you could take us back in time to before you were a dev ops manager and engineering leader, back in your early days of your career, when you were a junior, a software engineer or whatever, and you're diving into your first or second large code base. Do you have any like challenges, pains, or, or I guess war stories that you remember from that era of your life that have kind of informed your view on these things? Pains that you felt, that you would like to help others avoid?

Ryan Djurovich: Yeah, that's a big question. Lots of things that are popping into my mind, but I would say the feeling that I remember when working with a big group of people and kind of doing a pull request to assist them, that a lot of people were going to look at, there's a bit of intimidation I think. I don't know if it's imposter syndrome, but you feel like you're being judged at a scale that you hadn't been judged before, right? And you're kind of working with a large number of people. And maybe that was just the particular culture of the place that I was at the time. I certainly hope that today that when I have a more junior engineer join my teams, that they're not feeling this, you certainly want them to feel welcome and to have that safety for them to put up a PR and feel that it's only going to be a positive kind of learning experience.

Ryan Djurovich: There's not going to be any of that. But certainly I remember those first few PRs that I put up as a junior and people came in pretty heavy with the comments and it was quite intimidating at the time. But once I kind of understood the approach people using the conventions, I think that intimidation wore off and I felt more capable of putting together a PR that first time, every time was unlikely to attract such comments.

Beyang Liu: Yeah, I think there's an element of feeling intimidated and a little bit of feeling frustrated too, at least for me making the jump from school where it was mostly individual projects or very small teams where you knew the other people very well, to working now with a lot of people that you've only known briefly in a professional context, and in something like code review, before you actually working in the professional world, code review, if you do it at all is just like walking your friend through this change that you just made, and then you're done. Whereas going into an organization for the first time, there's all these conventions and standards and a substantive context about the architecture and how this fits with other pieces of the code and all that, that you just have no idea about until you've kind of attempted to submit your first PR and then gotten all those comments from people who are like, "Well, have you thought about this? Have you thought about that?"

Ryan Djurovich: Yeah, that's a really interesting observation the kind of shift from people that you're friends with, to this professional setting. And I think that that kind of highlights the importance of building trust in teams. If you have a high trust environment, and you create a safe space for people, it means that going through that process of creating a PR, your first contributions, you should feel much more comfortable in doing that and removing that kind of intimidation factor, and making it a more friendly environment. So it's not like you're going from friends at school to all these strangers in the workplace, but it's a team that you feel there's a level of trust there that you can go and do something, and you're not going to get in trouble for what you did or whatnot.

Ryan Djurovich: And certainly, yeah, that's something I always am trying to think about, how do we make sure we have high trust environments? How do we make sure we have that safety, make sure people have a really positive onboarding experience and that the experience in general, that stands true for everything, right? Not just juniors, but you want that environment for everybody. Especially if I decide the slack bot needs a new feature and maybe I just want to write a bit of code on the weekends and yeah, I don't want my PRs to get too much negative feedback, which yeah. I'm yet to see, which is great.

Beyang Liu: For sure. That's definitely a danger when one switches from IC to manager track, after being out of the code for a while, you go back in and you realize just how much additional context you have to be mindful of when writing that feature.

Ryan Djurovich: Yeah, a hundred percent.

Beyang Liu: Cool. Well, thanks so much for taking the time to chat today, Ryan, and for sharing your experiences with onboarding and how you think about onboarding at Xero.

Ryan Djurovich: Yeah, thanks for having me.

Want to dive deeper into better onboarding practices? Read about how to prevent codebase overwhelm and more onboarding advice from engineering leaders.