Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Technical management, at least good technical management, functions as a translator between business and IT. They make sure that you get clean requirements instead of vague business goals that need hours of follow-up questions and they keep CTAnythings and PMs off your back so you can focus on your work.
Only problem is that good ones are pretty rare, the rest recites one of five "motivational speeches" in between every 4 sentences and leans back feeling good about themselves and putting blame on "their techies". -
@Godisalie thanks. I appreciate your trial to answer my question. Nevertheless, I was always taught that translating business requirements to IT is a duty of a good senior engineer (or tech lead, whatever), so even in this point I don't see need of technical management, apart from teach lead(s). Thoughts?
-
As a technical manager, the best way I can explain is that I'm only needed if you don't have a good senior engineer leader. I regularly step back from projects if they're already well managed. I'm not needed there. But sometimes you need someone who can perform those duties because, simply put, "good senior engineers" are rare by their very nature. I'm a fill gestalt that's not as good, but gets us part of the way there. The key to good technical program management is flexibility with your role.
I also believe the more smart engineers you put in a room, the more chaos there is. And ultimately my job is to reduce entropy in the business.
Can someone explain to me the need of a "technical management"? I know my question is naive, but try to explain it like to kindergarten kid.
Case 1. When team is good, and has a good tech leader(s) then the software director/manager makes more harm with his silly ideas, pompous cliche "calls to arms" etc.
Case 2. On the other hand, when software team is shit, it means that the management is responsible for assembling such team. Then it further means that they can't distinguish impostors from really good talents, which leads to bad quality, missed deliveries, bugs, frustrations, etc.
I saw many times when good technical lead (aka architect, staff, principal) made a positive difference. But I NEVER EVER saw that things were bad and "manager/director" made a positive change. This concept is soooo flawed....
... any one explain please?
question