When process improvements can be more valuable than code changes

While looking for a new job, I've been thinking about how I quantify the work I've done previously. It reminds me of a role I had where I introduced positive changes far beyond the assigned coding tasks.

I was working in a team (of 8) building desktop software that the business sold. It was high-value software for a specific task and industry. The product was more than a decade old (when I joined), and updates were released (approximately) every three months. Updates would add fixes and new features. Some customers also paid for their own custom functionality.

I collaborated with the sales team to provide technical planning support for custom work and, as part of the general development team, implemented planned changes for each release.
It wasn't the most mentally taxing work and didn't break new technical ground. But, it did allow me the time to think about the broader picture of what we were doing and how we were doing it.

Here are five things I did in that role that others on the team couldn't or wouldn't have done.

1. Streamlined work distribution. When I joined, the work to be done for each release would be decided in advance and then individual tasks would be given out to developers one at a time as each task was completed. This way of working had been done for years, but I quickly identified multiple issues. I persuaded the manager to group related tasks (typically by area of the code base) and give them all to a single developer. This change resulted in faster changes, (so more work could be done for each release), fewer bugs, and developers gaining a deeper understanding of the codebase. Because each developer was spending more time in an area of code they got to know it better, could make multiple changes at the same time and avoid conflicts or rework when multiple developers tried to change the same area of code at the same time.
2. Increased documentation accuracy and quantity. The company used to have a set of Word documents that detailed developer processes and important information. These were hosted in a read-only form on an intranet. The process for changing or adding a document was slow, and so it wasn't done as frequently as would have been beneficial. I migrated the existing system to a wiki-based solution, which led to more documentation being created and it being kept up to date.
3. Simplified and automated the release process.  Releases were an important time, but they used to be very slow. Originally, a release would require a "release week" where all the developer team were involved in preparing the release or working on projects away from the main codebase. Creating a release build was a slow, manual process that took three days to complete. This would then be manually tested while custom builds were created for customers with unique features. After going through this process once, I saw the issues and began automating it. I reduced it to a 25-minute process that also included all custom builds. This was run multiple times a day as work was committed to the main branch.
4. Introduced automated testing. I joined a company with a dedicated manual tester and a technical director who refused to accept that coded/automated tests were a good use of anyone's time. When I was tasked with work that involved multiple complex calculations, I knew I couldn't complete the task without creating coded tests. There were too many variables and scenarios for me to remember everything, and even following a manual script would be slow and prone to errors. I created the tests anyway and even identified many previously unknown existing bugs in the calculations. At our next weekly meeting, I admitted what I'd done and showed how having the tests had not only saved me time and improved the quality of the code, but it also made future changes to this part of the code easier and with less risk of introducing unintended side effects. There was initial scepticism from the manual tester who felt threatened, but once they saw how it freed them up to do other work and reduced the bottleneck of manual testing from the development process, everyone got on board and creating coded tests soon became the norm.
5. Restructured weekly progress meetings. Every Thursday afternoon, the whole team would gather for a meeting. Initially, this was primarily dominated by each developer individually reporting what they had been working on and giving progress feedback to the manager. Most of the progress feedback to the manager was irrelevant to the rest of the team and so it wasn't a good use of time to gather everyone in a room for a series of 1-on-1 conversations. I suggested moving the progress reporting to email which, happened before the meeting. This freed up the meeting to collectively address any concerns and discuss wider issues or areas for improvement. I particularly remember the final meeting I attended on my penultimate day with the company. When I suggested a new process improvement and explained the benefits, another member of the team asked why I cared when I was about to leave. I replied that I wanted the best for the company and the team, even when I wouldn't be there. And, while I was there, I wanted to do everything I could to make it as good a place to work as possible.

The code changes I made could, arguably, have been made by any of the other developers on the team. That's part of the nature of coding. I expect that the increased use of AI/LLMs as part of software development will further reduce the distinction between the code produced by different developers. The distinguishing factor between developers may come down to their ability to do more than produce acceptable code. Being able to understand how the required task fits into the broader picture and identifying areas for improvement is a crucial skill. A knowledge of the wider business and its processes can also be valuable. Not that individual developers should always question every decision and attempt to change business processes, but they should be able to see and understand the broader environment and offer suggestions when appropriate.
I'm looking forward to competing in this developer marketplace.