That's not what I mean at all. JIRA doesn't imply any sort of top down approach. In fact, I'd argue it's the best tool for those tight feedback loops. Each ticket is a versioned history of the decisions, feedback and work history of a single task. Startups can get away without tools because they can communicate very tightly. That doesn't scale much past an org of even 20 people. Not everyone can talk directly to the CEO or the budget makers, nor are they all sufficiently cognizant of the business constraints to make the right calls on prioritization. There isn't a tier of professional managers as much there's a tier of experts in their discipleship who have visibility across multiple teams and into the business decision making. People who need to allocate budgets and resources without attending every scrum or sprint planning.
You specifically said Jira wasn't for developers, but rather for the managers and stakeholders. That sounds pretty top-down to me.
I also don't understand how you believe Jira can be best for tight feedback loops, but also agree that the tight communication and focused teams make Jira unnecessary. That seems contradictory.
I only meant developers don't necessarily need it to organize their team. Or at least they could get away with something simpler. But organizing the team is only half the battle. Or really less. Knowing what to work on and how to prioritize is more important. Especially if you're managing multiple products and projects. Developers may not need it to write code but they absolutely need it to manage expectations as much as managers need it to set expectations and track against goals and budgets.
Developers absolutely don't need Jira to manage expectations. And we don't need it (or managers) to set expectations and track goals. There are more things, Horatio.
I get that Jira may be a way that works for you, for a local definition of "works". But there are a lot of good ways to make software.
