[happychappy]

As a manager: If your code blows up in production on a Saturday afternoon, and you don't answer email/skype/phone, you've effectively left me in the shit. I know thats my job, and I will deal with it and survive, but your future work is going to be very heavily scrutinized - borderline micromanaged - until I trust you again

But the flipside, if your code blows up in production on a Saturday, and you spend four hours of a weekend fixing it, I'll say take 6 hours off during the week to compensate. I'd say take a day off, but our HR system will complain.

Aside from that, I expect 40 hours of "quality" braintime from you, and I don't really care where or when those hours occur, as long as you're collaborating with the team when they need you.

[grecy]

> As a manager: If your code blows up in production on a Saturday afternoon, and you don't answer email/skype/phone, you've effectively left me in the shit.

As an IT employee if you are running mission critical software and (as Manager) don't have an after hours call-out rotation and procedures, then you're not doing a very good job, and I'll be looking for another place of employment.

[happychappy]

The wonders of missing context :)

Its not mission critical or life-threatening. I know this, my team knows this, but someone up in the food chain is going to want blood for any serious outage.

I'm perfectly happy to shed blood for my team and take the crap, but I need something. Even if its a text back: "Dangling on mountain. Will check email on Monday" - then I can tell my higher-ups it won't be fixed till Monday, then they can tell who they need to tell.

Its the attitude that says "I'll only work 40 hours then turn my phone off" that I object to, there are real people up and down the line who are affected by business interruptions. If you're not flexible, sorry, but you're not that useful.

You probably wouldn't enjoy working on my team, and you'd probably pick that up from the interview

[CodeMage]

I think @grecy was pretty clear, but FWIW, here's my interpretation: the system is either important enough to disturb employees after hours or it isn't. If it is, you need to define and implement a support protocol: on-call rotations, procedures, etc.

If it isn't important enough to organize support for it, then it isn't important enough and you should not expect anyone to justify being off work and off duty.

[happychappy]

Okay, I see.

I will talk to my team on Monday and ask their opinion.

For the record, I don't agree that life is as black and white as the first sentence. There are plenty of symptoms which "could" be serious issues, but after a phone call I know can be safely ignored.

[grecy]

I appreciate your reply - thanks.

I honestly would like to hear the thoughts of your team if you are happy to reply here please.

In all honesty - you're right, I'm not very flexible. Either you're paying me to be on call and I'll answer my phone at 3am on a Sunday, or you're not.

Let's flip it around so you see my point of view. Either I stick to the employment contract and ask you to pay me my salary this week, or for reasons completely outside your control, I expect you to pay me $salary+$X, because I said so. If you say no, I view you as inflexible.

See my point?

[happychappy]

I do see your point, yes. The contract is formal for a reason. I'm being far too fuzzy, my team probably don't know what they're supposed to do in the case of an emergency, so log in out of a mixture of curiosity and apprehensiveness.

Hmmm. Well, I always hated pager duty, especially as a frontend engineer. What the hell did I know about these silly Hadoop clusters that were thrown together so badly? Why wake me up just so I can wake up the lazy SOB who can't build software properly?

I'd prefer not to impose that on my team. Is there a middle ground?

[CodeMage]

I agree that it's not always possible to know how serious an issue is from a first glance at its symptoms, but my first sentence wasn't about issues, it was about systems.

Feel free to substitute the word "system" with "project" or "service" or whatever best fits your own terminology, but the gist is: a particular chunk of deployed software either deserves after-hour support or it doesn't. You either care whether it's misbehaving during "off" hours or you don't. If you do, you should care enough to organize proper support. That's all I was trying to say.

Of course, "you should" might be too strong a phrasing; what I mean is that I think that it would be better for everyone and that I would rather work at a place where things are that way than at a place where they are the way you described them.

[Veen]

I think this attitude is the problem. If you pay me for 40 hours of work, I owe you 40 hours of work. That is all.

If you want me to be on call, pay me to be on call.

