[ecshafer]

My goto example of a dysfunctional and bureaucratic organization is an example I saw in a finance company I worked for.

I was a on team that we were doing a major project. We basically ran Kanban but had to run "sprints" so we chose 4 week sprints to get it out of the way and we put everything on the board we had to get done that month to stay on track. Our pipeline was setup in such a way that you were required to have a jira ticket to push a commit. We were really crushing our timeline, doing 2x the work we were expected, a really great team honestly. But we opened up bugs and additional features in the middle of our sprints to track our work as we did it.

What this amounted to was maybe us saying we have to do 40 tickets this month, and wed be closing like 80. Everyone should have been thrilled by this development! Well we had a sprint review where some "Senior Project Manager" That wasn't really affiliated with our project but was some manager higher up was mad that us opening up new tickets mid sprint and closing them was ruining the org level burn down charts and expected delivery. They wouldn't give up on this, and said it was our fault for not estimating better (which sure, but we were beating expectations!). So we did the reasonable thing and improved our estimates! No of course not, we doubled our number of tickets and filled in "placeholder" on half of them, and used them as needed then closed everything out at the end of the sprint, where we were congratulated by everyone for our phenomonal estimation.

[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!

[apozem]

That is amazing. I worked with a (different?) finance company that did the same thing - every team was judged on their burndown charts.

From what I saw, it did no good. Teams simply did not use tickets to track work. If a story surfed sprints, its “ticket” was closed at the end of one sprint and a new one was opened for next. If a priority bug came in mid-sprint, we simply worked on it without a ticket.

[ryandrake]

Careful, though, because you may encounter someone who can sniff out these tricks.

I worked at a place where, like many companies, tracked the bug burndown as one of the measures of project risk. So, the closer you got to the release, the fewer bugs were expected to be open. Having many bugs open early in the project was fine and encouraged. Having few bugs open towards the end was seen as On-track, and having many bugs open towards the end was a red flag, where the program might want to either step in and help organize things or at least raise the risk with higher management. This is a pretty standard scenario you get at a lot of software companies.

Well, one of the teams realized that if they just kept their bug count always at zero, they'd never be bothered by those nasty, annoying project managers. So that's what they did. They were constantly in crisis, fixing problems and committing code, but their bug counts always looked great. A trivial bug tracker query revealed what they were doing: They'd just keep a side bug tracker in a doc rather than filing them in the real tracker, and then seconds before committing the code, they'd quick create a bug and use that as the required bug in the commit message.

So, the following week, these "ninja bugs" were added to the automated reports, and that behavior ended quickly.

[sailorganymede]

Strange… The finance company I work at also does this. And it’s so strange. I feel like they value Jira tickets more than actual work being done. It’s even funnier cause we get asked to close work when we want to go into prod and told to create new tickets to put our work in to prod. which kind of is annoying.

[cruffle_duffle]

> If a story surfed sprints, its “ticket” was closed at the end of one sprint and a new one was opened for next.

LOL, just joined a team that seems to be doing exactly what you describe. You start attaching performance incentives to how tickets are estimated and closed... people are gonna game the fuck out of them.

[morkalork]

I used to work somewhere that different bug severity levels were a KPI. One day after opening some prod/blocker/whatever level bug, I got a slack message from some useless agile coach arguing over it. After that, I created one kind of ticket in Jira. Fuck it. And when I talked to another senior engineer on another team it turns out they had the same experience and came to the same conclusion.

[tokyolights2]

I have seen this multiple times before. Management chastising good work because some externality of that work shows up on a graph that they have to talk about at some weekly meeting. It doesn't even have to make the graph look bad, just stick out.

[aiisjustanif]

Could have spent that time more wisely by making a better graph that accounts for this…

[FireBeyond]

I am dealing with this as a Senior Product Manager, explaining to execs, and defending my engineers when they started introducing metrics, and one of the keys was "Planned points delivered".

My team gets and triages all the escalated bugs.

It's not accurate, not fair, and demoralizing for that team to be "red" because the metrics look like: "Story Points Planned: 30. Planned points delivered: 5." when they delivered bug fixes on what amounted to 20-30 unplanned points.

"If they have to do that work, they need to get credit for it, planned or not. You can't have work that is required but counts for nothing in KPIs".

The issue of HOW MUCH unplanned work is being required is a separate and valid discussion, but not in the realm of "engineering cadence/velocity".

[hinkley]

It's funny that my anecdote also comes from a kanban team, but amongst mostly waterfall people and one Scrum nutjob.

When you are showing people up they throw the book at you. Yes you're getting a lot done but you're cutting corners so that's cheating! In an org that is perpetually behind schedule they rely on one team being a scapegoat for why all the other teams are behind schedule, and when your team has never been more than 10 days behind it stings.

One of my proudest moments on that project was when I figured out a judo move to meet (and exceed) the documentation requirements for our part of the project with less than 3 man hours per milestone after I got it working (and half of that was typesetting fixes by one of our tech writers). I got the impression that the person who called it out was really hoping it would cost us 20-60 hours per milestone. I think I spent about 30 hours total, including the initial set up time for the tools and templates. So their gambit only worked for a single milestone and then it was back to the races.

[specialist]

> Yes you're getting a lot done but you're cutting corners so that's cheating!

Yup.

Merits of Agile aside, I don't recall any of the project/product management books preparing noob me for the organizational (and personal) psychology stuff.

As you surely know, this is what the gray beards mean when they say most challenges (obstacles) to shipping software are not technical.

[Aurornis]

> we had a sprint review where some "Senior Project Manager" That wasn't really affiliated with our project but was some manager higher up was mad that us opening up new tickets mid sprint and closing them was ruining the org level burn down charts and expected delivery.

This is giving me flashbacks of a company I worked for (for a very short period of time).

For some reason, they decided that planning accuracy was the most important metric for the software organization. This was the headline metric they talked about in executive meetings and it was primarily how the program managers' bonus structure was determined.

So everything in the company revolved around planning accuracy. Opening new tickets within a sprint was strongly discouraged. Doing work from the next sprint was heavily discouraged. Trying to take on big projects within a sprint was heavily discouraged, because if you couldn't 100% guarantee that it would be done by the end of the sprint it posed an existential threat to the Program Managers' charts, and therefore their bonuses.

Program Managers wouldn't come out and say any of this, of course. They knew the situation was at odds with delivering software quickly. However, if you deviated from the plan they would pull you into meeting after meeting for hours and hours to try to keep you in line.

If you opened a new ticket mid-sprint, you'd get pulled into meetings with Program Managers to justify it. They'd argue and debate and cajole you into deleting the ticket and rolling it into something halfway related. They'd CC your manager on 5 different e-mails and check in multiple times a day to make sure you'd fallen in line. It was hell.

Weirdest part to me was how many people around me seemed to enjoy that structure. They recognized the game and gladly played along, delivering a couple hours of work each day and then sitting in meetings to talk about it for the rest of the time.

It all came crashing down about 18 months in, when management brought in someone who actually understood software development and started actually looking into what people were doing. I was gone by then, but they went slash and burn on the remaining department. They cut it down to 1/5th of the size and started delivering, as far as I can tell, the same amount of work.

[imtringued]

>we doubled our number of tickets and filled in "placeholder" on half of them, and used them as needed then closed everything out at the end of the sprint

Seems like someone has become aware of the power of liquidity and delayed decision making giving one the ability to respond to future information.

[araes]

I like how the response was "falsify the metric data" because an ape in a suit somewhere demanded a "correct" metric. And were rewarded for their falsification. There's an Aesop's Fables story in there somewhere. I wonder how many metrics people depend on, like jobs data, get the "change the data" to suit ape in suit's needs?

[siva7]

> Everyone should have been thrilled by this development! Well we had a sprint review where some "Senior Project Manager" That wasn't really affiliated with our project but was some manager higher up was mad that us opening up new tickets mid sprint and closing them was ruining the org level burn down charts and expected delivery.

Why should they be thrilled that you were running on Kanban but claiming to do otherwise and therefore ruining the burn down charts?

[ecshafer]

This was a team of 10 people, so costing the company $2M+ a year. How is halving the timeline on a very major, mission critical project not a good thing?

Some appendage management structure in the organization having charts and reports looking a certain way is secondary to how much value is being produced by a team of expensive engineers.

[gopher_space]

Am I working for The Tacoma Chart Co. or are we developing actual products here?

[adammarples]

Because the burn down charts don't matter and the real work being done twice as fast does matter.

[nonameiguess]

I experienced something like this for many years across several of the big five defense contractors and smaller SBIR contractors working for the US DoD and IC. As someone who 20 years ago had a slightly better understanding of how computers and networks actually work than an average developer and was comfortable at the command line in an era when juniors increasingly couldn't leave their IDE without becoming hopelessly lost, as DevOps, SRE, and platform engineering started to become things, my career drifted in that direction.

The problem being on teams like that was always the same. You're responsible for developing software products of some sort, but they're software that runs, tests, or delivers other software or even orchestrates the operations of an entire environment shared by many different applications. This inevitably means a whole lot of your work is the classic incident response/post-mortem of operations, plus some level of customer support given to other development teams because internal platform teams never get a separate support organization. To this day, the government has no idea how to handle this in light of how DFARS (administrative law governing acquisition) works.

Every labor hour a contractor charges has to be tied to a specific line of accounting which is itself tied to some unit of planned work tracked in an issue tracker or project management system of some sort. Most of the time, this is an Epic in Jira. This is logical insofar as you consider the intention of acquisition as a category of appropriations bill. A budget proposal with line items tied to measurable product features is presented to and approved by Congress. You have to demonstrate you're spending the money they gave you on what they approved you to spend it on, because per the Constitution, that's how power of the purse works. The executive branch can't just do whatever it wants.

But it falls apart as contractor labor increasingly replaces federal civil servants. When your job is anywhere from half to all running and maintaining an operational system, that isn't really acquisitions any more. It's operations and maintenance, which is an entirely separate appropriation. Soldiers manning a defensive perimeter have no idea when they're going to be attacked or how much work they'll be putting in. Software operations is effectively just the less lethal civilian equivalent of that. The government arguably even recognizes this in many ways. Typically, running and maintaining the production system is a separate contract from the development contract and it uses separate work tracking systems, and if someone spends 8 hours watching a screen while producing no quantifiable work outputs, so be it. They charge 8 hours because that's what the contract says they're supposed to do.

But as we're increasingly expected to be modern software organizations with things like CI/CD, test and staging environments, and you inevitably need to run at least some of your own development infrastructure, well now what? You have a lot of people whose job is the same. Be on constant lookout and respond as needed, but now it's part of a development contract and they need to have quantifiable work outputs that be tied to a budgetary line item with an associated product feature.

So we convolute nonsense out of thin air like cloning the same monthly "Support" Epic in Jira, month after month. "As a developer, I want my tooling to work so I can do my job and deliver value to the government." Plug in some SWAG number vaguely guessed at based on how much of this kind of work you ended up doing last year. Every 90 days, play planning poker with it. LARP a product team even though that isn't what you are.

[OldGuyInTheClub]

Excellent and, to me, underappreciated points on HN. Now, expanding into the hardware world of A&D brings different levels of agony. If there's development risk, there's no good way to write a schedule that both accounts for it AND consistent with absolutely mandatory "Earned Value Management" where complex tasks have to be shredded into tiny 1-3 week chunks with metrics that the accounting team can track and report. If you need to fix a broken piece of equipment, if you need to buy a part, you're at the mercy of a procurement system that exists to survive audits and wants to know why the break or purchase wasn't in the plan. If the problem requires evaluating Plans A, B, and C, you have to pick one as the best, baseline, and execute it. Then if you need to consider the other two options that everyone knew up-front were possible, you get to explain why The One Chosen Plan didn't work. "You signed up for it."

The only way I've seen around it is a Risk/Opportunity Management system where risks/opportunities to whatever the baseline plan might be are enumerated, assessed, planned for, and maintained for when things go sideways or when there's a chance to save schedule and/or cost. But, that takes a VERY gifted _leader_ to run at the top level and those are rarer than hen's teeth. Ideally when a risk becomes a problem or an opportunity presents itself, the contingency plan is implemented. When it works, it is great and I've seen tough, ambiguous projects come in ahead of schedule and under budget. The common theme was one guy running all those projects and he's now retired. Usually the result is that the person reporting the problem gets stomped upon by a _manager_ who runs a cargo-cult process that s/he doesn't really understand.

Earned Value Management may be fine and dandy when development risk is done, the transition to manufacturing is complete, and the manufacturing process is relatively stable and the perturbations are small. Of course, that's when the contract SHOULD be Firm Fixed Price and not tracked by an army of accountants on both sides of the contract.

[constantcrying]

>No of course not, we doubled our number of tickets and filled in "placeholder" on half of them, and used them as needed then closed everything out at the end of the sprint, where we were congratulated by everyone for our phenomonal estimation.

Are you sure this is a negative example? You even have a work around which makes everyone happy.

This isn't what a dysfunctional organization looks like.

[loloquwowndueo]

It’s called gaming the metrics and it’s totally a sign of dysfunction at the org level.

The team that decided to do this to keep the metrics happy rocks, though :)

