Finding it hard to build and retain a high performing tech team?

So Ki-ora Ko Gretchen toku ingoa, which is Maori for, hi, my name's Gretchen.

It's pretty simple.

So I'm really excited to be here and talk about career growth frameworks, what they mean and why, and how we should use them.

But firstly, I'd like to acknowledge the Gadigal People, the traditional owners of the land on which we're meeting and pay our respects to their elders, past and present.

So I come from New Zealand, clearly.

I've got a funny accent.

I say stuff weird.

We've got a saying there.

It's not very popular at all, but I quite like it.

Ka mua, ka muri.

So it means that we walk backwards into the future.

So the past, the present, and the future are all woven together.

As we look to the future and how technology shapes it, which it does, right?

'Cause technology is the infrastructure of our entire existence right now.

I think we should reflect on learnings from the past, particularly those of indigenous people.

So we're all here, we're all leaders in tech, right?

It's such a hard space.

I'm a big fan of running away and hiding in the technical stuff because it's what I know and in many ways it's easier.

BUt the more of a leader you become, the more you start dealing with people and they're hard man, like they're seriously complex.

You write some code and few nudges, a bit of Stack Overflow and hopefully you can get some kind of expected outcome.

Not the same with people.

So more and more of your job starts being around motivating and engaging the people working with you.

Actually, if we go a bit further on that, a huge challenge right now is about staff retention.

My whole proposal here is that career growth frameworks are a really good place to start for this.

So this is our journey.

We're gonna start at the end.

I'm going to assume that every single person here wants a high performing and diverse technical team.

If you don't, that's cool . Just have a look now, right?

No stress from me.

To do this, you've gotta get your hiring practices right, so you need to be able to attract the right people.

Really good quality people that want to come and work for you, but more than that, they have to be the right person to fit into your organization with the skills you're looking for.

You also need some kind of career growth plans, right?

People need to know how to advance in their career, what's expected of them, and what opportunities are available.

And promotions need to be applied in a really, what's the word?

I'm thinking transparent way.

People need to know what it is to set them up for success.

None of that kind of, 'Hey Craig, look, you're good.

But just don't really have what it takes'.

Things need to be explicit.

Now, underpinning all of those three things, the good career framework just sets the skeleton and you can work off it and make progress easier.

So why use a framework?

I was gonna swear there for a moment.

The, the employment market for technologists is a wild ride at the moment.

Six months ago you couldn't hire an engineer for love nor money.

Or actually if you had a whole, whole whole heap of money, you could . It's changed a little bit.

There's mass layoffs and things are chaotic and moving, but at the same time, have you tried to hire an engineer lately?

It's still really hard.

So there's this kind of disconnect between stories from America or scales up here and actual on the ground, getting an engineer vibes.

And the people that are moving, some of them are just really burnt out and jaded from the last few years, so they're really cautious about where they're going.

So I'm hoping that this means smaller organizations get a chance to fill some of their skill gaps 'cause they've been smashed in the last couple of years.

They haven't been able to pay those exorbitant salaries that I think we would deserve . But whatever way you look at this, hiring and retaining engineers is a key part of our job.

The current cost of recruiting a dev in Australia is estimated to be about $200k.

I don't know, my budgets don't really allow for a whole heap of that coming and going.

So that factors in the cost of your HR people lack of productivity, and then how much time it takes to get them up to speed.

And then there's another risk factor involved here, right?

What if they break your culture or what if you made a mistake?

Lot of what ifs.

Given that technology is a key, key function of every business now, right, like Coles has a huge tech team, and I think CBA is the biggest employer of technologists in Australia.

Having the right staff and retaining them is a key business imperative.

There's research that says 52% of people are not happy with their job.

That's freaking miserable, right?

There's like half the world of going to work and hate it, or maybe don't hate it, but they're not happy with it.

76% of people want some kind of career progression that they can work towards or move towards or have some kind of goal, right?

And if you look at millennials, that stack goes up to about 87%.