If my code blows up, I don't owe you 45 hours of work for 40 hours of pay. If my code blows up, it's because you haven't managed testing and quality assurance properly. I shouldn't be able to get shitty code into production — that's why you're the manager and I'm the peon.

It may sound harsh, but demanding free work is exploitation. And trying to guilt people into working for free is immoral.

[bendixso]

I think at the very least we can agree that it is the employee's job to inform their superiors of feature creep, looming technical debt, and whatever bad practices they see.

If you're fixing bugs in production because your manager hasn't addressed longstanding technical debt, then yes, you shouldn't feel bad about the bugs that slipped through against your advice. In that case, I think your indignation at working extra hours without getting paid would be justified.

Ideally, we would do proper estimates upfront without being pushed to grossly underestimate features because so-and-so thinks it should only take a few minutes.

Pushy managers and bad employees are made for each other. It's a feedback loop.

[happychappy]

"I think at the very least we can agree that it is the employee's job to inform their superiors of feature creep, looming technical debt, and whatever bad practices they see. "

Yes, please yes. This is really where 1-1s come into their own. I can ask directly - is there any part of the code you're working on that truly sucks, and is going to break? I don't care who wrote it or when (it was probably me), I just need to know, so I can put it in the backlog

[dasmoth]

Some of us would rather take some responsibility for our code than be treated as "peons".

[happychappy]

"I shouldn't be able to get shitty code into production"

Seriously? My job is to watch over your shoulder and double-check everything you do?

No, there's more to life than this.

[Veen]

Of course there is more to life. That's my entire point. I want to be an actively engaged member of the team, rather than a peon. I want to value the work I do and the people I work with. But there's the rub. Being an active, committed, engaged member of the team shouldn't equate to giving away the one thing of value I have — my time — for nothing.

When you ask me to work for free you are making me a peon — someone of low worth whose time and effort aren't worth paying for. Someone who you don't respect enough to give them fair recompense for their work.

It would be absurd for me to demand that my employer gives me five hours of extra pay for doing nothing because otherwise I can't afford something that's of meaningful value to me. It's equally absurd for an employer to demand that I give them something they value – my work — in return for nothing.

A company is not a charity — it's a cooperative venture that exists to generate value for its owners. Every bit of work you do for the company is to generate value for someone else. I'm not going to work so that someone else benefits and I get nothing. I think any other view is either a manipulative management technique or a delusion.

[adrianratnapala]

I am all for flexibility -- but I think the quid-quo-pro here is that the phone is only for legitimate problems.

Not for example: "Oh the customer has decided that the feature we thought we implemented wasn't what he wanted. Can we have this weeks' requirement met by Monday?"

[happychappy]

Honestly, I'm talking about problems that I'm sure are actually affecting the core business. Anything trivial I'll deflect long before I talk to an engineer

This is all something of a moot point. Looking back through my diary, I've only ever had to call our IT support out of hours, never one of my own engineers. Someone on my team has always independently began to act on whatever alert has been raised.

[Dayshine]

>If your code blows up in production on a Saturday afternoon, and you don't answer email/skype/phone, you've effectively left me in the shit.

Um, why aren't you calling the person on-call? If you have up-time requirements then you write out-of-hours terms into your contracts and have designated staff.

[cookiecaper]

Others are recording the need for a real on-call rotation, so I'll just jump into this:

>Aside from that, I expect 40 hours of "quality" braintime from you, and I don't really care where or when those hours occur, as long as you're collaborating with the team when they need you.

There is no way you are getting 40 hours of "quality brain time" from anyone. If you believe you are, you don't know what "quality brain time" is.

Assign the amount of work you feel is reasonable. Let the worker do the work. If the work gets done, it doesn't matter how much time it took. Knowledge workers sell their knowledge to help you accomplish a designated task, not their time.

How much work really gets done in a 40-hour work week? Anyone who has been in any office environment knows that probably at least 50% of that time is always just farting around trying to rack up butt-in-chair time. Consider also that promotions and political favors are usually withheld from people who do the "bare minimum" of 40 hours and that butt-in-chair time comprises 95% of an external entity's (like, say, your boss's boss) assessment of job performance, and the time constraints can become quite demanding.

