Information Rage Coming Soon To an Office Near You 201
digitaldc submitted the latest excuse to get a few days off: "A survey released this week revealed the latest affliction to hit white-collar workers. It's called 'information rage,' and almost one in two employees is affected by it. Overwhelmed by the torrent of data flooding corporate workplaces, many are near the breaking point.
The aftermath of all this is the deterioration in quality that occurs when flustered employees — unable to sort through a pile of information fast enough — end up submitting work that's substandard. Almost three quarters of the survey's respondents declared their work has suffered as a result."
I call shenanigans (Score:5, Insightful)
This is new? (Score:5, Insightful)
I believe this has been a problem since the beginning of time. When managers see this "symptom" they need to "hire an additional employee". Some people might even say that managing employees workloads is the job of management.
RAGE somehow equals 'meh' (Score:5, Insightful)
Wait a second, this isn't some lame attempt to have a "road rage" analogy in an office environment is it? That's just a sad attempt at crafting buzz-words, and you should feel bad for it.
Re:Isn't this universal? (Score:4, Insightful)
I agree. There's so much information out there that is relevant to every situation that processing it all would mean nothing ever got done. Sifting information and doing what you can with the time and resources you have is all part of the job.
I don't get why they call it 'rage', though. Are they trying to play on 'road rage' or something? Seems to me it isn't rage, but apathy that is the problem.
That is, assuming there's a problem at all. I see nothing to suggest they aren't just doing their best. And the company pays them for it accordingly.
-yawn-
Re:Constant e-mail bombardment (aka signal to nois (Score:4, Insightful)
No, Sir. It is my professional opinion that you have a touch of the "Information Rage." Take 2TB and post back in the morning.
Personally, I do the opposite; I encourage emails and discourage phone and walk-ins. With email, you can safely disregard it for a while and get back to it later, but not so much the other two methods. I've been at my new job since April and have yet to connect to the voicemail system and initialize my box. I'm that frickin' serious about not taking phone calls. Wait... Am I crazy here?
Re:Oh, it's Australia (Score:4, Insightful)
I know that, at least for me, if I am given the opportunity to work on a genuinely interesting project, or to provide some aspect that seems valuable to the species overall, I will actively try to reduce distractions, including the internet. If I am asked to perform the same boring, repetitive tasks over and over, or if I feel the work I am doing is, quite literally, something that the world could do just fine without, I will actively seek out distractions. That's just my 2 cents though.
Re:I call shenanigans (Score:5, Insightful)
People get pissed because they don't have the best tools for the job, but I've never seen 'rage'.
Well stop bugging me about wanting green instead of blue buttons and I would have more time to get your tools done.
Re:I call shenanigans (Score:3, Insightful)
As for tools for the job, for latency insensitive stuff I prefer emails because I read faster than most people can construct and speak coherent informative sentences on the fly. Most people don't prepare a speech before talking with other people, and if they did, they might as well prepare it in their email client and click send when they are done
For latency sensitive stuff I often actually prefer IM to voice. Because at least some people would realize they're typing crap before they press enter, so less crap ends up being sent. And I can more easily log what they say and do something else till the full story finally comes out
But for "touchy-feely" "social stuff" I guess voice is better.
Re:This is new? (Score:4, Insightful)
When managers see this "symptom" they need to "hire an additional employee".
Most often, that's not what management needs to do.
Most often, what management needs to do is to fix the problem with business processes that is resulting in piles of unsorted information being generated and passed to their employees rather than actionable items. Sometimes the problem may be insufficient staff resources (but where it is, it often won't be in the place where the problem shows up, but in the place where the non-actionable information is coming in from), but most often (even when resource limitations on the data source cause the source to send bad input) the real problem management needs to address is with business processes, which adding more people won't do much to help (and certainly won't help efficiently.)
A system needs to reject information that is not of the kind it can act on at the system boundary, and needs to keep the information it can act on in a manner which facilities working on it, regardless of volume. That is just as true with a system implemented with people as one implemented with computers. While -- as is less often the case with computers, generally -- adding more human processing power can, at times, provide an inefficient way of papering over the problem of failing to reject bad input data at the system boundary, or failing to properly store acceptable input data once it is received, it still isn't a good way of addressing either problem. Its essentially the equivalent of throwing more CPUs and some complicated error correction code at a problem, when the source of the problem is bugs in the code validating and storing input data.
Re:This is new? (Score:4, Insightful)
Yes. I call that firing bad managers. That's the other side of the token. And also doesn't get done often enough.
Re:The cure is simple (Score:3, Insightful)
Now, instead of having nicely-organized information including business practices, already-solved problems, and the one vital flaw in the last Widget production batch, you have a million-row database table that's only accessible by a few select folks. Since they take a few months to make a custom report (because they're already so busy), it's easier and faster to go back to the original sources. Now you just have more information, redundantly duplicated.
Re:Agree with Parent (Score:3, Insightful)
Re:Agree with Parent (Score:5, Insightful)
Another thing Allen says when most people say they don't have enough time, its not really time its how they use/don't use it that matters.
Ohhhh... BullSHIT. Total Bullshit.
Anybody working in IT knows that when we say we don't have enough time, most often we fucking mean it.
The problem is not how we use time, the problem is the goddamn Scotty Effect. Clueless project managers and executives just look at us and assume:
1) We are lying.
2) We are padding our time estimates to look good.
3) It's easier than what we are saying it is
4) IT are a bunch of whiny overpaid bitches and why have we not outsourced this to India yet?
Guess what? I am experiencing 'information rage' right now :) Specifically at your assumption, or this Allen douchenozzle's assumption, that most often we are not managing our time right.
Nope....
The problem really is that the pointy haired bosses see a task that is reasonably a day's worth of work, assuming that we can even diagnose the problem that fast (which is fucking variable too), and they conclude, "Ohhh that's just 10 minutes tops".
There is another possibility you may not have figured out. Some people have jobs that their superiors don't understand or value and they get too much work dumped on them. Ask Slashdot how many IT people in here have experienced downsizing and then had to take on the entire workload of their missing peers? How many IT people have been in the position of being forced to work much longer hours (most often without being paid) to handle their increased workload because project managers cannot accurately estimate how long an action item really takes?
Once again, dude, I call *bullshit*.
Re:The cure is simple (Score:3, Insightful)
Sounds like our ticketing system based on some CA crap.
Gotta love it that it can store all this info about who touched what ticket, when they did, how much time they spent, who they transferred it to, when it was opened / closed / delayed etc... Yet they give us no real way to see the data it is collecting.
Oh yay! I can now add how much time i spent on my tickets... but guess what I can't see any aggregate statistics on how well I am doing...
So what have I been forced to do? create a python script to parse the only report you can see (just a big ole table!!!! YAY) and import it into my own database so I can actually get a better idea where i am spending my time!
(did I really spend 15 hours replacing keyboards this week!)
Maybe. (Score:5, Insightful)
On the other hand I see my co-workers more worried about their fantasy sports teams than whether they've tested the latest patches before deploying them.
Seriously.
The good people ARE over-worked and over-scheduled even when they correctly manage their time.
The not-so-good people are ALSO over-worked and over-scheduled because they chose different priorities.
But how do you distinguish between the two groups from the outside? I mean, other than "which people call on which people when their projects explode".
Re:Maybe. (Score:4, Insightful)
Re:Agree with Parent (Score:5, Insightful)
Break down your tasks into actionable items and ask management for a priority. When "Do X" becomes "Do I work on A, B, or C first?", and it is apparent that A, B, and C require nontrivial investments of resources, then it becomes more real to management. Further, in doing pieces A and B you can demonstrate progress toward completing X as a whole, whereas the nebulous "X" is either done or it is not.
This is an old technique for software project management. Take each requirement, break it into use cases, and put a level of effort next to each use case. A high-level requirement like "Add security to the app" becomes hundreds of "Restrict action A on target B to roles X,Y, and Z" use cases. Each one may take an hour. So whereas a manager might reject a blanket 100 hour estimate for "Add security to the app", showing him or her that there are hundreds of source objects to update, each of which requires checkout, modification, testing, and check-in, then the 100 hour estimate seem more reasonable. (This also shows that you put thought into the estimate and its not an off-the-cuff figure.) And if you get 8 use cases done per day, well that's measurable.
Also, if you can demonstrate a high degree of accuracy in your estimates then you will be taken more seriously. The smaller the unit of work, the more accurate the estimate. If you do 6 use cases in 6 hours (at 1 hour apiece), and then have 2 hours worth of meetings, you're still 100% accurate. Whereas if you estimate 100 hours for X and three weeks later it isn't done, then your credibility is shot. Meetings don't (usually) show up in the issue tracking system, so they aren't measurable. (The 50% or 75% devoted argument is not very effective in my experience.)
I used to say that I didn't have time to do the administrative part of development. But the reality is that I don't have time *not* to do it. Break it down and make it measurable, and then the demands (or at least the expectations) will become more realistic.
Re:Agree with Parent (Score:3, Insightful)
Some workers are genuinely lazy, but more often what's going on is that management is trying to make due with less in the way of employees than is really necessary to do the job and fails or refuses to adjust the workload.
Kanban - Solves (some of) this problem (Score:3, Insightful)
Join the "limited work in progress" society.
It's a simple tradgedy of the commons economic problem and it's common to many organisations. The people making the requests are not the ones paying for your time. You're free to them and it's human nature that we consume all of free resources.
It used to be that contacting people and asking them to do something was a pain. Writing letters, filling forms. There was an economic cost to doing so. Today you have email, instant messaging etc and asking other people to do stuff is easy, so you end up with vast amounts of utter crap (requests and information) being generated. Lots and lots of busy work. Put a cost onto your input. When there is a cost to your work, people will choose what they want you to do more carefully.
Things are paid for in money, you have to have money to gain service. No money, no service. However within most organisations, charging between departments is hit or miss, it's a pain to set up and a pain to run. Now, you could set up a pre-payment scheme. Create some internal money (hours of development work for example) and give them to the internal customers. When they run out of hours they don't get any more of your time.
Kanban does this by making "signalling cards" into a kind of internal currency. No card, no service. It depends how you implement it. Rather than cards, we've defined "slots". There are 2 slots per worker. When the slots are full, no more work can be requested. When it's complete, a slot is opened up. Often something stalls, which is why 2 per person rather than one.
Well, fairly quickly it becomes apparent that some work is (much) more valuable to the business than other work... And very quickly priorities are created and these fill the slots, the junk work simply doesn't get requested. It also becomes easy to track how long different types of work really take, any ticket system can do this. Real bottlenecks in the business throughput instantly become blindingly apparent to management.
It's a very simple concept, you pull the work you can do instead of staring at a mountain of work that other people push. The same for information. Pull what you need, ignore crap that others push. Pull vs push.
It's not information that they're angry at (Score:3, Insightful)
It's called bureaucracy, folks. In other words, the workers are sick of the procedural bullshit, various bullshit memos, useless uninformative emails that border on irrelevancy to the actual job, and things like that. Read the article.
It's a shame LexisNexis called it "information rage." The right name for this phenomenon is "bureaucracy rage."
I guess LexisNexis wanted a synergistic term that inspires forward-looking confluence of business values, hence "information rage" signifier.
Re:Kanban - Solves (some of) this problem (Score:3, Insightful)