Slashdot Mirror
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.
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.
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.
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
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
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.
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
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.
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.
This is highly unlikely in typical development, the reason is that schedules are based on a web of falsehoods. Not lies, just things that everyone should know are false but pretend are true.
Project scope usually ends up being a falsehood, the scope changes and everyone pretends it has not and the schedule for the previous scope can still be hit. Which leads to late nights and these are typically not the fault of direct management but hte whole management structure.
Time to complete the project is usually a falsehood because estimates are made which by definition are wrong, and the schedule is set as if those estimates are fact. Is this the fault of the direct manager or the whole organization.
All of which lead to attempts to over-estimate which are bad because most of the time the project fills the time available, which means they cost more than they should.
I am sure a lot of us can think of many other things in project management that are treated as fact when in reality they are false.
My favorite was when my manager would ask "on a scale of 0-100%, where are we on (x)?" One of my coworkers working on the installation scripting got fed up with it and answered:
"It's at 0% because it doesn't fucking work. It will remain at 0% until I work all the bugs out of it. When I get that last bug fixed, it'll magically jump to 100%. Let me be so I can finish it!"
If a job's not worth doing, it's not worth doing right.
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.
That is not going to work. Really, that is not going to work. I've got more than a decade of professional development experience, approx. half of that doing agile development. Developer, scrum master, project manager (PMP certified) - been there, done that, still doing it. Agile is not a magic wand which solves all problems.
Agile's forte is adjusting scope in a flexible way - to allow continuous input on priorities and features, to decrease cost of change, and to avoid schedule surprises by only scheduling well defined parts (if you don't know what you'll be doing, you schedule a timeboxed investigation instead). One good scenario is product development - you have a pile of potential features, and a rough release schedule. Another good fit is a scenario where the team is working directly with the customer, and the customer gets to select what gets done and changed (adjust scope) within the schedule.
In your scenario, scope and schedule are set. Several staples of agile methodologies may come in very useful, like quick daily status meetings, continuous integration etc... but you aren't doing agile development. You need to do the project the traditional way - break down the deliverables, estimate, schedule, do risk management and see if this is at all realistic. PERT is probably a better fit for your situtation.
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.
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.
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.
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 !