> "Your inability to adequately track my team's weekly or monthly performance is not my problem."
I'm an engineer and I can certainly understand and empathize with where that sentiment comes from.
However, when people say things like this the first thought that goes through my head is "there is a culture problem."
That sentiment underscores an adversarial relationship between teams and leadership/management. That adversarial relationship should never exist (it does all too often, but it shouldn't).
Tracking timelines and deliverables is something that requires communication. That communication can be automated, but it's not up to leadership or management to implement that automation. They are not the engineers.
So if the process that is in place, which has worked for them despite inefficiencies (which they may not be aware of) is suddenly disrupted then no, it is not only "their problem." Some team went and did something differently than how things are usually done. The team [rightfully] recognizes that it is an improvement, but it was unsolicited and the communication / warning of the upcoming change was likely lacking.
Companies are called "companies" for a reason. They involve multiple people with varying skill-sets, responsibilities, understanding of how things do and should work, they have their own pressures and reporting structures (they need to hand things over to their management who expects a certain status quo as well) and most people have a default low tolerance for change.
This is no one person's fault. The company culture needs to facilitate iteration, improvement and innovation.
This is a great, experienced reply. All reasonable companies operate somewhere between the extremes: Tracking a project minute-by-minute is extreme. "Kicking off a project one day, and then returning once on the due date to make sure it is done" is an extreme, too. What's an appropriate amount of periodic tracking is a negotiation among all the stakeholders, many of whom need to plan their own work: leadership/execs, marketing, sales, r&d, and many more. Some companies arrived at "weekly tracking" as a happy median, others have longer or shorter periods.
So we've hopefully established that all projects need at least some kind of periodic tracking. So then, how do we do it? As a project manager myself, my preference is to have some kind of automated metric/metrics that I can pull myself and not have to bother engineers directly about. "Ticket count" might not be a good one, but the team should, together, find that good one. My management expects progress updates in some other format (often E-mail or silly slide decks), and I'd love to automate these, too. But, if we can't automate status updates, then I'm not going to just not get them--I'm going to do it the annoying way, by checking in and watching tickets and looking at git logs and manually "pinging" for information. Yuck!
GP's "Your inability to adequately track my team's weekly or monthly performance is not my problem." quip is only partially true. No, it's not strictly their job to write your project manager's reports for them, but it's also not appropriate to block them. As a team lead, part of their job is to partner with others, and sorry, but that includes the folks watching the clock and looking out for slippage and risks.
Yes, and one of the most pressing reasons to track a project is figuring out whether you need to move the due date.
I work at a product company, and "whether the project is complete by the due date" is not the end-all, be-all, for us. If the project is done, eventually, and good, our customers get value! We do, though, need to do things like market the new feature, produce training materials for it, etc, and these efforts need to be synchronized with the the feature actually getting done.
Assessing team performance is honestly not the main goal here! It's coordinating with everyone else in the company who can't act until the project is complete.
the management where I work, has the known strategic objective of eventually outsourcing all our development jobs to our indian facility. However, they prefer us to not leave our jobs before time, to ensure an orderly transition that wont lose us customers.
In which universe are we not supposed to have an adversarial relationship?
Our role in this is that our former ownerboss sold us to one of the big vertical software graveyards when he retired.
You are right. Unfortunately, most companies out there do not operate as desired, hence the adversarial approach. I would even go further and say that if one lands in such companies (the not good ones, this is, the majority) with a non-adversarial approach, oh boy, you’re gonna be eaten (specially true for juniors)
I'm an engineer and I can certainly understand and empathize with where that sentiment comes from.
However, when people say things like this the first thought that goes through my head is "there is a culture problem."
That sentiment underscores an adversarial relationship between teams and leadership/management. That adversarial relationship should never exist (it does all too often, but it shouldn't).
Tracking timelines and deliverables is something that requires communication. That communication can be automated, but it's not up to leadership or management to implement that automation. They are not the engineers.
So if the process that is in place, which has worked for them despite inefficiencies (which they may not be aware of) is suddenly disrupted then no, it is not only "their problem." Some team went and did something differently than how things are usually done. The team [rightfully] recognizes that it is an improvement, but it was unsolicited and the communication / warning of the upcoming change was likely lacking.
Companies are called "companies" for a reason. They involve multiple people with varying skill-sets, responsibilities, understanding of how things do and should work, they have their own pressures and reporting structures (they need to hand things over to their management who expects a certain status quo as well) and most people have a default low tolerance for change.
This is no one person's fault. The company culture needs to facilitate iteration, improvement and innovation.