The article discusses the creation of the self-managed nodes in engineering teams as a strategy to reasonably decrease the personal involvement of Project Managers in tasks outside the project management plan scope, ensure project success, and avoid job burnout. The author of the article is Mikhail Mamontov who managed engineers at Auriga in 2015-2019.
Like many fellow Project Managers (PM), I used to be a software engineer programmer, mostly for embedded and system-level software. My personal role switch triggered various professional challenges, including the desire to track and solve engineering tasks myself while also trying to fulfill my new management tasks. Obviously, this greatly affected the project management plan. One might consider this a good mitigation plan against the risks of poor-quality operations; however, it is in fact a bad trade-off for unhealthy processes and missed opportunities that can jeopardize entire projects. My team delivers R&D services to a major international corporation; there are more research efforts in this than development, thus the employees assigned to the project are oriented toward engineering than programming.
Engineers grow into managers, which means that they generally understand technical details well. Such promotions will accelerate poor micromanagement practices when managers are anxious to give advice and help resolve engineering issues independently. This creates an ineffective team culture and improper expectations from managers: they become decision-makers in areas of responsibility that are normally assigned to engineers. At the same time, robust and healthy project management assumes that managers are supposed to decide what to do (manage scope), but not how to do it.
In a small team, when the manager takes part in product development and is ready to answer any technical question immediately, it might be somewhat effective and natural for a manager to interfere in engineers’ areas of responsibility. However, as we transfer to big or geographically distributed/remote teams, it is somewhat impossible to evaluate quickly whether a task has been performed correctly. A simple technical question from an engineer might require that a manager reproduce all engineering efforts. If it requires an equitable amount of time, there is often no need to bring an engineer in the first place. More importantly, engineers may get used to managers handling all of their questions and start approaching management with questions on a regular basis. As a team grows, the manager has to work overtime. In the best-case scenario, the time leftover is quite enough for checking the inbox and completing a few important and urgent tasks (as per the Eisenhower matrix). The manager has no time left over for project management plans including requirements analysis, work breakdown structure (WBS), reporting, budget management, timeline planning, changes, and risk management; moreover, being totally overloaded with operational management means that the manager is incapable of generating strategic ideas.
There are two straightforward ways to resolve this issue:
- Work overtime
- Affects the work–life balance and leads to burnout
- There is a limit to the number of overtime hours one can work per week
- Consider engineering tasks as low-priority
- Complete project duties first and then validate engineering tasks, which often results in too little time scheduled for the latter. While this is a better option, it is still insufficiently effective because the manager keeps making non-managerial decisions and loses engineering competency, thus risking the approval of invalid decisions by an engineer.
The strange rule of thumb here notes that a healthy team is managed by a leader who does not understand the technical details. This allows the manager to decrease the level of their workload that is not required to perform their management duties while not compromising their professional development.
Project Machine
There is another way to address the disadvantages of the above options while significantly reducing the manager’s workload and leaving space in the timetable for project-related tasks.
To drive a vehicle, one does not have to know how it works. It is sufficient to set a direction (define the scope) and speed (resources). Like vehicle parts (e.g. the engine or braking system), engineering teams are capable of working independently from the driver. It is a good idea to arrange subprojects, performed by sub-teams (like vehicle nodes). These nodes are capable of resolving local issues and overcoming minor difficulties and are self-efficient to some extent, being responsible for scheduling and changes, risks, and visibility management (reports and communication). However, the manager needs to manage the scope, bring in and take out resources, and prioritize tasks based on a project-wide vision. This type of team organization prevents managers from participating in technical discussions on behalf of their engineers and does not trade project management time for diving into technical details, thus avoiding duplicating engineers’ efforts, and does not stimulate an improper mindset (“I’m a programmer—my duty is to write code”). In nodes of ≥3 engineers, the PM needs to transfer ownership to a leading engineer in the subproject called the First Line Manager (FLM). The FLM should possess strong technical expertise, leadership skills, initiative and—preferably—a solid business understanding.
Once a node has been built, the manager lets it handle all operational tasks and some minor project tasks while some others can be delegated later:
- Requirements analysis, building WBS, and operations estimations. This can be done together by all node engineers in cooperation to increase their involvement and encourage sharing responsibility for deadlines with the manager.
- Building a timetable. Initially created by the manager with the FLM, the latter should keep track of any changes.
- Reporting. Initially, reports are created by all members, then using the review, and afterward commented post factum.
- Risk and mitigation plans—the PM defines the plans and appoints FLMs as owners.
The manager completely retires from participating in the development process and delegates some project tasks to FLMs as they become capable of performing them. This allows the PM to be almost invisibly around in every subproject while cutting him free from unnecessary and time-consuming routines.
Nodes can be managed via individual sync-ups on an “as needed” basis and by bringing all FLMs together on regular weekly sync-ups—usually to discuss risks and opportunities (be careful to avoid round-table status reporting). Based on my personal experience, a manager can easily control three or four nodes. Please note that the main purpose of increasing the node amount in a project is to decrease your workload. It means that—regardless of the number of nodes—it is always preferable to add a node rather than to leave some engineers directly reporting to you. If there are too many nodes in a project, it makes sense to review the organization structure.
Some managers are afraid of becoming some sort of King Lear—delegating to the extent where they lose their authority, control over the situation, and primarily, their power. However, this should not be a concern—a manager guided by personal interests is professionally unfit. Normally, PM’s goals should align with the general corporate goals and this has several positive side-effects:
- Extending the responsibilities of subordinate employees accelerates their professional development, increases corporate loyalty for both the team and their manager, retains personnel, and mitigates the risk of losing a key manager in the middle of the project. I gained management experience after my supervisor granted me the responsibility for a new subproject of six engineers, and I sprang up to manage several teams and handle project management tasks.
- While managers can take a day off, go on vacation, or leave the company, projects continue. All my teams are capable of working independently and can operate smoothly despite any manager absences. Some opportunities will of course be missed, but stagnation will quickly turn into prosperity and new team leads will appear.
- Balancing managers’ workloads improves their project processes, effectively boosts managers’ personal development, and enables strategic thinking, thus increasing project efficiency.
Managers are used to being heroes and act accordingly; they take responsibility for everything, have answers to all questions, make bold decisions if necessary, although they spend most of their time keeping the corporate boat from swaying. Now they must go further and make their employees heroes. (Alan R. Cohen)
