(upbeat music) - Thanks John, and thanks to the Web Directions team, for having me, today. I's like to begin, by acknowledging the traditional owners of the land on which we meet, today, the Wurundjeri people of the Kulin nation, and pay my respects to elders, past, present and emerging. I acknowledge that sovereignty was never seated and declare my support of the Uluru Statement from the Heart So, as John mentioned, I'm Cath.
This is my best friend, Tinkerbell.
She looks very miserable, there.
I think, it was quite a hot day, unfortunately. I'm the People Operations Manager at Buildkite. We don't build kites.
(laughing) We develop CICD tools for engineering teams, which is probably more useful to a lot of you, and, as John mentioned, when I'm not in the office, I'm completing my bachelors at Macquarie University, or travelling.
So, what is mythical about senior engineers? I know you exist, I've met you, I've hired you, I've been mentored by a lot of you, and, I no way mean to imply that you don't exist, but what I want to talk about, and draw our attention to, is this myth that senior engineers can, magically, come into an organisation and hit the ground, running, or, get in and get stuff done, or, ship features from day one. So, these expectations are made, based on a lot of assumptions about the knowledge that a senior engineer has, and what they need, when they're contributing to your organisation. So, let's unpack some of these assumptions. Oh, no.
(chuckling) (laughing) So, you're assuming that your senior engineer knows what the organisational goals are, that they understand the terminology, that the organisation uses, they understand how the organisation communicates, who they need to communicate to, how to do that communication.
There's a lot of assumptions, already, and we haven't even gotten to the technical assumptions. So, what happens when you make these assumptions? And a side note, I asked my CTO to do these beautiful illustrations, at about 8:00 p.m., last night, and I'm very grateful to Keith, for helping me out with those (chuckling) So, what happens when you make these assumptions, and you don't address them? So, you're actually increasing the stress and anxiety in your organisation, can lead to workplace conflict, higher employee turnover, less engaged staff and engineers, and this is actually decreasing your productivity, and that'll lead to burnout and fatigue.
These assumptions are also cumulative.
So, when I talk about accumulation of these assumptions, I'm saying that the more times, that you hire, and you're not mitigating these assumptions, they're getting worse and worse.
So, a common on-boarding strategy that I have seen and heard about, is trial by fire, and I don't know if anyone, here, has experienced that.
I've, definitely, went through it, as a more junior engineer.
It's sort of, where you turn up on your first day and you're expected, to just, kind of, figure every thing out for yourself, and be productive straight away, and everyone's kind of doing their thing, and you're like, ooh, I don't know what to do, but I'm not sure if I should ask, or if the expectation is that I should just know, why don't I just know, oh my god (laughing) what's going on? So, it makes you feel really isolated.
There's a lot of pressure and it creates a lot of unnecessarily doubt and anxiety.
So, how do you take all of this required organisational knowledge, and empower your senior engineers to be successful and productive? So, what I'm going to talk to you, today, in the context of senior engineers, is, employee socialisation, and that's not having a games console in the office, or a ping-pong table, table tennis.
It's not team paintballing events and it's not trust falls. Employee socialisation is a research-proven method, for taking someone from outside of an organisation, or group, and helping them to understand the group dynamics, expectations and, most importantly, how they can contribute to the group, as an individual. So, what's the point of employee socialisation? It helps mitigate all of these assumptions, that I mentioned earlier, about organisational knowledge, and this, in turn, reduces the anxiety across the organisation, facilitates organisational communication and networking, and it allows your senior engineers to contribute more meaningfully, sooner.
So, when do you begin organisational socialisation with new employees? I used to think that it was, when you first came into the office, and, if you've never thought about it, it's actually already happening, and it's not on that first day.
It's actually happening during your recruitment process, or, the pre-arrival stage. This is when your potential new senior engineers start to learn about the people in your organisation, how you communicate and your values.
If you want to limit the amount of anxiety that occurs on the first day, you can.
You could be more deliberate with the way that you're hiring and your final stages of recruiting. Structuring your interviews to reflect the working conditions in your organisation, and start to embed these processes earlier, will facilitate a smoother transition onto your team. A great example, that I've seen of this, is Automattic. They built WordPress.
So, what they're doing with their perspective candidates, is, in the final stages for a coding challenge or test, they actually spread it out over about six weeks, so it does make their process quite long, and they ask candidates to complete some paid work with them, and it could just be a couple of hours a week, but you're a actually embedded in a team, and you're learning how they work, how they work, remotely. So, it gives the candidate an opportunity to see if they are fit, as well as some, Automattic, to see if the candidate's a potential fit for them, and there's a match, there.
Preparing for transition can really help, as well. One thing that I wasn't prepared for, when I started at Buildkite, was the culture shock. I started with them about a year ago.
'Twas my first role in People Operations, coming from more of an engineering background, and I worked in a lot of startups before, but there was just so much autonomy at Buildkite, and I was, like, oh, I'm just going to get coffee, I'm going to be away from the computer for a minute, and I kept getting messages like, you don't need to tell us everything, all the time, it's okay.
So, it's some really interesting things that we've learned. And so, what kind of culture are your senior engineers coming from? Are they transitioning from a corporate structure, or a large organisation, or government? And what kind of roles are they coming from? Are they coming from, maybe, a CTO in a really small organisation, back into an engineering function? Is it their first senior engineering role? All of these things, you can start to communicate with, before their first day. So, how much direction they expect, the level autonomy or scope, and the impact that they can expect to have in your organisation. So, when we hired our first senior engineers, for a while, last year, we didn't manage this transition period well enough. We had engineers who've been embedded in companies for quite a while.
They had a lot of domain-specific knowledge, and they came into our organisation, and they didn't have any of that domain-specific knowledge, they didn't have any of those networks, and that was quite a shock for them.
So, we were currently working on communication strategies, to mitigate this. The next stage, I wanna talk to you about, is the Encounter Stage, and I'm gonna talk about some concepts of organisational socialisation, that I've used, and that I've seen used, and that will assist your senior engineers in making meaningful contributions to your team, sooner. These are mentoring, communications strategies and technical on-boarding.
So, one of the things that we've started to do, is, we hire in cohorts.
These are great, because we can batch tasks together, around hiring and on-boarding. I really carve out time for it, and, well, that's kind of selfish, it makes a lot easier for me. (chuckling) But, with our new hires coming in, it's really great for them, as well.
They get to network with other people in the organisation, from day one, but, being a fully-distributed team can be slightly challenging, sometimes, and they get to share the experience of starting a new role with someone else, and, just makes it a little less isolating, as well. Our largest cohort, so far, has just been two people, but we've benefited a lot from our engineering team, being able to make more time for the cohort, and our new senior engineer's been able to share, what they've learned with each other, as well, and feed that back into our process.
Our next cohort, we plan on bringing on, later this year. We're going to go crazy.
We're going to go up to three people. (laughing) And we're gonna have entirely different functions, as well, so, that'll be interesting.
Google also uses this method, as well, and there's some really interesting research around, what's come out of that, that I will share, when I share my slides, later.
Mentoring is also another research-proven way to socialise senior engineers, and reduces time to meaningful collaborations. It's also especially helpful, if you have a lack of documentation for your on-boarding process. However, it can be very labour intensive, especially if you have a cohort, like we do, and we also use mentoring, as well, at Buildkite. So, how can you improve informal mentorships? You can empower mentors.
The smallest amount of guidance and training can help, so we've just started out with a checklist of tasks that need to be complete and we give timeframes for some of those tasks, as well. We also share mentorship responsibilities.
So, each new hire will have two mentors, one for the organisation and one for the specific function, that they're in. One of the things, that I can't emphasise enough, is to value the process of mentoring.
Make it a promotable task, don't make it office housework. This will encourage people to engage more in your organisation.
And make sure that you set the expectations realistically, for what you're mentors are expected to achieve, during these periods.
Communication.
Communication is really hard.
How does your organisation communicate? Is it formal, or informal? Flows from your culture and values, often.
What channels do you use, Slack, Basecamp, HipChat? I think, that's still a thing, right, HipChat? No, it's not a thing? Okay, sorry.
GitHub, Trello, email, what are the expectations around communication? What communication is privileged, what's shared with a whole organisation, who do you need to communicate with? So, if you empower your senior engineers with this knowledge, it's going to help them facilitate their work and contribute, meaningfully, to your organisational, sooner again.
Authenticity is another point, I really like to stress around communication. Initial socialisation focused on personal identity, led to greater customer satisfaction and employee retention after six months than socialisation that focused on organisational identity.
So, authenticity improves productivity.
This is, because people are driven to be authentic, to want to be authentic.
When you allow people to be authentic, and include them, just for being themselves, you're actually reducing psychological exhaustion, and that's derived from inauthentic behaviours. Embracing difference helps foster belonging, which leads to higher self-esteem, and greater productivity. Technical on-boarding, something that I have thought about many times, and still don't have a perfect solution for. What I can say, is important that you allow time thread and that you value it, that you build your technical on-boarding process, so that your senior engineers can contribute back to it, as they're on-board, as well, and this helps, keep it up to date, and that helps keep your engineers engaged, while they're learning about your organisation. Pick out easy wins, or low-hanging fruit, as the way that you senior engineers can start getting comfortable with your code base, and it's important to note, that research has shown that there's a direct correlation between how long it will take to on-board engineers and the age of your application.
So, the last time we hired a cohort of senior engineers, what we did first, was, we put them on support, and we don't have a dedicated support function, so, the majority of our team, actually, do support rotations, and I thought, ah, support, this is gonna be a really great way to get everyone exited and engaged with the customers and learn about the product, and that wasn't the feedback that I received from our senior (chuckling) engineers, unfortunately. The feedback that we got, was actually that they found it quite difficult, and they didn't really feel that they were kind of contributing, in the way that they initially wanted to.
So, we're now moving towards more discreet and well-defined pieces of work, that come out of support requests, or bug fixes, to existing features.
The final stage, is Metamorphosis.
So, your senior engineer will have a personal identity in your organisation, your senior engineer will know how to contribute within your organisation, and your senior engineer will know how to contribute to your organisational goals. So, what are some of the takeaways, I can give you, today? Employee socialisation starts during the recruitment process Mentoring, or buddy programmes in cohorts are research-proven methods for enhancing your senior engineers' capacity to contribute. Communication is key, and not just with new employees, but with the existing team, as well.
And allow for early and well-defined technical contributions and build up to larger pieces of work over time. Spread on-boarding out over weeks, and don't try to cram it in, all at once, it's too overwhelming.
Thanks.
(audience applauding) (upbeat music)
