The Software Manager's "Joel Test"
adayinthelifeof.nl
adayinthelifeof.nl
You give a team a pool table, game console, or some other form of "getting away" from the work, and you'll get back tenfold in terms of work done from them.
The second biggest offense seems to be working hours... too many managers think that programmers should be working the same as everyone else - 9-5, onsite 5 days a week, etc... we just aren't wired that way... when I can put in a few hours at midnight, I'm much more productive for my boss...
I completely agree on the working hours. I do have the benefit of being able to work at home, but 8-5 is killing me. If I don't exhaust myself at the end of the day, I can't easily fall asleep. If I can't easily fall asleep and have to get up to be "ready to start" at 8, don't expect me to be productive until around lunchtime... in which then it's lunchtime. So really, don't expect me to be productive until nearly 1PM unless there's a gun to my head. I haven't solved the sleep issue since I was 13, so that's not going to fix itself any time soon. However we can change the hours to be more around when I'm productive, or relax the hours (the process) and emphasize the result.
#3 and #11 are equally important to me. I need to make some very difficult design decisions that will be very expensive if they're wrong. I don't want them to be wrong and add additional cost somewhere -- whether it be correcting it down the road, or designing something that no one ever uses.
The couch tells me the company understands that "flow" cannot be switched on and off. If there's no couch, I won't miss it, but I would worry that the company values busywork over results.
1. Do you enforce policies uniformly? Allowing some customers to bypass channels may seem helpful, but once everyone becomes special, no one is special.
2. Do you set priorities and avoid changing them? Nothing ruins morale like the emergency du jour.
3. Do you stick up for your programmers? Blaming them for your problems is an awfully quick way to lose them.
4. Are you consistent? If you tell customers one thing and programmers another, eventually they will all realize that you're the problem.
5. Do you understand the customers' business well enough to set priorities? No one wants to work on Important Problem #42 when we're going out of business.
6. Do all policies and procedures take into account the importance of production and dev environments, security and audit controls, quality, and testing? Programmers shouldn't have to educate you why this stuff is important.
7. Are you willing to do what you ask programmers to do? Working late is fine until you do it 18 nights in a row while the boss is at the bar across the street.
8. How good is your bullshit filter? Decisions made based on bad data will come back to haunt us all.
9. How "professional" are you? No matter how tough things get, most programmers don't want to hear your scream, cuss, or throw things around. Better to just leave and let us fix it.
10. Do you buy us lunch once in a while? Amazing how much harder we'll work for a sandwich and a smile.
"Allowing some customers to bypass channels may seem helpful, but once everyone becomes special, no one is special."
Well, some customers may actually be special. It depends if the customer is willing to pay for the special status. I'm sure that kind of philosophy can't be applied to all situations or kinds of businesses, but it's not absolute: it can work. I try to apply the same thinking to emergencies: I meet customer's emergency with higher price. Most of them back off and figure out they can wait for our normal procedure. A higher price is great filter to customers who have a real emergency and are willing to pay for it. With that, you can really have some customers to be special, but not everyone.
I can only agree with the rest, very well said.
I used to ask questions like this, both when interviewing managers and when I was looking for a job. But I've stopped, since they seem to have no correlation with the information I'm looking for.