Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««123»»

Stress – It’s Not Fair Expand / Collapse
Author
Message
Posted Monday, November 28, 2011 9:39 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 3:16 PM
Points: 17,951, Visits: 15,951
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, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Post #1212598
Posted Monday, November 28, 2011 11:06 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 2:03 PM
Points: 1,334, Visits: 3,069
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
Posted Monday, November 28, 2011 11:32 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, November 17, 2014 9:57 AM
Points: 323, Visits: 1,471
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
Posted Monday, November 28, 2011 11:51 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, October 13, 2014 8:02 AM
Points: 1,262, Visits: 13,556
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
Posted Monday, November 28, 2011 1:18 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Monday, November 17, 2014 12:50 PM
Points: 13,872, Visits: 9,598
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
Posted Monday, November 28, 2011 2:32 PM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 2:48 PM
Points: 1,754, Visits: 4,966
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.
Post #1212764
Posted Monday, November 28, 2011 2:32 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Today @ 11:19 AM
Points: 65, Visits: 260
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
Posted Monday, November 28, 2011 2:45 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 2:21 PM
Points: 31,282, Visits: 15,741
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
Posted Monday, November 28, 2011 2:47 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 2:21 PM
Points: 31,282, Visits: 15,741
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
Posted Monday, November 28, 2011 7:48 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, November 18, 2014 5:10 PM
Points: 97, Visits: 343
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 »

Add to briefcase ««123»»

Permissions Expand / Collapse