I think that in the end, we should feel that it is our own personal responsibility that the product is actually used.
Some organizations add a product manager/owner to the team to help solve these problems

Example: You’re writing an application to track employee’s time, so they can get paid. The company wants to move away from a paper timecard process to an electronic one, hoping to save time and money on the process of calculating employee pay.

The software team analyzes how the company currently handles pay periods and determines that it would be quite complex to implement some of the overtime calculations and comptime calculations because the company currently pays its employees once a month, on the last day of the month.

Difficulty number one is that overtime and comptime are calculated on a work-week basis. Each work week starts on a Sunday and ends on a Saturday. But months do no conveniently start on Sundays and end on Saturdays, nor are they all 28 days long. This creates a problem because employees don’t finish a full 40 hour work week before the end of a pay period when the month ends in the middle of the week.

In addition, the department currently responsible for processing timecards and paying employees requires that the timecards are turned in several days in advance to the last day of the month so they have time to process the payroll. Thus, timecards are turned in around the 22nd of each month. That requires employees to “guess” how much they’re going to work for the remaining 8-10 days of the month, including guessing how much overtime, or sick leave they might use. Any mistakes they make in guessing then have to be retroactively fixed on their timecard next month, which creates even more work for the software team to code all of these complex rules and procedures into the application.

The software team says, “Wait a minute, this seems dumb. Especially this guessing part. And why are we paying people overtime on the last week of the pay period when the week is incomplete and they haven’t accounted for 40 hours?”

The software team discusses this for a while and says, “Why don’t we just move to a two-week pay period that starts on a Sunday, ends on a Saturday, and give people checks a week later, after the pay period has ended?” Seems logical, and a good portion of the rest of the world uses this model.

Unfortunately, this isn’t something you can just change with code. You have to have a policy change in the personnel manual. For that, you need someone on the team who can approach the right people and perform the correct bureaucratic dance to get things done, so that the software team can write simple, elegant software to solve the problem.

And if you think this story is made up, it is not. And it is actually much worse than I just described.

A more proper way to put it might be to say, I expect the manager to be removing non-coding obstacles so that the team can focus on solving software-related problems.

This may not be an issue for the teams you work on, or the projects you work on, but at my current position it’s a big deal. I work for a government agency and I’ve been absolutely blown away by the amount of bureaucratic and political obstacles that have been put in our path. And to my manager’s credit, s/he does a good job of bulldozing most of that garbage out of our way so that we can focus entirely on code.

As an example: a lot of problems can be solved multiple ways. Sometimes the software solution to a problem is overly complex, and the better solution is a personnel change, or a policy change, or a change in the way a task is performed.

With a policy change in place, the software can be written in a leaner, simpler fashion with fewer bugs. The policy change represents a non-coding obstacle, and I find it a complete waste of time and money for a software developer to get involved with that.

This is where I see value in the manager for this role, because s/he can take that problem off the developer’s shoulders and get it handled; get to the right people, make the right arguments and get the policy changed.

I always believed that a manager should spend more time with his best people and best teams. If a manager is ignoring his best team and not spending time with them, what value is he giving the team, why not cut the management layer?

BTW, the manager was far from useless and added loads of value on other teams and personally, just not on that particular team

http://www.fastcompany.com/magazine/28/ge.html

http://www.inc.com/magazine/20050101/eoty-rutan_pagen_2.html

http://www.stevemcconnell.com/ieeesoftware/eic10.htm

sincerely.

Fix the Bug that everyone is scared of.
Refactor the legacy code
Make sure that they do unit test HttpContext

A perfectly humming self-directed team that is aimed squarely at the target? Sure, let them run. But that sort of accuracy is probably not achievable for the lifetime of the project.

In addition, the manager absolutely needs to be there to run interference for the team. The manager needs to be actively removing obstacles from the team’s path, be they political obstacles, or bureaucratic, or whatever.

There’s a role for a manager. If there isn’t, they you’ve either got an all-star dream team, or a terrible manager.