Slashdot Mirror
Information Rage Coming Soon To an Office Near You
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."
As a long time worker in a G8 tax department, information overload has been going on for years. People get pissed because they don't have the best tools for the job, but I've never seen 'rage'.
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.
I'm sorry, but where exactly does the rage part come in? There's a lot of work to do, people get lazy, skip it, and submit things without properly checking everything they should. That's laziness, apathy, or simply being bad at their job. If there was any rage, I imagine that things would be smashed and people would drop kick printers, possibly to rap music.
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.
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*.
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".
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.