My favorite remedy for this is the Peopleware, which I also mentioned in An Engineer's Guide to Silicon Valley Startups. However, that book seems to be
- Have lunch with your team at least once a week. If you learn nothing else about leadership, learn to eat with your team. (If you're an industry veteran, I know this sounds basic, but I assure you that I ran into multiple tech leads at Google who did not do this, because no one told them that this is necessary and essential) If necessary, put it on the calendar. Communal eating is such a major bonding ritual since the dawn of humanity that not to do this marks you as an idiot tech lead or manager. One of the best tech leads I know at Google, Arup Mukherjee does this not just once a week, but nearly every day. In Peopleware, Demarco and Lister describe a situation where a crafty tech lead turned making dinner into a team-building exercise. That's the way tech leads should be: even when they're leading, it's not obvious. When a great leader is finished, the team says, "We did it all by ourselves without a leader!"
- Schedule 1-on-1s with every team member, at least once every two weeks. This ensures that your team member has time to catch up with you and tell you about problems that are important but not urgent. Many people have a fear of speaking in public, and private meetings ensures that little nagging things that could blow up don't blind side you. You can also use this time to provide feedback. Most people crave feedback, and being able to provide useful feedback regularly distinguishes a great leader from the rest.
- Make sure that members of your team don't hear from you only when things go wrong. Many tech leads only talk to team members only if something went wrong. Do this enough times, and your team mates will start avoiding you out of repeated Pavlovian training. If this means you have to find ways to praise them every other time you see them, so be it. In Orson Scott Card's book, Ender's Game, the protagonist instinctively knows something that many executives do not: bad news should come from the top level, and good news should come from line management. This is something that every executive should learn and do.
- Make a big deal out of milestones. Celebrate every milestone. Reed Hastings was a great cheer-leader for every person in his company. When I applied that to small teams of 3 or 4, it was just as motivating. Most technical leaders err too much on the side of not providing sufficient positive feedback to encourage teams.
- Try to give team members whatever they need in order to get things done. Your role is to support them. Avoid grabbing the glory by taking all the interesting jobs and treating them as minions to do work you don't want to do. Note: if you work at Google, this might not apply to you. It's more important to get promoted early at Google so your evaluations of your team-mates matter more so they can get promotions --- this is another way incentives get mixed up in big companies in a way that don't at startups.
- You're spending well over $100k a year per engineer. There's no reason to skimp on $5,000-$10,000 worth of hardware sitting at his workstation so that he's more productive. Yes, it's nice to be frugal, but one big sign for me that a company has gone too far is when I'm tempted to bring my home machine to work so that I can have a faster machine at work. And no, I don't consider upgrades every 18 months a waste of money if your business depends on the productivity of engineers, but many companies do. I just don't understand it.
(I now have a book full of useful tips like these: Startup Engineering Management)