Two weeks of overtime: what I told him

Story about avoiding overtime in software projects: planning, transparency, and team well-being; strategies for prioritizing and reallocating resources.

domingo, 17 de agosto de 2025 • 5 min read • Q2BSTUDIO Team

Artificial-Intelligence-

My substitute during the holidays told me he had to work overtime for two straight weeks to handle the workload, and today I want to share how I reacted. But let's start from the beginning.

It all happened in the project team I'm currently leading. My vacation plans this year overlapped with those of another senior developer on the project for two full weeks. This is problematic because we usually cover for each other. The only viable way was to find someone willing to keep up the pace while we were away.

We thought of a developer on the team who wasn't senior yet but whom we value highly. Since he intends to get promoted, we thought it would be a great opportunity for him to see what it's like to coordinate the team and manage additional responsibilities.

The idea was to prepare tasks in advance and distribute them among team members so he could focus on supporting them. Unfortunately, it didn't go exactly as we had planned. Even shortly before our vacation, it wasn't clear whether we could get the most important requirements into a workable state. This is due to general project difficulties, but that's another story.

In the end, we managed to formulate a plan and leave some tasks ready for the two weeks we were going to be away, so we took our well-deserved break with a certain sense of remorse.

We trusted him with good reason. The team didn't move slower than usual and, most importantly, no one was idle during those two weeks, which was our biggest fear.

When I returned, I had a one-on-one chat with the brave substitute, and this is what he told me. Overall, he really enjoyed the new challenges. He had never coordinated a team before, and doing so was very rewarding for him. His priority was to support the rest of the team whenever possible, especially by clarifying requirements and reviewing code.

But this came at a cost. All his time was consumed by making sure others could work. He didn't want to disappoint us, so after a day full of meetings and support, he stayed late working overtime at night to make progress on his own tasks. This went on for the full two weeks.

My first reaction was to thank him for his dedication and effort; I appreciated that he had gone the extra mile. However, I was also concerned because it seemed unnecessary to me, so I told him he didn't have to repeat it next time.

If he had told us from the start that his day was consumed by supporting colleagues and that he had no time left to make progress on his personal tasks, I would have understood. We would have discussed strategies together to move his tasks forward and meet the target dates as a team.

You might wonder why I place so much emphasis on some overtime. An intense work period is part of the job, true. To understand my aversion to overtime, you have to look at the broader context.

The project we're talking about is actually problematic. It started chaotically, without a clear target picture and with a lack of strong leadership. That's why I joined and was able to bring structure and get us moving forward. With the initial obstacle overcome, it soon became clear that the deadlines were going to be tight.

As the months went by, the timeline became increasingly unrealistic as we discovered what was really expected of us. This situation creates great pressure on developers. Being relatively inexperienced, they don't always know how to manage it, and many times they choose to compensate for the delay by putting in more hours.

Individual contributors should never feel responsible for the state of a delayed project. It's not their fault, and it's not within their power to fully resolve it. The causes are usually poor planning, too many tasks in parallel, and communication issues with stakeholders, among others.

What they should do is be transparent about the situation and voice their concerns when a deadline is too tight. That way we can look for solutions as a team: rethink priorities, reallocate resources, or negotiate deadlines with stakeholders.

Going back to the initial story, my reaction was firm because it was the most recent example of a developer doing more work than necessary, a behavior that is rarely detected or properly appreciated. We prefer to encourage communication so that no one has to systematically sacrifice their personal time.

At Q2BSTUDIO, a company specialized in custom software and application development, custom software services, artificial intelligence and artificial intelligence for business, cybersecurity, and aws and azure cloud services, we believe that team health and proper planning are key to success. We offer business intelligence services, AI agents, and power bi solutions to help organizations make data-driven decisions and optimize processes. Our experience in AI for business and in implementing secure systems ensures that projects move forward without overloading teams with unnecessary overtime.

If you've experienced similar situations, I'd like to know how you handled them. If you want to stay informed every time I publish new content, look for my substack and subscribe to my newsletter to receive updates. If you need support with custom software projects, artificial intelligence, cybersecurity, aws and azure cloud services, business intelligence services, AI agents, or power bi, contact Q2BSTUDIO and we'll be happy to help you define priorities, plan resources, and prevent the burden from falling on the wrong people.

Thank you for reading and for supporting a sustainable work culture where communication, transparency, and the right technology reduce the need for overtime and improve both product quality and team well-being.

OUR SERVICES

How we can help you

Do you have a project in mind?

Tell us your vision and we'll turn it into a software solution. Whatever the scope, we make your idea real.