When Developers Work Late, Should the Manager Stay?
jammag writes "A veteran developer looks back — in irritation — at those times he had to work late and his unskilled manager stayed too, just to look over his shoulder and add worry and fret to the process. Now, that same developer is a manager himself — and recently stayed late to ride herd over late-working developers. 'And guess what? Yep, I hadn't coded in years and never in the language he had to work with.' Yet now he understood: his own butt was on the line, so he was staying put. Still, does it really help developers to have management hovering on a late evening, even if the boss handles pizza delivery?"
... STFU, keeps the hell out of the way, and does nothing other than bring pizza (and a few beers later on towards the end of the shift), that's ok.
Anything else is NOT HELPING!
If I'm in the shit, I want you in the shit with me. Though, being a manager and staying late with your developers, your first priority shouldn't be riding them but play a support role. What do they need to get the job done? What can you do to remove obstacles from their way? Food? Drinks? Problems come up. What can you as a manager do to resolve that problem?
If the developers are staying late because the manager messed up, it doesn't hurt to stay late (but stay out of the way and order them food)
If the developers are staying late because they come in late or they messed up, no, the manager doesn't need to stay.
The author indicates that when he was a developer, his manager would "every hour on the hour, he would pop in and say something he thought was very witty." It is one thing to stay late with your team because you feel that if they are sacrificing, then you should sacrifice too. It is quite another to provide "moral support" that is nothing more than a distraction.
Last summer, I worked 80 hour weeks in preparation for a bake-off in the fall. It was pretty important that the developers and managers be there because even though we knew our assignments and set measuring points we wanted to meet everyday, the inevitable things came up that would require a supervisor's ruling basically so the developer's ass wouldnt be on the line if we should of done something different.
although that was a one time, or one summer circumstance, i could think up similar scenarios where managers should stick it out for similar reasons. Dev make products, managers make certain decisions, and sometimes you just cant describe the situation over the phone.
Since when does being a Socialist mean 'someone who has a different opinion than me'?
Dont be a micromanager. Just be there for the employees and let them know that its okay to ask for help.
Yes -- and pizza is all the better. It's great to know that the challenge is being shared, IF it's a healthy, collaborative effort.
OTOH, if it's an over-the-shoulder kind of assistance, that's rather frustrating. Not so generative, and it's simple enough to know the difference...
If deadlines are coming and you need to stay late with your employees make sure the situation: Everybody's butt is on the line including yours. That being said, also make the distinction between shepherding the process as opposed to micro-managing the process. Sometimes, a management decision might need to be made late. If you're there that helps ease the stress of an already stressful period. You're also there so be helpful so that they code focus on coding. Documentation needs screenshots before product goes out: You can handle that. QA needs someone to tweak the test plan? You can handle that.
Well, there's spam egg sausage and spam, that's not got much spam in it.
I can relate to evenings like this. Two lines I will never forget:
/. =)
"Where we at on this?"
"Let's see it!"
I think one of the other lines that really stuck with me/irritated me was "Lets table this". I am glad to have moved on. I'm sure there must be some other lines used by other managers. Lets hear it
Man blir trött av att gå och göra ingenting.
If the manager asked for the developers to do extra work...a shortened timeline, extra workload dumped on the department, whatever. If the manager has asked his team to give up some of their time (with pay, of course), you're damn right the manager should be there too. He probably has work he could do too, but if nothing else, he should be cheerleading (delivering pizza, atta-boys, making jokes to help keep the developers mood light, and so on). It doesn't matter if the manager messed up or not...developers have a schedule, and if you ask your people to work more than what they're scheduled, you'd better have your ass planted in YOUR chair until the last person goes home.
I'd say 20% of the time the manager should stay, since about 80% of them are idiots.
The function of a manager is to manage, not micro-manage.
There will be times that questions arise that need management input. Not often, but sometimes. When those arise, it is extremely irritating to have no manager present. However, that does not mean hovering over the developers' shoulders and adding to the pressure. Arrange pizza, yes. But apart from that, stay resolutely in the background, available to answer questions, but leaving the devs to their own devices.
I'd actually refer back to Robert Heinlein on this one. In Starship Troopers (the novel, not the wretched film) Lt. Rico, just after he gets his pips, is told by his CO that his wandering through the crew quarters is simply putting his men on edge. He should go back to his quarters, and when it was time to act, his sergeant would have his men ready for action.
I'd suggest that you do likewise, even to the extent of perhaps taking on some small, tedious task to take it off the plate of some dev, and keep yourself busy while you wait for the questions.
Only if the manager stays late to 1) eliminate external distractions, 2) order meals, 3) test, or 4) write macros, scripts or other shippable elements, if the product supports such features.
Hanging around just to make sure developers stays put or focused implies the developers aren't professionals or the manager isn't doing his job (item 1 above). If true, then it's the manager's fault for hiring or keeping the developer around and no amount of babysitting is going to deliver quality code. If not true, then an insulting hindrance and is quite likely to hinder or prevent delivery of quality code.
Lastly, there's always the question "Why are developers staying late anyway?" and whose fault is it. If it's the manager's fault, and it always is unless we're talking about developers who work night shifts, then hanging around to make sure developers get work done the manager caused or should have prevented is likely to cause resentment. Tread lightly and focus on items 1 - 4 above.
A good boss provides direction, clarity in job tasks, and the resources to get the job done. If the team starts a LAN party whenever the boss leaves the room or are unable to order pizza on their own, the boss might need to stick around. Otherwise they should get out of the way. Part of being a good leader is letting go.
If the manager is staying so they can micromanage, then no it isn't useful. If they are continually hovering over the shoulders of their people and yelling at them for not working faster, then it'll be a detriment.
However, it can be useful. In part it shows solidarity. The manager is saying "I'm not better than you, I don't get to go home just because of who I am. We ALL stay here until it is finished." Also if they do a good job of staying hands off, but being there to solve problems. Anything comes up that is out of the responsibility of the dev staff, they handle it. Plus things like ordering food can go a long way too. They can't add to the development, but they'll make sure that any non-dev stuff is taken care of.
So it all depends on the personality of the manager and how they relate to the team. It is a case where the manager needs to know themselves and understand what is best. If they are the kind that just can't help but hover in stressful situations, then get out and go home. Your team will be better off. However if you can sit back and let your people handle it, and just be there as a symbol more or less, then yes stay around, it helps.
I've worked in shops where management is pretty much hands-off and let us do our jobs. Currently however I have a clingy boss who is more a hindrance than anything else. Doesn't matter if it's after hours or not. At least the worst of them (yes, multiple supervisors, Office Space-style) is off on Mondays...I used to hate Mondays....
If you expect your workers to work late, you damn well better not be taking off to see your family or hit the links. I say this as a manager.
We all go home or nobody goes home.
"Not to mention all the idiots who use words like boxen."
Anonymous Coward on Monday August 04, @06:49PM
It depends on the urgency of the situation, the relationship with the employees, and the style of the developer.
When there is some code that needs to be demo'd the next day, and you may have to omit some features or make some things less functional the boss MUST STAY until it's fit for demo. His input will be needed to decide what's OK to leave out, what must be finished.
If it's less urgent, and the deadline is spread out over days and the developers work better without interference, then the boss can just check during regular hours.
It's a judgement call, just like anything else. And yes, the manager should definitely buy pizza if he stays. It's just common courtesy. It also builds the team, and aside from that I find that pizza is fantastic energy food for late-night coding.
Oh, and ideally the manager should have figured out how not to have it come down to late-night; but we don't live in an ideal world. The team that works into the night will win, even if their code has bugs. The 9-5 coders with no bugs will be late to the market, late to the VCs who funded the later-nighters project, etc.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
No need to add to the anxiety. Give them a comp day (of their choice) and back off. If you've been doing your job correctly they'll want to stay and they'll know that you will make it up to them. Hey, this is part of the world we live in. Keep the faith and you won't have a problem.
I'm not a programmer, but a journalist. My best hovering manager story was 2 years ago, when a shopping mall caught fire in the middle of the night. A photog and I put down our beers and rushed out there. When we got back to the office, the editor was there, and it's a good thing, too. His instructions to me were to "write something quickly, so we can get it in the paper." To the photog, he said, "pick out your two or three best pictures." I shudder to think what we'd have done w/o that guidance. /sarcasm
If the boss is the type that wants to micromanage stuff they don't even understand, get them as far away as possible, they only cause problems.
On the other hand, if they let the experts do what they are payed for and stay out of the way, it's a great thing.
Here's some reasons why:
Since the boss has to stay late, they aren't as likely to tell the underlings to stay late unless there's at least a half decent reason.
(The ones that don't stay, tend to get an attitude of fire & forget, ie you stay at work till it's done or I'll fire you, and I'll happily forget how crappy I'm treating you... Or at least that's how the underlings will feel about it.)
Also, the boss can get the pizza, or chinese, or whatever food you order that night. Don't want to mess things up if you're in a groove.
And here's a biggie, management is there in case something goes wrong. If the power goes out, a fire alarm goes off, somebody breaks in, whatever, if it's just the underlings, the shit's gonna hit the fan and guess who gets it in the face. On the other hand, if a manager type is there, those higher up are far more likely to listen to his side than that of the underlings. It's not that a manager can prevent the shitstorm, but he can lessen it and redirect most of it where it needs to go. (Even if where it needs to go is next door where their busted sprinkler system dropped the water pressure and automatically set off your fire alarms because of a water pressure sensor... Yes, I've been in that one.)
I don't develop. I sysadmin. Recently I was asked to build out 15 new servers. At 5:30pm. It was an emergency and had to be done ASAP, oddly enough because the coders wrote a crappy code release that required a threefold increase in horsepower just to handle the normal load and the companies QA process never picked up on this highly important fact and the code was pushed to production where it ground things to a standstill. I know the company isn't going to do squat for me. I don't get overtime. I won't get a bonus. I won't get comp time.
For my managers manager to stay the night was a show of solidarity. He doesn't know how to build the systems, but at least he was there. Now the important thing is that he wasn't watching over my shoulder every step of the way. He'd ask for updates every couple of hours and he went out and brought me dinner so I could stay working, but otherwise stayed out of the way and let me do the work.
Psychologically it helped to know that he also missed playing with his kids and putting them to bed that night. 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.
"The avalanch has already started, it is too late for the pebbles to vote." -Kosh
Our late night installs bring out the best and worst in my colleagues. The best comes from incredible scripts done on the fly...the worst from management, trying to quantify the status.
After midnight, it becomes a steady stream of `hot items` of `major client impact`...from management trying to help out, by providing more management. Fortunately, my brain has tuned management out well before midnight, so things still get done.
0 = 1 + e^(Alt something)
My boss has the perfect answer for this:
Get everyone set up with dinner/beverages. Then, go home, sign in from there, walk away from the computer and keep the pager close.
We page him if we need anything, or when we get finished.
Out of our hair, but still handy if needed. Perfect.
How about nobody works late and stick toghether as human beings ?
I've worked 4 years in the game industry and this is just making me sick. The company makes millions and millions and makes programmers work late without any compensation. They even break the law doing so (at least were I used to work) and don't care about it at all.
If the manager is a true leader they should be available (there or in contact) to give clarity. The worst overtime experiences I ever had were caused by ambiguity. Are we done now? How about now? What is the measure of success tonight? Managers who ask you to come in for attendance, but not a goal, have no clarity themselves. If you know what the goal is (ie. Clicking SUBMIT 10 times will no longer crash the database/app/game) then you can focus and feel good when you've finished. You don't need anyone around if you have clarity, unless it's to support you with food, drinks, or more clarity.
If you are working late because there is a crisis it might be that although a manager cannot do the technical work they can evaluate the situation and determine what to do next.
A few years ago I was in this situation; we had two developers working late to resolve a customer problem that was critical. My team was very committed and were technically excellent. I knew that I was just getting in the way in many respects. I kept away as far as possible, just keeping an eye on progress (or rather the lack of progress). When it got to the point we were considering deleting customer data to resolve the issue we pulled the plug for the day. It was late, we all wanted to leave, and we were on the verge of making decisions that could have had massive knock on effects. In the end I called it a day and we went home. The issue actually took a week to track down and resolve. The actions we considered on that night would not have helped, and would have caused significant secondary issues.
The manager is there as a backstop to make sure that actions are not taken that may make things worse. His job is to stand back and look at the larger picture than simply the technical issue; ask himself - what if it can't be fixed tonight? My primary role was one of communication and buffer. That is I could communicate with the customer and support teams while the development team worked relatively unhindered.
Yes, make the manager stay and see what us devs have to go though to make deadlines. Deadlines that are usually set by clueless managers. Especially if the manager is salaried and the workers are paid hourly. Get SOMETHING useful out of what the company is paying them. :)
... "work late" of which you speak?
I used to do that in my old developer job. I don't do it any more.
Salary = 40 hours/wk ... PERIOD
If management wants to negotiate something, that's fine, I'm always ready to deal.
Short of this, I don't work over 40 unless it's a critical production issue and guaranteed comp time.
This may seem cold, but if the situation were reversed:
"Umm yeah, my daughter wants a new $FAD_ITEM to impress her friends. Could you put an extra $100.00 in my paycheck? I'll bring you a $5 frozen pizza to take home to make up for it?"
Let's see how far anybody would get with that.
Reciprocity.
A good manager would not put his employees into such a situation in the first place.
Overtime in general, and unplanned overtime in particular, can only be attributed to one (or both) of two causes:
As you can see, the two are closely related. If one has a reduced budget to work with, the proper answer is either a reduced project scope or an increased timeline.
“Good. Fast. Cheap. Pick two.”
Punishing workers for failures of management is a sure sign of an unhealthy corporate environment.
A middle manager may be squeezed from both sides, but then either it’s a failure of the middle manager to manage those below, or to manage the expectations of those above, or of those above to manage their end of things.
Of course, an exception can be made in the case of true disasters, such as fire, illness, or other catastrophe. But management’s second responsibility — after running interference during the crisis — should be getting things back to normal.
Otherwise, what on Earth is management being paid for?
Cheers,
b&
All but God can prove this sentence true.
That seems to be the gist of this article.
Slashdot "libertarians": Small government for me, big government for those I disagree with. -1, I disagree with you
Having gone through late night deployments where I have been both the deployer/dev and other occasions where I have just been the manager, I have never been in a situation where I personally was not going to be able to take charge of any random role and heave to. That said, if the random role is a minor one that takes small pressure off the fulcrum, hey, crises are no time for egos, I'll do what is needed and try and contain panic in those of my staff not used to fan shit interaction.
That said, I have most definitely been in the position where a deployment has gone to shit, and the time and effort to keep a manager who was utterly unable to provide any useful feedback or even perform minor ancillary tasks in the loop is absolute torture, if I had had a stronger sense of my use at the company at the time I would have said "the most useful thing you can do right now is fuck off and leave me to it", but as my manager was also the Head Cheese, such a comment was not going to go down well at the time.
Anyways, my 2c.
This is really more of a question about leadership than about management. The two cross over a lot, but leadership pretty much == how you influence others, while management == how you utilize your resources.
I don't see any reason for a supervisor/manager not to want to stay up late when their developers are getting asked to do the same thing. A developer is not going to be as motivated to push themselves and do good work if they see that a higher up is acting like a douche. There ARE times when it is appropriate to micro manage. Proper team building and leadership, however, should lead one away from having to do this. The main thing the manager should be doing when people start having to stay up late is make sure the team is moving overall in the right direction (macro management), and provide support to keep everyone motivated.
Where can I get a job in which I'm considered the most useful when not working, yet still get paid?!
If someone is considered more useful not working, they've immediately lost value. The three correct answers are: Yes, they should stay because they're good. No, but they get paid proportional to their utility. No, because I'm firing them.
The problem here is the manager. Their job is not to put pressure on you, their job is to organize and delegate. What is this "looking over your shoulder" shit? If that's what your manager is doing, leave that mickey mouse operation and go somewhere better.
He could just learn to be a competent project planner so that you don't wind up having to work late nights and weekends ....
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
I will never ask my team to work late or weekends without being there myself. It's not mistrust. It's that I should not ask my people to sacrifice their personal time without doing so myself.
I typically stay in my office and keep busy. My door open to answer any questions or to provide any needed support. I also make sure meals are provided. If it's a situation where we're working extra for a critical customer escalation or a deadline, I will occasionally walk about to get status. Sometimes it's important to understand if it's time to call in another functional team (CM, QA, support, etc) because their entry is soon to be met. Part of our task is to coordinate tasks. If it's a situation where we're doing this for a couple weeks to catch up on a blown schedule (usually VP dictated feature creep), then I leave the engineers be as I would during normal working hours.
If the manager demands that I fuck up my evening/sleep then that's fair enough but he also must stay. agreed he shouldn't interfere, but there's no way im staying that late if he's not also prepared to sacrifice his evening.
SURELY NOT!!!!!
Now, this is not my line of work and it never will be, but I don't think whether it be developers or another type of job, it is always beneficial to have someone a rank above you present. It doesn't matter if the manager has no ability for what his workers are doing, if he has a friendly relationship with his workers, understands that positive reinforcement(such as ordering pizza) is better than just making sure people are focused, and allows some extra freedoms since these hours are beyond the norm, then having a manager present will result in better output. I've spent many years as a supervisor and assistant manager at the restaurants I have worked at - yes, I realize these work environments are a little more casual than what is suggested in this article - and these principles have always served me well for when I and others have to work past when we would normally close up and go home.
Having the manager who can't help with the job you're doing present when things are going wrong seems to be the norm in every industry. If everything breaks down you call the manager, because they manage things, that's their job.
I've been in the situation where a manager in a crunch period really slowed the whole thing down because they were demanding explanations of every check-in. I've also had the experience of having a technical manager save the team no end of hassle by running interference and buffering us from the political realities even higher up the chain in crunch periods; in those cases the manager was technical enough to just let us get on with it.
The job of the manager is to help the developers prioritize. In an overtime situation, prioritization is all the more necessary. Only the manager can take the decisions about what to cut to meet both deadline and essential requirements. Only the manager can legitimately revise the definition of "done" to adapt to resource constraints.
Sure, if the directive is clearly "implement all of it, no excuses" then the manager isn't really needed, during the overtime nor at any other time during the project - at least not more than in the capacity of "spy" for higher ups to track implementation velocity and perhaps wielder of a whip.
But to a real manager, the question of whether they could go home during the time they would quite obviously be the most useful to the project should seem a very suspect one to ask.
I do remember one time we had our three-levels-up director in on a Saturday when we had a rush project. It was an RFP, not a programming project, it was important to get done and had a short deadline to produce hundreds of pages of accurate interesting responses to inherently dull and boring material. We put him to work photocopying and fetching pizza, and he avoided micromanaging (something he didn't always avoid :-) He probably did add a bit of value to the executive summary part, but I wasn't working on that section. It was a couple of decades ago, and since I still remember it it was probably good for morale...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
A good manager has godlike omnipotent powers to handle all externalities and all incidents and occurences of Murphy's Law etc.....
Unplanned overtime happens because sometimes, sh*t happens, even in the best run organization. The best manager is still not responsible or able to control what sales promised the customer nor what legal said were restrictions on the code, nor the schedule changes the customer asked for.
Do not taunt Happy Fun Ball
It is annoying when the CIO inquires every five minutes about how things are going, and if we are nearing resolution, offering different ways of patching the problem, each diverting from the problem at hand every single time.
Then again, it is terribly annoying when the CIO asks for something very last minute, demands that it be ready for tommorow, and then takes off, leaving everyone to work on it until 10pm.
Not sure which is more annoying. I wish there was a middle ground somewhere.
If I'm a developer and my manager asks me to work late to hit a deadline (shit happens sometimes), then bolts, I'm not very happy, especially if you *know* the situation was a managerial screw-up (as much as we'd like them to *all* be managerial screw ups, they aren't all).
If I'm a manager, and I ask my developers to work late to hit a deadline (shit happens sometimes), I ask them what they need to be the most productive. Food, beverages, me getting out of their way. One of the roles of manager is to "take one for the team" so your developers don't have to, especially if it is your screw up (admitting it is your fault goes a *long* way to gain credibility).
The stunning thing about this question (and almost every manager/employee situation) is the complete lack of the most basic level of communication. Everyone involved is a person. Treat them as such and things will be pretty much okay.
Yes, the manager should be staying late as well to handle everything that is not development. Make coffee, order pizza, shoo the cleaning staff away, even call people for the developers if desired.
If they're looking over shoulders, making people nervous pacing and repeatedly asking "are we there yet" like a 5 year old on a trip, they really should NEVER be there, that is, they shouldn't BE the manager.
A helpful manager after hours builds team cohesion and inspires the team to follow them. They prove themselves worthy of being followed.Since nobody wants to stay late because they have to, the manager who stays proves that he's not just giving the shirt off of other people's backs.
A manager who could be helpful but instead goes home sends the entirely the wrong message. He proves that he thinks himself better and that he expects to simply crack the whip from on high and have the peons grovel in response. He will easily over-promise to the team's detriment since he won't himself ever suffer for it.
All of this presumes it's really an all hands on crunch. OTOH, some developers just like to stay late for some focused work when everything is quiet. Where there is flexibility, they may do that for a few days then take a day off or they may work late and come in late where permitted during normal times. There is no need for the manager to stay in those cases. A good manager will know when that's the case.
if you have to work late, then it's because he failed as a manager (planning to short, failing to extend dev-time in advance, failing to communicate it to superiors, etc...), so of course he should stay too.
Why write "a verteran developer" instead of "Eric Spiegel, veteran developer"? I would like to click on links because I have information leading me to click on them, not because I am curious after being baited with lack of information.
Sure, occasionally it's essential that something has to be delivered the next day. In general, working longer hours doesn't reduce development times. It tires out developers and produces shoddy results.
Work to reach specific goals. You shouldn't need to stay late to show solidarity because there should be no occasions when they're all working late for extended periods.
I must have been lucky. My manager stays with developers working late out of loyalty. He tries to keep out of work's way, and when he is most bored or if it gets rediculously late he will even go and get snacks. I appreciated his presence everytime we had to do that, and when I get into his position I hope I will remember to the right thing.
Generally I'm there until midnight or 1AM ANYWAY, but most of my developers probably get the bulk of new work done between 10PM - 2AM. I think we have more code commits during the 1AM hour than any other. Sometimes they work at home, other times at the office, if the Application and Web Development people are working on something that involves the API. But typically our developers set their own hours. Just so long as the work gets done by the due date and are responsive to SMS if we have an "Oh shit" moment and they need to come in. It happens, but not often.
However, I HAVE to be at the office at 8AM and keep normal business hours for client meetings and if clients call with problems, they expect someone to be there and as it stands right now, the buck stops at my desk. Generally everyone is in the office by 11AM and if have meetings it is usually during lunchtime. Afternoons are usually spent fixing any issues that may have popped up and if the different development teams need to work together.
Then again, we're a small company, with 10 full-time developers plus six interns (4CS, 2ECE) at the moment. We have 4 + 3 Interns on Desktop & Mobile Java Application Development (Java Team), 4+1 intern Web Development Group, and 2 of us who are Database & Systems people with 2 interns working on a R&D project.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
The absolute last thing I want when I'm coding is a manager sat behind me making 'jokes'...
No sig today...
it depends on how well your team works together. I've had both good teams and bad--the bad ones are where having your boss hovering over your shoulder is a huge encumbrance. But the good times, those were great; your boss can play any number of positive roles, from getting the pizza to running interference between his subordinates and his superiors, to using his position to Get Things Done with parts supply or special access etc. So OP, if you're a good boss and your guys like having you around, then by all means you should stay. But if you sense you might be getting in the way but you still think you should stay, then go hole up in your cube--your guys will appreciate your sacrifice all that much more.
There is simply too much glass..
His mismanagement is the reason they “have” to work late is the first place!
A good manager is always the last one to go and the first one to come. Not the other way around.
I have seen enough people who owned their own company, and because it was their life, there was no point in leaving. (Ok, they should not forget their family. I have also seen where that ends. And it’s very ugly.)
So usually, if a manager is quick to go home, or stays away very often, you know that he does not really care or like it. That means, it’s time to find a new job, that will not fall into pieces as soon as that manager leaves, an the others find out that it was all smoke and mirrors.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
If it's the manager's fault, and it always is unless we're talking about developers who work night shifts
You can delude yourself into thinking a middle manager has the power to dictate deadlines if you like but in a lot of organisations that simply isn't true. The deadline is decided by those higher up based on external pressures and the desires and will of upper management. The middle manager has to try to make it work. Often it is expected by upper management that developers will stay back late to do it. The resulting timeline is a fiction and everyone's butt is on the line. If it doesn't work, there's always an outsourcing firm willing to lie about being able to deliver more quickly and efficiently (as if that were in their best interests).
These posts express my own personal views, not those of my employer
I have been on both sides of the fence, with "manager" being my current role and my take is this: If my people are sacrificing their "home" time to meet a deadline, I feel it is my duty and responsibility to be along with them. However, I don't sit and ride people and look over their shoulders. If anything, I am there for moral support and to show them that they aren't in this alone and that their efforts are appreciated. I always take care of the snacks. The crew knows I'm not just a "paper manager" and that I was in the trenches at one point as well, so the respect is there.
I have to say, though, that I had a similar manager when I was a young cub and I thought highly of that person, thus, I crafted my managerial style accordingly. It seems to be working well for me and for the team.
"The resulting timeline is a fiction and everyone's butt is on the line."
"The middle manager has to try to make it work."
Then you agree that it is the managers fault.
We could of course debate whether a manager who has no control is really a manager. In such a case they might as well get rid of the manager and hire an administrative assistant to do paperwork at a fraction of the price.
Sounds like he doesn't realize how serious the issue is unless his manager is present or his ass is on the line.
I'm a manager and a coder, and more often than not, I stay later than my developers -- as does *my* boss (who's not a coder).
It's one thing to require developers to stay later every now and then; if it's fairly self-directed the work, I don't see any need to stay with them. As other comments have noted, there is a valuable role in being around to provide direction if it's needed.
The real question though is -- do you work harder/longer than your developers the other days? If you do, then their late nights are no big deal.
If you don't then stay, buy pizza, and pray they don't quit.
A lot of posts here simplify the situation. People are staying late because of the Manager, or people staying late because of crappy code.
In my experience, people always seem to stay late when there's a deadline. It's just the way it works. Because no matter how reasonable the deadline or how awesome the code, there's always more that can be squeezed in or improved at the 11th hour.
In practice, deadlines are always unreasonable and code is often crappy (or can be improved). If we waited until things were perfect, nothing would ever go out.
So as far as the Management issue goes, do whatever it takes to make your team happy and productive. Stay late for whatever reason so long as that reason is helpful to your team. Be ready to advocate that developers be compensated for putting in extra effort.
All in all, reading through these responses, it's clear who the biggest beneficiary is. Pizza companies.
On the one hand I like to see them suffer. On the other hand I won't get antyhing done.
If only we could convince them to go somewhere else to be tortured.
As with any "what's the best way to run a team" issue, this will largely depend on the personalities involved.
Whether you stay or not, buy them dinner. Not once, but three times: Once that night, once at the end of the project, and once in the form of a dinner-for-two gift card at a nice restaurant, as a thank-you. After all, their spouses/significant others sacrificed as well.
Just make sure these dinners aren't in lieu of cash.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
My coworkers and myself often work late, but we do not "stay" late. We have laptops and a VPN connection. So if we're working into the night, it's' generally in the comfort of our own home. That said, when the team is working late, we sure as hell do expect to see our manager online (at least giving the appearance that he is "in the shit" with us).
A good manager will still be a good manager at 9pm. A bad manager not only will still be a bad manager at 9pm, but he'll feel obligated to be there.
I just got off the death march on a VERY BIG VERY SERIOUS project (hence the AC post). Here is management's contribution to the project:
1. Set the immutable date (no real reason other than a VP will get his bonus in 2010 instead of 2011)
2. Find his own piece of minutiae and force the entire team to focus on it because he is technically inept.
3. Bring in low quality, insufficient amounts of food and force us to eat at our desks.
4. Ram the project in to meet the deadline while saying things like "We'll test it in production". and "You've known about this problem for $TIME, you should have fixed it already"
5. Demand to know employees and their spouses PERSONAL cell phone numbers so the employee can be available if he needs them.
6. Leave at 4:00 every day leaving only a few hours for the team to work without his constant interruptions and harassment.
Finally force into production with the inevitable:
The system turns out to be a house of cards, the boss gets all high and mighty and begins calling the high-end bosses in other divisions demanding the other divisions workers drop what they're doing and "help" us out. The on-call staff is burned to the ground like a fireworks factory trying to hold the flimsy system together while the users become unmerciful by paging the on-call people for anything and EVERYTHING. The bosses simply turn off their phones at 4:00 and demand EVERYONE is in for a "Root Cause Analysis" at 08:00 the next day.
So Hell no, the less the bosses are around the better.
Oh and the VP WILL get the big bonus because the only metric was whether we hit the deadline on time.
This isn't a yes or no answer. If you are an ass-hole manager who is constantly checking to see how far along your coder is, then you should probably get your ass home and leave him/her free to think and work. If you are supportive, can add value - even if it's to say "hey, I'm here if you need me", grab the pizza, stock the sodas in the fridge, whatever - then you should hang. Knowing that you are there to back them up can be very helpful.
You have to know what kind of manager you are and how your team feels about you, then you can answer your own question.
If the manager is staying late to set an example or even for taskmaster duties, that's one thing (it's not a great situation, but it is what it is).
But when the manager isn't familiar with the technology the devs are using, if the manager is standing around giving bad technical advice, that's a problem no matter what time of day they do it. Either the manager needs some training, needs to spend some time getting up to speed with the help of knowledgable devs, or just needs to settle into a role where giving technical advice isn't needed. If the manager is second guessing their employees technical decisions excessively, even when they realize that they don't know what they're talking about, simply because they feel their butt's on the line so they've got to ask all the questions they can, they should consider the implications for their butt in the scenario where some of their employees get fed up and talk to their boss' boss about getting them some retraining and/or a job change.
Most employees rise up the ranks in one way or another (certification etc). You are no different in that aspect. You may have changed employer or even work for yourself.
As manager, you are obligated to manage, just as the active developers are obligated to work. That's why you get paid.
You need to make your own decision on what level of involvement you are comfortable with. That comfort zone includes your innate evaluation of your team and how productive they are with minimal supervision or using a buggy whip.
It's your call. Best practices are that you stay and monitor the work because if something goes screwy you are responsible.
Don't be apathetic. Procrastinate!
Do you need to be there when a contractor is fixing the roof, or replacing a faucet, or replacing your carburetor? Do you want to be awake when a doctor sets your broken arm?
It depends tremendously on the level of trust, and the risk of needing to consult the person who holds the authority and the purse strings. It also depends on the expertise of the manager. If the manager is the one who remembers the last time this happened in a department full of new hires, or if the manager is needed to sign off on rebooting all the servers or taking core switches offline and disabling email for an hour, it can help if the manager is onsite. People accept such orders more readily, and it's often easier to explain consequences to the manager, if they're right there.
When it's the manager's bonehead decisions that caused the disaster, however, it can help the cleanup a lot if they're not there playing the "hide the evidence" or "find alternate explanations" game. I've been faced with that one on occasion, and on one memorable occasion had to sneak a pager message to a corporate partner's CEO to get him to send the manager home and out of our hair so I could speak unsupervised with the engineers.
Good managers should be the first to arrive at work and the last to leave.
Bad managers should just never be there.
nothing made me happier than at 6 am, after an all night repair job, a manager turns up with toasted sandwiches and hot coffee. Don't get in their way but certainly handle the pizza and coffee. Maybe a good time for informal chats, without an office full of people, get some of your own work done, and at the end you do all of the locking up etc, while they go home.
There was an unknown error in the submission.
Staying late means poor project management. Time to find a new project manager.
Cory Doctorow talking about cloud computing makes as much sense as George W Bush talking about electrical engineering.
I've only really been in this situation once (non-technical manager, big deadline, his ass on the line), and I think the guy in question couldn't have handled it better.
First, he asked us for a list of things he could do to help. Then, he got us free takeout from our choice of local restaurants, a couple liters of soda, and a six-pack for when the job was done. Finally, he told us to get in touch with him if we needed anything, and he went around the corner and hung out in another office until we were done.
He had a beer with us at 1 AM and told us not to come in the next day until noon.
Good guy.
Like anything else, there's no right answer. It's not black and white.
My default is to never leave my guys alone if I can help it, and/or it makes sense. If it's a minor complexity or criticality problem, I'll just leave the guy and trust him to do his job. I try to build trust on my team - and let the developers own their stuff. I always hated being micromanaged, and I don't do it to my guys.
But if it's a high visibility problem, with significant financial or operational risk, then we're all in it together.
Depending on how the problem unfolds, I might be able to help with the debugging, or to coordinate different efforts that my guys have going on. I also find that it's my job to gather information that can help in the fixes, or in the workaround. The business/users needs to be managed, status needs to be communicated, phone calls need ot be made to get other support people on line, or grease the wheels / pre-cache work in order to help speed the implementation once the code is fixed. There's a lot to do, to keep the pressure off the team and to help them so they only have to worry about doing their job.
At the same time, if it's a long term (meaning more than a couple hours) fix, then the logical thing is to break the team into shifts. So that when the current guys are wiped out, the second team can pick up the work.
For the big problems, I find myself going onto team 2, which is usually the 'morning shift'. My thinking being that in the early morning the business and my senior management comes in and wants to know what's going on. I need to be fresh for that - and also, if the problem isn't fixed, I need to be able to speak to what went wrong, as well as help where I can with contingency, etc.
Bottom line - don't be a primadonna as a manager. Help where you can - coordinate, give ideas, be a sounding board, stop bad ideas that go down the wrong path, manage the users, buy pizza, etc. And make sure that when you do go home, make sure that the team trusts YOU. They need to know that you're leaving for good reason...not just because you want to go home.
Huh?
Because the experienced, competent team was replaced with idiots from India on H1-Bs.
People didn't fight for a 40 hour work-week so us computer geeks can stay late. The occasional deadline, sure, if time and a half is paid.
You have to understand, when changes are allowed five minutes from or after the deadline, then by definition it is impossible to be on time, no matter how great a job you've done as programmer. I don't stay late, and I don't do overtime. Period. As a result, I'm always on time (of course, I do get my part done on time). Is that counter intuitive? If you've been in the trenches, you probably understand, the problem is not technical, it's social. As such, all it requires is a little backbone on your part to solve it.
* Do yourself a favor, say no and hold onto your dignity. Any programmer who won't stand up for themselves is just asking to be a punching bag, and those sort of relationships turn the manager into something worse.
* It's just last minute nerves, they'll get over it. The change wasn't important anyway. No, it really wasn't.
* You won't get in trouble for not "taking one for the team". Deep down, the guy asking for the change knows the reason for being late is his fault. If it was a genuine problem, he was either unprepared or didn't think things through thoroughly. Anyone looking into it will see that it's his fault, and after all, it's his butt on the line. At this point, cognitive dissonance will kick in, and they'll either decide the problem wasn't so bad, or it's OK to be a little late.
* You won't get rewarded for "taking one for the team".
At my first job we had a project that required overtime. We had two managers. One was an ex coder, who taught himself the basics of the then novel language we were working in (Java). He help with deployment and his database skills were as good as ever. The other one was of the kind that you can manage anything by just dealing with the processes. One stuck with the team until there was a stable build, helping with database issues, deployments and helping make thorny decisions based on arguments. The other was out at 1700 because he had to pick up his girlfriend from horse riding. Now 12 years later, I found that the latter seems to be the norm, worrying over generally trivial processes and their usefulness defined by how well they can keep upper management away from production. A project's success generally won't be determined by their contributions (a project's failure is another story). The former I remember as the best manager I've had up to date, leading by example without using useless one-liners that apply to only others not himself, capable of communicating (and getting) our needs to the upper levels and sticking with the team. To me a manager that sticks around with the team and manages to make himself useful is a valuable asset. A manager that sticks around and provides nothing but a sign - off is replaceable by any from the large pool of line managers.
Make the manager stay on - it stops frivolous requests for extra or unscheduled or "seemed like a good idea" work when the person requesting ot requiring it has to share the pain. If they have to give up their evening, or weekend or holiday they are much less likely to ask others to - unless there is a good reason for it. Hell, why stop at the immediate line manager. If it's important enough for me to lose my personal time I want a LOT of senior people to appreciate the sacrifice I'm making. What brings it home more than if they have to make the same sacrifices too?
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
It's amazing how many of you will sell out your free time for a little pizza and soda.
Why is everybody here in slashdot expecting pizza? Whenever I worked overtime, the manager would either get us Subway or Chipotle. Pizza may be very cheap and easy to order; but, if your manager is willing to go the extra mile and take each persons' individual order; then it is so much better! Most managers can't do too much in an overtime night so they tend not to mind getting each person's order.
After reading the article, I'd have to say he should just go home.
You give your best programmer the task to help a customer and he agrees. Then go home and don't bug him 5+ times a day/night about the job and the progress even though you can't help him.
I'd rather get a bigger bonus rather than pizza and a couple compliments the next day.
I rarely work over time as the net benefit over a long time isn't worth it. You get burnt out, can't use the comp time and start producing shittier work as time goes by.
We have a saying at my work: "Lead, don't manage." It does wonders for morale and productivity.
possibly more an architect role. I write my ramblings and ideas in a document and some poor sap has to try and shape that into functioning code.
I used to be on the other end of this and there was NOTHING more miserable than sitting in an office, slaving away to get something functioning - and then hitting a logical block, where the person with the answer was sat at home eating their dinner.
Personally if my team is now working on something, I'd like to think I'd be the last one to leave the office. It's not a martyr act, or wanting to micro-manage - it's just I'm in notionally responsible for this piece of work. If we're sitting there late, then I've screwed up. I'll get coffee, pizza, whatever they want. If there's any work I'm capable of doing, I'll be doing it. If not I'll just be doing everything I can to help (and yes that means leaving them alone and just being there if there's a question).
Possibly something that's been overlooked is that there needs to be somebody there to decide when it's too late, everybody needs to go home and get some sleep - and is prepared to explain and take responsibility to 'above' why the task wasn't completed that night.
I'm not sure if it's ever recognized as an occasionally required role, but sometimes somebody just needs to stop the shit being hurled at the people on the coal-face.
Your point is very valid, but it does not take away the fact that in real life the grandparent poster is way too often right. In many/most companies, a middle manager's job is exactly what he describes: make the impossible happen with not enough people and/or resources and without real formal authority to change those things. Yes this is stupid. So are most big companies.
Linux user since early January 1992.
My PHB is just that - she started out in Admin. and worked her way up to managing a team of software developers. She hasn't a clue about software development. Not quite, "I think that mauve has the most RAM" but not far off.
A few weeks ago she put a great deal of pressure (stupid deadline) of one of our senior developers. I got diverted from my task do doing a code review and running my new automated regression test suite to help him meet his deadline. Our other senior developer dropped his task and helped out with some testing too. (I'm not senior, just one of the regular guys).
Our PHB left at about 19:00 as usual and two of us we left. The code review took 4 to 5 hours. As usual the PHB had no idea that this was 2500 lines of code touching many modules in C and C++. This is embedded real time stuff that runs on two platforms.
We actually got finished at 19:30. The poor guy was under such pressure to get his stuff delivered (i.e. to cut all possible corners) that he broke the unit tests in the nightly build.
A week later, we were pleasantly surprised when we all received an official letter from our PHB cc'd to more senior PHBs about what a great job we'd done! They all emailed us personally to thank us.
Anyway, the poor guy got humiliated by the PHB in front of everyone for breaking the build and a couple of weeks later I got the telling off of my life from our dear PHB for wasting time! "Your time is not your own! Your time is not your own while you're here! There are people who pay us..." This lasted half an our!
I'm not the one who spends 3 hours a day surfing the internet.
My crime? Doing unit tests, refactoring my code and doing code reviews. Oh, and helping people for 10 minutes when they are stuck.
Stick Men
I'm a "development team lead" which, as you all no doubt know, translates to "a working developer who also had manager duties, but gets no more pay for those manager duties."
So I'm very technical, i know how most of the system works, I really can be of help.
But I don't know how, for example, to do the full two-day build. (Yes, two days. The end product is a disk that installs everything, including Windows, on a naked box.)
So I'm always torn when the guy who does most of the builds is stuck there late. Do I leave, or do I stay?
Sometimes I stay, but I do MY work, and leave him the heck alone, because he can see me from his desk, so if he needs me, he can just call my name out.
And sometimes I go, but I always ask if he needs anything, and I always ask if he wants me to stay.
One time, I stayed and sent him home, because he was to a point where I knew how to finish, and he looked like he was going to pass out.
I have no idea what the right answer is.I don't think there really is one.
The preferred solution is to not have a problem.
At my first real job, there was a manager who never left work during deadlines until the last developer did. For him, it was a point of honor. He really meant it as - if you're busting your ass for the company, he shouldn't be home watching tube. Other than that, he was a waste of skin, water and oxygen.
Years later, I was a boss. I didn't stay late unless I actually had something to do - which was most days. 70+ hour work weeks were common. My job was to:
- Help set realistic schedules that could be met without killing ourselves
- Run interference from upper management
- Get the highest raises possible for my team
- Get promotions for my team
- Take all blame for any failures in our work
- Pass on credit to the team and individuals
Behaving like this leads to teams who work well together and look out for each other. Any of my former teams will help me whenever they can too. My managers hated that I wouldn't give up "who" cause every issue, but that wasn't needed. Inside the team, it never needed to be said, everyone knew who did.
I absolutely want managers to be there too!
Generally the off-shift stuff is their idea/fault/decision in the first place, so if I'm in it they need to lead by example and be there too. Whether it's overtime in the evenings or weekend work, I expect the ones responsible to be there too.
Sic gorgiamus allos subjectatos nunc
Yes, he should, but instead of "herding" perfectly adult people, he should spend his time making sure their time is spent as productive as possible. Or in other words: Do what managers are there for, before they became all overblown ego-trippers. Make sure there are no disturbances, give encouraging feedback if someone hands something in, order pizza or sort out the paperwork - whatever keeps them productive and happy.
Do not/b, under any circumstances, look over their shoulders or "herd" them.
Assorted stuff I do sometimes: Lemuria.org
I've been working in IT since I was a teenager, and I'm currently in the second term of my return to college. I have a BS in comp. sci. and I'm undecided at the moment as to what my end goal is this time around. I've been considering aiming for management in my field, and this thread has truly given me some direction, and some real things to hold true to if I ever achieve the status of "manager." Thanks to all for the great discussion.
YES! If you are in charge, you STAY!!! The man in charge, no matter how little he does, is still in charge. He should be the last one to leave!!! I don't care if you're in the military, or a programmer, or on Wall Street, or if you even run a cleaning crew, you're in charge so you have to stay.
If you leave you only reveal how NOT in charge you really are!
If it is the case, then the manager has to make that clear to the developers at the beginning of the project. Having a manager that pretends that the project is doable is worse than not having one at all.
We all know what to do, but we don't know how to get re-elected once we have done it
Yup, manager should stay. If they don't it only breeds resentment among staff. Though they should stay out of the way. Coffee, pizza delivery, write documentation that you can, budget work... keeping higher ups and biz partners from bugging developers directly. Just stay out of the way and try to make things as efficient as possibly by handling all the non-developer things you can. Best managers are the ones who follow that advice. Keep busy, assist in every way possible to let developers do nothing else but code, and otherwise just stay out of the way. Nothing breeds hate other than to hand off a bunch of work and run off... just looks like your lazy and clueless as to what's going on. At the very least play flash games in your office and pretend to work. Ideally help with non-code work.
Apart from agreeing with other replies about supporting the team and staying our of their way, the manager should also be pondering how they got to this mess in the first place. Having to work late is a screw-up, somewhere. Sometimes its because of things outside of the team's control but most of the time it isn't. If it happens regularly then there is definitely a systemic problem with the process that needs to be sorted out.
No, we want to play Counter-Strike in peace.
No, the manager should go away. It'll be done when it's done, and it'll do what he wanted when he wanted if that's possible.
If the manager is an exceptionally competent programmer, and has an excellent rapport with the programmer, then he can maybe stay and pair program. Personally I don't like pair programming, but I know others that do. Certainly not everyone is a match for this though. There are a lot of people whom I couldn't get along with pair programming.
This is not an answer you can get from /. Nor should you be trying to get it here. That you are asking it of /. says much, indeed. In the end, every situation requiring after hours development is different. Sometimes having the manager around is more useful. Sometimes NOT having the manager around is more useful. Somewhere along the line, MBAs the world over convinced everyone that there was a logical decoupling of the understanding requiring for managing a business and the understanding of the business being managed. This, inevitably, means that more often than not, it is the staff who know more about what needs to be done than does the manager. The good IT managers have realized this and understand that their role is now more one of strategic thinking based on team recommendation mixed with supporting and enabling their team with resources and authority than one of hands-on involvement or mentoring in the execution of any of the underlying details. This, in turn, means that for every scenario the team has to work after hours, the manager's job is to ask 2 questions: First, ask the team, "Is there anything I can do to help or can you foresee any challenges I might be able to remove?" Second, if they say no, then ask yourself, "If I'm going home, is there anything I can do to show my team some small measure of my and the company's appreciation that they're not?"
Down with the career politician! SUPPORT TERM LIMITS
In this country, our work-week is 40 hours. Our ancestors fought hard and made great sacrifices to win this right and pass it down to us, and I'll be damned if I'll see it steadily erode. Routine unpaid overtime is harmful not only to ourselves individually, but to the entire social contract we've managed to hammer out between capital and labor.
Respect yourself. Do not work more than 40 hours without getting the same time and a half premium someone in any other field would earn. If a project is late, that's not your fault. It's management's, and management ought to pay for the mistake.
Ah! So you can replace your manager with a chatbot script. Sweet!
When our name is on the back of your car, we're behind you all the way!
I'm not even vaguely in general direction of development. Nevertheless...
I get paid overtime pay at a fairly decent rate, for even as little as fifteen minutes extra. My supervisor and manager, however, do not. One of my colleagues was whining to me that the manager never stays on overtime but instead asks the rest of us to do so. To me, it seems an obvious choice: he doesn't get paid or get time in lieu, usually, so why should he stay when one of us can get paid extra to do so instead? My colleague for some reason wouldn't accept this, and I couldn't understand his reasoning.
For several years at performance reviews, I have tacked on the request "it would be great if the employer really worked on improving staff support networks, which would in turn leave people like me free to do what we are paid to do, and do it in a more timely manner.
I may as well of said nothing.
A couple months back a person resigned from another biz and she was talented but also an absolute stunner(drop dead gorgeous) and my manager wanted her in our organisation.
Her reply was a short but polite "No thanks, I really am looking for a place with strong support networks.". It was a real blow to him, and a wake up call. Now our managers "support", not "oversee". It has worked well, and we seldom pull late shifts now, as the jobs done.
In post Patriot Act America, the library books scan you.
In my opinion, the manager must tell the developers to return to their home, and take a good night sleep.
A few years ago (when I worked as a game programmer), it was common to do some all-nighters, since everybody was doing it.
There were some problems, though:
- the code tends to be crappier, since we are tired
- jetlag: if you are alone, this is not a problem, but it's difficult to live as a couple
- burnout: you'll pay your night of work
- you can be very productive the first night, but not for an extended period
Also, when the project finishes, all the tensions disappears, and everybody is completely demotivated, resulting in their resignation in 30% of the cases.
It's not reasonable to work like a crazy when you approach the deadline.
Now, I much prefer the agile approach:
instead of trying to put all you want in the product, just try to put what can fit within the given amount of time.
There are some interesting techniques that you may apply:
- YAGNI: http://en.wikipedia.org/wiki/You_ain't_gonna_need_it instead of implementing a ton of things, implement the simplest set of what is needed
- BDD: http://en.wikipedia.org/wiki/Behavior_Driven_Development instead of coding without a goal (except to finish the product), ask your manager to write executable specifications. This includes also to concentrate on finishing the features one after another (and not keeping them half-finished, due to lack of time).
And the most important thing:
if you cannot add a feature in your program, because you lack of time, DON'T ADD IT !
I hadn't coded in years and never in the language he had to work with.
If as a software development manager you do not have the ability to do the work of those you directly manage, then you shouldn't be managing them. This inability is not tolerated in other engineering disciplines and it shouldn't be tolerated in software engineering either.
Note to trolls:
Brew fresh coffee. Take care of the food orders (and maybe go for special pick-up as a treat). Make sure anything that hinders their smooth progress is handled by you. Noise? Go deal with it. Something not where it should be and makes their life harder? Chase it like a rabbid dog and solve it. The best way to ensure their success (and thus cover your ass, if that's your persuasion) is to, precisely, do whatever you can to remove the obstacles to that success.
But heed the warning: if you're staying just so you can keep an eye on them, you're making a huge mistake. If you don't trust them in overtime, then you have no reason to trust them in normal work hours, and your problem is something much bigger and uglier.
Its quite common, in the corporate world, to find oneself thrown into the fire, and being forced to put it out. But 99 out of 100 times, its management who started the fire, and threw you in it, and this is one of the major reasons that I dropped out of the corporate world.
Lets look at the common scenario. Big project. Big client. Everythings super important, even tho last weeks project was just as super important, for just as big a client. Management promised the world in 2 days, to a client that needs the project whether it takes 2 days or 3 days or 4 weeks, they still need the job done. Its only because management and sales are telling people ANYTHING to make the deal, do these fires start, and the developers are asked to work overtime, stay late, miss their kids birthday party, not have sex with their wife, who runs off and cheats with the pool boy, etc. in a futile attempt to make up for the fact that management HAS NO STANDARDIZED PROCESS FOR MAKING TIMELINE PROJECTIONS.
So, I say, tell management to finish it. Tell management to make sales finish it.
Stop being the fall guy for sales and managements sunshine packing bullshit process.
If you continueally "go the extra mile" ... they will continually make promises that require you to go 2 extra miles.
Stay late, but leave the developers alone. Sit in your office and try to think what YOU did wrong that your developers have to work late. Did you fail at scheduling? Did you fail to convince your bosses how long the work would take?
As someone who straddles the fence between being a developer and being a manager (I'm upper management, but at a small business that means I still occasionally get involved in the coding) on the rare occasions that we have to ask the developers to stay late to fix something, get something out the door, etc. I'm almost always staying late with them.
When the manager can provide useful input (either by helping get the code written, testing, communicating status with the customer, etc.) their presence helps achieve the goal and helps keep morale up. Even when the manager can't provide useful input, their presence (in their office, not interfering) still helps keep up morale, and lets the developers know their efforts ARE noticed and appreciated.
I say let the managers stay late with the developers - but keep out of the developers' way.
Honestly, I don't care about that. I would much rather have a boss with a backbone who prevents unnecessary late night requests then one who is micro-managing me during one. Most bosses I've had fall into two categories: self-confident, competent people who don't agree to crazy requests from other teams and their managers and who generally leave me alone - and - incompetent managers who worry about their position and who agree to impossible demands and who get nervous and pissy whenever something goes wrong and who are always micro-managing. Being one or the other is what keeps me there or looking for a job elsewhere. If I have to stay two hours extra to finish something, I prefer my boss leaving, its sort of like "I have faith and confidence you can handle this, call me if there's a problem". On the other hand, if I or the team has to come in at 3 AM Saturday morning for some reason and the manager comes in just to show moral support that an inconvenience for us will be one that he will bear as well, that can be a nice thing - you know he's not going to have you working hours he won't work himself. But as I said, being competent, self-confident and having a backbone with other business units and with his own management is what I want more than working late with me. I'd rather him making sure I don't have to work late to deal with some other groups problems or lack of planning or whatever.
Ever hear of the expression "lack of planning on your part does not constitute an emergency on my part"? The product planners at the last company I worked for would take their sweet time deciding what the next big product would be and then would want it yesterday. They literally gave the engineering staff LESS time to develop the product than they took to come up with the details for. And guess who DIDN'T put in any overtime doing their job and who did.
There is another expression, if you want it badly enough that's how good the product will be (IE: it will be BAD!). I'll gladly put in the extra hours to go the last mile, but if you schedule the ENTIRE project based on overtime, there won't be ANY time left to get that last mile in time.
Of course they should say late. If there is any question about that, then you have Bill Lumbergh as your manager and NO he shouldn't.
I don't even know what to say.... of course not..... why should the manager stay late....... ?????
maybe in some extreme circumstances or total lack of control for the programmers... if they just play $MMORPG then maybe you have deeper problems then working late....
jeeeze
i'm flabbergasted
Exception Duck - may or may not contain chicken.
Unless the manager is a developer on a different project, I think making a developer a manager is a bad idea. First, it makes performance reviews very difficult. All developers make mistakes, including the managing developer, and the manager has to work extra hard to stay above the fray. In addition to management responsibility, trying to be the model developer as well puts tremendous strain on a single individual, and it would be hard to find anyone who would last long and be effective in that position. Furthermore, a manager who does end up making significant mistakes as a developer might find himself devoid of credibility, which compromises his/her effectiveness as a manager.
Also, things get super hairy when the manager is responsible for compensation increases and bonuses.
The only way this could work is if performance reviews are based strictly on raw data (eg. #bugs fixed, #lines of code, etc) but we all know these kinds of metrics rarely tell the correct story of a developer.
I do think engineering management should understand the code and architecture, however. But this should be done through instituting regular code and arch reviews, good documentation, good source code management, etc.
The the large (two letter) defense contractor i work for the managers "ask" for you to stay, but then claim the "entire" project is on the line if you dont... then when i work all night to get it done... i get crapped on.
Project managers could care less. They've obviously spent too much time in the navy or something... because i'm not captured $2 hour labor like some seaman...
The place is a nightmare in general, everyone is a tough guy, everyone is stupid but them... they yell and scream at people, and treat them like idiots...
Yea... first chance to leap im gone.
Seriously - go read this book, and then get back to us.
Weaselmancer
rediculous.
If the development team routinely needs to stay late to finish standard work; it's management's fault (either committing the team to an unrealistic schedule or not building a competent team): management better damn well screw themselves too.
Lot of "always do this" type responses here. For me this is pretty situational. Often I stay behind and bring dinner and beer. I do usually try to be there for most of the time, but not always. For me there are a variety of possibilities, and I use one or several, or occasionally none, depending on a lot of things. Some examples:
* making sure time in lieu is available, and cutting through red tape around it
* showing flexibility around working conditions, leave requests, etc
* making sure that people get recognition for special effort
* remembering _specific_ examples and making sure they form part of reviews and remuneration and bonus decisions
* making it clear that career progression is not a random event
* making sure that the most committed get the most interesting and challenging technical work
* making it clear that I will carry !00% of the blame on (reasonable) fuck ups for the guys who put in the work for the team
* creating a good team culture, I was a developer and I always worked harder to make sure we were on track as a team and I wasn't holding up someone else than I did for a PHB
Interesting. I've never heard the converse question... "When the manager comes in early, should the developers come in early?" But that's another topic...
The real question is "why would the manager stay?" Here are some possible -- one or more -- reasons:
1) Because the manager does not trust that the job will get done... "trust but verify".
2) Because the manager feels like it will gain him/her credibility with the team.
3) Because the manager feels guilty and wants to share in the pain.
4) Because the manager feels like it will give the bosses peace of mind during hard times.
I can't think of any other reasons. But it is important to say that usually, if a manager wants to stick around, it is for noble reasons.
My advice to developers, is that if reasons #2, #3, or #4 are any of the motivations for their boss to stick around... cut them a break. Even if #1 is also a reason.
In my opinion, I believe this is a good quality any boss should possess.
I used to work in an IT service company with a group of engineers. Every morning, Senior Engineer (my boss) briefs and delegate tasks. Then he visits every work site and check whether we have issues and our well-being. If it is a grave yard-shift, at least he will spend the first hour with us. If he is not around, he will take calls at any time and give any support he could. Essentially what he does is, kick start the work and empower us to finish it.
What I feel is, if someone is breaking sweat for me, it is my duty to support them. At least stay connected through IM, email or mobile. After all, without co-workers, we are nothing!
Apart from the tea lady role, the other good thing about having management around is that when the shit is hitting the fan, at some point you are often going to need to do some rather unconventional and similarly scary things to fix it.
Having the manager a "Hey boss" yell away means you can at least get "approval" for whatever it is straight away. Now the plebs can't be scapegoated or blamed for solving it by doing something against policy. Granted, it would be nice if that wasn't needed, but the fact you CAN get approval for crazy things quickly means the people fixing the problem are less likely to hesitate due to fear for their own skin.
I stayed back to support my crew and when _my_ boss found out, he chewed me out, then sacked me shortly after. I think it was because _his_ boss (CEO) came through the next day and wondered why he wasn't also working the midnight oil, therefore making me look a little _too_ good in the CEO's eyes (he made an example of me in front of the higher managers on how to properly perform as a team, wish he hadn't).
Worst company I've worked for.
I understand there are times when you need to stay late and finish something. However, it sounds like this is a recurring pattern. Try to decrease the number of times you end up in this situation rather than improving upon, and promoting, your company's last-minute-culture.
If the manager's first job is to facilitate the work of her programmers, then, yes, she should stay if it makes a contribution.
speaking as an ex-dev, now IT director, I do stay - but I have specific rules about it. I dont like my devs to work unnecessarily long hours so I have a blanket ban on anyone in my teams (about 40) working later than 7pm at night and do from time to time return to the office at around 8pm to check - and if I find anyone i send 'em home. If on the other hand we have a major deadline to hit, then a) we make a group decision as to who has to stay and b) all managers of the affected teams stay. Bottom line is we are all in it together. What I dont do is baby sit anyone . I cant code anymore, but I can act as a tester and I can still offer an objective design or issue sounding board - failing that I always have enough work to be getting on with not to be in their hair and I always make sure there is enough pizza
"Shared hardship creates intimacy" ;-P
I have heard many times how people feel obliged to be in the office earlier because their boss is earlier, and leave late, because the boss leaves late.
Both the boss and the underlings are puerile: the boss should not be putting pressure on its reports this way, the people working for the boss should leave once their shift is finished: the boss has no way to give you your time back, so why are people giving it away for free?
IANAL but write like a drunk one.
.... that the team has to be sitting in the same place at the same time?
Don't you have a clear delineation of your responsibilities and the tasks that you need to accomplish?
Don't you have a clear delineation of how you will be compensated for your work out of hours?
If you have both of the above, why do you need your boss around?
Do you need moral support? Cant you gather enough of that while you are planning your work or during the emergency planning for the work you are now doing?
Honestly, I see no reason for this "Titanic" approach to working culture.
IANAL but write like a drunk one.
All this nonsensical management style comes from the US, where lots of people have seen this in play in the US Army, one of the biggest employers in the US.
Well, you are wrong, it is just a job, doing draconian shifts is not helping, is bullying your reports into putting unsocial hours when the real solution should be to have more resources.
The most productive companies I have seen (Asia, Mexico, UK, Germany) worked 9-5 and the boss was chasing people out of the door at 16:55.
IANAL but write like a drunk one.
If the employee is compensated properly and knows what the objectives are, there is no reason to be angry at a boss leaving on time.
A boss's job is not cheerleading, it is to provide leadership, and leadership is provided by setting clear targets, providing resources and ensure you are compensated properly for your efforts.
A manager that sits with you all your working hours but then proceeds to give you bad marks (thus lowering bonuses), fails to ensure you are compensated for working long hours, and puts hazzy objectives in front of you, is not any good.
Give me a manger that leads and that leaves at 17:00 please.
IANAL but write like a drunk one.
The US is perhaps the only OECD country with provisions *not to pay* people for work they have provided.
The US also does not celebrate the 1st of May, which says it all really regarding workers' rights.
IANAL but write like a drunk one.
I have read several comments, and it seems Slashdoters in the US are very fond of this practice of working for free.
Not only that, but they seem to believe that working for free is so much better if you force your boss to partake in the misery. Most endearingly bosses seem to believe that being miserable with your people for doing work, that you should not be doing in the first place, will enhance morale, in the same way the morale of the Titanic's crew was enhanced by the valiant captain staying to drown in the ill fated ship.
Another interesting tidbit that has emerged in the thread is several star-stripped Slashdoters referring to experiences in their Armed Forces as a good example to follow when dealing with a corporate civilian environment.
In the immortal words of my dad, a fearless Presidential Guard if you must know, "the military teaches you shit about real life because the military is not real life, unless you think your wife is General $YOUR_FAVOURITE_GENERAL"
So no, the manager should not stay, because arguably a good manager has planned unsocial hours work and you knew that and will be compensated properly.
Also in a properly run company, you will know the roles and responsibilities of most people, your manager included, and even if you don't, you should work under the assumption that every person is responsible and allocate their time in a matter that better serves the company's aims, as you surely do as well.
So if a manager leaves while you are working, perhaps it is because he has to be early next day, is taking lots of work home, or is going to watch a shitty movie like Avatar 3D, but since this is none of your business I fail to see why you should care at all instead of getting your work done.
IANAL but write like a drunk one.
I agree completely. Back in my younger, whinier, more idealistic days where I thought maybe you could make the world fair, I had more than one middle manager tell me (paraphrased, but nearly exact wording) "Yep, it's bullshit. But if you don't do it, my boss is going to tell me to fire you. If I don't do that, my boss is going to fire me and then fire you anyway."
Over the years I've learned that it's better for everyone to just get the job done. If it's the same person making the same mistaking (or just not caring about anyone else's time as long as they get what they want) on a regular basis, then it may be time to bring it up. If it's the occasional honest mistake or even the occasional uncaring asshole, it usually makes everyone's life easier to just do what you know is going to have to be done in the end so that you can get back to business as usual asap.
I have been managing developments teams for 10 years and I follow these simple rules:
1. I act as grease in the wheel so my team keeps working without interruptions or BS
2. I shield them from all the BS, meetings, business decisions, etc so they focus on what they are getting paid for, development
3. I care more about my team then the project. It is common for me to give the whole team off a day here and there without counting it. I have delayed projects by few days to help alleviate the pressure on the guys
The way I see it is that I work for the team not the other way around
For morale - yes. For food - yes. For support - yes. If the purpose is to lord you power over the workers, flinging implied threats -- take you stinkin' butt home. If you can't trust your developers, fire them. Otherwise let them do their jobs.
I manage developers and they can count on me to be here if they're here (and when they're not). But I'm also *not* a useless lackey. I'm a developer myself and I'm here because I add something to the process. In addition to going to get the food (which I always do), I can actually participate in the process of making decisions and solving problems.
In my opinion, if you can't do that, you shouldn't be in the position. And you certainly shouldn't be looking over anybody's shoulder if you're not needed. Give them the space. Surely you have some of your own work you can do while you wait.
But yes, be there -- unless you can't be there without getting in the way, in which case you should leave.
As a manager who is not qualified in the development language and tools my team uses I feel impotent. That should not translate to me being a busy-body and hovering over my team-members. I think it's much more empowering to let my team know I trust them and respect their ability. Let your people know you have the utmost respect for their skills. They'll do everything possible to meet your expectations. They usually are much harder on themselves than you would ever be.
This is also the same as when they ask a developer to stay and work overtime and work through supposed vacation time (gov. declared vacations) to catch up on a project falling behind, is it fair that the team lead not work as well to catch up on what they can do for the project?
If the team lead is responsible for the oversee of the project is needs to be present during most of the man hours put in for decision making, should he not also be available when he asks his employees to work those extra hours, seems only fair.
Wow, that would have been awesome if my boss came in during one big project I was working on where I was working 15 hour days during the week, 15-20 hour days during the weekends for about one month straight.
I got no overtime, no free lunch from my boss. I got a paycheck for being salary, but that was it.
I am actually in the lower 10th percentile for what a programmer analyst should get paid, but since I am still new in the industry, I want to build work experience, so I am staying here until I hit at least 2 years experience.
Well, my boss did note that I push hard to hit our goals on my 1 year review of my work, but that is what I got and that was about it.
One thing I have noticed about this industry is something that I was informed about, but did not experience it until this current job, where I will have those months where I am working everyday for a minimum of 15 hours a day, and then I will hit a week or two where I have to drag something small out because I know there is nothing to do besides a small item for the next 2 weeks.
The world is how you make it
doesn't bother me... with one exception. You are doing the implementation, something that would take 5 minutes to fix pops up, and it gets rolled back because of it. What they don't know won't hurt them and if it ends up taking longer, rollback is still an option so you lose nothing by working out the implementation kink. There's always at least one with a complex application and making me come in on a weekend, AGAIN because of a 5 minute problem really irks me. Shit happens, let me deal with it and get it done, especially when the rollback takes longer than the hot fix would.
Don't kid yourself. It's the size of the regexp AND how you use it that counts.
Rather than someone willing to come in and support you when you work overtime, how about having a boss and management above that ensure you don't HAVE to work overtime.
We had a project where due to being screwed on the contract, we had a hard deadline combined with the usual flexible requirements (NBD if you charge time&materials--if they want to eff around with the details they just have to pay, but either their contract overseer was completely incompetent or they were looking for a way out of paying (or both))...we ended up pulling in everyone else in the company off their own projects for a 2-week catchup. Everything was carefully spec'd, all the interfaces defined, all the developers seasoned. WORKED LIKE A CHARM. One or two of us tied up the loose ends, it all compiled and worked, and voila! B******* had to pay up for the 6 months they contracted for. (If not the total expenditure, but we needed to win this one.)
That being said, it has to be exactly the right set up: everything defined, everyone ace, everyone committed.
I still miss that job. (But not that contract.)
First off, if the developers are always having to stay late, the manager isn't doing his/her job. Now, if they are running behind schedule, it's the managers job to bring that schedule into focus with the stake holders. Good plans usually get trashed because the managers allow stake holders to change the plan mid stream and forget to actually adjust the schedule accordingly.
If the manager feels a need to stay late with the develoeprs, this can be a good thing. Bringing the pizza in is a morale builder. Cranking the tunes up is a morale builder. Stopping them occasionally just to bs with a few of them swapping stories is a morale. Now, treating them like a normal employee during a normal shift after hours, that's a morale killer. Asking them to keep it down after hours is a morale killer. staying late and not interacting is the same as not being there, a morale killer.
If you are making your people stay late regularly, you might want to as well, but make yourself useful, don't criticise, and basically you need to be there b i t c h (hey, no offense made here, you're staying late for them, make it worth it).
So, balance the equation. Do you need to be there and if so, can you make a difference to help them?
As a coder, my managers were sometimes incapable or tying their shoes, thus stay away from me. As a former technologies manager for a larger top 5 bank, I had to have my people stay late on several days. I generally would only stay around if they needed me, but occasionally I would stay around so they would not that we are all taking one for the team.
If your developers are staying late, you already failed as a manager. Stay if you want, but don't bother them any more than you already have.
And hopefully if it's a burden to the Manager, he'll work to ensure it doesn't happen often.
...or to be available to answer questions, or try out a new UI screen or feature and give feedback, or to act as a sounding board (if the manager is competent to do that), etc. but DON'T HOVER .
Downmodding is the refuge of the weak. Don't downmod, make a better argument!
Seriously. The insanity of working late to meet some artificial, wholly-arbitrary deadline has to stop.
Unless people *actually* die if you miss your deadline -- i.e., unless you work for the CIA or maybe work directly with patients in a hospital -- go home. Your wife, kids, dog, and personal mental health will sincerely thank you.
Your boss likely won't do that, and even if he does, he won't compensate you for your extra time. Unless you believe in communism, stop working for free.
And yes, I am completely serious...
Is Capitalism Good for the Poor?
If she's hot and puts out, she should absolutely hang out and provide stress reducing "management activities" during after-hours sessions.
Otherwise, he'she should just buy you a hooker who gives massages and leave you to your work... =).
I believe Patton had a similar approach. He would set the objectives and let his commanders handle the details. If there were problems holding things up, he would personally survey the situation and make suggestions.
There is a book titled "Patton on Leadership" that gives a lot of examples of his management style.
I worked for one company where the boss stated that working overtime to get something done was counter productive. The longer you worked, the more mistakes you made and the less productive you were in the long run.
I once had a supervisor(now unemployed because he's incompetent) who did nothing but annoy everyone in the office. My strategy to get him out of my office was to make it more unpleasant for him to talk to me than vice versa. It really wasn't hard with this guy either. Simply by being precise in communicating my thoughts, and calling him out on his lack of precision ultimately drove him crazy.