What you don't get here (and he didn't really spell it out because I guess it seems obvious once you're in that position) is you don't have time to (nor should you even want to) follow every email thread about every project that you (should, theoretically) already have complete faith that your employee is successfully executing. If you need an update, you just want an update (hey I noticed Bill's getting a little antsy, here's the status of project 127: "status") not to find and trace back through a discussion of x y and z aspects of implementation or marketing or whatever.
Bingo - you have to trust that the people working for you know what they are doing. This means going to meetings and being belligerent with other managers at times as they try to claim your people are screwing everything up, without even checking with your people. You always defend first, never call anyone out by name and never let any other manager talk derogatorily about your employees. Part of your job is to protect the people who aren't there to defend themselves.
This also means that if your developers drop the ball, you're screwed. You can't possibly know if someone is sticking bugs in the code as they race for a deadline, but when the system misses deadline because of it, guess who's responsible?
Doesn't help when you stick up for a dev for weeks or months and then they burn you by introducing shoddy code or not testing thoroughly, and their response is 'well I sent you a bunch of read receipt emails, so those browser bugs I introduced aren't my fault - you should be paying attention'.
This experience is why I work so hard to back up my boss or lead when I'm just a developer on a project.
