SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Stress – It’s Not Fair


Stress – It’s Not Fair

Author
Message
Andy Warren
Andy Warren
SSChampion
SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)

Group: Moderators
Points: 14893 Visits: 2730
Comments posted to this topic are about the item Stress – It’s Not Fair

Andy
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)

Group: General Forum Members
Points: 114855 Visits: 41397
Heh... you've gotten really good at hitting "hot spots" for me in your articles, Andy. :-D

[Rant ON]

Unless you're the project manager, there's no way to reduce this type of stress other than to realize there's nothing you can do about it except report the reasons correctly and without emotion. People always wait until the last minute or some teams do a less than stellar interpretation of the requirements they've been given which requires rework and the resulting stress that causes.

When a project is being put together, people need to realize that there aren't "different" teams. There's only one "project team" and the individuals and groups in that team need to work together and keep each other informed about the project on all fronts... especially if you have a less than stellar project manager. ;-)

I am, by no means, suggesting an "it's not my job" attitude (which becomes self-prophesizing at times). For a team to perform and perform without stress, the component parts of that team must constantly and effectively interact on a daily or even by-the-minute basis. There is no stress in a well-oiled machine that's running on-time. :-)

I'll also say that stress in a project is normally and unwittingly a "planned" thing because most managers don't plan for contingencies that will take extra time or even add scope to the things that need to be done. The old saying of "failure to properly plan is planning to fail" has a lot of merit to it.

That includes the "worker bees", as well. Many developers (front-end and back-end) will "plan" their own priorities in the project along with other projects (and ad hoc tasks they're given every day) they may be working on and they usually grossly under-estimate what actually needs to be done and the time it will take. By the time they get around to working on "the project", it's already too late to have any chance to properly meet the actual deadline. As a result, they end up taking huge shortcuts just to "get things off their plate" and it fails in test which requires still more time in the form of rework and you end up with totally-crap-code and a death spiral of rework (along with the related stress) in the project.

Right after all of that, a new form of stress arises... the stress of having a totally pissed-off customer because either the code doesn't work correctly or doesn't scale to meet their needs. Reworking that, of course, causes additional stress because the deadlines for all the other poorly planned or poorly controlled projects have deadlines looming, as well.:-P

This vicious cycle of stess can be broken but it takes everyone to do so. Managers need to stop making silly, uninformed promises as to when something might be done and they need to build in some contingency time for things that (it seems and therefore should be anticipated) WILL go "bump" in the night during development, testing, and deployment.

Project Managers need to do the same and they also need to learn that things are easier to say than do. It's not that Developers intentionally lie... they just underestimate especially when under pressure to meet a deadline (no one wants to admit to something that will take longer than the given deadline). Developers need to understand that things will go wrong and provide estimates that have contingencies identified ("If we don't have data to work with to test for scalability, we'll need to build code that builds adequate test data.", etc).

Developers also need to properly test (happy-path, unhappy-path, performance, scalability) their own code because it's much easier and much more time effecient for a Developer to catch his/her own mistakes rather than starting the horrible "rework after test" cycle which can take a whole lot more time than simply taking the time to do it right the first time. That also means that a Developer must have an absolutely clear understanding of not only the requirements of the code they're writing, but what the process that uses the results from that code will be doing.

I know... I know. The thought that most folks will have after reading all that will be "Jeff... You're talking about a perfect world that will never happen." That would be another of those self-prophesizing statements. w00t You've got to start somewhere because if no one starts to make a change, then you're right... it'll never happen. :-P And, yes, I have seen what happens when "the Team" get's it all right... early and less costly developent and deployment, much less stress, and 40 hour work weeks for everyone.

[Rant OFF]

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
rfr.ferrari
rfr.ferrari
SSCommitted
SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)

Group: General Forum Members
Points: 1661 Visits: 13630
Fantastic article! Andy!
thanks for sharing your ideas and experiences!


rfr.ferrari
DBA - SQL Server 2008
MCITP | MCTS

remember is live or suffer twice!
the period you fastest growing is the most difficult period of your life!

bitbucket-25253
bitbucket-25253
SSCrazy Eights
SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)

Group: General Forum Members
Points: 9441 Visits: 25280
Jeff - you have summed it up perfectly........ I have been in situations as you described, unfortunately going to hell in a hand basket all to fast and way too often .... and yet have been in other situations where although not perfect but with managers / developers working as a team with the results that you know and have stated will happen. In those cases, when all is said and done, one feels as if he ls walking on cloud 9.. the feeling of satisfaction with a job well done is an aphrodisiac know to no others.