So growth plans help with this.

And our friends over at Culture amp, yay to the back table, and the badges, I I got got by Culture Amp, They've done a whole heap of research in this space.

And what it comes down to is that if your staff are engaged and believe, hang on, I said that wrong.

If your staff believe they've got a career growth plan opportunity available to them, and they believe in the people delivering it to them and that it will be followed through, they're 46% more engaged.

Now, people don't have a lot of discretionary effort to go around at the moment, but engaging your people means they might spend some of it with you.

But growth plans are really hard to write.

They take time.

They take thought, and they can be a bit tedious to be fair.

I wanna put to you that if there's a career framework underpinning your organization and your software teams, they're really easy.

People can write their own and then you just have to follow through with it.

I'm gonna also be a little bit opinionated because that's, that's one of my core skills in the world.

I think career frameworks should be tech specific.

Like it's super great if your HR team has here's a framework, has growth plans and this is what we're all doing 'cause we're all the same, and tech isn't special.

I mean it's a good place to start, but actually tech is a bit special, right?

Like it's nuanced, it's complicated.

And the same skills you reward a marketing team for, I don't know how that translates over to tech, right?

Like where does it sit?

We need to be more specific with what we are looking for.

So given that HR people are pretty awesome.

And they love creating frameworks and growth plans and all these things.

We need to take them on this journey with us.

And I've found a good way to get them to do a tech specific framework is by saying, 'Hey, we know you don't love this tech staff, and it's a bit finicky, we can help you with that and make it happen'.

People tend to lean towards what they're good at, right?

And if your HR team's not full of technologists-we use a lot of lingo and rubbish and chaos, and it's just messy.

So take it off their plate and help them out.

And if someone wants to take all the marketing off my plate in my life, I would love for that to happen.

So at its core, a career growth framework is just a skills-based assessment piece.

It empowers managers to make data driven decisions.

It gives them a greater understanding of their team, the skills within their team, and also the gaps within their team that sometimes we need to fill.

And more than that, it empowers engineers to have meaningful career conversations with their leaders.

And understand what they can work on in the future.

I have a side quest time.

Leadership is freaking hard.

Honestly.

Take me back to writing code.

IC is easy and a kind of safe space, right?

You're all here because you're leaders.

You might be an excellent experienced manager, but odds are, you're employing people who might've just come into the role in the last six to 12 months.

They don't have the skills you've got.

And statistically in Australia, I think they'll get their first leadership training in about 12 years.

Bit of a pro tip at the bottom, send them to leadership training.

It's really important.

Imagine just coming into your role as an engineering leader and someone comes up and says, 'Hey Steve, I wanna be a senior'.

I'm like, do you?

You really need to empower your managers to be able to have conversations back.

If you had a framework underpinning this, your new leader might be able to go, 'that's really cool.

But what we wanna work on is your communication skills and how much scope of influence you have within the organization'.

You're empowering your leaders to be good leaders if you have a framework.

I still struggle massively with giving career guidance to people.

Which is kind of funny 'cause a woman who code heaps of people come and say, 'what should I do?' I'm like, 'I dunno.

I really dunno.

Good luck.

Good luck out there'.

So engineers are often promoted into leadership roles, and expected to build their people skills just magically on the side.

Unless you've got a really good mentor, like we heard about earlier, it's hard and it often takes time.

If you're unsure how to review performance, create development plans for direct reports, or assess people on their skills for promotion, it's stressful and you're expected as a new leader to do all this and learn all this often without support, while still running your technical direction and the technical vibes for your team.

There's a lot going on there.

Second little side quest I wanna talk about is DEI.

Given that I'm running Women who Code Melbourne, it's like a passion piece of mine.

I used to teach Web development for years and spent huge amount of time focused on getting underrepresented people into the organization.

And I will say, I keep talking about women.

I'd like to acknowledge that it's far broader than that, but we just don't have any data sets to talk about.