We should do away with the Industrial-era culture of minutely managing hours (when time working was directly correlated to the quantity of products a company could assemble, and thus counting time allowed the company to reasonably reliably assign a portion of the revenue to its employees) and embrace the Information-era mandate of small, irregular work units moving the majority of the product.

We should accommodate workers such that they can cultivate a fruitful and creative mental state for use in employment when inspiration and flow is most likely to strike (which, for coders, is usually in the middle of the night when there is a solid block of 5-6 hours with 0 interruptions), instead of forcing our supposedly-revered knowledge workers into deadened, drooling blobs stuck to their chairs for 55 hours a week because they're vying for a promotion next year.

It's a major pet peeve to see someone treating knowledge workers like assembly linemen. More butt-in-chair time != more productivity, and in fact, once a certain threshold is reached (probably ~20 hours), it becomes counterproductive.

[CodeMage]

Before I dive into my comment, let me just state that I agree with you on the impossibility of delivering 40 hours of "quality brain time" and on the stupidity of measuring productivity in "butt-in-chair hours".

That said, I always get worried whenever someone starts advocating for getting rid of 40-hour work week without a very clear idea of how to replace it in concrete terms. See, maybe I'm cynical, but it seems to me that a lot of people forget that the whole concept of 40-hour work week comes from a compromise between the workers and the employers: it's supposed to mean you can be expected to work no more than 40 hours a week. Naturally, the employer will expect you to work no less, otherwise they're "not getting their money's worth".

Whether we like it or not, there is a power imbalance between workers and employers and it's usually in favor of employers. I don't want to touch sensitive topics of how that imbalance might be redressed, but as long as the imbalance is there, having a fixed number of hours in a work week -- even if that's only nominal -- is still better than getting rid of that and making workers vulnerable to having their historically hard-earned rights eroded or downright stripped away.

If that sounds too jaded and bitter, consider the "unlimited" vacation policy. At best, it means you'll still take roughly the same time off as the rest of the team. At worst, everyone ends up taking less vacation time than before and the company profits because they don't have the financial liability of unused vacations anymore.

[grecy]

> Whether we like it or not, there is a power imbalance between workers and employers and it's usually in favor of employers.

I wanted to chime in and mention this balance varies greatly by country. I've worked in Canada, Australia, USA for years, so has my brother.

I personally feel in Australia the balance is clearly in favor of the employee, in Canada it's over to the Employer and in the USA it's shockingly (scarily) in favor of the Employer.

After 7 years in the USA and Canada my brother went back to Australia. One month in I asked him what the most shocking thing was - what do you think he said? Going from years of -30C winter to +40C summer? Driving on the wrong side of the road? food? accents? Nope.

In Australia, you are a valued person at work, rather than a slave. I think that says a lot.

[cookiecaper]

I actually have the same opinion as you on "unlimited vacation". I'd rather know what the company explicitly allows and use it guilt-free than have to ask myself every time I take time off, "Wait, I mean, I know I'm technically allowed to do this, but am I allowed?" People who go in to companies like that guns blazing, oblivious to social matters like colleague perception, are usually destroyed pretty quickly.

So, I can definitely see where your concern arises. I don't want to make it seem like you should do any quantity work that the employer throws your way. There should be a basically agreed-upon range of value delivered in person-week units; the employer should expect to get some value within that range per week, and the employee should expect to provide it on an ongoing basis. This value range is something that is going to be negotiated between employee and employer and the only way to get a realistic feel for it is to undertake a relationship and see where you land. By accepting the standard timeframe for value evaluation to week-units, it matters much less whether you were in your chair from 2pm-4pm all 5 days of the work week. It just matters that you got your work done.

I don't have an exact way to quantify it, because again, in knowledge work, employee productivity isn't really calculable by a simple equation. It's really just about whether the company feels adequate progress is being made and whether the employee feels that his work-life balance isn't falling apart. As long as both of these things are synchronized on an individual basis, there is no problem and no hard rule.