If everything seems to be going well, you have obviously overlooked something.

Ron

Please help us, help you -before posting a question please read

Before posting a performance problem please read
scoleman-670023
scoleman-670023
Forum Newbie
Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)

Group: General Forum Members
Points: 1 Visits: 29
I deal with this on a regular basis. Great observation!

I mainly see this, not between development groups, but between the standard Business to Business Analyst to Developer flow. Naturally our solution is to "partially" implement poorly understood processes and call them Agile to solve these problems. Now we seem to get to the stress scenario you describe quicker than we used to!

I believe that it all stems from poor communication.....like all all relationships.
GSquared
GSquared
SSC-Dedicated
SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)

Group: General Forum Members
Points: 30221 Visits: 9730
"Stress" is primarily an endocrine reaction to fear or anger.

In this case, it's primarily going to be low-intensity fear, engendered by a threat to project success, as a reaction to unknown vectors entered into a survival calculation. Of course, getting to fear requires passing through antagonism and anger, on a standard emotional curve.

So, the genesis of it hints directly at a cure for it. First, it's a reaction to unknown factors being entered into a survival calculation, so a positive response is gather more data, disseminate more data, and validate new calculations/plans based on that. In other words, communicate, then communicate some more, then communicate some more, with the areas affected.

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".

In summary, three very easy ways to reduce work-related stress in most circumstances: Communicate more, and more effectively; Do it right the first time; Don't pick something up, analyze it, then decide to handle it later.

The biggest stress factor after that is fear engendered by people who just plain enjoy spreading bad news. Simple solution, just avoid those people if 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
TravisDBA
TravisDBA
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2398 Visits: 3069
Great article Andy! I am also reminded of great saying in our business that I use all the time to throw the stress back into their (BA's and PM's) court. "Lack of planning or fore-thought on your part does not necessarily constitute an emergency on mine". My boss has stopped many deadlines cold because of this.

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
Eric M Russell
Eric M Russell
SSCoach
SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)

Group: General Forum Members
Points: 16488 Visits: 10947
When something like this arisis, it helps a lot when the team's manager acknowledges that he or she is aware of the situation and understands the reason for delay is external and outside the team's control. Even better is when the other team's manager acknowledges the situation. That reduces the sense of unfairness and stress.


"The universe is complicated and for the most part beyond your control, but your life is only as complicated as you choose it to be."
WolforthJ
WolforthJ
SSC-Enthusiastic
SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)

Group: General Forum Members
Points: 162 Visits: 268
In my experience, the "other team" stress has usually been worse, because of how blame was distributed. In one case, it never seemed to matter what had happened for most of the project cycle, the blame went to IT for projects being late. The IT manager put up a chart, tracking the dozen or so major milestones that all projects went through. These were the projects that were consistent and similar enough that estimating each step was pretty easy. 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.
Jason Selburg
Jason Selburg
SSCarpal Tunnel
SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)

Group: General Forum Members
Points: 4351 Visits: 4113
I've found the one and only thing that can mitigate the impact of this kind of stress is communication.

I was recently involved in a rather large company acquisition/merge project that involved the entire IT department for a solid year. Toward the end, there were several months straight where overtime became an issue for everyone because of the “im-proper prior planning ….”. The stress level rose to a rather extreme level.

To my point, I was the only manager that seemed to communicate issues that affected timeline to the executives. Although I could have been considered the “sky is falling” guy, the adverse was true. I was praised for my “matter of fact” delivery. No matter the bitterness of the news it was delivered.

It seems all too often that people get stuck in their roles and perceived effectiveness to manage and forget the common goal of the TEAM. Many will not raise the red flag for fear of being seen as this “sky is falling” guy, often causing more stress. We all know that if someone came to you and explained the situation when they know it’s an issue that you’re less likely to take the “it’s not fair” attitude. Wait until it’s too late, then all hell breaks loose.

Put simply, “Communication Is the Key, although it’s often hard to find the lock.”

______________________________________________________________________

Personal Motto: Why push the envelope when you can just open it?

If you follow the direction given HERE you'll likely increase the number and quality of responses you get to your question.

Jason L. Selburg
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search