One pattern that I've seen work well in software development management is one I call The Atomic Team pattern. Basically what it means is that ideally the smallest indivisible unit for management is the team. I think it's a cornerstone of healthy service-oriented architecture, but it's rarely talked about because it's on the more touchy-feely and less-technical side.
Management of such a team ends up primarily involving:
There are a few disadvantages:
Let the team self-organize around tasks instead of being command-and-control orchestrated. Drop prioritized work into the team work queue and they can figure out who does what and when based on their own availabilities and skillsets. Team members can hold each other accountable for the team objectives.
Cross-functional teams often have more than one person capable of doing a given task. This keeps the queue moving even when someone is sick or on vacation.
On a well-formed team, team members can count on one another for help and support. Vacations and sick days rarely affect a delivery timeline much at all. No one needs to be the only one responsible for stressful issues, outages, deadlines, or un-fun work. The increased autonomy in how the team executes on its objectives is highly motivating.
Team members can teach each other skills and organizational knowledge so that they level each other up. My best career development has come from working with brilliant peers.
Put simply, two heads are better than one. The best solutions that I've seen in software development are most often devised by a team riffing off each others' ideas with a whiteboard.
In reality, software doesn't just get deployed and run in perpetuity without engineering intervention. Even if there aren't any new features to add, there are hardware issues, bugs, security issues, and software upgrades. When teams own the software they write forever, they write better software, they monitor it better, and they manage it more easily. Without team-ownership, you're often left looking for someone to work on some long forgotten service when it inevitably needs work.
The result of these advantages is an software development organization that scales much more easily.
Examples:
These types of activities remove the mutual trust and comradery from the team and stop the team from forming beyond "just a group of people". This stops the members from working as closely together as they could otherwise and undermines a lot of the advantages of having a team.
Examples:
These types of activities are mostly unnecessary except in extreme situations so they're a time-sink and create a bottleneck that makes scaling your organization harder. Additionally, a manager can often make much worse decisions in these areas than the team members because they're the people closest to the team and the work.
Examples: