Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>Another JIRA flaw: highly formalized process is usually a hindrance, especially considering who in your organization invents, applies and benefits from process. Hint: middle managers.

This just reads as someone who hasn't had to actually think about what is being built, and who is paying for it. Effective teams are more than just "developers write and push code" - it's about being able to predictably say we are implementing this feature (or fixing this bug), therefore it will be available to customers at X time. As organisations grow, it becomes more and more critical to be able to predictably forecast the work that teams will complete, so that the right work can be planned out and roadmapped.

I had plenty of problems with this article, but this one stood out the most.



Your interpretation of the quote is that middle managers don't provide value, but I think that may be too broad. I understood it as "highly formalized process often rewards middle managers", which I do think is true.

The best manager I was lucky enough to report to personalized his approach to his direct reports. He recognized that some people are more creative, others prefer more structure, etc. He still had his responsibilities, e.g. report progress on project X and estimate completion, but this was abstracted away from the team. For all we knew, we each had an area of the system we were responsible for, and we had longer-term collaborative projects that would take on the order of months. I didn't realize how great of a manager he was until I had other managers who firmly believed in the One True Way™ of managing projects, and also pretty much required everyone to be heavily involved in it. (Give estimations for things you haven't worked on, and move tasks as you get to each stage of development.)

Getting back to my original point - highly formalized process often rewards middle managers because it simplifies work for them. Everything is already tracked in the system, it's a matter of moving around and allocating resources. But why does everyone need to be involved in this? Why isn't heavily formalized process compartmentalized to just managers and the people they report to (and maybe their reports that enjoy that process)?

I recognize the value that managers bring - otherwise every individual contributor becomes a mini-PM - but I also believe that the best managers put in the work. They build good personalized relationships with each member of the team, and are able to compile estimates based on their interactions. It's not always a cold science in the vein of "since Alice has 13 points out of a maximum of 18 points per sprint, I should try to allocate 5 more points - the biggest task that fits into that is 4 points, so let's assign that to her."


>Your interpretation of the quote is that middle managers don't provide value, but I think that may be too broad. I understood it as "highly formalized process often rewards middle managers", which I do think is true.

I agree, but I don't think that's a bad thing - I think something that rewards management, rewards the team as a whole. If the PO/PM overcommits, it's the team as a whole who suffers. Likewise, if targets are smashed, the team gets recognition.

As such my interpretation wasn't that middle management is bad, but that formalised development processes are bad, which is what I fundamentally disagree with.

Businesses as they grow end up having abstractions on abstractions. Formalising development processes allows for the business to actually be aware of what it's doing, how effectively it's being done, and where opportunities lay for improvements.

Don't get me wrong - too much management creates warrantless red tape and frustrations, however standardising the development process through things like Jira (which the author was complaining about) doesn't fall into that bucket (in my opinion), especially when the author compares that the same can be done with a blank sheet of paper - if senior management want a rough understanding of the roadmap for the next 12 months, why would you "forecast" with some guessing on paper, over actual proven data of this is roughly how this team performs, this is the rough estimates on these initiatives, ergo, we can commit to these X projects.


yep. When managers and their subordinates are just following "the policy" instead of improving it, makes sense that everyone hates the big bad JIRA monster.

Most managers and non-managers never get to figure out that JIRA is there to help them, and as such they MUST change it at the first sight of a problem. Those who fail to realize that it is a malleable tool that must be configured according to needs and particular situation are missing out.

But this is not really a surprise. In 99% of orgs I worked for JIRA has been a "dictated tool" instead of a "chosen tool", which means that those who dictated it are not the ones who are using it - and are basically just there to spread suffering to those who do use it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: