I’m a software developer. When I see a technical problem, my first thoughts are always for technical solutions. It is the obvious thing to do.

However, solving a problem well often requires understanding what caused the problem in the first place. “The previous developer is so bad and I am so baller was often the answer when I was a lot younger. That specific answer is often incorrect. However, it does bring up the point that technical problems don’t just appear. They are created by people. The underlying cause of any technical problem is a people problem and these are the hardest problems to solve.

The most obvious people problem is skillset. Not having the right expertise in building software can cause lots of problems. I’ve been on plenty of teams that were primarily back end developers who muddled through front end code. What should we have done though? Stopped work until we hired an expert to teach us? I’ve never seen that kind of hire take less than 6 months. That’s a lot of time to spend waiting.

Databases are also another great example of a skillset problem. Any database will work for any feature before a product is launched. At scale is when things start to quickly fall apart. What do you do if you don’t have anyone on the team who has dealt with your particular database at scale? Do you stop building software until you can make that very difficult and expensive hire?

Messy front end code and crashing databases are nasty technical problems, but their underlying causes are people problems. Is someone with expertise available? If not, how can someone on the team gain that expertise and how long will it take? What’s the downside of moving forward without expertise and what’s the downside of not moving forward? Does the team even realize they are missing an important skillset?

Sometimes the skillset is available, but the issue is with attitude and decision making. For example, some developers really hate change. They cling to practices that may have been standard at one point in time. They stay in the comfort zone of those familiar practices. I knew a developer who kept an entire engineering org using SVN through sheer force of will. SVN used to be how most developers stored their code.

Today there are probably a large percentage of developers who have never heard of it. That’s because GIT is way better. Integrating work from multiple developers can now take minutes instead of hours. SVN was an inferior technical product, but our problem wasn’t the technology. It was that a person was preventing progress from happening.

That’s an obvious example, but there are plenty of subtle ones. I personally have a large amount of skepticism with using Docker in a production environment. I know people who talk about putting it in place, but I don’t know anyone who has scaled it. I have concerns about being able to solve any problems with it should they arise.

I lack expertise in the technology, but I also haven’t spent much time gaining that expertise because I’m not sure it’ll be worth my time. I’m sure the developer who loved SVN thought the same about GIT though.

Am I being old and cranky? Am I being rightfully cautious? Only time will tell. But I may or may not have a people problem with myself and I have no idea which way things will end up. All I can do is keep an open mind that I may be wrong to be skeptical of Docker and jump on the bandwagon if it becomes a clearly superior solution.

Of course there are developers who have the opposite problem of jumping on whatever is newest and shiniest. They adopt technology before it is actually ready to be widely used. This can cause problems if the technology has a lot of bugs. This is an even bigger problem if it turns out the new technology is fundamentally flawed and it took using it to find out its flaws.

There are plenty of other examples of where people problems cause technology problems. Some developers like to over-engineer solutions and create more complexity than necessary. Some like to hack things together and add an overwhelming amount of technical debt. Some developers like to build everything themselves. Some developers pick third party solutions without any diligence done. All of these things have extreme examples, but they all also have subtle examples where it is difficult to know which side a developer is on.

The last type of people problem involves managers and it manifests in many ways. There are managers who are more concerned about not getting blamed when things go wrong instead of making sure things go right. There are managers who like to think of their area as a fiefdom rather than work with the rest of the company. There are managers who equate more hours with getting more work done.

These people problems create all sorts of technical problems, but the most devastating people problem with managers that I have seen are managers that don’t understand how software development works. I have seen these come about either because a manager has forgotten what it was like to be a developer or someone became a manager before they developed a strong foundation as a developer.

It is a manager’s job to make sure their developers are incentivized to do good work. Good incentives can not be created without understanding how developers can do good work. This results in a number of practices that sound good in theory, but fall apart in practice.

For example, estimates are essential when planning projects. Some managers believe in rewarding developers who have more accurate estimates. But note the word “estimates”. Not “exact amount of time needed”.

Things often come up in software development. Developers will most likely think of a better way of doing something halfway through implementation. You want to encourage a developer to bring this up so that the team can decide if it is worthwhile or not. If a manager includes accuracy of estimates into performance reviews, the incentive is to make sure estimates are accurate. That means being quiet about new possibilities and focusing just on making sure the work is done within the estimated time. The result is more technical debt.

When facing an onslaught of technical problems, there is a temptation to tackle them all directly. This makes sense if there is a time sensitive crisis (e.g. all the servers are down). When things are less urgent though, it makes more sense to take a step back and think about the underlying causes. Those underlying causes are rarely technical.

This post was originally published on blog.professorbeekums.com