[riskable]

I also work at a large financial institution and have had many similar situations. Fortunately, I'm the one in charge (team lead of sorts) and I have a pretty standard response to such "high level" nonsense:

"Your inability to adequately track my team's weekly or monthly performance is not my problem."

Every "project" has plans, deliverables, and due dates and those are the ultimate arbiters of a team's performance. Not the weekly/monthly statistics! If we open 10 or 10,000 tickets it makes no difference. It's entirely arbitrary and only carries meaning for the team in question (not upper management).

Like some high-level manager/PM is going to be able to make any difference whatsoever on some software development task by watching weekly Jira ticket statistics. Sounds like they're giving themselves busywork to justify their role. Because having fancy charts and statistics at meetings of managers makes you look like you know what you're doing (LOL).

[gspencley]

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

[ryandrake]

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.

[neutronicus]

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.

[fifticon]

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.

[tkiolp4]

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)

[roenxi]

ecshafer's response seemed more productive. He was effectively providing an explicit maintenance budget in his estimates, which in practice seems to be exactly what Mr. Senior Project Manager wanted. No real cost to the team. Everyone a winner.

[parkerhiggins]

outcomes > outputs

It’s proven time and time again by DX programs (S.P.A.C.E. etc) that focus time is really the only KPI that produces outcomes.

[gmfawcett]

Reference, please?

[gmfawcett]

My laconic question was downvoted. Sorry, I was on my phone, but didn't want to forget about this. I'm sincerely interested in reading the source of this research. Searching for it now, I came across this article:

https://www.microsoft.com/en-us/research/publication/the-spa...

But is this really the one you mean? Even the abstract states that there is no single metric that measures developer performance, which contradicts your claim:

> Developer productivity is about more than an individual’s activity levels or the efficiency of the engineering systems relied on to ship software, and it cannot be measured by a single metric or dimension

So I'm still interested in reading the research you're talking about, and I would appreciate a reference. Thanks!