I have been hearing this argument for as long as I have worked in IT. Some say a manager must be able to program, otherwise he does not understand what he is managing and developers will feed him fairy tales. Others reply that a manager should manage people and deadlines and leave the code to those who can write it, otherwise he will poke into every line and get in the way. The funny thing is that both sides are right. They are simply answering different questions.
My answer is short: a manager does not have to write code. He does have to understand how the system works. These are different skills, and confusing them is dangerous in both directions.
A coach does not have to play better than the players
Take a football coach. Many great coaches were mediocre players, and some never played at a high level at all. Nobody expects a coach to step onto the pitch and score better than his striker. But a coach who does not understand the game, does not see why the defence is falling apart and cannot feel where the team loses tempo will not last long. His job is not to play but to see the whole game and make decisions the players on the pitch cannot see.
The same goes for a manager in software development. He does not need to write code better than the programmers. But he needs to understand what the system is made of, how its parts connect, and why one task takes an hour while another that looks similar takes a week.
Why a manager needs technical knowledge
Without basic technical understanding a manager is in the position of someone buying a car without knowing what an engine is. You can tell him anything.
- Telling real complexity from fairy tales. When a developer says "this will take three weeks because we'll have to rework the data model", the manager should at least roughly understand whether that is true. Not to catch anyone out, but to ask the right follow-up question.
- Estimating together with the team. Estimates without an understanding of the architecture turn into guesswork. A manager who understands the system sees risks in advance: an integration with an external service here, old code there, a data migration over there.
- Translating from the client's language into the development language and back. This is probably the main thing. The client says "add a button", and the manager has to realise that behind this button lie a new user role, access rights and three new scenarios.
- Speaking the same language as the tech lead. Not necessarily at his level, but at least with a shared vocabulary: database, API, deployment, migration, cache.
There is an old joke about a boss who asks a programmer: "Make the app tell where a photo was taken, and also tell whether there's a bird in it." The first takes an hour; the second once required a research team and five years. From the outside both tasks look the same. A manager who cannot feel that difference will constantly promise clients the impossible or be frightened by the simple.
A manager does not have to be able to fix the engine. But he has to hear when the engine starts knocking.
The danger of the coding manager
Now for the other side. I have seen many managers who came from development, and they have their own disease. When the project is on fire, their hands itch. They sit down and write the code themselves: it's faster, it's more reliable. At that moment the project loses its manager. Nobody talks to the client, nobody watches the deadlines, nobody notices that the next task is on fire too. The captain has gone down to the engine room to turn bolts, and the ship sails on without anyone steering.
The second disease is smaller but more unpleasant: a coding manager tends to impose his technical decisions on the team. "I would have done it like this." The team stops making decisions itself and starts guessing what the boss would do. It is the same micromanagement, just in technical wrapping.
The best managers I have met knew how to hold this line. They could open the code and read it, understand the database schema and argue about a decision in a review. But during working hours their hands were not on the developer's keyboard but on the project's helm. They used technical knowledge as eyesight, not as a tool.
What changes with AI
Today the question has gained a new dimension. With AI tools, a manager who cannot program can assemble a working prototype in an evening. That is wonderful for showing an idea, testing a hypothesis or explaining to the team what is meant. At Ingello we use this a lot: a prototype in days instead of months changes the conversation with a client.
But a trap appears right away. A prototype assembled in an evening looks like a finished system, and the manager feels there is only a little left to do. Yet between a demo and production lies everything You cannot see on the screen: security, data, load, support. This is exactly where technical understanding becomes critical again. Not to write code, but to avoid mistaking a stage set for a building.
What to do tomorrow
If You are a manager without a technical background, ask your tech lead to give You an hour-long tour of the system: draw on the board what parts it consists of, where the data is stored, how it moves, what is connected to what. Ask silly questions, that is fine. After a few such sessions You will start hearing the engine knock. If You are a manager who came from development, write down for a week how many hours You spent on code and how many on management. If the first number is bigger than the second, think about who was at the helm during that time.
