A lot of people move into IT management and treat the technical side as something they can leave behind. Meetings, roadmaps, budgets, that’s the job now, the thinking goes, and the details are for the engineers. It doesn’t work. A management role only works if you actually understand the core challenges and the complexity of the work your team is doing. Without that, you are not managing, you are just relaying messages up and down.
Understanding the complexity
Managing something you don’t understand feels manageable for a while, right up until it isn’t. You can read a status report, nod along in a meeting, repeat the words back up the chain. What you cannot do is tell whether a “two week” estimate is realistic, whether a team is cutting corners that will hurt later, or whether the person pushing back the hardest on a deadline has a real point or is just being difficult. Every one of those calls needs some real understanding of what the work actually involves, not just the vocabulary around it.
The Restaurant analogy
Imagine you are put in charge of a restaurant, and you have never cooked and never worked a service in your life. You can still read the P&L, track table turnover, and ask why the kitchen is slow tonight. But you have no way of knowing if 45 minutes for a dish is normal or a sign something is badly wrong. You cannot tell a chef with a real problem from one who is just making excuses, so you either trust everything you’re told, or trust nothing, and both are bad management.
The team notices fast. Either they learn what they can get away with because you can’t tell the difference, or they stop bothering to explain the real issues in depth, because you won’t understand it anyway, and every conversation gets reduced to a shallow status update. You can’t help them make a hard call under pressure, because you don’t actually know what the hard call is. You can’t push back on the dining room manager asking for a faster turnover, because you don’t know what that would cost the kitchen. You end up managing by whoever sounds the most confident in the room, instead of whoever is actually right.
A manager who has worked a kitchen, even briefly, asks different questions. They know what mise en place means, they know a slow ticket during a dinner rush is not automatically someone’s fault, they know which corners are safe to cut on a bad night and which ones will get someone hurt. That’s not the same as being able to cook the dish themselves. It’s enough to have a real conversation instead of a guessing game.
IT works the same way. A manager who has never touched the guts of a migration, never had to explain why “just add a cache” is not a five minute fix, never sat through an incident in the middle of the night, cannot really help their team steer a decision. They can’t push back on an unrealistic deadline, because they don’t know what reality is. They can not defend a team’s technical call to their own boss, because they don’t understand the tradeoff being made. All they can do is pass pressure downward and hope the team sorts it out, which is not management, it’s forwarding.
Being technical enough doesn’t mean staying hands-on with the code forever. It means understanding the complexity well enough to ask the right questions, tell a real problem from an excuse, and actually help the team steer instead of just watching them from the dining room.