The main problem with issue trackers is they treat everything the same way (bug/issue, task, goal, project, milestone, team, etc.). Where they break out of the one size fits all mold their abstractions generally start to break down and using them requires mental hoop jumping and too many clicks.
Key feature: Disparate views. View as self. View as department. View as project. View as team. View as team member. All views should work across an arbitrary number of repos.
As a manager I frequently have to context switch like this and I want to see three things: what's being worked on, what has changed, and where we are headed. For the latter, a clear distinction between abstract/relative prioritization between tasks and a timeline view (GANTT or critical path or inter-project/inter-issue relations) would be good.
The ability to summarize what's gone on today/this week (visually), eg. send me roughly what each team member achieved, status of their goals, what is blocking them, and what they're refocused on, where the time and money went. Critical when I am out of the office and don't want to spend time re-interpreting git commits across 10s of repos.
Basically keep the need for human effort out of the loop wherever possible - remove the reporting cycle, just use git history, any other system history (wiki, issues, etc.) and auto-compile a comprehensive view.
The fact that github only recently added beta org dashboards and they still have a long way to come shows there is demand here. However, you are effectively racing against github.
Also, we do hardware so ordering or acquiring parts is a huge issue that affects speed of iteration. I would want connectivity to accounting, purchase order, order tracking and inventory management systems. The key feature there is order status transparency, largely driven by third party platform order identification and subsequent logistics provider tracking number lookup integration for realistic ETA.