The Magical World of Software Development (Part 3)
In part 1 & part 2 of this series I did a brief history of software development as I see it and how that impacted the people who were coming into the industry, I would like to finally get to the topic I set out to write about. How the heck to you manage these people?
Based on my hypothesis that we are operating in a new digital world where the rules don’t apply the same way as they do in the physical world, there are a few things I think that make managing these people tough.
Why Its hard
I think managing people is just hard. I hear it from all industries. However, I think there are some unique challenges that are present in the software engineering manager role.
Writing code is an art and a science
As we talked about in part 2, writing software is as much an art as it is a science. Each developer has their own writing style and if you work with people long enough you can even begin to pick out who wrote the code based on the style. This makes it hard to develop metrics and standards that are extremely prescriptive. Prescriptive standards favor the science aspect of writing code and will stifle the art aspect of it.
Developers can work from anywhere now
To office or not to office? That is the question.
It's clear that remote work is here to stay. It was inevitable that it would become more popular over time. Covid sped up that timeline by about 10 years. It forced everyone to develop the capability, and now that the capability is there, it's hard to find any excuses.
It's hard to manage people in a completely remote setting. It takes a lot of trust to know that while people are not being watched, they are putting in effort. Even if people are putting in the effort, it's hard to verify that some of the more senior-level activities like code review and mentoring are happening since you can't observe it.
The digital world is not the physical world
As I talked about in part 1, we are in a whole new world that doesn’t have the same rules as the physical world. But, just because you can do something doesn’t mean you should. In the digital world, there are so many crazy things that you could do to solve a problem. These “clever” solutions often end up being a burden to the team because they were a little too clever and ended up being hard to understand for the people coming after.
Developers like to interface with computers, not people
I have a longer post about trade-offs that deep dives into this topic, but the obvious trade-off of being really good at working with computers is that someone might not be good at working with people. Some of your best developers can be some of the quirkiest and hardest to communicate with. This is so common that it has become the stereotype for our industry, particularly among men.
Perverse Incentives
Almost everything that tracks developers can fall victim to 2nd and 3rd order consequences. Creating software is a complex process, and it can be easy to assume that there is a silver bullet metric that can cause everyone to align on the right thing. More likely than not, that will align them to that one thing but create chaos in other areas. Almost every code metric you monitor will create a perverse incentive if you tie it to performance.
Managing Software Developers
This is by no means a comprehensive list, and I lay no claim to having figured all of this out. However, given the challenges presented, I find these things to be helpful.
Team Metrics
Because people need to perform multiple roles at once, the best way to measure their performance is not against the individual but against the team. Developers need to wear many hats, but they will likely specialize and find a niche. Like elite military units, everyone needs to be competent, but everyone has a special way that they contribute to the team. Individual metrics can inadvertently cause people to prioritize only one aspect of the job. Team metrics focus people on doing all of the things necessary to ensure the success of the team.
The team also creates a checks and balances system against perverse incentives. In order to game the metric, everyone has to do it, and that is harder to pull off because people have to be vocal about their intent.
Do Things in the Open
Because remote work is so prevalent, I encourage more people to do things in the open. By this, I mean that comments and feedback should be public. Code review should be more like open source where it all takes place in the PR and not in private meetings or chats. Without a paper trail, it becomes almost impossible to validate that certain tasks are being done. So, I encourage everyone to do more in public.
Trust but Verify
Individual metrics should be used to inform but not tied to performance. Managers need a way to get an indicator that they need to dive into the weeds on something. That is what individual metrics are good for. It's a trailing indicator that something has gone off the rails. Use metrics as a signal to get personally involved in a process.
Connect Them to the Bigger Picture
We have heard it a million times, “start with why”. But the reason it is repeated is because it is important. If developers can see how their little task connects to the larger mission, it makes it much more meaningful. I don't think people get burnt out because the work is hard or even if it takes long hours. They get burnt out when that effort is meaningless. It's important to align your team to the mission of your company.
It is also important to align the company to your team. If the company isn’t connecting its success back to the team in a meaningful way, then there won't be true alignment. If, when the company succeeds, the team benefits, you will find that people will enjoy their work and find it extremely meaningful.