[sodapopcan]

Exactly. Org-level metrics are a sign distrust and micromanaging. It's useful for a team to look at their own metrics so they can understand what they are capable of delivering, but no one else should care. That they can reliably and consistently deliver a satisfactory amount of work should be the only "metric" they are judged on.

[snapetom]

As an engineer recently turned technical product manager, I think this is one of the values I've provided. I focus on feature deliverables and meeting timelines. How you get there is sausage making that doesn't need to be over-emphasized.

There are too many ways to game the metrics. I've done it, and I'm constantly impressed at seeing how innovative colleagues do it. If you focus so much on metrics during the development process, you're going to just add useless overhead and piss off developers. My boss comes from a sales background, and thankfully he gets it despite pressure from other senior leaders.

[constantcrying]

>It’s called gaming the metrics and it’s totally a sign of dysfunction at the org level.

Have you seen actually dysfunctional organization?

Millions being burned over ridiculous mismanagement. Bureaucracy which takes up vast amounts of time. Tracking of completely meaningless metrics. An IT department which needs to be "worked around". Managers who's only interaction point is them asking you what they should write into their MS Project document. Constant shifting away of responsibilities. People making completely unqualified decisions over the heads of the actual people being concerned. Inter department conflicts.

Really I could go on, but a bit of massaging metrics (which are totally irrelevant anyway and their trackers can be safely fired) is not particularly bad.

