Posted on: 2025-01-24

In this short essay, I'll explain why people who overload their time are not only inefficient but a detriment to a team. I will tackle the topic using the perspective of a software engineer, a project/product manager, and an engineering manager.

Before splitting into three different personas, the main idea is that when someone becomes overloaded, their focus, attention, and level of caring on any task drop drastically to the point that their contributions are more in appearance than in actual tangible work.

Software engineer

The first perspective is the software engineer who has so many tasks in parallel that the person becomes paralyzed in every task. While it seems that this person is busy, the actual work is reduced by a large factor. The issue of taking too many initiatives is the multiplication of bureaucracy, the lack of focus, no time for teamwork and overseeing details. For example, the engineer will need to be in a meeting specific to these tasks, give time estimates, and update on each project. But, also will need to understand different business logic and might get into different technical challenges. Each task comes with peer review, code review, documentation, and test. Supporting the features and other tasks accumulate to a point where the engineer does not have any time. At the end of the year, it looks at the surface that this person was always in all meetings and in so many situations that the person must be an overachiever. However, looking at someone who was doing less at the same time will often show that at the end of the year, that same amount of actual work was done. Not only that, there is a huge chance that the person who did not overload himself produced a better experience.

First of all, someone overloaded cannot provide good guidance, support, and side-improvement to the team. The pressure to deliver on so many features reduces the time to get involved with other engineers. The pressure usually leads to this engineer not following up on telemetry or trying to avoid any teamwork that is not directly touching one of the many tasks in play. Worse, being so involved in several tasks often leads to missing the bigger picture, creating technical debts that could be easily avoided.

Second, an overloaded engineer does not produce the best solution: just a solution that works now without a vision for the future or what could be better for the user. The engineer does not have the high-level perspective of using existing projects or libraries or simpler solutions. They are too busy even to take a small walk to think about how the user would use the system and realizing that it does not make sense does not occur. They rush building a solution, they do not question the specification or the design, nor try to be inventive. They are on the run to close the work ticket.

Third, other team members might create tools or libraries that are useful but the overloaded engineer does not have time to use them. They rush as fast as possible. They do not have time to learn, to iinstall or use anything they do not already know. Someone might have a new tool to get real-time errors but it does not matter because the priority is not having something stable and carrying once something is released, it is to blitz to the next feature to code to gain a bullet point which will be useful for the performance review at the end of the year. The result generates non-generic code, barely tested functionality, and lacks all the quality that the team might have agreed upon but the engineering managers or other people who influence the end-of-year results won’t know – they are also too busy. Often, these leads in the future to a re-write pivoted into a “version 2.0”.

Product manager

The overloaded product manager works on the visibility and forgets the content of each task. They are so involved in different visible projects that they are always in meetings. They barely add thought to any project. Maybe early on when the project has the spotlight and gets the green light to move forward. Then, the product manager becomes a project manager who falls into the trap of micromanaging and asks about the end date without trying to iterate with the engineers about what could be better as the engineer brings more information. An overloaded project manager is never sitting in the team room and does not have the time to actually play with the demo or try to get deeper to understand the initial need of the user. For the engineer, it is hard to get a grasp of the product manager to bounce ideas as the project manager is already trying to get the next project going. The problem is that schedule shifts, bugs appear, and priority changes. A project manager might have been implicated in 20 different initiatives but 5 was really tangible. With an overloaded project manager, features often derail or the expectations are not aligned. Even with the many recurrent meetings, the overloaded project manager is so overloaded that the information is not really taken into consideration. In the meeting, the overloaded project manager is already using Slack and Microsoft Team to answer messages about other projects -- listening but not understanding important details.

Overloaded project manager misses the obvious and fail to improve their documents from project to project because they are already running miles away but also fall into the trap of adding more and more meetings when there is some confusion. The confusion happens more and more as projects are long creating a pile of Slack threads, documents, and meetings which all could be avoided with the right focus, synthesizing, refining, iterating, and keeping simple every task. Simple features become a multiple-phase initiative. A project that would take 1 month becomes 4 months.

The communication becomes complicated without a real need to. Information is spread into different documents, wiki, emails, Slack messages (public, private, or group one), and verbal communication. In the end, the project manager has no time to summarize and have a source of truth leading to many people referring to different versions of what needs to be done. The solution is mostly another meeting causing everyone already overloaded to be even more.

Engineering manager

An overloaded manager loses track of what everybody in the team is really doing. The great technical improvement is lost in the sea of delivering features. They are dragged into meetings with product managers and then with 1-1 with the team which ends up being not 1-1 but just status updates. They have a hard time keeping track of engineering matters and delegate every engineering decision to the most senior people on the team. These senior engineers become half engineer, half manager. Questioning the over-delegation does not happen because of the popular belief that a good manager knows how to delegate. Weeks and months pass and the overloaded manager collects initiatives across the organization. They are hard to reach, hard to talk, and hard to just have a basic discussion about how we could improve engineering work.

In every management and leadership book, we read that people should develop below and above their grade but the overbooked engineer manager almost only develops upper relations as it is what benefits them the most long term. The quality of "leader" fades as the engineering manager does not lead anymore. The senior engineers are the drivers of the engineering practices and the engineering manager becomes simply a "people manager" who acts as a proxy between software engineers and other team managers or product managers.

Conclusion

I've barely touched the topic. Nuances are missing. However, the goal of this post was to bring light toward a phenomenon that keeps increasing as it becomes more and more popular to focus on "impact" and "KPI" (key performance indicator) and "hustling", etc. However, the reality is that in most cases, it only creates an illusion of doing more while it actually costs every company a lot. Software engineers want to create a good product and code but struggle. The product manager would like to follow up on their project as if it were their baby but just cannot be invested. I know many engineering managers who would like to focus more on engineering but there aren't incentives besides checking checkboxes on a few high visibility improvements leaving many engineering challenges unresolved and without time for the engineers to tackle.

Avoiding overloaded people requires a different organizational mindset than the one described. Having engineers focus on a single task (fixing bugs and technical debts) is key. The project manager should focus on the actual now task and partially prepare the next one—that’s it. Engineering managers must focus half their time on their staff below, having time for them and understanding their daily struggle to prioritize a healthy balance between features and developing a framework that makes the work easier to do.

Reducing the number of meetings to only the ones useful. If someone does not participate actively in a meeting, that person should not be there. People in a meeting should end the meeting with actual benefits like having questions answered or having a clear plan of what to do. At the end of the meeting, if you cannot say “That was useful, I am now in a way better position to accomplish what I need to do” then it wasn’t a good meeting. Trimming the number of people to the minimum as possible and sharing the overview in a written form is more effective

The problem is that thinking about making meetings efficient, making the work environment more productive, and ensuring everyone is fully committed to doing their best requires some perspective, and to do so, people need the time to think.