Is maintaining 10-15 projects simultaneously considered normal for a software engineer in a small company?

Question

I am working in a very small software company (2 developers - I am a senior one and an intern, and 2 designers) for 3 years. The working environment of this company is good. I worked very happily for them, but when time goes, I feel like very stressed out.

I have started around 7-8 projects in these 3 years and updated around 7-8 old projects also. So currently I have involved more than 15 projects. New requirements/ changes are coming each month for all old projects.

It is very hard to remember and working all projects together. Each month I am working a maximum of 3-4 projects. Next month another 3-4 project, etc.

Still, I feel like this is very stressful. The problem was not in my first two years because I have involved only a few projects.

Is this a normal situation for software engineers? Or is this the time for looking for new jobs?

Update: After SRS is approved, I have finished most projects within around 100 - 300 hours which means some projects can be done using 100 hours and some project need around 300 hours (not included documentation time, designer time, etc). So I think these are small projects, isn't it? I added this part just to give an idea about project scope.

Answer 1

I have started around 7-8 projects in these 3 years and updated around 7-8 old projects also. So currently I have involved more than 15 projects. New requirements/ changes are coming each month for all old projects. So it is very hard to remember and working all projects together.

All of these points to the fact that your company is seriously under-staffed. Given the description, I simply do not see how it is realistically possible for two people to handle the load you mentioned (unless all the work is very localized and contains activities that takes very less time).

Is this a normal situation for software engineers?

No, not at all. The most efficient way of multi-tasking is to focus on one thing at a time. Yes, you read it write, focusing on one important thing at a time and getting that to completion actually yields much better output than trying to multitask with several things.

Some suggestions:

First, do not commit / accept any work unless you know you have the time to work on it. Making false commitments (i.e, fail to deliver because of poor planning) is worse than refusing to accept and re-scheduling at a later point of time when it can be taken up and completed. You need to prioritize the activities.

• If you're in a position to take the call, do it.
• If you have a manager / supervisor who can help you in getting the tasks prioritized, ask / involve them.

This will ensure you are only commuting to the tasks you can cover, without the need of stressing too much about the other things you need to complete.

Then, also talk to your manager / boss / CEO and ask them to recruit new engineers to help you out. Given the workload, it clearly indicates your organization has enough work to be done, however, every individual can only accomplish a certain amount of task, so if more work needs to be done, we need more employees / engineers. It's that simple.

Finally, if (or after) you have already presented the scenario and the situation did not improve - yes, you need to look elsewhere.

Answer 2

There's a big difference between

• I've done active work on 15 different projects in the last 4 years
• I'm supposed to be working on 15 different projects right now.

The area I'm in right now has 3 people, and we easily have more than 15 projects under our responsibility. But we're not actively working on all of them at any given point in time. In fact, we're generally never working on more than 1-2 of them at any given point in time - because as another answer said: multitasking only works when you focus on one thing.

Instead, I would focus on Work Management. How are you managing what you're supposed to be working on, what you're doing, what your timescales are, etc? Honestly, this situation is something that screams 'KANBAN' to me.

Basically, the short story of Kanban is you have a pool of work that needs to get done. You also have categories for 'In Progress', 'Hold', and 'Done' - along with limits to the number of items you can pull into any of those categories. Does someone want you to work on something? Add it to the pool. Finish a task and need to find something else to work on? Get the highest priority item from the pool. Does someone want you to work on something right this moment? Well... depends on whether you've got an opening in your 'In Progress' section. Basically, its a framework built around avoiding pervasive, vampiric multitasking.

The beauty is, you may have 15 projects... but you're only touching a few of them at any given point in time. You don't waste loads of time 'Context Switching' - you get to focus on a task, finish it, and move on to the next one.

Answer 3

You asked,

Is this a normal situation for software engineers?

That's a tough question to answer without a lot of context - some software engineers may only have one or two projects that last years while others may do 15 or 20 projects in a given year. It's probably more typical for the latter to be the case in smaller companies where software is a means to an end (versus the company's actual product) - for instance, your situation is probably quite common for a team of 4 engineers in a small community bank, versus uncommon for a team of 200 engineers at a software vendor or consulting firm.

That said, you commented,

It is very hard to remember and working all projects together. Each month I am working a maximum of 3-4 projects. Next month another 3-4 project, etc.

Still, I feel like this is very stressful

In order to address your stress, you need to ensure you're attributing it correctly. Are you stressed because of a large backlog of work? Or are you stressed because there's no mechanism in place to help you manage the backlog of work? If you have a constant queue of 15 or 20 projects, and you're working on 3 or 4 at a time, that doesn't strike me as unusual or even stressful, unless you're missing a method or process to manage the backlog - which usually means your "management" approach is to work on whatever project you're getting the most pressure about at that very moment, which can be very stressful regardless of the size of your backlog.

You haven't provided any information on your work management process, so it's hard to give specific feedback - but if you don't have a ticketing system or project management system, and you're managing work based on emails or phone calls or other informal methods, it might be time to suggest something more formal. If you haven't done so yet, you should consider having an honest conversation with your manager, where you can describe what's causing your stress - good managers are invested in helping their team perform, and a stressed employee is rarely a performing employee.

Answer 4

Is this a normal situation for software engineers? Or is this the time for looking for new jobs?

This is a sign both the company is growing and that you are growing expertise on the company software, and as such you are asked to handle a wider variety of task. For this part, it is "normal" as in to be expected if the company don't have the money/the objective to hire. Note that it might not be a smart career move to quit now than they rely so much on you.

What isn't normal however, is that you are asked to work at unsustainable pace, or asked to deliver features for unrealistic deadlines. You should be able to exert some resistance to tasks handed to you, in order to slow it down and make it manageable: question tasks priority between each other, question deadline extensibility, and question feasibility in given deadline, until you have a clear schedule of doing things one by one at reasonable pace.

Answer 5

I will answer per the OP question but also the following comment of OP :

All things like documentation, customer support, preparing SRS do me and the intern. Actually, 90% of the work done by me since the intern developer just learning everything... But all design related works and support request, documentation related to design do other two designers. –

That means you're doing project management and developper instead of just developing.

Since you're doing project management and you are overloaded your best bet is to actually learn to delegate. Pick up from your intern the projects that are the most easy and delegate every developement to him. By delegating specifics projects, you are asking him to specialize in those projects and let the others to you. This is, IMHO, the best way to have your intern help you as fast as possible.

As for what can happens :

• If the intern seems like really unable to be helpful, have a talk with your boss about it.
• If the intern has been successfully behing helpful and the workload is still too big. It's time for you to choose if you're interested in doing only project management or developer and ask your boss to get someone, or hire, doing the other. Since you have being already managing everything, you should have a decent chance to ask for becoming project manager and ask a raise for it. Of course that is only if it's what you want.

Answer 6

Ift depends. It depends on the amount of maintenance you've got to do for each. I've been in a position to maintain, in a team of 2, 36 banking batches, some of them very old & very big.

It worked.

It worked, but most of them required my attention maybe once or twice for the 3 years I spent there. One of them, not even the biggest one, 50% of those 3 years.

So, to answer to your stated question, there is no norm. It just depends on the actual amount of job. Which leads us to the underlying question, which Walfrat indirectly answers : do you have too much work to do? from what I read, yes : all those projects are active, it seems. And that's a workload problem. It's not the number of projects, which is a problem, it's your overall workload.

I'd then advise to measure the time you need for each maintenance, and compare it against the number of maintenance you are required to do. With some metrics, convincing management that you need someone to help should be more doable. The number of apps is not a sellable metrics. The sheer amount of work hours is.