Go stand behind him
-
Have you ever been given a task that involves getting someone else to do something, and when they don't do it, you're told, "You have to go to his desk and stand behind him while he does it. Sometimes that's just how you get stuff done."
That ticks me off for several reasons:
- That's not how I interact with people. If you want me to do something, don't stand behind me and expect me to do it right now unless it's a genuine emergency. If it's anything normal, send me an email or schedule something. If it's project-related, add a task and assign it to me. Standing behind me is borderline rude. Therefore I don't do it to other people.
- Why am I expected to do my job without anyone standing behind me, but instead of managing your own people you need me to do it for you?
- Unless the task requires my physical presence - which it doesn't - it's a degrading waste of my time. We should have a supply of mannequins, and when you need something done you put the mannequin behind the person and leave. I'm not even kidding about that.
- If that's really how we manage our tasks, then it's no wonder we can't get anything done. We've set the expectation that nothing matters unless someone stands behind you. The person I need isn't blowing me off because he's lazy. We just have no better way to communicate our priorities to him and he has no better way to manage them.
- What if I go over there to stand behind him and he's not there? That was a waste of time. What if someone else is already standing behind him? Are we supposed to stand in line? Is that how we get work done? It's only a matter of time before the person we're waiting in line for can't get something done because he needs someone to do something for him, and that person is standing in line behind him. Then we're gridlocked.
- If you think that we should stand behind people when we need them to do something, and you need me to stand behind him, then will you stand behind me while I stand behind him? Really, that sounds stupid? You didn't think it was stupid when you wanted me to do it.
-
Relevant
RosieTDS:
https://dilbert.com/strip/2018-12-16
-
@Andrew-Scott said in Go stand behind him:
You have to go to his desk and stand behind him while he does it. Sometimes that's just how you get stuff done.
Translation: I have tired of trying to manage this report, so I want you to do it for me.
-
@Andrew-Scott I can't remember having been asked to stand behind someone, I would have flat out refused to do that and told them to fire the person if they cant trust him to do the work unless someone is watching him perform it. I have been asked to pair program with someone to get them to finish a task, which isn't much different really. There is a point of some skill of mine rubbing off on them, but most of the time, I would solve any pair programming task faster on my own, because I always end up dictating exact code to the other person, or just ignoring them and typing away. (I am really shit at pair programming, if you couldn't tell)
And for dictating, just writing code myself is faster than telling someone else what code to write and then waiting for them to understand and then writing what I want them to write.Aaaanyway. Sounds suboptimal to have a worker that wont work unless you have a second worker stand and look at them to make them work.
Of course, you could just hire a burger-flipper off McDonalds and have them stand around staring at such lazy fucks, it'd be cheaper and get the job done just as well. And the burger flipper might even get a raise!
-
@Carnage said in Go stand behind him:
And the burger flipper might even get a raise!
The burger flipper needs to be kept from being promoted into management, though, then they'd stop being effective at management.
-
@Gribnit said in Go stand behind him:
@Carnage said in Go stand behind him:
And the burger flipper might even get a raise!
The burger flipper needs to be kept from being promoted into management, though, then they'd stop being effective at management.
Truth be told, standing around staring at people that do actual work doesn't sound that far off from actual management. Just add a bit of useless reports and documents.
-
@Carnage said in Go stand behind him:
@Gribnit said in Go stand behind him:
@Carnage said in Go stand behind him:
And the burger flipper might even get a raise!
The burger flipper needs to be kept from being promoted into management, though, then they'd stop being effective at management.
Truth be told, standing around staring at people that do actual work doesn't sound that far off from actual management. Just add a bit of useless reports and documents.
well, interfering with the work is also necessary.
-
This post is deleted!
-
Sounds suboptimal to have a worker that wont work unless you have a second worker stand and look at them to make them work.
In most cases I've seen it's not that a person won't do the work. The problem is just that there's no better way to manage and assign tasks, or there is one but it's not used in this case. So the person just has a giant inbox full of things people want him to do, and someone else stopped by his desk, a few people sent him IMs, and then on top of that there's his "real" work.
If I'm on a team and people start sending me messages and emails asking me to do this or that and I can't keep up, I ask them to make them tasks which become part of the backlog. That way I don't have "real" tasks and side tasks. I just have tasks, and either I or someone else can prioritize them.
-
@Andrew-Scott Yeah, I've worked at places where people and teams have been given secret offices hidden away from everyone else just to let them get some of their work done free from interrupts. Seems like a better solution really.
-
@Carnage said in Go stand behind him:
@Andrew-Scott Yeah, I've worked at places where people and teams have been given secret offices hidden away from everyone else just to let them get some of their work done free from interrupts. Seems like a better solution really.
Wait, so some sort of a building full of like, walled spaces with doors? How would you get the noise level high enough?
-
@Andrew-Scott said in Go stand behind him:
stand behind him while he does it.
I've always interpreted that metaphorically rather than literally — pester the person mercilessly — frequent emails, phone calls, IMs — every day, twice a day, every hour, every 10 minutes, whatever, depending on the scale of the task. Annoy and interrupt them more often than any of the other people demanding their attention, so that you become the squeaky wheel that gets the grease. Put almost as much pressure on them as if you were literally standing behind them, but you can get your own work done between the haranguing.
Of course it's still unpleasant and shouldn't be necessary, but it's better than the literal interpretation.
-
@HardwareGeek Patent pending patent pending patent pending
This should be able to be automated.
-
I just refuse. My policy is that I answer my emails and take care of my tasks. If someone else doesn't, then they don't. If that means that they don't do what I need them to do, then they don't do it. (I'll also point out that I don't need them to do something. We do.)
If that in turn means that something critical won't get done then it won't get done. If that means that software won't be delivered then it won't be delivered.I'm not saying absolutely never ever. But I've seen cases where too much allowance is made for someone. I was recently told that someone doesn't check messages so I need to walk across the building at intervals to see if he's at his desk. I refuse. If he's too busy, make him less busy. If he's just not responsive, make him responsive.
Finally someone gave me his number so I can text him. Thanks. I'm going to share it with everyone right after I'm done writing it on the bathroom wall.
-
@Gribnit said in Go stand behind him:
@HardwareGeek Patent pending patent pending patent pending
This should be able to be automated
Just use cron to pester them. Set them on pester with a big sack of pesters to pick from. Maybe mutate the pesters to evade spam. Or hell, maybe I should write an application to do this. REST API sounds like /pester/{user} for minimal - would be nice to have the pester settings sort themselves out via some sort of feedback mechanism...
POST PesterDefinition /pester/at/{user} = PesterDefinition GET /pester/at, /pester/at/{user} = PesterDefinition[] POST UserDefinition /pester/user/{user} = UserDefinition
-
@HardwareGeek said in Go stand behind him:
I've always interpreted that metaphorically rather than literally — pester the person mercilessly — frequent emails, phone calls, IMs — every day, twice a day, every hour, every 10 minutes, whatever, depending on the scale of the task.
It still makes little sense when you think about it. If you're not a manager, micromanaging people is literally not your job. And if you are a manager, having to micromanage people means you've made poor choices.
-
@Andrew-Scott Thankfully, no. This is just an example of poor management. They're passing the buck down the chain, hoping someone else would do it. So, I'd recommend doing the same thing, assign the task to the person who should be doing it and go back to Youtube.
-
@aapis said in Go stand behind him:
@Andrew-Scott Thankfully, no. This is just an example of poor management. They're passing the buck down the chain, hoping someone else would do it. So, I'd recommend doing the same thing, assign the task to the person who should be doing it and go back to Youtube.
The alternative is saying that you have insufficient bandwidth and asking if they can talk to them, which is asking them to do their job. Given that 9/10 managers are (what is this thing that walketh like a man) that can be a bad idea. It would technically be the healthy and right thing to do. Be careful of what organizations you try a stunt like this in.
-
@Zerosquare said in Go stand behind him:
And if you are a manager, having to micromanage people means you've made poor choices.
Micromanagement is almost never caused by the subordinates, unless they're so incompetent that you simply have to do their job. Which is rare - for example even bad developers usually produce working, even if unmaintainable, code and few managers care about maintainability anyway. It's usually caused by lack of clear goals and planning. If the employee doesn't know what the end goal is, he can't plan his work effectively and will ask for decisions on every single small item so that he isn't blamed when he guesses the goal wrong. In extreme cases you have this distributed micromanagement, when every higher up can come at the employee's desk and demand switching to new 'urgent' thing.
Personally I think the common cause of this pathology is the habit of paying by the hour rather than for results, especially when combined with rigid schedule. This makes this alavanche of bullshit wishlist tasks look like it's free, because 'X would be nice, and we're paying him anyway, why not make him do X', while simultaneously removing any incentives to get the job done quickly from the employee, unless he can be threatened with firing, which doesn't usually apply in high-paying jobs. If the management folks were buying, not simply requesting these bullshit side-projects, little change requests etc, they would change their attitude quickly.
By the way, that's why I refuse jobs with fixed hours. They tend to devolve into this 'hmm, everything's done and we're wasting man-hours, let's try some bullshit change request'. For small projects I would even prefer fixed price with fixed scope as opposed to hourly rate, just to avoid suits badgering me with questions like 'why did you exceed this estimate by 15min' and expecting an answer they could understand and do something about.
-
Management by
WalkingStanding Around.
-
@sebastian-galczynski: yeah, that's what I meant. Micromanagement is caused by incompetent subordinates, poor workflows or inability to delegate ; in all three cases, it's a symptom of bad management.
-
@sebastian-galczynski said in Go stand behind him:
just to avoid suits badgering me with questions like 'why did you exceed this estimate by 15min' and expecting an answer they could understand and do something about.A good answer to such a question is "on the express written instructions of Our Lord Satan".
-
@sebastian-galczynski said in Go stand behind him:
It's usually caused by lack of clear goals and planning. If the employee doesn't know what the end goal is, he can't plan his work effectively and will ask for decisions on every single small item so that he isn't blamed when he guesses the goal wrong. In extreme cases you have this distributed micromanagement, when every higher up can come at the employee's desk and demand switching to new 'urgent' thing.
Back when I recurringly had this issue where I had a handful of all very extremely equally important tasks and manglement utterly refused or was incapable on agreeing on the most important task, I'd just sort out a meeting (Usually in my office) where I'd explain to them that if they didn't prioritize i would. And that I would do the most fun and/or interesting thing first.This was usually met with a lot of hoing and humming and them saying that I cant do that, and me explaining that I do not have the information to properly tell which thing is the most important, and that that is their job, so until they do it, I will do it my way.
Every single time, it took the involved managers less than 15 minutes to agree on a prioritized backlog of things for me to work on.The last decade as a consultant, they tend to value my time better and tell me exactly what they want me to do.
-
@Gribnit Fuck outta here with that legitimate career advice.
-
@sebastian-galczynski said in Go stand behind him:
Personally I think the common cause of this pathology is the habit of paying by the hour rather than for results, especially when combined with rigid schedule. This makes this alavanche of bullshit wishlist tasks look like it's free, because 'X would be nice, and we're paying him anyway, why not make him do X', while simultaneously removing any incentives to get the job done quickly from the employee, unless he can be threatened with firing, which doesn't usually apply in high-paying jobs. If the management folks were buying, not simply requesting these bullshit side-projects, little change requests etc, they would change their attitude quickly.
On one hand, it would definitely help with lazy developers. On the other hoof, it's totally incompatible with all agile methodologies, as the management would become extremely careful not to schedule something they aren't 100% sure is going to end up in final product in unchanged form (good luck coming up with even a single such feature).
-
@HardwareGeek said in Go stand behind him:
Annoy and interrupt them
GO AWAY. I CAN'T GET MY WORK DONE!
-
@GÄ…ska said in Go stand behind him:
On one hand, it would definitely help with lazy developers. On the other hoof, it's totally incompatible with all agile methodologies, as the management would become extremely careful not to schedule something they aren't 100% sure is going to end up in final product in unchanged form (good luck coming up with even a single such feature).
My recent experience contradicts this hypothesis. I'm paid by the hour, but without fixed schedule, so if they request more changes, they will pay more, and I can roughly estimate how much more. They still insist on making poorly thought out changes.
And even if it was so, this is not really incompatible with agile as intended - the whole team still can, and should, react to external changes (the market circumstances, or even results of some tests). What is lost is the wasteful changes of internal origin, which are simply results of doing first, thinking later or some territorial marking by middle managers. The problem is not the boss saying 'we got it wrong, we need to change this', but 'you were right, we didn't think it through'.
Most of what's called 'Agile' these days is some kind of farce anyway. The main difference from the BDUF methodologies of the past is that instead of a 'big design up front' project failing once, with big losses on the balance sheet, you now have these 'agile' projects dragging for years, generating even bigger costs, but never formally 'failed', because they're always 'in progress'. The whole team, including the management layer can change multiple times, and the zombie project still goes on eating money without delivering value. The clueless C-suite is fooled with pretty statistics (we already have
1MLOC9000 tickets closed! think about this value! So much velocity!) and continues being milked without any tangible gains. After some time the tap with cash is being closed and the project is declared 'finished', still in a pretty unusable state. But hey, it's not failed, we just reduced scope in an agile way!The other difference (especially with scrum) is that developers are now forbidden from properly architecting the software, since after the initial sprint there's no ticket for that, so they just hack more spaghetti on top of the initial design to accomodate changes.
-
@sebastian-galczynski said in Go stand behind him:
developers are now forbidden from properly architecting the software
Technically, you can raise a refactoring ticket. In practice, the refactorings get rolled into every other ticket. If they happen.
-
@da-Doctah said in Go stand behind him:
@sebastian-galczynski said in Go stand behind him:
just to avoid suits badgering me with questions like 'why did you exceed this estimate by 15min' and expecting an answer they could understand and do something about.A good answer to such a question is "on the express written instructions of Our Lord Satan".
"Had to take a dump" might work too.
-
@Gribnit said in Go stand behind him:
Technically, you can raise a refactoring ticket.
Yea, sure. For example in my current project the devs, including the lead can't raise any tickets at all. And that's not the first time I see this rule. Of course we pad estimates and put refactoring and bug fixing inside other tasks, so that they don't know and still get some quality, but without this kind of lying we would be effectively bound to hack buggy spaghetti.
-
@sebastian-galczynski said in Go stand behind him:
@Gribnit said in Go stand behind him:
Technically, you can raise a refactoring ticket.
Yea, sure. For example in my current project the devs, including the lead can't raise any tickets at all. And that's not the first time I see this rule. Of course we pad estimates and put refactoring and bug fixing inside other tasks, so that they don't know and still get some quality, but without this kind of lying we would be effectively bound to hack buggy spaghetti.
Wonder if there's a way to give them only the quality they're allowing without all the sanity costs. Considered outsourcing your job?
-
@Gribnit said in Go stand behind him:
Considered outsourcing your job?
This wouldn't work. All the tickets are in Polish, so if I hire some cheap thirld world guy, I still have to translate all communications, which means I have to be available all the time while he's working. Bad deal.
-
@sebastian-galczynski said in Go stand behind him:
@Gribnit said in Go stand behind him:
Technically, you can raise a refactoring ticket.
Yea, sure. For example in my current project the devs, including the lead can't raise any tickets at all. And that's not the first time I see this rule. Of course we pad estimates and put refactoring and bug fixing inside other tasks, so that they don't know and still get some quality, but without this kind of lying we would be effectively bound to hack buggy spaghetti.
If you have short sprints then bugs are supposed to be tackled as first things in the next sprint. If bugs are not immediately fixed than your company is failing to get its priorities straighte and is seriously fucked up.
As for padding estimates for refactoring: if that's the time it takes to do it properly then that's just the time it takes to do the task — as long as it can fit into a few day's work. It's problematic when you notice that e.g. your database scheme is not at all set up to do a particular thing, and that's when you need to create extra tasks which you say is impossible to do.
I wonder then: who decides in how many tasks a particular feature gets split? Who decides on the initial estimates?
-
@JBert said in Go stand behind him:
If you have short sprints then bugs are supposed to be tackled as first things in the next sprint.
Eh. Sometimes bugs can live forever. Low impact, expensive to fix.
And/or customers. Some simply like shiny more than correc
-
@swayde said in Go stand behind him:
@JBert said in Go stand behind him:
If you have short sprints then bugs are supposed to be tackled as first things in the next sprint.
Eh. Sometimes bugs can live forever. Low impact, expensive to fix.
And/or customers. Some simply like shiny more than correcThat goes doubly for managers. Shiny is always more important. App crashes? Don't care - SHINY!!!
-
@JBert said in Go stand behind him:
I wonder then: who decides in how many tasks a particular feature gets split?
The non-technical product owner and his equally non-technical assistants. Usually they can be takled into splitting some feature when it's too big, or defer it to the next sprint if it looks poorly defined, but we can't add anything.
@JBert said in Go stand behind him:
Who decides on the initial estimates?
The developers, fortunately. It's not that bad really. When I said about developers being forbidden from refactoring I didn't mean this particular project, at least not how it operates now. In fact, we did what amounts to a rewrite.
It seems to be how the previous team operated, though, when you read the code they produced. You don't see any substantial data model changes (it quickly became awkward when new features started growing), almost all commits were adding new code and not removing old etc. The branching model speaks for itself (how do you even refactor when you never have a single current version of the project?).
-
@sebastian-galczynski said in Go stand behind him:
This wouldn't work. All the tickets are in Polish
You just need to find a cheap Polish guy. Have you tried asking on https://what.thedailywtf.com/?
-
@sebastian-galczynski said in Go stand behind him:
@GÄ…ska said in Go stand behind him:
On one hand, it would definitely help with lazy developers. On the other hoof, it's totally incompatible with all agile methodologies, as the management would become extremely careful not to schedule something they aren't 100% sure is going to end up in final product in unchanged form (good luck coming up with even a single such feature).
My recent experience contradicts this hypothesis. I'm paid by the hour, but without fixed schedule, so if they request more changes, they will pay more, and I can roughly estimate how much more. They still insist on making poorly thought out changes.
Paying by the hour is very different from paying by the task.
-
@Zerosquare said in Go stand behind him:
@sebastian-galczynski said in Go stand behind him:
This wouldn't work. All the tickets are in Polish
You just need to find a cheap Polish guy.
You're forgetting one thing: he's a cheap Polish guy himself.
-
Every time I read the title of this thread in the thread list, I keep thinking it is about a certain programming language that doesn't like exceptions and has weird types…
-
@dkf said in Go stand behind him:
Every time I read the title of this thread in the thread list, I keep thinking it is about a certain programming language that doesn't like exceptions and has weird types…
Having just read it, I'm only slightly sad it isn't.
-
@GÄ…ska said in Go stand behind him:
You're forgetting one thing: he's a cheap Polish guy himself.
That was part of the joke, yeah.
But you can always find cheaper.
-
@Zerosquare said in Go stand behind him:
But you can always find cheaper.
Not once you've reached a meth drinker in Chelm, you can't. Not and have them able to speak an approximation of Polish…
-
@dkf said in Go stand behind him:
meth drinker in Chelm
Maybe a few krokodil using Russians have passable polish skills?
-
@swayde I tend to assume that Russians won't know Polish out of sheer chauvinism.
-
@GÄ…ska said in Go stand behind him:
You're forgetting one thing: he's a cheap Polish guy himself.
But I always feel like I'm overpaid. I certainly wouldn't pay myself this much for this work.
-
@sebastian-galczynski Hence why you work for someone else instead of yourself.
It's very easy to confuse job difficulty with job skills. They're not paying you for your instant ability to solve incredibly difficult problems; they're paying you for your learned-over-several-years ability to solve very easy but open-ended problems that still require skills and experience to know how to solve.
-
@pie_flavor said in Go stand behind him:
It's very easy to confuse job difficulty with job skills.
My doubts are less about skills or difficulty, more about value added. The skills aspect seems justified - it's hard to find anyone competent, so the price is high, that's just how markets work. If paying this price for solving these particular problems makes any sense is much less obvious to me.
-
@sebastian-galczynski said in Go stand behind him:
But I always feel like I'm overpaid.
Whatever you do, stay quiet.
-
@sebastian-galczynski Even those problems require the competence which is what the market is buying.
