|
|
|
|
|
|
by wppick
2728 days ago
|
|
|
I think this is one of the most illogical aspects of the software industry -- the transition from developer to manager. In order to be a developer you need to spend years learning, studying, and practicing software development, but a lot of times becoming a manager is just some magical title change where suddenly you're qualified to take on some new role which you most likely have no training or experience in, and stop doing the role which you are qualified for, experienced in, and were hired for. Suddenly there is no way to measure or evaluate you (how do you evaluate a manager?), and you really don't have to do anything difficult; you can delegate anything hard or laborious. I've seen time and time again managers who don't do anything at all. They just fill their schedule with meetings upon meetings, and through some mental gymnastics and leaps of logic claim to have an essential impact on the work that is being done by others. The feedback in many comments in this thread seem to echo the same things: communicate, be a force multiplier, increase productivity, don't write code, coach. It seems like a bunch of unaccountable b.s. to me, but maybe I am missing something. I think instead there should be clear roles like Project Manager, Product Manager, Software Architect, Senior Software Developer, where the people in those roles can be actually evaluated, accountable, and hired specifically for the role that they will be doing. |
|
|
For example, I develop tools for internal customers. Those people may have feedback/feature requests/etc which they want to send me. But I'm busy working on something else, and although input is good, we need to prioritize. So my manager takes on the task of processing and prioritizing input, leaving me free to develop.
My manager also has a role in shaping the broader roadmap, advocating for the team's priorities and leading us to a position to deliver on whatever the end result it, which may for instance involve prioritizing space for developers to learn new skills if they're going to be important to the roadmap.
So all that to say, I think there's a role that involves personal development of developers more than project management, and it makes things go a lot better when it's done right (and conversely, makes things worse if not).
As for quantifying it, I think technical debt (specifically, the variety that is actively hampering a team's development work rather than just "this could be better") can serve as an approximation. The team I'm now in had been poorly managed for a long time and was constantly buried in technical debt. We got a good manager, and those issues are drying up as we get the space allotted to solve the problems amid other feature work.