Tech Management: The Good, The Bad And The Ugly

The quality of your direct manager can make your job either dream or a nightmare. A manager’s impact on the quality of their work life is so great that it’s sometimes said, “Employee’s don’t quit companies, employee’s quit managers”.

I often rage about bad tech management. I thought I’d take a slightly more productive approach to this topic in the Ruby Hub blog and list out things which tech managers do that makes them bad managers.

Bad management

Let shit roll down hill

Bad managers will make no effort from shielding their workers from the wrath of upper management. Part of the reason managers usually get paid more is because it’s their neck on the line one something goes wrong, the buck stops with them as it were.

This means when the buck doesn’t stop with them, but instead they pass it down to an individual developer, you wonder if they’re really earning that extra salary. Don’t get me wrong, developers should still be hold accountable for their own actions, but if a manager is too quick to offer up a developer as a sacrifice every time, then that’s bad from the manager’s end.

This is particularly insidious when a manager who usually micromanages you makes a big deal over getting you to make a particular decision, then tells you, “Well ok, this is *your* decision”. You wonder why after all the micromanagement they make a big show over letting you make this particular decision, then you realize that in this case something big can go wrong. This means they are making sure that if something does go wrong, and the shit hits the fan (please I’m sorry but permit me to use the word “SHIT” as we go along), the fan is pointing in your direction. And I can tell you this for most of the developers passing through it, I have passed through same situation before, but I’ve now known how to overcome that shit.

Micromanagement

I don’t have much to say about this. I think everyone knows what it means, and that it’s a very fast way to demoralize highly skilled knowledge workers. Despite this, micromanagement occurs with surprising frequency.

Treats their workers like their time is less valuable

I remember a CTO who was working where I’m currently in, he was very much of the opinion that his main job was to maximize the teams productivity I can tell and I love him for that. This mainly involves making sure that we keep coding without much interruption, as interruptions don’t go well with developer productivity.

But a bad manager seem to view themselves as better than their developers and this comes across when they interrupt their coding.

Hidden in this is the belief that they are better than you, since they are a manager, and you are not. This can be especially irksome when you are a highly experienced developer who has specifically chosen the individual contributor route over the management career path, a choice which is very viable in software development. It’s possible to be in a situation where you out earn your manager and would be at their level or even higher if you’d chosen to go the management route, but you’re where you are at because it’s where you want to be, not because you couldn’t be a manager. No, you aren’t my manager because you’re better than I am, you’re my manager because I think management is boring!

Assumes their technical opinion overrules that of their workers

This is relevant when your manager is a lead developer. A lead developer is often not the most skilled worker in a team in a technical sense, I have seen and I can tell. This makes sense because unlike the difference between a midlevel developer and senior developer, the difference between a senior developer and lead developer is not technical skill. It’s simply a case of the lead developer having management skills in addition to their technical skills.

While a lead developer may sometimes need to be the final arbiter on technical disputes which will cause work to stall if not resolved, it does not make sense for a lead developer to be a dictator on smaller scale technical decisions. Put bluntly a lead developer generally shouldn’t be telling a senior developer how to write their code, since it may well be the case that the senior developer is as good as, if not better than the lead developer. A lead developer is mainly meant to organize the flow of work to maximize the team productivity.

A good example of a lead developer over stepping the mark in this sort of way is code reviews. Whereas when other senior developers who review your code will have to convince you that changes need to be made, some lead developers will act as if any comments they themselves add to pull requests are dictates that must be followed. The way they see it is that they can pull rank, as it were, when asking for changes. Unless coding standards are being violated, this should not be the case. A lead developer’s comments shouldn’t really carry any more weight than that of a senior developer’s. If this isn’t the case you will have highly skilled developers who feel like they aren’t free to make their own coding choices, and who instead have to code exactly to someone else’s liking. This is particularly annoying when the lead developer is in terms of coding ability actually weaker than the senior developers on the team (I have seen this be the case).

These are the biggest examples, but I’m sure there are more. All in all my preference is for a servant leadership style of management, as I feel this empowers developers and is certainly best when it comes to retaining the top developers on your team.

Let’s face it: For some people, management is a boring job anyway. Far better to stay a developer and write code all your life, lol. But for me I think you have to balance it all for effective management.

 

Share on facebook
Share on google
Share on twitter
Share on linkedin