In previous blog posts, Michael Gray outlined his thoughts on teams, structures, and ways of working. Taking his posts as a jump off point and building on those points I wanted to focus on good team practices, the evolution of DevOps, and the need for a supportive engineering culture.

Before diving into those points, I think it’s important to set out some core principles.

I believe engineering teams need to make time and space for important non-coding activities like documentation, training, retros and continuous improvement. Furthermore, building a good engineering culture is about paying attention to the little things that make a big difference, like automation, testing and fixing technical debt.

It’s also important to say that there’s no one right way to achieve these goals.

Often in the push to get stuff out of the door, we forget to look at the wider picture.

Software development is knowledge work, and in many respects, we know that writing the actual code is not the hardest part. If you can solve a problem with less code, that's good because the more lines of code you have, the more complicated it is to support. We want to solve problems with the least code that we can.

Sidenote: the use of AI in the process is going to be interesting because the way the industry is currently looking at AI and software development seems to be about writing more code more quickly. And I don't think that's where the problem is or where the benefits are.

The problem with churning things out is that we then don’t make time or space for the other things that we need to do, like documentation. I know it's almost a joke that engineers don't like to write it. But we need it. It's important. Especially when we are working remotely or working across distributed teams and across time zones. You need people to be able to self-serve information.

It is vital when you get a new engineer into your team because you want them to be able to be productive as quickly as possible. When there is no documentation and you have to ask someone every time you don’t know something, it’s frustrating for everybody and interrupts people’s flow.

With anything that’s not actual coding, there’s always a temptation to say ‘we’ll come back to that’ but we don't because we have the next feature to get out the door. It’s important to find the time for team retros and take time together to reflect, to learn, to take that step back and say, "how can we do this better?"

People also need personal time, space and opportunity to just be curious and to learn. If you don't give people that space, they don't have that continuous improvement time. I’m a huge fan of weekly tech talks that get teams away from code and provide the space to learn. You help teams to make new connections, you create new ideas, and you create bonds between people across teams, and across the wider organisation.

But this is all stuff that doesn't have an immediate return on investment. It's slower and it's less visible, but it's massively important that you make space and time for these things to happen.

Those little things make a big difference, making and defending the time and space to slow down to ultimately speed up.

As an industry, we’ve become more data-led in recent years, and that’s a good thing. However, we have a particular focus on quantitative metrics where there is pressure to show hard data and numbers. That quantitative data is vital. But so too is qualitative data, telling stories and people's lived experience of creating and supporting software. There's an awful lot more to doing that than the picture told by the DORA metrics, which is why I like how the SPACE framework and the DevEx framework are advocating for using both quantitative and qualitative metrics.

You could have amazing DORA metrics, you could be doing 1,000 releases a day for example, but what value are you giving to your customers? And what experience did your engineers have while producing those amazing DORA metrics? They could be burnt out, they could be totally miserable, they could be looking for new jobs every night on LinkedIn. That quality of experience is important as well as the hard quantitative data that you get from the DORA metrics.

In the push for hard data on everything, we run the risk of missing other things that matter too. We then run the risk becoming a feature factory where there is no nuance when software development and engineering is really an art more than a science.

So how do we balance doing great work that delivers value, while also making it better for the people delivering it? For me, those ideals are embodied in the ideas and practices of DevOps. Seemingly small changes in the way we deliver software, such as continuous integration and continuous deployment can have a massive impact. These practices made a lot of sense to me because not only is it good for the business, but obviously you want to be able to release frequently and get more value out more quickly, and you don't have to do releases out of hours and the weekends.

Crucially, it’s also good for the people doing it because no one wants to be doing releases at the weekend and in the evenings. I've been there and done it and it's horrible. And big scary releases where you're releasing six months’ worth of work, when you've got this massive deployment plan written down on paper: do this step, do this step, do this step. But you've got no rollback plan, and you've got no way to test it, and you've just got to keep going and fix the problems as they happen. That's no fun, that's no good for anybody.

So, the idea of DevOps where we can automate and do smaller releases as frequently as we like and get faster feedback, that's better for everybody. It's a win-win.

I see the same with the platform engineering side. When new tech such as Docker containerisation came along, it felt like more and more stuff was becoming the responsibility of developers. When I was developing and I worked with ops engineers, I concentrated on writing applications. I didn't have to worry about provisioning the infrastructure for it to live on, or about networking beyond a base understanding. But over time, it felt that more and more aspects were becoming the responsibility of developers, and that massively increased the cognitive load placed upon them.

Instead of shifting left, I like the concept of ‘abstracting down’. This idea that it becomes a platform so that the software engineers, the developers solving the business problems can just self-serve the resources that their applications need. That to me is about making it better for people if in a slightly abstract way. It's miserable when you've got to try and think about everything and do everything and be responsible for everything and it's overwhelming.

Burnout is a real problem in engineering and developer roles. To some degree, I believe that is a byproduct of being overly focused on always trying to get new features out of the door as fast as we can.

That’s why it's incumbent on engineering leaders to be the voice of their teams to other parts of the business and make the case for how to do software well. You can’t just constantly churn things out, software development is knowledge work that is more of an art than a science.

Every problem is different every time you come to write it. We have patterns, architectural patterns and software patterns for example. But you're applying them in a different way each time.

A good engineering culture begins with the realisation that part of what makes good code isn't about writing code.

It's somewhere that has space for learning and space for doing the important and necessary stuff, those little things that make up the big things. So, make space for your documentation, making it matter. Having things like Definition of Ready and Definition of Done for the work your team does. Paying attention to how much work-in-progress your team has at any one time. Giving people time to have retros, giving people space to go to conferences.

It feels counterintuitive but by doing these things, the result will be better code, and you'll deliver better value to your customers. Crucially, you'll be empowering people to solve problems in better ways.