Mental breakdown in 5... 4... 3... 2...

May 6, 2005 4:02 AM

When work is getting far too crazy for you to keep up how do you cope? I've been made the lead on a project that was pretty out of control to start with and things have just been getting worse as the project gets more and more successful. What advice do you have for handling the stress before I find myself telling my CEO exactly where he can go stick whatever nearby objects are available for sticking.

I'm the lead on a computer project that has found itself a lot more successful than anyone expected. So right now I have a woefully understaffed team, customers who are demanding all sorts of random things, a CTO/CEO who is breathing down my neck needing more demos, more features, more more more, and a bug list that is growing out of control.

This is the most responsibility I've ever had and I'm worried I'm going to screw it up. I'm beginning to lose track of what needs to be/has been done, and I've become pretty interrupt driven. My teams task lists are still growing faster than they are being completed and deadlines are coming really really soon. The team works well together and I'd like to think I'm a decent manager and that morale is pretty good considering, but by now the work load is making everyone a bit punchy, and that's of course making getting things done even harder.

All this is causing enough stress that stress itself is becoming an impediment to getting stuff done. How can I handle the stress? I know exercise is important and I'm making sure I don't avoid that, but I'm not sure where to go from there. How do you handle insane work stress. (And no, quitting is not something I'm interested in.)

posted by anonymous to work & money (12 comments total)

The book Getting Things Done by David Allen is the obvious answer, so I might as well say it--it's very good, and it will probably help you get a handle on your interrupt-driven work situation. You should definitely check it out; there are a ton of resources online for GTD, but none of them are as good as the book, which is skimmable in about two hours. It is made for people in your situation.

Beyond that, my advice, based on my own experience managing (smaller) insane technology projects, is that you need to have a serious meeting with your superiors and make clear that the parameters of the project are out of whack. If you really are experiencing success here, then more staff will not be out of the question. Predictability is the #1 business virtue, and the more unpredictable your performance become the more sketchy you will seem as a manager. Conversely, if you say to your CTO that, with the current progress of work and the current number of workers, you will be getting work done by such-and-such a date, whereas with more workers another date will be possible, and stick to that, then your competence will be more apparent.

It's possible to come up with semi-solid data to support these types of meetings. Look at how much work--how many features, how many bugs--are addressed by per week per programmer, for example. And say, "If we had three more people on staff right now we could get done by the deadlines you are setting." Don't go to your boss, throw up your hands, and say "This is crazy!"--Go calmly and advise the management that there is a collective lack of realism. Your project or product has apparently made it to the next level; to support it fully your team has to go up a notch too.
posted by josh at 4:23 AM on May 6, 2005

josh's points are all great, especially for their basic assumption that the real question is not "How do I learn to deal with all this stress?" That's a really, really bad question to ask. The first question you really should be focusing on is "How do I get some control over this situation that is giving me so much stress?" (That's not to say you can make stress disappear completely, or that you don't have to learn to deal with it. I'm just saying that your most urgent task is to focus on the cause, not the symptom.)

I'd just add that you need that it really sounds like you need to start asserting yourself more. The bane of many junior/first-time project managers is a fear of saying "No", when that's actually one of the core competencies of any really good project lead.

There are obviously times when going the extra mile is a good thing, and getting a team to deliver under an insane deadline is truly impressive. That does _not_ mean, though, that those sort of conditions should become the norm. Sometimes the hardest but most important thing a project lead can do, after over-delivering dramatically up front, is to scale expectations and requirements back down to something that's genuinely sustainable.

To give you some more concrete advice on what to do:

1) Make it clear that your team is at capacity, and nothing more can be added "for free". Insist that the fastest way to get the current set of requirements completed is to go into a "requirements freeze", and to just leave the team alone. Once the current set is clear, or at least in testing, they can move on to the pending list.

2) Do not accept any new requirements without a clear commitment on how they're going to be "paid for"--either with more time, or more resources. If someone cannot assure that you'll either get an extension or more (good) team members to make it happen, be as diplomatic but as firm possible in explaining that they are basically taking deadline responsibility out of your hands. Reiterate that you cannot simply spin results out of thin air, and that you'd be a bad project lead if you made believe you could.

