When Developers Work Late, Should Manager Stay or Go?
itmanagement.earthweb.com
itmanagement.earthweb.com
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.
> 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.
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.
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.
> ... many managers ...
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.
In particular this comment is great: (http://developers.slashdot.org/comments.pl?sid=1484856&c...)
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.
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.
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).
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.
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.
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.