It's hard to get to this because as you said, an employer feels that they're not getting their money's worth if there isn't 40 hours on the clock. However, that's based on the antiquated model of production where time-at-station pulling levers was directly correlated to the value provided to the company. In a factory / assembly line context, that approach still makes sense. For knowledge workers who depend on creativity, like software developers, it doesn't -- it's not an accurate way to measure performance. The challenge for us is in educating employers to view knowledge workers appropriately.

On HN we're all probably familiar with PG's Maker's Schedule essay. I believe that schedule arises naturally because our brain is trying to self-optimize and do work in the most productivity time period, which is usually overnight when there are minimal interruptions. We should all be free to engage with that. It will result in both happier employees and superior work product.

Finally, I think there's a more basic component at play here that I don't actually think we'll overcome anytime soon. The workweek is entrenched into American lifestyle now. People are taught to expect a 9-5 and to be suspicious of those that don't have one. People are taught that colleagues should all go hang out in a big office building for 1/3rd of the day 5 days per week. This is a common expectation even if it's unsuited for modern work. Most people, even most knowledge workers, like this arrangement and don't want it to change. The social costs of doing something unusual with your work day can be substantial, especially if you're in the midst of a period of financial difficulty. I don't think that will change any time soon and I don't know that it'd be a net social good if it did.

However, there are companies that accommodate people that want to work differently. They can be found with some degree of discretion and specific searching.

[happychappy]

I phrased that wrong, but I'm not sure how else to phrase it. I suspect we violently agree, but if you want to take this offline I think my email is in my profile

I have a remote team, spread across the western seaboard of the US. I don't track hours, I don't do the whole "burn-down chart" crap. I keep almost no metrics about my team's productivity. As a result, my team are all far higher performing than I ever was as an engineer. If higher-ups want an assessment of my team's abilities, I'll figure out a way to give them what they seem to want that is truthful to my beliefs.

The employment contract says 40 hours, and our timesheet system will freak if you enter less than 40 hours, and of course you mustn't lie on your timesheet (hello HR! :) ) but what hours you work and when are up to you. My only caveat is that if another team member needs your help in office hours, you need to be able to talk to them and help them. The business pays for 40 quality hours, thats the rule. But nothing is black or white...

If you're "at work" but really you're on hacker news - as I am right now - then I'm not getting "quality" brain time.

Believe it or not, there are people in the world who'll spend 1 hour working, 7 hours on hacker news, then shut their laptop and demand that the rest of their time is out of bounds of work.

Honestly, though, those people are so easy to spot and manage. They're the ones who do deliver what I ask, but never more. They'll spend 3 days writing a post function, not because it took 3 days but because thats how much time I seemed to agree with in the estimate.

There are other people, who'll maybe spend 1 hour on a post function and say "done, whats next?"

There are others still who'll spend 1 hour and say "Hey, boss, the post function is done, but this entire framework is kinda crap, mind if I take three days to look at what else is out there?"

There are others still who'll spend 1 hour and say "Hey, boss, the post function is done, but its kind of weird for the users, how about we do this instead?"

Those last 2 types of people seem to enjoy life more, they're happier in themselves and I'll fight tooth and nail for anything they want. If they really work 30 hours a week, get their shit done and don't let any team members down: who cares, the lying on the timesheet issue is the only problem and I'll cover for them the best I can if they get caught. But the best folks will generally happily work 40 hours, and the 10 or so extra hours - I've found - are best "given" to them to do with as they wish.

The first person (the person who spent 1 hour on code and 3 days on netflix) might be temporarily useful to get code written, but really they're not worth hiring. Yes - I know - its my fault - I should get better estimates - I should follow up - I should write out requirements better. But that person is getting seriously out-shined every day by their team - who (lets be honest) know they're slacking - and that person at the very least is going to first on any chopping block. But more likely I'll work with HR to get rid of them.

The other one - the one that says when they're done and asks for more work - that person I'll try to coach into thinking for themselves more so in future they say "I've done the post function, now i'll go ahead and write the get/delete etc and document it, and there's a new unit test package i'd like to fiddle with"...

