Management: Innovation and Maintenance
Basically ever since I started my journey to become a software engineer, I've wanted to become an engineering manager. It's literally the first thing I say in all of my interviews. As I progress in my career as a developer, I want to do more reading and writing about management.
I've begun reading An Elegant Puzzle: Systems of Engineering Management as a way to learn more about the language of engineering managers and leaders. I'm going to use these blog posts as a way to take notes as I progress.
"Keep innovation and maintenance together"
This line really stood out to me, because it resonates with so many of the projects and teams I've worked on. When you have a bunch of engineers building up a new project, they'll likely use some cool new technologies. The problem is that there are still projects with older technology stacks laying around in maintenance mode.
On my current team, we have a bunch of new projects starting up and almost as many legacy projects. We keep the lights on, but we don't do any feature work for them. This is super frustrating for our customers. On one of the projects, we actually decided to hand it to another team to take care of. It made more sense in their hands, and they actually re-wrote a majority of application and took the time to innovate and bring it to life.
As you're building your organization, if you have teams that innovate, and teams that maintain you'll create a system of second class citizens. Everyone wants to be able to demonstrate impact, and it's going to be a lot harder for those in the maintenance space to shine.
The best way that I've seen this work is to have the engineering team have an 80/20 split on new feature work and attention to legacy, especially when the new feature work is replacing legacy work. The hardest part about legacy code is understanding how to contribute meaningful changes. If only one person is capable of making these changes, they suddenly become the "legacy person".
As a manager it's important to make sure all team members are familiar enough with the legacy projects to make changes, that way there's somewhat equitable braintrust on the team. If everyone at least knows enough out the legacy code to contribute, the barriers to making changes lowers a little bit. Plus, if you're willing to spend some capacity each sprint on it that familiarity doesn't go away. That was my biggest problem with some maintenance mode projects. I only looked at the code a few times a quarter, so when I did need to do something... I had to spend a lot of time building up my mental model of the codebase.
I think the most important part of this is making sure that people don't feel implicitly undermined by the design of the organization. It's hard to give your best on a team that you don't feel is contributing important work.
In the example I gave earlier, we gave one of our maintenance projects to another team and it became their innovation project. When that's not possible, it's important to invest in the changes that will reduce the barriers to contributing to legacy code. Developers want frictionless experiences for local development and deployment.
If you're not sure that everyone on your team can run your oldest projects, carve out some capacity to make sure they can. My first commit at SAP Concur was fixing a typo in what was supposed to be the word "administrator" on our legacy codebase. It was a 1 word fix, but I had to go through the full process to commit, build, test, and release my code.
TL;DR
Basically, we don't have the capacity to always build everything using the latest and greatest. We use most of the time we do have to deliver new features, but we also have to maintain existing projects and efforts. Avoid relegating a group of people to maintaining a legacy codebase, lest they feel their work is less valuable than their peers. When possible, blend innovation projects and maintenance projects and use the momentum with new projects to transform legacy experiences.
Make sure that within your own team all team members are capable of contributing to legacy codebases, and make the necessary investments to reduce friction for developers on these projects. When only a small set of developers know how to contribute to those projects, they often get pigeonholed into doing the work unwillingly.