Joining us on episode 53 of Talent & Growth was Samantha Mountford, CTO at Feast IT. In this episode we discuss what a safe engineering culture is, how we can make our culture safe and still drive high performance and how companies go wrong when building an engineering culture.
We’ve taken some of the key points for creating a safe engineering culture and outlined them for you below, we hope they help!
Let’s define what we actually mean by a safe engineering culture.
It’s an environment where developers feel like they have the space to plan and deliver their work, but they also have the space to grow and develop. They need to be able to do that without feeling like they’re under pressure to deliver deadlines that they didn’t agree to and be able to move quickly without being put in a position where they can make a major error.
The feeling of anxiety is one that I know well from my years as a developer. I was full of questions and concerns. Can I ship this code now? If I don’t work late to get this feature delivered my project manager is going to get it in the neck from a client. I’ve got five tickets to deliver but I wasn’t to spend some time learning and I’ve been asked to take on more duties. No one seemed to understand that all of that was too much for me and the quality of my code will suffer which means that it will take longer to code review, longer to QA and I’d feel the weight of that all.
I want to avoid these scenarios for my team as much as possible. That’s not to say there isn’t a desire to get a lot done quickly, but the solution isn’t to work people to burn out. I’ve seen a lot of burnout in people I’ve worked with so anything we can do to stop that is really important.
How do we enable this safe engineering culture in a start-up, which typically involves the cliché of long hours, intense pressure and working non-stop?
I try to make it really clear that a start-up culture is one of pace and ownership- not presentism, long hours and unrealistic deadlines. In terms of ownership, we make sure that everyone has the capacity to affect positive change, then they can own and optimise their processes to get work done quickly and safely. Keeping pace involves setting a target or deadline and being committed to hitting that. We want to give people the confidence to set ambitious targets, feel like they have control over the way they work and they have access to data to help them make informed decisions. They also need to know that they have the support of the wider team to be able to deliver in the timeline they’ve set.
How do we make sure that the culture is safe whilst still driving that high performance?
You need a strong and short feedback loop, allowing developers to voice their concerns and opinions often and making changes quickly based on that feedback. One to ones are a great place to gather this feedback, as well as team retros where you can agree to try something new quickly.
You also need to have a blameless culture. It’s rarely one person’s fault so we should instead approach an investigation to see what could have been done differently as a team. For example, are there alerts that should be set up to notify the team and if not why not? Or is there a manual process that should be been automated? AWS had a major outage of one of their storage solutions, due to a single developer following a manual playbook and making an error on a command that they ran. They should have never been put into a position where one line of code written in the wrong way could cause that much damage (loss of customer data).
The great thing that AWS did was acknowledge that they needed to improve the process and did it quickly, therefore protecting their developers in the future. There are lots of questions employers can ask themselves. Did we require that code have test coverage in the code review process? Did the developer that run the code review process actually have the space and capacity to do that thoroughly at the time? Are you giving developers the ability to monitor their code and production to know when things go wrong? Do you have the appropriate level of logging? There are many steps that would protect a developer from feeling like one of the many thousands of lines of code that they write might cause a major issue.
As well as a blameless culture and tight feedback looks, we’re also shifting to using cross functional product teams to deliver value. The smaller, more focused teams are able to optimise their process much faster and find a way which works for them.
Listen to the full podcast here.
On Talent & Growth we speak to talent leaders about the challenges they face and their solutions for attraction and retention. If you’re interested in hearing about how companies are building a more diverse talent pool, how you can attract top people from the big players, ways to create a more inclusive interview process or learn about the latest and greatest automation software to make your life easier, then this is the podcast for you.
