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.
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.
"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.
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.
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.
> 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.
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.
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).
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.
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.
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.
>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.
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.
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.
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?
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).
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.
22 comments
[ 3.1 ms ] story [ 84.3 ms ] threadIn 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.
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.
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.
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.
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.
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.