How to stop feeling overwhelmed when asked to deliver a project?

Question

I am senior software engineer, and have done pretty much as 10 projects till date. But last year I was given a task to lead a team which had a continous scope creeps, and I had to deal with lots of pressure and the work took a toll on my health.

Recently, I have been slacking and don't consider any work due to the negativity I encountered in my last project. Whenever a new project is given to me or new task is given to me, I do it really quickly until my interest starts to wane after a few repetitions. I always try to do my best in the beginning and then start to lose interest.

I feel really overwhelmed to conside taking any kind of project as I start imagining the risks associated with it. Another problem is completing the task totally. I don't know if there is any better way to put it, I would love to know from others, how they tackle tasks and complete the project without feeling overwhelmed and deliver the project. I have so many side projects, which never see the light of the day.

Major problems I wish to tackle: 1. Feeling overwhelmed when given a project/task and thinking about not able to deliver it on time.(commitment phobic) 2. Unable to stay focussed on a project whose requirements keep changing.

Thanks

Answer 1

Let me start with this piece of advice from Neil Gaiman:

https://www.youtube.com/watch?v=aFiXZCzzHF4

"Finish things."

And I struggled with it for a long time. Still struggle with it from time to time. I used to start a lot of projects, finished maybe tenth of them, if even that much. So I recognized it as a problem that needs to be solved. Now I finish 7-9 out of 10 I start. Not perfect, but getting there :)

The trouble for me are things with no external incentives or deadlines to finish them.

So here's how I fight those urges and "solved" it, with occasional lapses.

3 things:

1. time yourself and recognize the moment
2. small chunks
3. work every day, track your progress and push through

1) time yourself and recognize the moment

This one is experiment you do on yourself, gathering data about your base behavior. Start the brand new side project. Something you think is really cool. Work on it, mark in a notebook every day you worked on the project, even if with one sentence. Just Date, Started At: 20:17, Finished At: 21:05, Short Description (implemented login page).

Don't try to push yourself just to prove a point. Do what you would usually do on your side projects, just record it in a notebook. See how long you can keep your attention on the project. Then try to recognize a moment when it stops being fun. The moment you start to laze off. The moment you would rather do or start something else. The moment you lose interest, you feel tired and don't want to do the boring thing. Maybe you need to write 12 basic tests for your code which is boring work but will save you time later. Maybe you need to spend 2 hours to setup an environment. Whatever it is, remember it.

Remember that moment, mark it in a notebook with red ink. Keep on with your life, marking in the notebook every time you do some work on your side project. When you haven't worked on your side project for 3 days in a row, stop the experiment. You're done. If it is not finished by then, it probably won't be finished at all.

Count the days, the amount of time you worked on a project. Two weeks, a month, two months, whatever. That's your baseline. That's how long you keep your attention on the side projects. That is the amount of time you have to finish whatever personal project you start (at first. with practice you can prolong that time. But lets not rush too much). I'll be back there later, in later points.

2) small chunks

Start with a goal. Make a plan how to accomplish it before you start the next side project. Divide it into large chunks, then into smallest chunks/ tasks. Every large chunk needs to be a whole, just big enough thing that you can call finished. The large chunk can't be larger and take more time than your baseline from point 1. Those are your limits, that's how long you are interested in the projects you start. Until we push them, this is what you have to work with.

Try to recognize at which points in the project you might get bored. Note them on the plan. Write every task on a Post it note. Write what counts as finished task. Write down two things: 1 page -1 sentence every point list of things which worry and make you anxious about the project and 1 document detailing the list. Put five checkboxes by each item on the short, one sentence per point list. Check the list once a week. If the thing you worry comes to pass, mark it in the checkbox. If it doesn't that week, crisscross it.

Now you have a plan. Now you have a design document. Stick to it. No more scope creep. Any new cool feature must wait until you finish the current project. Have a separate notebook or word document where you list your cool ideas for a future feature. Then once your side project is actually finished make a new project with the goal of implementing that feature.

Start the side project.

3) work every day, track your progress and push through

Reserve 20 minutes every day for working on the new side project of your choosing, preferably at the same time every day. Forgive yourself if you miss one day but make sure that you work on it the next day. At least 5 minutes on the project. After every session, write in your notebook, with pencil on paper, what you worked on that day. Date, task, short description.

When you recognize the boring parts of the project, push through them. Make yourself do it. Force yourself to work on the boring parts for at least 5 minutes every day. Set alarm clock to 5 minutes, but work on it. What's 5 minutes? It is nothing. Everybody can work for 5 minutes.

Now you're tracking your progress in the notebook. You need to track it more. Take a ruler, a pencil and a piece of A4 or letter paper and draw a 30 day calendar. Starting tomorrow. 13th June, 14th June, etc. Up to 14th July. 5 rows, 7 columns. Draw it, mark the days. Every time you work on the side project, cross the day on the calendar you have just drawn. 5 minutes is worth the X, X marks the spot. Put finished post its into shoebox.