Now - to join back along with your comment - "We should accommodate workers such that they can cultivate a fruitful and creative mental state for use in employment when inspiration and flow is most likely to strike"

In my head I have an expression that I can't quite get into language - let people be people, let them be the best they can, and compensate them enough so that their best is directed towards the business - the thing that also compensates me for being the best I can be. but Don't demand more than that, don't try to take ALL their best time, don't try to elbow out their family or their hobbies etc. It needs to be voluntary, given. Not in a contract somewhere, demanded. It can be done, I've seen it, even in a big ole faceless corporation you can make a team perform just by shaping the environment to work for humans, rather than spreadsheets.

[bendixso]

You seem awesome to work for. Need an iOS developer?

Your style totally matches mine.

[cookiecaper]

I understand, and I think that you're right that we probably mostly agree with each other. I just have a few nits to pick.

>if you want to take this offline I think my email is in my profile

Your account appears to be a throwaway and doesn't contain an email address.

>My only caveat is that if another team member needs your help in office hours, you need to be able to talk to them and help them.

What are "office hours"? Unfortunately, this is tantamount to an ordinary dictated work schedule. If you can't say "Hey, I'll get to this in [some period of time > 30 mins and < 24 hours]" without getting in hot water, you might as well stay tethered to your desk during whatever "office hours" are. I know this from experience working "set your own hours" jobs that expected near-immediate response times between "core business hours". It's just a normal schedule.

I would say the only schedule expectation should be attendance at specific, pre-planned meetings, barring emergency needs. If you have a colleague that needs a video chat or real-time communication and you're not able to run into each other naturally, I would say it should be scheduled, just like anything else. As long as time can be made within 24 hours, I don't think there's a big issue there. Even in remote environments (and I've been a full-time remote worker for over 10 [non-consecutive] years), extemporaneous meetings are too often a distraction and a drain on productivity.

I understand that's a lot of freedom to give employees and that not all of them can handle it. In those cases, I would suggest the privilege be removed in specific instances rather than assuming that no employee can handle this responsibility.

>If you're "at work" but really you're on hacker news - as I am right now - then I'm not getting "quality" brain time.

I've always encouraged my subordinates to spend a (paid) hour or two every so often reviewing the industry news in trade outlets like HN. Staying abreast of industry developments and engaging with the discussion about them as they emerge makes everyone a much more effective programmer. I wouldn't say it's not quality brain time.

Tech employees are knowledge workers. Expanding their knowledge is absolutely beneficial to you and its importance shouldn't be discounted.

Obviously, 7 out of 8 hours per day is excessive.

>They'll spend 3 days writing a post function, not because it took 3 days but because thats how much time I seemed to agree with in the estimate.

While I agree that laziness is a potential explanation for this type of behavior, there are several other factors that can cause it, like an employee's feeling that their input isn't considered trustworthy or valuable. In the real world, please don't discount potential explanations that aren't laziness, especially if the employee has a good track record at other employers.

>who cares, the lying on the timesheet issue is the only problem and I'll cover for them the best I can if they get caught.

First, most employees who do this work aren't going to be filling out a timesheet. Are you talking about contractors? I'm confused why they're not paid a regular salary.

Second, sometimes you just have to understand that there's a translation barrier here and what the HR dept really means when they ask to affirm a 40-hour work week is "Did you honestly provide the expected amount of value to the company this week?", to which the truthful answer is "Yes." (This is especially true if you're monopolozing a chunk of time known as "office hours" and demanding that people be available within that timeframe -- I would say that should count as paid even if they don't have anything to respond to. You're still consuming their availability.) While people may be entering a literal value that isn't commensurate with the literal reality it appears to represent, the intent and spirit of the question has been correctly fulfilled. Thus, it's improper to call this a "lie", especially when, as already discussed, the 40 hours put in by conventional office workers are so clearly half-hearted, even resentful.

Other than this, it sounds like we're in pretty good agreement.

[mahyarm]

He did say "or their production software isn't working"