SQLServerCentral / Editorials / SQLServerCentral.com / Stress – It’s Not Fair / Latest Posts

RE: Stress – It’s Not Fair

GSquared — Tue, 29 Nov 2011 07:14:05 GMT

[quote][b]Jeff Moden (11/28/2011)[/b][hr][quote][b]TravisDBA (11/28/2011)[/b][hr]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.[/quote]Heh... I was thinking just the opposite, Travis... "Poor planning on your part DOES consitute an emergency on my part" and that's why I'm stressed! :-D[/quote]I think it was Matt Miller who used to have a sig on this site (might still) that said something like "Your lack of planning does not constitute an emergency for me. Unless you're a VP or higher, or in Sales, or a customer, or ... what was my emergency again?"

RE: Stress – It’s Not Fair

peter-757102 — Tue, 29 Nov 2011 02:34:58 GMT

Just read the article (I am free on Mondays \o/)...I find the conclusion of the article strange to me as it could just be said that it is the 'having no control over the situation' factor that is killer. Maybe it is my perspective as a control freak, but the effects you describe perfectly fit my conclusion too. People are placed, by the other team, in a situation they have no control over and it harms their own efforts. The same effects can be seen with mismanagement and lack of direction by leadership, it all boils down to having no control over your own situation, regardless of your personal efforts and persistence.

RE: Stress – It’s Not Fair

Jeff Moden — Mon, 28 Nov 2011 21:15:03 GMT

[quote][b]TravisDBA (11/28/2011)[/b][hr]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.[/quote]Heh... I was thinking just the opposite, Travis... "Poor planning on your part DOES consitute an emergency on my part" and that's why I'm stressed! :-D

RE: Stress – It’s Not Fair

mtucker-732014 — Mon, 28 Nov 2011 19:48:23 GMT

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 ****!

RE: Stress – It’s Not Fair

Steve Jones - SSC Editor — Mon, 28 Nov 2011 14:47:59 GMT

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.

RE: Stress – It’s Not Fair

Steve Jones - SSC Editor — Mon, 28 Nov 2011 14:45:37 GMT

[quote][b]TravisDBA (11/28/2011)[/b][hr][quote][b]WolforthJ (11/28/2011)[/b][hr] 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.[/quote]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.:-D[/quote]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.

RE: Stress – It’s Not Fair

WolforthJ — Mon, 28 Nov 2011 14:32:45 GMT

[quote][b]TravisDBA (11/28/2011)[/b][hr][quote][b]WolforthJ (11/28/2011)[/b][hr] 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.[/quote]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.:-D[/quote]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.

RE: Stress – It’s Not Fair

Eric M Russell — Mon, 28 Nov 2011 14:32:09 GMT

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.

RE: Stress – It’s Not Fair

GSquared — Mon, 28 Nov 2011 13:18:40 GMT

[quote][b]ken.trock (11/28/2011)[/b][hr][quote]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".[/quote]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 [i]because[/i] it's Friday afternoon :-DKen[/quote]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.

RE: Stress – It’s Not Fair

rfr.ferrari — Mon, 28 Nov 2011 11:51:47 GMT

[quote][b]ken.trock (11/28/2011)[/b][hr].....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 [i]because[/i] it's Friday afternoon :-DKen[/quote]it's true and very common in most people!!!!

RE: Stress – It’s Not Fair

ken.trock — Mon, 28 Nov 2011 11:32:49 GMT

[quote]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".[/quote]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 [i]because[/i] it's Friday afternoon :-DKen

RE: Stress – It’s Not Fair

TravisDBA — Mon, 28 Nov 2011 11:06:57 GMT

[quote][b]WolforthJ (11/28/2011)[/b][hr] 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.[/quote]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.:-D

RE: Stress – It’s Not Fair

SQLRNNR — Mon, 28 Nov 2011 09:39:37 GMT

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.

RE: Stress – It’s Not Fair

Jason Selburg — Mon, 28 Nov 2011 09:30:43 GMT

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

RE: Stress – It’s Not Fair

WolforthJ — Mon, 28 Nov 2011 09:16:26 GMT

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.

RE: Stress – It’s Not Fair

Eric M Russell — Mon, 28 Nov 2011 09:07:34 GMT

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.

RE: Stress – It’s Not Fair

TravisDBA — Mon, 28 Nov 2011 08:17:12 GMT

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.

RE: Stress – It’s Not Fair

GSquared — Mon, 28 Nov 2011 07:01:34 GMT

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

RE: Stress – It’s Not Fair

scoleman-670023 — Mon, 28 Nov 2011 04:13:11 GMT

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.

RE: Stress – It’s Not Fair

bitbucket-25253 — Sun, 27 Nov 2011 16:21:30 GMT

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.

RE: Stress – It’s Not Fair

rfr.ferrari — Sun, 27 Nov 2011 15:40:54 GMT

Fantastic article! Andy!thanks for sharing your ideas and experiences!

RE: Stress – It’s Not Fair

Jeff Moden — Sun, 27 Nov 2011 10:27:28 GMT

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.:-PThis 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]

Stress – It’s Not Fair

Andy Warren — Sun, 27 Nov 2011 08:47:05 GMT

Comments posted to this topic are about the item [B]Stress – It’s Not Fair[/B]