

The Software Manager's "Joel Test" - vlucas
http://www.adayinthelifeof.nl/2010/12/18/tutorial-how-to-manage-developers/

======
foresterh
I find the single biggest problem with managers is #9 - "Do you have enough
distraction for programmers". Time and again, management, or whomever can
offer distractions, don't see the importance of it.

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...

~~~
raganwald
If you give me everything else I need, I can go for a walk when I need a
distraction. I find that providing distractions is more of a signalling thing.

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.

------
edw519
He missed a few:

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.

~~~
selectnull
Very well said and with that, consider this:

"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.

------
martincmartin
These are all great sentiments, but as interview questions, they're largely
useless. By definition, the manager gives as much time for unit testing as is
reasonable, given the deadlines, work to do, and importance he or she attaches
to unit testing. So "Do you give enough time for unit testing?" is a
tautology.

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.

------
yannickt
I _really_ hate not being kept in the loop, and then getting blamed when
things "break".

