My vacation stand-in told me, he had to do overtime for two weeks straight in order to handle the workload and today I want to share with you how I reacted. But let's start at the beginning.
How did it come to this?
It all happened in the project team I am currently leading.
My vacation plans for this year were overlapping with the other senior developer in that project by two whole weeks. Which is bad! Because we both would usually be the stand in for the other. The only way this would be feasible is when we both found someone willing to keep the ball rolling while we are gone.
A not-yet senior developer in the team, we both regard highly, came to mind and since he plans to join the senior ranks, we thought it would be great opportunity for him to see what it could be like.
The idea was that we would prepare tasks in advance to be distributed to the other team members. This way, he could focus on supporting them.
Unfortunately, it did not work out as planned. Even shortly before our vacations, it was not clear whether we could get the most important requirements to a workable state. This is due to general difficulties in the project, but this is an entirely different story.
After all, we managed to formulate a plan and have some tasks ready for the upcoming two weeks. So, we took our well-deserved leave, even though we were feeling some remorse.
How did it go
We rightfully placed our trust in him. The team might not have progressed slower than usual, but at least no one was twiddling their thumbs during the two weeks - which was the scenario we were afraid off the most.
Once I acclimated myself back at work, I managed two have a one on one chat with the brave stand-in, so here is what he told me.
In general, he did enjoy the new challenges greatly. He never had to coordinate a team before, but doing so felt very rewarding. His first priority was to support the rest of the team whenever possible. Mostly in the form of requirement clarification and code reviews.
This would come at a cost though.
All his time was spent while making sure everyone else is able to work. Yet, he did not want to disappoint us, so after a day full of meetings and support, he would do overtime in the evening, where he worked on his own tasks.
This was going on for the entirety of the two weeks.
My reaction
My first reaction was to thank him for this dedication and effort, I was thankful for him to go the extra mile.
But, I was not happy, because it seemed unnecessary to me, so I told him he does not have to do that the next time.
If he had not gone this extra mile and told me that his entire day would have been spend with supporting his team members, leaving no time to work on anything himself, then I would have understood that.
Together with him, we would have discussed strategies on how to move his task forward, so we can make the target date.
Now, you might be wondering why I make a big fuzz out of some overtime. A bit of crunch is naturally part of the job, right?
To understand my aversion against overtime we have to look at ...
The bigger picture
The first thing you need to understand is, that the project we are talking about is somewhat ... problematic.
It started out chaotic, with no clear target picture and a lack of strong leadership. Which was the reason why I joined it and I was able to create some structure and got us moving forward. With the initial hurdle cleared, it soon became clear that it is going to be a tight one.
With the months passing, the timeline becomes only more unrealistic because we are slowly unveiling what is actually expected from us.
This situation creates massive pressure on our developers. Since they are still inexperienced, they do not know how to handle it. Which often means that they to compensate for the delay.
But, individual contributors should never feel responsible for the state of a delayed project.
It is not their fault and it is not in their power to fix it. The reasons for a delayed project rarely lie in a lack of dedication of the team. It is more likely due to bad planning, too many parallel tasks, communication issues between stakeholder etc.
Instead what they should do, is to make this transparent. They should voice their concerns with a dead line that is too tight. Then we can search for ways to solve the issue as a team.
Closing thoughts
Going back to the initial story, it hopefully is clearer that my reaction was the way it was, because it was the latest example of a developer doing more work than necessary. Something that is rarely seen nor appreciated.
Have you experienced similar situations in the past? If so, I would really like to know how you have handled it.
Want to be informed every time I publish something new? Then subscribe to my substack
Top comments (0)