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

Fast, cheap, flexible - choose one

[Anonymous Coward]

This reminds me of the "Fast, cheap, flexible - choose one"-idiom.

You can be a great developer, a shitty manager and a good spouse.
You can be a good developer, good manager and a shitty spouse.
Or you can be a shitty developer, great manager and a good spouse.
(Forget about being a great spouse if your mission in life is to please a company!)

One of the best managers I've had have been technical, and got the boring parts done.
One of the best managers I''ve had have not been technical at all, but championed our services well and established a good network of connections throughout the organization that made the processes actually work.

It's all trade-offs. This also goes for "agile", which is just a choice for some trade-offs over another set of trade-offs.
The main problem is when people don't work together to find the best solutions, together.
Often, new hyped-up processes and tools become yet another excuse for people to NOT work together!
This even escalates the bigger the company gets.
Oh, and you should compensate work well done.

I'd make at least one change

[Registered Coward v2]

I would disagree with "Which means: find out what kind of important work your developers dislike the most, and do it for them." I would say:

"Find out what non-essential stuff is interfering with real work and protect them from it."

There often is work that is important that must be done but is not exactly fun, such as documenting code, helping tech writers prepare user manuals, listening to users and getting feedback on the UI, etc. Developers may dislike that work but they are the ones that need to be involved with it or do it. Sometimes it's the manager's job to point out stuff that needs to be done and find a way to get it done; even if it isn't what they want to do.

My best manager

[Lorens]

told me that his job was only partially to tell me what to do (because I should know most of it) and mostly to shield me from the bureaucrap so that I could concentrate on doing it. I try to emulate that.

Two other nuggets I aim for:

- a good manager tells his people what *his* objectives are, and explains to them how that translates into the objectives he's giving them.

- there are different kinds of management for different people, and a good manager must adapt. A newbie or an incompetent *needs* micromanaging (but beware of giving the impression of thinking either one is incompetent). As they get older/wiser/more experienced the manager can go more and more hands-off, until with a senior engineer/whatever the manager should be able to just discuss strategy and budget and priorities and such.

Managers need to know how to code

[Karmashock]

Or whatever your people are doing. You need to be able to understand what your people are doing so you can know if they're doing a good job or not.

The whole TPS report thing from office space was a consequence of someone that doesn't know how to code or understand the product trying to keep tabs on people that were creating that product or service.

So they create artificial benchmarks and paper work and then judge the employees by how well they comply with the paperwork.

The problem is that the paperwork is not actually anything the customer cares about. It has nothing to do with the product or service. It is an arbitrary management mechanism. And it is FINE if the manager doesn't need it. If the manager can judge your work without it, than the paperwork might make his job easier.

However, if he can't judge your work without that paperwork than he literally can't do his job at all. He can at best APPEAR to be able to do his job. And the only people that would make that mistake would other people that also don't know how any of this shit works.

How is a non-doctor going to judge the quality of a doctors work? You can't.

Same thing. Managers have to have experience in CS if we're talking about developers... ideally they should be programmers themselves.

Again, if you don't have enough programmers with management experience, then it is easier to give programmers management training than it is to give managers programming training. So do that.

Re:If it were easy

[Ol Olsoc]

Actually being honest is less work. It just takes a minimum of courage.

Very true, But I have found that probably 99 percent of humans lie very easily in self interest. That led me to be a very meticulous documenter. Which was also what taught people that lying to me was not even remotely in their self interest.