3) Over time, you need to establish a clearer process on how changes and revisions actually get handled. Typically, all changes should go through a very concrete cycle, and they begin as _requests_, not as _requirements_. Nothing--no matter how important--should move from the "request" pool to the "requirements" list without a very clear agreement on how it's going to affect the schedule and the team. Typically, in a sane project, requests can come in at any time, and they just go into a pool. Once a week, you go through a planning process with the stakeholders and management to confirm exactly which requests are being promoted to requirements, and what the new deadlines are.

This process is critical, since it formalizes the role of gatekeeper that you _must_ play if you're going to be a successful lead, it forces the stakeholders to face up to the cost of their requests, and it creates a window to prioritize and reconcile requests before they get locked down. The best way to get that kind of system in place is to make it very transparant how you're managing those two lists--even if it's a simple Excel spreadsheet, keep an open list of feature requests/bug fixes, and use that as the core agenda for your weekly governance process, where you change the actual requirements and schedule. (This doesn't have to be a big meeting every week--it can just be something you do yourself, or with a couple of key people, and distribute. In general, though, you should have a governance meeting at least once a month with all the key stakeholders, to keep them involved, and more importantly, _force_ them to make decisions about priorities and deadlines on a regular basis.)

Hope that helps--maybe the best piece of stress management advice I can give you is that _every_ good project lead goes through this exact same stage. I used to have a recurring stress nightmare that I was taking my current boss' or client's car out for a spin, and crashed it--pretty transparent, huh? Get your sleep, get exercise, and find activities that can take your mind off your work (that aren't drinks or drugs). You'll be fine.
posted by LairBob at 5:45 AM on May 6, 2005

Bad leaders aren't the ones who say, "We're overworked... we're understaffed... and this project is getting away from us." Bad leaders are the ones who don't say anything, and let the project crumble around them in order to save face or protect their ego.

You have to go to your senior leadership and lay out what is going on. Point out that the staffing might have been right at one time, but it hasn't kept up with the project needs. Point out that the time and expense budget were created based on a specific set of needs and parameters, and as those have changed, the budgets haven't. Basically, just communicate your concerns. It's the easiest way to solve problems before they become problems.

Plus, it's much easier than finding an object small enough to actually cram up there... ;-)
posted by NotMyselfRightNow at 5:49 AM on May 6, 2005

I would sit down with another knowledgeable member of the team and scope out the work remaining to be done before going to the boss. Try to create some key choices for the boss and/or client. For example:

-These goals can be met with this number of staff by X date. We could get to these additional goals with the addition of one staff member by X date. Or these other goals by X date with two more staff members.

-These are the remaining large goals that need to be accomplished...what would the priority be in order to get to our end result by X date? Which goals could possibly be put on hold if we were pressed to the wall? How does putting certain goals on hold affect the outcome?

Then, when you talk to the boss, follow this pattern:

-I want this project to be successful for the client, and I am defining the bottom line of success as delivering (this large chunk of the project by X date) with these specific bugs corrected. I want to make sure this is what you're thinking too...is it?

-Okay, I've reviewed the remaining work that needs to be done in the time allowed and I have some decisions that I would like your input on...(talk about staffing issues and priorities here. Try to avoid saying things like, "This just can't be done", etc. Stick to "We can do that with this amount of staff by this later date OR we can do that with 2 more staff members by this earlier date.")

-If the boss becomes stubborn in his/her skewed expectations, calmly reassure them that you "...want the project to be a success, you don't want the client to be disappointed or surprised unnecessarily, you want to make sure that the work reflects extremely well on ABC Company. AND in order to deliver these results to the client, you're making sure that you have the resources to get this done correctly and efficiently by the deadline." You may have to repeat this a few times, in a calm way.

Three things are key here: Helping the boss or client to see the problem that is preventing them from reaching their desired goal, reassuring them that you are there to help them figure out how to make their project dreams come true without breaking the bank, and giving them some realistic choices about the situation (people respond much better to choices than to "We can't!")

If they still seem resistant, question them as to what might be behind their resistance. Are they worried about budget? Something else? Try to draw out their worries so that you can work on those issues together.

Best of luck to you.
posted by jeanmari at 6:04 AM on May 6, 2005

One broader point occurred to me after I wrote that last comment, and it kind of ties everything together--the most important response you can have to cope with your stress is to do something about it.

I'm not just talking about dealing with the underlying cause, like I had said before. I'm saying that the best way to help deal with the emotional impact of stress is to improve your sense of control over the situation. Most stress stems from--or is seriously compounded by--all the things you don't control. Asserting yourself and bringing more of the situation under your control goes a _long_ way to helping master your mental torment.

Just look at the way you've framed the whole situation--it's a list of the things that are being done to you. I'm not criticizing you for that, I'm just saying that that kind of passive position is typical of first-time project leads, and it can lead to enormous stress. Whether or not you can totally overhaul how the project is being handled, you will feel a lot less personal stress when you can look at some very specific actions you took to assert more control over things.
posted by LairBob at 7:21 AM on May 6, 2005

For what it's worth, if your product is in such demand, you may not have to make the requested changes in order to sell it. Have you a good code repository and changelog? Have you investigated something like Basecamp? These are basics for a reason.

Don't forget to take a big-picture, 40000 ft view of things. Where should this software be in 2 years? How should the project be running now and in 6 months? These sort of questions force you to pull back, take in more than small fires, and get some clarity.

One anecdote before I sign off. I was rebuilding a domain for the previous company I worked for. I had a fever at the time and was just running on auto-pilot. In front of me was my own documentation of what needed to be done and in what order, click by click style. My boss stopped by for an update. Clearly she was wanting everything back the way it was, but was pleased with the progress. She said something just before leaving me to my work. She said something to the effect that, "It's work. It will be here in the morning." There's a fair bit of wisdom in that.
posted by kc0dxh at 7:28 AM on May 6, 2005

[putting my librarian hat on]:
Software Project Survival Guide
Peopleware
The Mythical Man-Month
posted by matildaben at 8:03 AM on May 6, 2005

There was a long Slashdot thread some time ago (that I am unlikely to find) on some coping strategies for IT staff (not quite your position, of course).

The trick I found most interesting was having a large whiteboard with a ranked list of things to be done. Then when people come saying "I want this done!" you say "okay, I'm putting it here." "No, I want it done now!" you say "Okay, then this [obviously more important project] will be delayed." "Erm... don't do that... I want both done now!" "Okay, then you're going to have to provide us with more staff." Basically, a way to efficiently push the difficult decisions onto those making things difficult.

I'm hoping that everything could be better for you if you had a free hand to get more manpower on the job. If that would only slow things down (as is typical in software, apparently), then I have nothing to suggest, so I'm going to assume otherwise.

In that case, then, the basic problem is that you have responsibility (for your project) without power (to hire enough people). Go to your boss and present it that way. It sounds like you should have a bunch of pull, saying things like "My project's successful, so I'm doing something right, so you should entrust me with this extra power." Of course this depends on having an enlightened enough boss.
posted by Aknaton at 8:35 AM on May 6, 2005

look for a new job. get out now.
posted by andrew cooke at 9:57 AM on May 6, 2005

can you delegate any of it? aren't there any ambitious people on the team who would love to have a chance to keep track of things with you, or be in charge of a subset of the project?
posted by amberglow at 12:01 PM on May 6, 2005

Look at how much work--how many features, how many bugs--are addressed by per week per programmer, for example. And say, "If we had three more people on staff right now we could get done by the deadlines you are setting."

If you ask for more people don't forget to take into account the time needed to get them up to speed. Don't just assume that they'll plug in right away at x features/week or x bugs/week like the rest of the team. In fact, you'll likely be *less* productive until the new people settle in since you're probably going to have to devote some resources to training them.
posted by juv3nal at 12:08 AM on May 7, 2005

I agree that going to your boss with your recommendations for how to put this project back on track is a very good move. Shows you are thinking. When you come into "complain" or point out deficiencies it's critical to have alternatives ready to lay out.

I also agree that if you put these together that, in itself, will help reduce your stress (the stress is you feeling things are out of control --if you have ways to bring it back into control you will feel better).

Also, keep a paper trail. Put your concerns and your thought-out alternatives on paper. Never know when you might need it to show what really happened. This means, for example, after speaking to your boss about alternatives, send him/her an email outlining what you talked about. In fact, sending out minutes or notes of meetings with action points and who is responsible for each is a good way to reinforce workflow.
posted by Taken Outtacontext at 5:48 AM on May 7, 2005