<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQLServerCentral.com
»
Editorials
»
Stress – It’s Not Fair
23 posts, Page 2 of 3
««
1
2
3
»»
Stress – It’s Not Fair
Rate Topic
Display Mode
Topic Options
Author
Message
SQLRNNR
SQLRNNR
Posted Monday, November 28, 2011 9:39 AM
SSCoach
Group: General Forum Members
Last Login: Today @ 10:25 AM
Points: 18,754,
Visits: 12,337
Nice hot topic button Andy. If you are already under a fair amount of stress, adding this outside stress compounds the problem. Being able to communicate the cause of this secondary stress (and report reasons for delay) while keeping emotions at bay is difficult. Nonetheless, it is an important thing to learn.
Jason
AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server 2008
SQL RNNR
Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #1212598
TravisDBA
TravisDBA
Posted Monday, November 28, 2011 11:06 AM
Ten Centuries
Group: General Forum Members
Last Login: Thursday, May 09, 2013 9:23 AM
Points: 1,288,
Visits: 2,996
WolforthJ (11/28/2011)
The chart went up in the break room, so everyone saw it when a project was behind and knew which team caused it. After a while we didn't need the chart.
Personally, I'm not a big fan of this kind of public display to get a point across, because it destroys team building and tends to promote a pay-back atmosphere (us vs. them) in the department. I think there are other more tactful ways to deal with this, even if it did turn out to be effective. You can motivate people in other positive ways than mounting signs in the break room for EVERYONE to see (including the janitors and vending machine operators) IMHO.
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...
"
Post #1212666
ken.trock
ken.trock
Posted Monday, November 28, 2011 11:32 AM
Old Hand
Group: General Forum Members
Last Login: Tuesday, May 21, 2013 2:51 PM
Points: 315,
Visits: 1,356
The single most common cause of both work overload and project failure is doing work twice. The most common cause of that is picking up some piece of work (opening an e-mail, looking at a piece of code, whatever), and not handling it right then and there, but instead deciding to handle it later. Right there, you just made yourself do at least twice the work of analyzing whatever it is you just had to analyze a first time. The second most common cause of double-work is not doing something right the first time, usually in a false sense of "just get it done".
That is a great point. Try to finish something now that you've already started. Don't go 3/4 down a task and say "I'll finish it up next time", even if it's Friday afternoon. Or maybe especially
because
it's Friday afternoon
Ken
Post #1212674
rfr.ferrari
rfr.ferrari
Posted Monday, November 28, 2011 11:51 AM
Ten Centuries
Group: General Forum Members
Last Login: Thursday, May 02, 2013 10:51 AM
Points: 1,219,
Visits: 13,507
ken.trock (11/28/2011)
.....That is a great point. Try to finish something now that you've already started. Don't go 3/4 down a task and say "I'll finish it up next time", even if it's Friday afternoon. Or maybe especially
because
it's Friday afternoon
Ken
it's true and very common in most people!!!!
rfr.ferrari
DBA
- SQL Server
2008
MCITP | MCTS
remember is live or suffer twice!
Post #1212682
GSquared
GSquared
Posted Monday, November 28, 2011 1:18 PM
SSCoach
Group: General Forum Members
Last Login: Tuesday, May 21, 2013 1:55 PM
Points: 15,442,
Visits: 9,571
ken.trock (11/28/2011)
The single most common cause of both work overload and project failure is doing work twice. The most common cause of that is picking up some piece of work (opening an e-mail, looking at a piece of code, whatever), and not handling it right then and there, but instead deciding to handle it later. Right there, you just made yourself do at least twice the work of analyzing whatever it is you just had to analyze a first time. The second most common cause of double-work is not doing something right the first time, usually in a false sense of "just get it done".
That is a great point. Try to finish something now that you've already started. Don't go 3/4 down a task and say "I'll finish it up next time", even if it's Friday afternoon. Or maybe especially
because
it's Friday afternoon
Ken
Actually, starting something Friday and finishing it Monday is a good way to end up with your mind locking on the incomplete action all weekend, thus ruining any chances to pay real attention to the weekend at all. Essentially, you get to work the weekend for free, off the clock, even when you're asleep, because your mind will still have pieces of that work stuck in it. So, finish what you start, if you can, and finish as close to when you start as you can.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #1212729
Eric M Russell
Eric M Russell
Posted Monday, November 28, 2011 2:32 PM
Ten Centuries
Group: General Forum Members
Last Login: Today @ 9:21 AM
Points: 1,164,
Visits: 3,340
Members of different teams often follow a rigid "start [this] only after [that] has been completed" development path that isn't necessary.
For example, when developing the data model and stored procedures for a new database, I'll shortly provide the application developers with prototype stored procedure calls that have input/output parameters and mockup resultsets that closely match what the final version will have. Of course, this works much better when the app developers are only making procedure calls and don't have direct access to tables. The stored procedures provide the necessary abstraction layer required for unit based development.
Likewise, when I need to interface with tables on a remote database owned by another team, I'll mockup my own local tables or procedure calls based on the design specifications they are currently working from. Once their end is ready, I only need to make a few minor retrofits to the datasource and programming on my end.
I've found this to be more effective than sulking, nagging, and raising a stink.
"Wise people understand the 10,000 things without going to each one.
They know them without having to look at each one,
and they transform all without acting on each one." - The Tao Te Ching: Verse 47
Post #1212764
WolforthJ
WolforthJ
Posted Monday, November 28, 2011 2:32 PM
Valued Member
Group: General Forum Members
Last Login: 2 days ago @ 7:14 AM
Points: 60,
Visits: 242
TravisDBA (11/28/2011)
WolforthJ (11/28/2011)
The chart went up in the break room, so everyone saw it when a project was behind and knew which team caused it. After a while we didn't need the chart.
Personally, I'm not a big fan of this kind of public display to get a point across, because it destroys team building and tends to promote a pay-back atmosphere (us vs. them) in the department. I think there are other more tactful ways to deal with this, even if it did turn out to be effective. You can motivate people in other positive ways than mounting signs in the break room for EVERYONE to see (including the janitors and vending machine operators) IMHO.
I agree. This was a pretty dysfunctional company. But in this case, it inspired the department that had to order stock to start using an actual project management tool. Exactly what we wanted them to do, and had been suggested, but when it became their idea they were more enthusiastic about it and other departments adopted it. Eventually most departments were included, except IT, which was listed, but never had any time assigned to it. So, if you looked at their GANTT chart apparently we were doing our job in zero time.
Anyway, the guy who put up the chart was eventually fired because of his anger issues and the director was promoted just because. She was diagnosed with Alzheimers not too long after that. Stranger than fiction.
Post #1212765
Steve Jones - SSC Editor
Steve Jones - SSC Editor
Posted Monday, November 28, 2011 2:45 PM
SSC-Dedicated
Group: Administrators
Last Login: Today @ 3:30 PM
Points: 31,436,
Visits: 13,751
TravisDBA (11/28/2011)
WolforthJ (11/28/2011)
The chart went up in the break room, so everyone saw it when a project was behind and knew which team caused it. After a while we didn't need the chart.
Personally, I'm not a big fan of this kind of public display to get a point across, because it destroys team building and tends to promote a pay-back atmosphere (us vs. them) in the department. I think there are other more tactful ways to deal with this, even if it did turn out to be effective. You can motivate people in other positive ways than mounting signs in the break room for EVERYONE to see (including the janitors and vending machine operators) IMHO.
Tend to agree with this comment. I think this is the type of thing that should be handled by a manager in a less public setting.
It breaks teams up. Many people may not realize what the slowdown is, or understand if there is a good reason. Like an unrealistic schedule.
If you think a team is slow, or not doing their best, then deal with them directly.
Follow me on Twitter:
@way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
Post #1212771
Steve Jones - SSC Editor
Steve Jones - SSC Editor
Posted Monday, November 28, 2011 2:47 PM
SSC-Dedicated
Group: Administrators
Last Login: Today @ 3:30 PM
Points: 31,436,
Visits: 13,751
Stress can be very hard to deal with, especially when it comes from friction between teams. I've tried to be more efficient at work, but also do a professional job. Set my own limits on what I can accomplish, and then move forward to do them.
If I fall behind, I can only do so much to catch up. I can't live to work, at least not for more than a week or two.
Follow me on Twitter:
@way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
Post #1212772
mtucker-732014
mtucker-732014
Posted Monday, November 28, 2011 7:48 PM
SSC Journeyman
Group: General Forum Members
Last Login: Sunday, May 19, 2013 5:07 PM
Points: 90,
Visits: 282
A month or so ago there was an entire issue of Scientific American MIND devoted to Stress, causes, effects and how to deal with it. The research suggests that by far the best strategy is to avoid getting into stressful situations, by good forward thinking, planning etc. Strategies for dealing with stress, such as modifying the way you think about the situation are only moderately useful (according to the research) in comparison.
I would say that it is reasonable to express a certain amount of dissatisfaction if other people have let you down. The approach suggested by Andy of dealing with other people's failures as if they are just another problem to solve might make you miss the most effective problem solving technique of all - a good kick up the ****!
Post #1212856
« Prev Topic
|
Next Topic »
23 posts, Page 2 of 3
««
1
2
3
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
