

When Developers Work Late, Should Manager Stay or Go? - edw519
http://itmanagement.earthweb.com/article.php/3854421/When-Developers-Work-Late-Should-Manager-Stay-or-Go.htm

======
ShabbyDoo
>So I needed to be there to make sure I did everything >possible to ensure a
positive outcome.

Yep. I once worked for a large, old-school company where a large system had
begun to fail. Management decided to fix it by assigning tech folks to 12 hour
shifts -- 24/7 coverage! Each shift would report to the next before leaving to
sleep. I'm very bad at time-shifting and especially inept without sleep, so I
was all but worthless. It quickly became clear that the middle managers
involved cared more about making upper management think they cared about the
problem than actually fixing it. Finally, they gave up on putting their
software factory into full production and instituted more normal hours. The
problem was eventually diagnosed and solved.

There were two things that were especially sad:

1\. The root cause of the problem was that middle management was rewarded for
making projects "come in on time" and the technical quality of the work was
never evaluated. So, a manager whose on-time project left the codebase very
brittle might be rewarded while the manager whose well-designed project was a
few weeks late could be out of a job.

Specifically, the above issue was caused by a custom framework (Red Flag #1)
which made LDAP/DB calls inside a synchronization block. Furthermore, when
tracing was finally enabled, the application (which rarely served over 100
simultaneous users) was making thousands of DB calls per second. Since no one
in a position of power knew how much had to have gone wrong to get to this
point, these "oversights" had no effect on managerial evaluations.

2\. The project's post-mortem was initially limited to reviewing the tactics
used to fight the fire once it was noticed. I, the ever unpopular guy,
suggested loudly that we discuss why we had to fight a fire in the first
place. Lucklily, others quickly piled on, and the discussion shifted toward
prevention. No wonder I didn't stay there too long. It was as if occasional
broken-ness was a given.

I just re-read what I wrote, and I sound like some angry code monkey. But, my
core point is that the discussion in the article surrounded what a good
manager ought to do when developers must work at 3 AM. Perhaps the real
question that ought to be asked is, Why do developers have to work at 3AM so
often? In the example I gave above, management was GREAT at providing pizza,
coffee, and encouragement. But, they were really just covering for
organizational ills that allowed such crap to manifest itself in the first
place.

There seems to be some odd American obsession with timeliness over most other
measures of quality. Perhaps it is because it is so easy to measure? The
article cited the need to re-work a payroll system at the last minute. Either
(1) the payroll update could wait until the last-minute corrections were made
during daylight hours and tested appropriately, or (2) the inherent drop-dead
date for the change (perhaps a regulatory requirement?) should have led to the
system being tested and approved by business users (who understood the
requirements much better than the BA) well before the drop-dead date. Either
way, something was broken, and it wasn't the manager sitting in the cube at
2AM.

------
JulianMorrison
I don't give much credence to the "moral support" thing - a manager is a
disruptive figure to a coder, whose presences implies the possibility of
sudden changes of course, and who can't be casually ignored. If you want a
coder working in "the zone", then stay away! But the real question the manager
should be asking is: am I going to be the bottleneck - for a decision that
needs to be made, for knowledge only I have (such as the root password on
"live"), for some likely situation where I need to pull rank over the phone to
get a 3rd party to move in a hurry? If yes, stay (and stay quiet). If no, go
home.

~~~
RiderOfGiraffes

      > a manager is a disruptive figure to a coder,
      > whose presences implies the possibility of
      > sudden changes of course, and who can't be
      > casually ignored.
    

You mean a _bad_ manager. A good manager is none of those things.

I try to be a good manager, and my programmers tell me that they appreciate my
staying on those rare occasions they have to work late.

~~~
cia_plant
Your programmers also tell their mothers-in-law that they _love_ having them
over...

~~~
RiderOfGiraffes
I've been trying to find a way of saying this nicely - I hope I've succeeded.
My apologies to all if I haven't, and I would welcome suggested rewordings.

While some may find your comment witty and amusing, it presupposes that my
programmers lie to me, and that I am taken in by their lies. It presupposes
that I am in fact a bad manager, and that my programmers feel they would be
better off without me.

In short, you are implying that I am either incompetent, a liar, or both, and
perhaps worse, that my programmers are liars.

I find it somewhat offensive that without knowing me, my management style, my
work, my company or my programmers, you feel free on a public forum to make
such suppositions. I take very seriously the relationship I have with my
staff, and to have it criticised unfairly is, to my mind, obnoxious.

I write this mostly so that you know how your comments can and have been
interpreted. If this is not what you meant then I invite you to clarify them.
If this is what you meant, then I invite you to say so.

On the other hand, if you were making a quick, witty, snarky comment, then I
would suggest it's out of place on this forum.

~~~
cia_plant
I didn't mean it personally - I obviously have no idea about your own
management style. I have found that many managers are unaware of how much a
formal relationship hurts open communication, and how much effort must be
expended to maintain an atmosphere of honesty. In my experience most
programmers - most employees for that matter - tell their managers what their
managers want to hear. If that constitutes incompetence and dishonesty, then
incompetence and dishonesty are the normal conditions of corporate life (as
most any popular depiction of corporate life will attest).

~~~
RiderOfGiraffes

      > ... many managers ...
    

I would've thought my presence here on HN would've taken me out of the usual
class of manager.

Sometimes it's hard, but I make certain I reward open and honest
communication. I use various techniques, but I make sure my programmers, and
employees in general, can give me bad news without fear of personal
repercussions. This includes telling me when they've screwed up. No one gets
punished for that. The only things I demand are honesty and
consideration/diplomacy. And even if they express themselves less than
diplomatically, they still don't get punished.

Some years ago when I was senior, but not really a manager, the company was in
the process of going under. I and some senior colleagues managed a semi-
hostile management buyout. In the middle of all this, when none of us had been
paid for four months, and it was going to be at least another two before we
could take control, 90% of the staff were still coming in and working 24 hour
weeks (4 days of 6 hours).

Without pay.

When we'd given a briefing of where things were we asked one or two to stay
behind, and asked why they hadn't left. Their response - we don't want to work
with anyone else.

We've worked hard, really hard, to maintain that kind of working relationship,
and to this day any of them, when necessary, will come into my office to give
me bad news, knowing that I want the truth.

That's why I object to comments like yours. I accept that it wasn't intended
personally, but wanted you to be aware of how it could be construed, and how
potentially destructive attitudes like that can be.

------
notpablo
The slashdot comment thread is surprisingly insightful [
[http://developers.slashdot.org/story/09/12/20/1656248/When-D...](http://developers.slashdot.org/story/09/12/20/1656248/When-
Developers-Work-Late-Should-the-Manager-Stay?art_pos=3) ]

~~~
notauser
It's amazing how well Slashdot's comment/karma system works, despite 10 years
of frankly inexplicable web site management. Porting it to HN (without the
crazy interface) might help with managing growth.

In particular this comment is great:
([http://developers.slashdot.org/comments.pl?sid=1484856&c...](http://developers.slashdot.org/comments.pl?sid=1484856&cid=30505688))

Sometimes inspiring your employees is as simple as demonstrating that you
share their pain, even if you can't share the workload.

Now if this behavior becomes the norm, it doesn't matter what management does.
People will soon be burnt out and will leave.

------
Poiesis
Interesting question. When I was the developer, I tried to convince the
manager to leave. Bad enough to ruin my own day; I'm not going to ruin
his/hers out of vindictiveness if there's nothing they can do.

------
ghotli
If a manager does not trust his/her employee to deliver on a feature by a
given deadline (even if that is 8am tomorrow morning) then he/she is to blame.
The request to the programmer should not even make it to them if you don't
believe that they can deliver. At that point it's a management/political
decision. If by the virtue of a political decision it makes it's way to the
programmer's desk then the manager should ask if they think they can honestly
meet the deadline and how they should interact to aid in this deadline.

Secondly, if you don't understand at least the high level concepts involved in
the technologies your employees are using then you are to blame. Asking an
employee to stay late to fix a problem when you yourself have not stayed late
previously to further understand the technologies at hand is hypocrisy.
Whether or not you are aware of it, your development team is self organizing
itself around perceived ability and trust within the department. You should
make sure you are a part of the team and have some approximation of the
ability to determine whether or not a problem could even feasibly be
accomplished by a requested deadline.

Otherwise management should be playing nothing more than the role of damage
control if a requested bug fix, or feature won't be ready by the requested
time line. Your developers will trust you more as a manager if they perceive
that you are not regularly exposing them to the risks of over promised
deadlines and unreasonable expectations.

Clearly I speak to the ideal and I understand that sometimes shit hits the fan
with an inherited team where trust has not yet been established. Damage
control is the name of the game at that point. It may be tempting to expose
your developers to the risk of not delivering. But, if that does occur and
consequences arise because you over promised a deadline then resentment will
take hold in your subordinates. In the long term, resentment and dissent are
often more poisonous than making sure a (usually arbitrary) deadline is met.

Building trust with your subordinates is what you should strive for. The
decision as to whether or not you stay late should hinge on whether or not the
trust you have as a supervisor will be compromised.

The deadline may not be met this time around, but you sure as hell want to
make sure that you are armed with your developer's best estimates as to how
much time future development is going to require. Contempt and resentment will
often undermine this process and ensure that situations like the one at hand
will remain mostly cyclical.

------
PabloCh
When I was a manager of a small team, I use to say: "I'll be the last to leave
and I want to leave early". That's was usually enough to magically make
programmers to leave earlier and still get thinks done, because working late
has to do a lot more with bad habits than with technical problems. And no,
they didn't work from home, they couldn't (it was a very restrictive
environment).

Sure, sometimes they had some tough problems, and I usually stayed in my own
office only appearing to ask them if they wanted something to eat, for
example. I also use to have a brief meeting after two hours or so just to
evaluate if it still made any sense to stay or it was better to leave and come
back early when other involved people were around (for example, a DB expert).

------
johnl
The manager should stay, explain why he is staying, announce specific hours he
will pop in for updates (he may have to report to others too), stay out of the
coders way, don't make additional distractions, and order dinner.

------
RiderOfGiraffes
It depends.

It depends on whether the manager adds value.

When I stay with my programmers it's because sometimes I can:

\+ be a cardboard programmer

\+ actually help with the code

\+ make a decision about things to leave out

\+ order pizza (or other food/sustainence)

\+ clarify priorities

\+ be someone to check weird noises in the building

And I want to make it clear that I trust them to do the work, and will be
there to support them.

What I don't do is drop in every hour to make a witty comment.

------
mscarborough
Poor management, obviously.

Another aspect is that developers probably don't push back as verbally as can
be needed in situations like these. This manager increased the scope, and the
developer said 'fine, whatever you need'. The manager consistently interrupts
the author, and eventually camped out in his cube, and seemingly without any
resistance. Just seems a little passive aggressive.

------
dennisgorelik
I never mind if somebody else helps me with coding. Another person (whether
it's developer, manager, business analyst, or tester) helps to identify silly
mistakes and helps focusing on solving the problem. In certain cases such help
accelerates development even more than 2x.

------
iworkforthem
Definitely! Developer is most likely to be just the worker, he did not cause
the issues in the first place. Mgmt are the ones, but how many times do they
really stay?

------
naz
The manager should also be a developer. So stay

~~~
BigZaphod
I had a manager that was also a developer and it was horrible. It's likely he
was just a bad manager; by virtue of being a developer he felt he had a
certain justification to micromanage the hell out of everyone.

~~~
JulianMorrison
"Boss" might be better handled by an MBA, but "project manager" urgently needs
at least a little coding experience. If you don't have a gut feel for the
work, your estimates will be noise and you won't be able to protect the
developers from irrational imposed deadlines.

~~~
btilly
Only a bad project manager will assign time estimates. A good project manager
armed with a detailed breakdown of work and reasonable time estimates from the
developer is able to push back on irrational imposed deadlines.

In a perfect world I'd go on and say that good management won't try to
motivate by deadline. But unfortunately this one is so imperfect that that
particular stupidity is common. But it is common sense that a person who does
not understand the work to be done in detail is unable to accurately estimate
it.