After the first month, look at the calendar, look at the notebook, look into your shoebox. Is the project finished? If yes, cool. If no, it doesn't matter, it will be done. Look how much we accomplished already! Look at all those Xs. Look at all those post-its in the shoebox! You should be proud, but keep on working. Draw another calendar. Can be on the same piece of paper, can be on another one. Keep marking every day you worked on your project.

And one day, the project will be done. And every day, forgive yourself if you do not work on project that day, but promise that you will work on it tomorrow, if only for 5 minutes.

And this works on everything that usually doesn't have set goals or deadlines. Physical exercise, learning new language, side projects.

With these things you are training yourself that it is okay to be bored sometimes, you are training yourself to track your progress, you are training yourself to commit yourself to the goal. You're training yourself to limit the scope to what you can accomplish in the time you have and at the same time prolonging that time you can work on a project. You are forming a habit.

Chunking things and making plans helps with number 1. (1. Feeling overwhelmed when given a project/task and thinking about not able to deliver it on time.(commitment phobic) )

Planing also helps with 2 (Unable to stay focussed on a project whose requirements keep changing) by preventing change of requirements until the project is finished.

It should be a general rule in software development but it is often ignored these days: once you finish the analysis, requirements are set into a design document and signed by business. Business says "Ok, we agree on this. This is what you do." . The requirements are not supposed to change much until the project is finished.

If they do change too much, you either scrap the project and replace it with a new one or finish the current project and follow it immediately with a new one with changed requirements.

I hope you will find this helpful.

Answer 2

Since you've done 10 projects, I assume you know how to do a project. You've managed scope creep and such before. But what I am hearing is that since this last project was so bad, you've gotten a bad case of burnout.

Over the last 5 years there's been a lot written about engineer burnout and a lot of tips on how to avoid and/or recover from it. But to TL;DR it, the answer isn't "do your work better!", it's that you need a break. A long vacation or sabbatical; a project not under pressure or that you're not leading; hobbies or other things to reduce general stress in your life.

John Willis has done a bunch of talks and podcasts and such on burnout - here's one that you might find worthwhile.

Answer 3

I have the same problem from time to time, especially with projects that are boring or those I don't like doing. If you don't have a manager that's asking for updates on a continual basis, then you need to self-monitor and get these done so you can move them off your plate.

Make a list of projects and what needs done. As you get them done, check off those items. I find that finishing those and then marking through them or deleting them gives me satisfaction.

Answer 4

Major problems I wish to tackle: 1. Feeling overwhelmed when given a project/task and thinking about not able to deliver it on time.(commitment phobic) 2. Unable to stay focused on a project whose requirements keep changing.

Feeling overwhelmed when given a project/task and thinking about not able to deliver it on time.

First of all, what you are feeling is normal. When you are coming from a software engineering role you are used to having certainty. In fact, when you are an engineer, you can't really do your job without 100% certainty. When you make a commitment as an engineer, you're making it with 100% of the information you need to make it.

Then you transition over to a management role (I mean management as not necessarily man management, but delivery responsibility), and suddenly you are asked to deal with uncertainty all the time. Now when you make a commitment, you only have 50% of the information you need to make it. This is very unnerving, and probably contributes to your stress levels.

However, the important thing to realise is that your manager still needs you to make a commitment, because she needs that information to make a commitment to her manager, etc. It's like a tower, where the higher you go, the available information gets less, and the pressure to deliver increases. So you have to make a commitment. But you should also realise that your commitment is not so much a commitment to deliver the software by a certain date, but rather a commitment based on the available information, and one which will be refined at a later date when more information becomes available.

The thing is, no-one expects you to be able to predict the future. Everyone knows that delivering a given number of software features takes as long as it takes. It's not an activity which can be compressed that much. Yes, the constant pressure to deliver on time can weigh on you, but that is a trade off you accept when you also accept accountability for delivering software. And when you are accountable for something, you gain something very valuable called autonomy.

So there's no magic bullet for not feeling overwhelmed by it, but by considering the true nature of what your commitment means, it can help.

Unable to stay focused on a project whose requirements keep changing.

I get this. You do a whole load of up front work on analysis and design based on meticulously documented requirements, and then during the first week of the project your manager introduces a completely new feature. What's more, the delivery date stays the same. "The project can't slip because of this extra scope..." says your manager. This can certainly suck the wind out of your sails and be a huge demotivating factor.

However, you should start to see scope creep as a fact of life. And actually, scope creep should be welcomed. Scope creep equals requirements, and meeting requirements delivers value to the people who are paying for the project. You see, even though your boss or their boss is saying that the new scope creep shouldn't impact the delivery commitment, they have to say that. It's not what they actually believe. But they have made a decision: it's better to have the feature and deliver late, than not have the feature and deliver on time. But of course they can't say this. When you deliver late, well what did they expect? they added scope into a fixed-duration project.

Now, as the person with the autonomy to deliver this software, your job is straightforward: deliver the requirements which your manager says are the highest priority. If they refuse to prioritise, then you do it. They made you accountable. That's what having autonomy means - you can make your own decisions. And an excellent way to be motivated and focused on a task is by having autonomy over it.