Slashdot Mirror
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?
Honesty is a biggie.
And once you can fake that, you got it made.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Reminds me of the time years ago, I wound up in a bank. We got this company-wide email from someone in senior management, I don't remember who. Maybe the CEO or CTO. I read something like: "We've had a management consultancy in this week, and and their advice was that productivity could improve if staff were recognized and shown gratitude for their contributions. So thankyou!". . . . And that was the end of that.
If it acquires resources on instantiation like a duck, then its a shared_ptr<Duck>