[sodapopcan]

The person you are responded to said it's a sign of dysfunctional org, not that it by itself make an org dysfunctional. There is a huge difference.

[constantcrying]

>The person you are responded to said it's a sign of dysfunctional org

He said it was his go to example of dysfunction.

[loloquwowndueo]

I did not. Read more carefully. It’s “totally” a sign but it’s neither the worst nor the only one.

> Have you seen actually dysfunctional organization?

I have. I quit because of it. Imposed metrics and untold amounts of time gaming them to avoid losing one’s job was just one part of it. Most of the ones you mentioned in your first reply were also there.

[sodapopcan]

Ah GP did ya, fair enough. I assume a bit of hyperbole but sure. I would infer that there is a lot more going on than just some guy worried about if some guy is worried about individual teams' metrics getting messed up but I don't know the whole story.

[pyrale]

> Have you seen actually dysfunctional organization?

I have yet to see an organization that is not dysfunctional.

Some dysfunctions I can live with, though. I agree with you, if gaming the metrics wastes a reasonable time (say, 5 minutes a week), it's definitely not the worst.

[danaris]

It's still dysfunction even if the group in this case was able to finagle a happy ending to this specific story.

Charts and processes are there to serve people, not the other way around. If a particular group is clearly doing a great job, but the way your metrics are set up claims they're causing problems, then the problem is in your metrics.

The organization is dysfunctional because a higher-level manager is able to enforce their particular view of how these metrics are supposed to work at the expense of actually productive groups underneath them.

Note that if the GP had actually done what they were told, they would simply have not worked on all those bugs that came in mid-sprint until the next one.

[constantcrying]

My point was just that the example is a very low bar for dysfunction.