Why don't they leave the software to software engineers?

Leaders often guide problem-solving in the software and involve themselves in every decision. Instead, they should clarify the goal and bring transparency to problems.

Every time I see an engineer gets headroom to make some improvements in the system, I get worried. Even though they can turn complex tasks into complicated ones and solve them, they often struggle with freedom. Even though they know exactly where the problems are or where the team needs to improve, they get lost easily without guidance. I have seen this many times, and as an engineer, I also was the same. When I became a leader, I learned that the problem is not with the engineer. Whenever I see an engineer focus on something wrong or try to over-engineer something these days, my worry comes from me not doing my job.

When an engineer tries to over-engineer something, they appear to lack some skills, such as not identifying the most pressing tech debt. They look for what they want to change instead of what needs to be changed. I also did the same: there was a new technology that I wanted to use, and I tried it at the first chance I found. It was often neither required nor needed. It was me learning something new, which was cool and totally okay. However, the problem was precisely here: "I tried it at the first chance I found." And the chances were not always aligned with the biggest problems.

Identifying the most significant problems on the codebase requires analytical thinking and finding a way in ambiguity, and I thought most engineers lacked these skills. They couldn't prioritize which issue was the most pressing one and couldn't tell when exactly that issue could become a blocker and a real pain for development. I started helping engineers to find these issues by listening to them, asking questions to help them approach better, and understanding the technical challenges. Although it initially helped, it didn't solve the root cause. To make things worse, I thought it was my job (as a leader) to hand-hold all engineers in these situations and help them figure out why they should avoid over-engineering or solving the wrong tech debt.

That guidance mindset is dangerous. In hindsight, it looks like something that a leader should do. It is tempting to guide engineers because that is the shortcut that brings quick solutions and leads to better outcomes in the short term. However, it limits engineers' autonomy. At some point, it only satisfies the leader's ego. In the worst case, it leads to micro-management.

The problem appears to be on the engineer, but it is actually on the leader. If the team doesn't have clarity around where they want to go, what they need to build, and why they need to build that, they will struggle. They will build unnecessary solutions that only bring joy to engineers and have no use now or in the future. They will over-engineer things or take very opinionated approaches, which will create conflicts or cause complaints from the next developer. All of this will lead to the "everything needs to be rewritten" conversations.

If the leadership lacks strategy and clarity on the goals and fails to communicate them with the most junior engineer, there is nothing an engineer can do besides over-optimizing wrong things. If that's the case, the team needs a lot of hand-holding, and that's why they don't leave the software to software engineers.

Leaders should seek clarity in the team's goals and ensure everybody understands why and what so that engineers can focus on how. If any leader finds themselves involved in the how part of the work a lot, that means the leaders are doing something wrong. When that is the case, the leader should start by NOT leaving the software to software engineers. The leader's job is to ensure the team is building the right things. However, they shouldn't stop there.

Most problems occur when the leader stops there and falls into "always guiding mode," where they help the team with every single problem. Even though they should not leave the software to software engineers in the first place, they never change that behavior. They don't work on creating strategy and clarity. They get stuck in organizational work and don't extract themselves, and never help people learn how to navigate within some ambiguity. Although this looks like a problem for the team's leader, the problem often goes up in the leadership chain.

Leaving the software to engineers requires a good amount of work from the organization. Not a single leader can do it alone in their teams. If the organization doesn't provide transparency, clarity, and a good communication culture, the leader can do only so much. Even though the front-line leader may or may not succeed depending on the organization's culture, they should still seek to bring clarity to the goals.

Of course, leaving the software to software engineers won't work all the time. Junior engineers need that guidance to learn where to keep the balance. In these cases, senior engineers should provide this guidance. And for senior engineers to do that, they have to have autonomy. It's like a rolling ball; clarity and transparency start from the top leadership in the company and roll down to the most junior person.

In the end, engineers can't be left alone to decide the software's destiny unless they know exactly where they are going. The last thing any leader wants is people working on the wrong things. That's why leaders involve themselves a lot in every process. However, they should aim to bring transparency, clarity, and good communication and leave the software to engineers. If none of these exist, the software won't be left to software engineers.