Friday, June 12, 2015

The meddler

This is a true story. The company name has been changed.

Changing direction

Acme Corporation, a manufacturer, was building a new data warehouse with multi-dimensional analysis and reporting capabilities. There were two main teams, one building the technical infrastructure and one developing the multi-dimensional cubes and reports.

The project was already underway when the project manager left and a new project manager was hired. At the first technical team meeting after the new project manager joined, the technical team lead discovered that his team was trying a new approach instead of what had been agreed as the path to developing the technical architecture. The team members explained that the project manager had decided that they should try a different approach. The technical lead spoke with the project manager to find out why he had been left out of the discussion. The project manager was surprised. She had certainly not intended to leave out the team lead. She had dropped by to discuss a different matter, when an informal discussion on the technical progress had come up and the change in direction had been agreed. The technical lead pointed out to the project manager that once the discussion turned to alternative approaches, he should have been involved in the discussion. At the very least, he should have been informed of the outcome, as it affected his team’s scheduled tasks and his resources. The project manager hadn’t meant to leave out the team lead, the new approach was a good one, and so she didn’t see the harm.

A few days later, the technical lead discovered a member of his team was working on a different assignment. The project manager had approved the reassignment. The team lead discussed this change with the project manager, who explained that she had just bumped into the other project manager in the elevator. This had not been a formal meeting. The other project manager happened to have been short-handed, so she had agreed that the team member could help out. Again, the technical lead protested that he had been left out of the decision and not been informed. The project manager didn’t think this was a problem. After all, the technical lead had not been left out deliberately, it was just informal, and the decision was a good one, so she didn’t understand his concern.

This pattern of events continued. It didn’t take long for team members to bypass the technical lead and start going straight to the project manager to resolve any requests or issues. The technical lead became extremely frustrated. Repeated meetings with the project manager did not correct the situation. So instead, the technical lead just tried to keep up to date on what was going on with his team and understand the progress they were making. The technical lead disliked working this way, but his repeated discussions with the project manager had not corrected the problem.

The technical lead regains control

The cube and report team started to have significant problems. The users had rejected the prototype cubes and reports. Significant re-design and re-work was required. End users and developers were blaming each other for the rejected work. In addition, the cube and report team had a lot of difficulty in doing the re-work. This team now required a lot of time from the project manager.

As a result of the upheaval in the cube and report team, the project manager was too busy to address informal questions about the technical team’s work. The technical lead regained control of his resources and scheduled tasks, and kept the project manager informed about progress through the weekly status reports and meetings. The work proceeded according to schedule.

As the cube and report problems were resolved and the project neared completion, the project manager congratulated the technical lead on a job well done. The technical lead pointed out that he had delivered the work with the appropriate quality on time, even though the project manager had been unavailable to interfere. The two laughed about the situation together.

Moving on

On their next project together, the technical lead met with the project manager at the beginning of the project. The project manager agreed to try very hard to avoid interfering. They met weekly to discuss progress, issues and explore alternative approaches.

Sometimes, the project manager slipped back into her old ways, but the team lead would remind her to stop meddling. They would laugh together about it, and the project manager would back off.


There were a couple of reasons for the project manager’s behaviour. First, she was new to the organization and felt a need to prove herself in the new environment. As a result, she was spending extra time getting involved in details to reassure herself that the project was going to succeed. In addition, the project manager was a very easygoing, approachable person, so team members and other project managers felt comfortable chatting about their project issues and getting her involved.

The project manager was usurping the authority of her own technical lead who was competent and did not require close oversight. By doing so, she was working very long hours doing more work than she really needed to. She could have been focusing the whole time on output and issues, and instead got involved unnecessarily in the details of the technical team.

It is fortunate that the project manager and the technical lead had a friendly relationship and were able to laugh about this problem and solve it. Overriding the technical lead’s authority was really no laughing matter.

Copyright 2015 Debbie Gallagher