So when I default to, 'Hey, women' for stats, more, and I'm trying to collect more data and bullying others into doing it, and there's some great work happening in this space, but what I learned over the years is that there are countless programs to get women into tech.

And not a lot to keep them there.

And at the moment, women leave tech at twice the rate of men in Australia or 1.8 times, and they often get promoted two to three years slower.

Which is odd, right?

Because they're coming out of their education pieces as equals with the same skills, the same qualifications, and the same abilities.

And yet, somewhere along the line we mess it up.

Now the reason people give women give for leaving the industry, there's four main reason.

One is lack of flexibility and I'm gonna mention the C word here.

Covid has helped with that, a whole heap, right.

Now you can work from home, flexible hours, so thank you Covid for speeding us up on that piece.

Another reason is unequal pay.

I was talking to someone at very well known tech company in Melbourne about three weeks ago.

She's a mid-level dev and a solid one.

She found out she was getting paid $200 a year more than a junior, and when she asked about it, they said 'you're not meant to discuss pay'.

She did what you promptly do and started interviewing elsewhere and she's now moved over to Atlassian and is very happy.

Third and fourth reasons are around skills and assessments.

So because they're promoted slower, women tend to leave, they get bored, and the easiest way to get a promotion is to change organizations.

The other reason, and this is the one that I find really, really jarring, is perceived incompetence.

Talks to some of the reviews that say Women's code is rejected more often than men, but only if they know it's written by a woman.

If it's ambiguous and no one knows all good, that's accepted at slightly higher rates . So here we are.

DEI is a huge, huge thing.

The C-suite is starting to push for it, right?

There's metrics in place and there's over 10 years of research that shows quite resoundingly that diverse teams perform better in terms of innovation and actually profitability for organizations.

So having everyone assessed and promoted according to a skills assessment that is specifically designed for software engineers and is comprehensive enough to just get the subjectivity and the bias out of the place allows people in marginalized groups to be given the same opportunities as others.

And also it's way more fun to work in a team that has people different to you.

I get really bored by me.

I spend a whole heap of time here.

I wanna hang out with others.

So we've talked about why we need a career growth framework, but I haven't said what it is.

At its core it's just a comprehensive skills assessment tool.

It's just a list of things you should do at each level.

Super simple, right?

It's a roadmap.

It's how everyone, managers and employees alike know what's going on.

But frameworks are only successful if they underpin all the processes in your organization from interviews through to reviews, through to growth and promotion.

What this means is that we can gather all the info, from the skills assessment and that drives what goals individuals are given for growth.

And the actions that are undertaken that they then undertake are contributions that are meaningful to the organization and contributions that we'll promote them for.

It's a win-win, right?

Like you're just supersizing your teams.

So a really good framework should include a whole, whole, whole heap of detail, like to the point where it's really boring, and what this does is gets rid of any scope for kind of vague interpretations of chaos, and it also makes it really clear to individual contributors what the scope of their role is and what they need to do to get to the next level.

I'm really passionate about this one.

Glue skills should be included in every framework, right?

Teams don't just exist with a whole heap of individuals doing whatever they're doing.

You need to value the skills that build people together explicitly.

Part of my passion around this is that it tends to be done by underrepresented people and then not rewarded.

So focus on this one.

Delivery and execution skills are super important.

So these are the skills around how your team tracks and practices for continuous improvement.

Inclusive practices.

Now I look at that, the wording's quite vague.

What I mean here is ways of working that create belonging.

So it's generally around explicit communication techniques like peer programming or clean code so people know what the heck's going on.

There's definitely some risk factors with implementing these babies.

You can break your own culture or you can expand on your own culture, own culture that was really, really rubbish in the first place.

You just didn't realize it.

Another big risk is poor implementation.

So what I mean by that is, let's say you decide to build it in house.

You sit down with your leadership team, you smash out all these ideas, you think you've nailed it.

but if you haven't asked anyone that's not in your in crowd, you've just thrown them out the door.

