On Managing Developers

An anonymous reader writes: A columnist at TechCrunch takes a crack at advice on how to manage developers. He has some decent starting points. For example, "Basically a manager's job is to make other people more productive. What's one really good way to do that? Do the work that is getting in their way. Which means: find out what kind of important work your developers dislike the most, and do it for them." Also: "[D]on't bull$%^& anyone, ever. ... Speak the truth as you see it. Speak it diplomatically, don't get me wrong; but be trustworthy. Only then will you be able to trust others." But some of his statements are open enough to be nearly devoid of meaning: "Any particular process artifact is probably irrelevant. The finest tech team I ever worked on began every day with a daily standup; so did one of the worst, most dysfunctional teams I ever encountered. ... [T]he systems and processes you choose for any given project should be fluid, and flexible, and depend in large part on the team and the context." If you are or have been a developer, what qualities have made your managers good or poor? If you've been in position to do the managing, does you experience jive with this guy's?

Comments

BS from managers

[Anonymous Coward]

Well, if I'm left alone (no bullshit), it doesn't bother me to work extra time to get something done well. As soon as I have to deal with bullshit from a manager, I move into my 8 hour mode. That means I come in and do 8 hours a day as per my contract and don't give a shit.

Re:If it were easy

[Kjella]

Everyone would be great at it. Anyone that thinks you can find the secrets to being a good anything in a couple of paragraphs, just doesn't know very much about the topic.

I don't think you can learn the how in a few paragraphs, but sometimes you can learn about what developers expect from a manager. Let's face it, a lot of managers just ended up there by being put in charge and is learning by doing whatever they think a manager should be doing. And sometimes not even that because they're still techs at heart and want to dive into problems, not manage them. Others have just gone the management 101 school and don't have anything but generic theory.

In particular, there's a massive difference between production work and creative work when it comes to estimates. If I need to get my car repaired or order catering, I expect a rather good time and cost estimate because it's standardized inputs and known quantities of work, at least for the most part. And you can fairly easily scale production with overtime, extra shifts, rush orders etc. to meet deadlines. And if a part is not in stock or you burn the cake there's a fairly standard and known fix.

Most time I've wasted with management is discussing timelines or estimates that are as good as it gets and they're not going to get better by repeating the question. In the end you just fudge it up by a factor of x you hope is big enough and give them a number, because that's what they wanted. This is particularly true when there's bugs or problems that I really don't know where is, what the root cause is, how long it'll take to fix or even if I can fix it since it's in third party code/systems/tools.

The best managers understand enough about computers to know this variation is natural and are pragmatic about working with it and working around issues when they arise. Those who come from a production industry seem to think you can beat a square peg into a round hole and act like I'm in the one being intentionally obtuse. "Can you do it man, yes or no?" which makes sense if you got a painter with three walls left to paint. It does fuck all when you got a developer who has no idea what to fix, but it's probably a one-liner when he finds it.

Furthermore, those who don't understand that you want me out of that meeting and working on plan A - getting it done - while you work on a plan B, what to do if it doesn't get done on time or fixed in a reasonable time. I've had to sit through rescheduling sessions which were almost as pointless as the original scheduling sessions, the problem is that you don't have good data on how long it'll take. And rather than accept that you just double down on the developers and their poor estimating ability and demand that this time, you need correct estimates. In their eyes, we're the hopeless ones...