Really enjoyed talking today at @CTOCraft#CTOCraftCon today about fostering a culture of progression within your team.
This is a summary and some follow up links :)
Whilst expectations around progression are important, so is creating an environment where it can actually *happen*. In fact, a culture where progression is not only possible, but it's the default.
First, though, why should progression and retention matter to an engineering leader? For me, I have three motivations: intuition, responsibilities and data.
Want to learn more about being an engineering manager? Join my mailing list to learn more from engineering leaders.
It's logical to understand that hiring is hard and if you're losing people, you'll spend more time on it and not on other things.
Retention is critical to team performance: teams build psychological safety over time and frequent churn stops this.
Next motivation: two responsibilities.
Responsibility 1: I believe that as engineering leaders we have a moral responsibility to build a diverse workforce through an inclusive environment. Yes, this brings business upsides too.
If your retention is poor because your growth opportunities are missing, you will necessarily build a less diverse team as people leave. You see this with organisations that run large grad schemes - a diverse intake doesn't correspond to diverse leadership.
Responsibility 2: We live in precarious times. I sleep at night knowing I've tried to enable growth for my team members, so that if the worst happens, everybody leaves more qualified and more employable than when they joined.
And final motivation, let's get into the data!
We talk a lot about Maslow's Hierarchy of Needs. That's fine - it's a useful model.
Once needs like shelter and belonging are met, it teaches us that self-actualisation... being the best you can be, is what keeps people satisfied. By why he means... growth.
There are, however, additional surveys and datasets available. Here are a few I found.
Gallup has been surveying US employees since the 1990s, asking them their Q12 questions which cover how well their needs are met - basic needs, individual needs, teamwork needs and growth needs.
It turns out that companies that score higher on this (in the top 20%) have 59% better retention than those in the bottom 20%.
If you enable a culture of progression within your company, your people will stay longer and will get better at their jobs. It's win win.
Source: State of the American Workplace (Gallup, 2017).
Now I'm motivated, the question I ask myself is: am I creating an environment in which learning *can* actually happen, not just the expectation that it will happen?
For an engineering leader, my list is: remove obstacles, teamwork, transparency, delegation and support.
What about formal progression frameworks? They're great but they might not need to be your starting point.
A development plan can jar against reality in a culture where progression isn’t supported.
That’s why I talk about the culture of progression - the opportunities to learn - as a precursor for the learning plans.
So here are some ways to get going.
First... remove obstacles: How can you have an authentic conversation about growth when even getting the day-to-day stuff done is hard?
If you've got broken process and broken IT, expecting growth to happen can look delusional.
Next: teamwork. A team can provide the primary locus of learning through a supportive, teaching environment. Get this right and growth can follow.
Working transparently is important, too. One thing I love about the technology industry and the practices of teamwork and agile is that there’s no slight-of-hand to it: we show how we’re doing things and by teaching through our daily actions we make knowledge accessible.
It’s much more possible to work with a stakeholder, to run a retrospective, to do a story kickoff when you’ve been part of those processes many times before.
Delegation: giving folks the opportunity to try things, with the safety net they need in case things goes wrong, is important.
Don't forget the feedback when things don't go perfectly. If they went perfectly first time, you probably should have delegated sooner.
And lastly, be *intentional* in your support. Show up for development plans and ambitions - give feedback on what's working, check in on how people are feeling about their plans.
You don't need to drive, but you need to make your interest and support very, very clear.
And when it comes to building out your progression framework, you should check out @sallylait's latest blog post:
One of my favourite stories about product / engineering / scaling / really knowing your customer:
📈 I worked on an e-commerce project which had been very successful and started handling a lot of volume, straight away.
This was before virtualisation and elastic scaling, so the servers we had were the servers we had. Keeping the site running in busy times was hard.
An odd behaviour started: the site would crash on the hour, every hour. To the minute.
🤯 We couldn't figure out why.
There was no rush of traffic to the site, but the servers got crazy busy and started falling over. We were baffled. What's more, it wasn't consistent - sometimes it was in the evening, sometimes in the day.