As leader of a team of six software developers, I get to see a wide variety of experience levels, coding styles, and effectiveness. I also have a multi-year backlog of work for my team to do. My constant challenge is balancing quality, maintainability, and productivity. These are hard enough to juggle as an individual, and they’re incredibly difficult to manage well across a diverse team.
The goal of my development team is to deliver value to our customers. This is a superbly straightforward goal, but it’s not hard to lose sight of it as we work through a miles-long list of feature requests and bug reports. We’re under constant pressure to deliver features on tight schedules, and it would be easy to give into the temptation to do the bare minimum to get the work done. There’s a popular term in the startup world for this: minimum viable product (MVP). We actually do practice this to a certain extent, but we’re careful to keep an eye on where the project is headed; if it looks like it’s going to be around for a while, we need to shift gears and start building a higher quality, more maintainable product. We are not delivering real value if the product is riddled with bugs.
On the other hand, we have to be careful to not spend months designing a small app that really should be thrown together in a few weeks. Change is the only constant in software development, so we have to be ready to change gears quickly. The best approach seems to be a combination of planning for change and failing fast. Not everyone is great at both of those approaches, however, so I have to be careful about what types of projects each team member works on. We do strive for growth wherever possible, but sometimes you really do need to get it done right now.
I am personally a stickler for coding style. I like to use a consistent style, preferably one that matches the accepted standards for whatever language I am using. For me, this consistent style makes it far easier to spot potential issues. In theory, this should also make it easier for a large team to maintain the same code base.
When I first became responsible for reviewing the work of other developers, I wanted to point out all of the minor style errors that were driving me crazy. I was blown away with how different each developer was in this regard. I quickly realized that I was going to paralyze the team if I wanted to take that much control, however. Instead, I made a decision to only focus on the bigger problems and make small suggestions where practical. My goal is to move in the direction of greater consistency, but it does not have to happen immediately.
Seeing the incredible variation in individual productivity has also been eye-opening. We’re dealing with complex systems and it’s impossible for me to fully understand every problem that my team is working on. Because of that, it’s hard to know if everyone is really being as effective as possible. Rather than trying to figure that out exactly, I choose to focus on giving my team everything they need to succeed. I meet with my team members individually a minimum of once per week to make sure they have a forum to talk about anything they want to cover, especially something they need help with.
Shifting from being a full-time developer to leading a development team has come with a set of challenges. Once I accepted the fact that not everyone approaches problems the same way I do, things got easier. One-size-fits-all does not apply in software development, whether managing projects or teams. For me, finding the right balance for each situation is key.