They will never show up in your sphere again.

You're ignoring them.

And then what typically happens is there's no implementation rollout.

There's no plan, there's no change management.

People throw spreadsheets at each other.

Everyone goes 'Cool story' ahh, a spreadsheet.

And one of the other other things I've seen happen is extreme uniqueness.

So often we believe that our culture is like, 'we're special, right?' I used to when I was at uni run weddings like six figure wedding receptions.

Everyone believed that their wedding was this fabulous, new, unique thing, right?

And they paid me a lot of money for them.

But really it was the same thing.

It had the same recipe, it was the same format, just with little different lace stuff around the outside.

I reckon some of your engineering teams might be the same.

But it's worth recognizing again here if you think you're unique, you're unique and valuable to your in-group, but what that translates to to the out-group is just vagueness.

And it's really helpful if the leveling and contribution expectations in your organization are clear and super obvious and in line with the greater industry, right?

Because if you want someone new to come on board and hit the ground running, you don't want them to spend three months trying to figure out what their role actually is.

So you got a few options, if you wanna implement a framework.

You could do nothing.

And you know what?

That might rarely be the best idea for you.

If you're gonna do something disastrous.

But I wouldn't recommend it.

You could build one in-house.

I've seen a couple of organizations do this in Melbourne recently, and so far they've both spent around 80K in terms of labor and they're about halfway to building it.

I'm, I'm really intrigued to see if there's any implement implementation happening.

I reckon if it was me on the ground and I had unlimited budget, I would go with a bespoke consultancy who could come in, love us to oblivion, talk to all the right people, build the thing and run an implementation program, but we can't afford it.

I don't see many that can at the moment.

You can grab one off the internet, right?

The big kids have all got them.

They'll publish them, they're out there, but then you're gonna have to pop them on a spreadsheet and they'll go die in spreadsheet dying places.

You could though.

Number five, I quite like it, right?

You could take that spreadsheet and you could hang around with, I think Latice gives you a whole heap of things you can build out on.

But again, there's an implementation piece around that.

But there are some off-the-shelf products on the internet.

Go have a look and do the engineering stuff you wanna do.

So I've been chalking a whole heap here, right?

The labor market is wild.

You don't know if you're coming or going, but regardless, hiring engineers, retaining them and getting them to be high performing is a really critical business aspect.

People are tired as well right now.

You need to love them a little bit more.

I think we all need a bit more love and diverse teams are really important.

I covered off that quite a bit and I get a bit too ranty.

I'll leave that one be.

If you haven't implemented a framework in your organization before, I really think you should, but do it cautious, cautiously, and in a considered manner.

I guess at the core, I'd like you all to head away today.

Not yet, 'cause we've got parties and things happening.

But have a think about career development and what that means and maybe mess it up a little.

At the moment we tend to do.

Hey, here's a kind of, here's your job every six months, if you're lucky, maybe every 12 months we'll catch up for this really discreet thing that happens.

We'll talk some trash.

You'll say You did some good things.

I'll say, I don't remember you doing them.

You won't get promoted.

I might give you a pay rise and we'll move on.

That's how we jam.

It's rubbish.

So I'd like us to do this ever-present thing where career conversations happen all the time.

It's just part of your existence in an organization, and I think that if we do that, It would encourage more action because we are people and little bite size pieces of information and action points are easier to implement.

It'll make your organizations have a bit more agility because you know you can move a bit faster and things change a lot.

It would establish a bit more connection between you and your staff, 'cause just having those conversations with people as if they're actual humans is really, really important.

But it also builds trust because when you do that other kind of career performance review piece, I alluded to that's just a manager rotely going through a process and people see through that rubbish really fast.

It doesn't feel meaningful.

So ka mua, ka muri, as we move to the future and start having some great technical teams building amazing products, the kind of designing the world we live in, let's learn some of the lessons from the past.

The past from our teams.

The past from those around us and the past from traditional people.

Thank you.