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?
"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
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.
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.
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.
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
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.
If you could separate the inbound traffic to either the website or the API, then you could do this. You'd need something in front of the code you're deploying though
My team has a 500k monolith written in java 1.6. I don't really want to invest in fixing it, I'm migrating stuff to the new system. So a way to keep the old one going risk-free is to create three load balancer pools, and have apache send some traffic to the three based on URL pattern
* /users goes to pool one
* /dashboards goes to pool two
everything else goes to pool three
That guarantees that /users and /dashboards can be kept to certain level of performance - by adding more machines, not by diving into the code and trying to fix stuff.
The benefit is that its the same deployable in all cases, so its very easy to push.
Assign bug to me...
Fix bug in 20 minutes...
wait 3 days (binge watching netflix)...
Commit fix, mark bug as fixed...
Relying too much on commits / tracking tools is a red flag of poor management.
If any of my team reported "still working on bug X" in the standup 3 days in row, without any significantly interesting details, I'd have assigned a few more people to help out.
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?