Developers have opportunities to improve management by increasing management-visible headlines about user goals, and decreasing management-visible headlines about implementation details such as UI, WBS, wireframes, flowcharts, and tech.
Try this thought experiment: Imagine you have team task list with headlines such as "Add red button to top of home page". Imagine rewriting the headlines such as "Customer wants to contact us" and similar kinds of user stories.
When managers continually see headlines with user emphasis, and do not see headlines with implementation details, then management improves and developer autonomy improves, because both groups are looking toward users.
It turns out focus on user stories can help significantly, even more than some developers might intuit. Look at your task board headlines and the opening paragraphs of your management-visible writing-- can you improve your writing to emphasize user goals?
Or... managers could do this translation themselves, by first learning how to do the technical work. My personal gripe is how much we have to chew and digest things for the non-technical people. The managers that know how to solve the problem technically would not ask this as much, but maybe then they would also be writing code as that is always needed.
I feel like managers that can't understand the technical part are the one to ask for this "translation", and because of that the technical people get a significant overhead in work, and because of that more people are needed to do the work, and that in turn creates more need for more managers. It's like a vicious cycle that could be mitigated if everyone knew how to do the technical part, and for this to happen I think companies should start making programmers the managers as much as possible, but I guess that won't be happening anytime soon (but I'm sure it will in the future once programming becomes widespread enough).
This is such a good point, Its a bit like how developers neglect to write documentation, developers often neglenct to communicate effectively or create 'communication artefacts' like diagrams, etc that make their work more comprehensible
Interesting that developers are expected to do all this other ancillary work that is the remit of other professions.
How often do we expect the technical writers, marketing, sales, management, etc to also do their share of writing the code?
I too would like to do lots less work and have other professions help out and be available for the scapegoat game when it goes wrong. Documentation not up to par, blame developers. Marketing failed to achieve goals, ...
I think the person doing much of the communication has to be the developer, noone knows what's happening in hid system better than he does.
But that must be a separate activity pruoritised and with time allocated. Lawyers have to do many anciliary activities, but they are given time to update their qualifications, etc by their employer
Try this thought experiment: Imagine you have team task list with headlines such as "Add red button to top of home page". Imagine rewriting the headlines such as "Customer wants to contact us" and similar kinds of user stories.
When managers continually see headlines with user emphasis, and do not see headlines with implementation details, then management improves and developer autonomy improves, because both groups are looking toward users.
It turns out focus on user stories can help significantly, even more than some developers might intuit. Look at your task board headlines and the opening paragraphs of your management-visible writing-- can you improve your writing to emphasize user goals?