I don't necessarily disagree with the points the author raises but to paraphrase JFK "ask not what your people can do for you, ask what you can do for your people".
I've been in team leading positions before and my approach is this:
1. Lead by example. You should be working at least as hard as anyone else who's reporting to you. Never make a fuss about it. Never complain about it. Just do it;
2. Shield your people from crap. Part of your job when you're in a leadership position is to shield them from crap. And by crap I mean things like management BS, customer requirements and so forth. Let them get on with getting the job done. Your job, at least in part, is to deal with these (typically overblown if not outright imagined) exigencies that customers tend to have. Likewise, your people should spend very little time in meetings, particularly with people outside your team;
3. Appreciate that every developer is different. We all like to work in different ways. Some of us are good at (and like) sailing through uncharted waters. Some like a far more structured environment. It's your job to cater to that to get the most of your people; and
4. Make sure each person knows how what they do fits into the big picture. This can be as simple as "you're writing this component so when the reporting falls over, which happens because of X, Y or Z, the system recovers". People work better, in my experience, when they have a level of understanding about where their piece of the puzzle goes and why it's important. Again, different people want/need different levels of detail here.
Too often management also thinks that team leadership just happens. In my experience, depending on the project and the size of the team, it can take as much as 25-50% of your time. Too often you're still expected to produce work as if you were spending 100% of your time programming however.
There's a fine line from shielding people from crap, and shielding people from reality. In my experience, the latter happens way too much.
So I prefer to shield people from having to deal with the crap directly, but I definitely inform them about said crap, and how what they do can help me keep the crap at arms length.
As a developer, shielding me from crap means forwarding customer/client e-mails to me and telling me what they said on the phone, but never giving them my direct e-mail address or phone number.
In some organisations I feel that #2 is pretty much all the day-to-day work of the manager. Once the team is assembled, functional and given a goal (these might involve #3 and #4) then the rest of the project is letting them do what they're capable of by protecting them from everyone else.
I ask something similar of my people. I think it's fine, it's trying to set expectations about how you work together.
I ask, that when given a "requirement":
1. Question why we do this. Think: is this feature really valuable, or should I rather be working on stabilizing the server? If so, say so, let's discuss.
2. Question how to do it. Think: is there an easier way to implement this feature that gets 70% of the value for 30% of the work. Can we cut half of it? Then let's discuss.
And yes, totally agree with your nr.2. My people should understand what we are trying to do (ie. have context), but they don't need to know about all the crap.
I think of RAA when I think of project management.
R=Responsibility
A=Authority
A=Accountability
Make sure the team member understands what his Responsibility on the project is.
Make sure the team member has the Authority to carry out their Responsibility.
Make sure the teem member understands how they are going to be held Accountable.
Once underway, communication and feedback are the keys.
I'm all for shielding people from crap, but is that really what you think of customer requirements? Are you building the software for your own enjoyment?
Make the requirements intelligible for developers so that at the moment she needs it they're crystal clear. Rewrite this "can we move that button a tad on the left and make it blue like your tie" into "Move button X on screen Y 3px to the left and make it #5544df".
There is often a difference between what the customer says they want (which they label "requirements") and what they actually need. Sometimes they need to be told no, and when they ask for the third time and nothing's changed, that's definitely crap that your developers should be shielded from.
Just a further point, often the both you and the customer agree that there is a problem that needs addressing, but the customer is not sure how it should be solved. Alice from accounting wants the system to do X, while Bob from compliance needs it to do Y, which directly conflicts with X. Finally Carol in management has determined that they are not going to pay for a solution anyway.
This is exactly the 'crap' that you need to shield your developers from. Shielding developers is a lot deeper than just ignoring requirements.
I've been in team leading positions before and my approach is this:
1. Lead by example. You should be working at least as hard as anyone else who's reporting to you. Never make a fuss about it. Never complain about it. Just do it;
2. Shield your people from crap. Part of your job when you're in a leadership position is to shield them from crap. And by crap I mean things like management BS, customer requirements and so forth. Let them get on with getting the job done. Your job, at least in part, is to deal with these (typically overblown if not outright imagined) exigencies that customers tend to have. Likewise, your people should spend very little time in meetings, particularly with people outside your team;
3. Appreciate that every developer is different. We all like to work in different ways. Some of us are good at (and like) sailing through uncharted waters. Some like a far more structured environment. It's your job to cater to that to get the most of your people; and
4. Make sure each person knows how what they do fits into the big picture. This can be as simple as "you're writing this component so when the reporting falls over, which happens because of X, Y or Z, the system recovers". People work better, in my experience, when they have a level of understanding about where their piece of the puzzle goes and why it's important. Again, different people want/need different levels of detail here.
Too often management also thinks that team leadership just happens. In my experience, depending on the project and the size of the team, it can take as much as 25-50% of your time. Too often you're still expected to produce work as if you were spending 100% of your time programming however.