6 ms·

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 kno

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 10y ago
> 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 10y ago
  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
  - adrianratnapala 10y ago
    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 10y ago
      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.
  - CodeMage 10y ago
    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 10y ago
      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 10y ago
        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?
Dayshine 10y ago
>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 10y ago
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.
- happychappy 10y ago
  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.
mahyarm 10y ago
He did say "or their production software isn't working"

grecy 10y ago

> 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 10y ago
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
- adrianratnapala 10y ago
  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 10y ago
    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.
- CodeMage 10y ago
  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 10y ago
    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 10y ago
      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?

Dayshine 10y ago

>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 10y ago

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.

happychappy 10y ago
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.

mahyarm 10y ago

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