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.
Conclusions
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
