Not directly related to your question, but please for the sake of your subordinates read and internalize Scott's review http://slatestarcodex.com/2017/03/16/book-review-seeing-like-a-state/ and also another review of the same book: http://slatestarcodex.com/2017/03/16/book-review-seeing-like-a-state/ (I haven't read the book itself, I'm not sure that it would tell me more than these two reviews).
The conflict between the management and the software engineers, as far as there is a conflict (like if there weren't any you wouldn't have to ask how to lead better), must be viewed through this very important lens, in addition to any others of course, but this one is important and you must use it.
Basically, the management wants to track everyone's performance so that they can reward and retain good workers and rehabilitate or fire slackers. To that end they implement bureaucratic procedures that help with this tracking, from filling "time spent on such and such task" tables to having procedures for dealing with bugs to having cute stuff like a centralized "send a Kudo" system.
It is essential to understand that all this bureaucracy is annoying to the workers, including good workers. It is useful for the management and the enterprise as a whole, but the usefulness must be balanced against annoyingness.
It is also essential to understand that it can't and won't capture some essential stuff. For example, almost every day some programmer or implementation specialist asks me a question about the way our current functionality works, or whether something is a misconfiguration or a genuine bug, and I tell them my expert opinion, over Skype, and it takes me 5 minutes to triage their question and either tell them the answer or tell them to register a bug.
You can't make that legible for the management, like, require everyone to register their question in Jira and have me respond and log the 5 minutes it took me, so that the management could see my value, because questions in Jira don't get answered for like a couple of days. Because there's this underground network of those implementation specialists talking about their problems face to face or in Skype, and they teach each other to ask this guy (me) if shit really seems weird, and it works much faster than going through the official channels.
One point of Agile is having constant feedback to Product Owners, so that they can see if some of their requirements actually are very hard to implement and just cut that functionality and deliver on time. Another, less appreciated point, is shielding the individual members of an agile team from the management's bureaucracy. The team takes a task, the team either completes it or not in the sprint. And then it's up for the team to see if the guy they assigned to the task was slacking or there was some critical bugs or whatever.
I think that the job of a good manager or scrum master or internal product owner is all about shielding their subordinates from the Management's attempts at inflicting "objective" performance measurements and instead getting into the meat of it and understanding who's slacking and who provides value by understanding what's going on in your team, then reporting that to the above.