Straight to the point: IMHO, here is the least that a lead or manager should do for his developers:
– provide security and appreciation. As a lead, do your best to understand what your developers are thinking about their department. Avoid situations in which you mislead one of them to think you started disliking his or her work style. Don’t let the impression you plan things in secret (unless you really do) and don’t call one developer to your room regularly without telling the others what’s happening. Developers need to feel secure and don’t like being kept in the dark. It’s not the job security I’m talking about: it is the type of security given by the good relation with the team and the lead. If you don’t consider how they may feel about their stability within a team, don’t let yourself surprised by the low performance.
– arrange periodic public reports and talks. Why not have a weekly 15 minutes meeting to let your team know your thoughts and progress? What happened during the week, what you think about what happened, what’s new and the others don’t know, what are the recruitment plans, what are the development plans, how are the current projects going, what is your version regarding that rumor spread through the company? If nothing happened, tell everyone that nothing interesting happened. A good habit of 15 minutes per week could make a difference between your department/company and the others. It’s a good time to encourage positive criticism, preferably with quick solutions from the persons bringing problems to public attention.
– arrange periodic private talks and evaluations. Don’t let the developer prepare surprises for you. In a world where both good and bad programmers are headhunted continuously, it’s good to see their opinion about how things are going. Have a 20 minutes meeting every 3 months with each of your developers. Ask them how they feel about the recent changes (no matter which they are) and how they feel about the future. If possible, gather opinions from the other persons that are in touch with the developers (PMs, Marketing) and let them know what others think of the past 3 months’ work. Talk about the future, talk about technical thoughts, talk about anything – maybe even philosophy. Consult and let yourself consulted. Create a different, more serious context compared to the daily activity. Be honest, otherwise they’ll use dishonesty as a reason to leave. There’s a chance that they’ll be lying by letting you know that everything is perfect, while secretly planning to change boats. But that’s understandable: they need to secure a safe transfer. It’s a good time to encourage negative criticism and appreciate honest disapproval of your work or style.
– help your team’s development. Try to get a budget for books and create a small library in the company. Encourage them to read and gather as much information as possible. Look online for job requirements of other companies and search those technologies online. Learn new things for yourself, while letting them know about them. Search for conferences and, even if it’s not in your power to finance their participation, let them know about the opportunity to join on their own. Be happy if developers work at home for external projects (as long as they don’t compete with your company), as supplementary work will bring them both experience and revenue. Don’t try to be “head of the class” all the time: it’s a lot more important to have a good team than to falsely assume you are the super-lead who reacts first.
– understand they can do work on their own. If your developers are seniors, most probably they’ll do a decent work. We all know that perfect code doesn’t exist – so say thanks for the decent one. Their performance or code quality will be relative to lots of external factors, so don’t get biased about the future based on how bad someone’s code looks at this moment. Communicate, but don’t enforce. Share your experience, share your concerns, try to provide exception cases but don’t try to enforce unexplained things. It’s difficult to do so or to express your disapproval for their work without affecting their mood, but hopefully you’ll have smart team that can easily understand if something was wrong (even if they’ll not immediately admit it).
– develop good methodologies and engineering processes. A team or a company must offer more than what a developer can do as a lonely freelance. Do code reviews, encourage design patterns, comment code as professionally as possible, have good references or FSDs, write quality tasks, consider unit-testing and help the team members interact as much as possible to gain more knowledge from each other. To summarize: offer more than what they can get from lonely work-from-home. Using them just to do digging work and move the company forward will not give them enough motivation to stay with you for a longer period. Good developers are daily learners, so they need to progress with time.
– enable developers to choose some missions. Obviously, developers are resources. But they are human resources that need motivation. Don’t switch their projects without asking what they think about it. They’ll accept the contextual necessities, but don’t do the mistake of treating them like rooms or projectors. Developers may have plans, may have ideas, may have something good to share. Moreover, developers have the need to progress in their careers and, sooner or later, they’ll have to write the completed “missions” on their CV. If they realize they’ll have no new mission to write in a year or so, they’ll find a way to escape the trap. Moreover, try to avoid giving the impression you’d block one developer’s way to ascension. Let them know that, as soon as opportunity comes up, their capacity would be rewarded.
– make sure they have good salaries. This may not be under your control, but I have to mention it. Love covers a lot of sins, while money can close lots of eyes. It’s just a matter of time until recruiters will wave amounts in front of your developers. If those amounts are considerably higher than what they get now, they’ll be making the first steps to the interviews. If they find a company 70% as good as yours, but 20% higher in salary, they’ll go for it. So force yourself to build a good team or company, such that the 70% I’m talking about would be impossible to touch. If you control the money, use them wisely.
– fight for your team. Don’t let external departments drain your resources or their happiness. Protect your team’s focus and time and try to act as a buffer that catches unreasonable requests. Bring balance to the team, try to help the other departments interact better with your people. Be there to explain what others in the company couldn’t. Work hard and smart, such that developers’ source of frustration is not you or your disinterest.
– be flexible and offer them comfort. Your team members are probably very different from you. Trying to make them follow your style will fail. Do they like playing games and you don’t? That’s ok. Do they wake up at 10 while you’re in office at 8? That’s ok. Is it vice-versa and they leave early? That’s ok. Singletons vs static methods? That’s, most probably, ok (if it doesn’t break agreed patterns). As long as they can produce the scheduled output, let them enjoy your flexibility. Trying to lock them down under some patterns or requests will just increase their level of frustration. Look more at the results and less at the style. Talk, express feelings and expectations, but don’t enforce. Moreover, don’t change your flexibility rules in the middle of the sprint (or any other pre-planned period).
Of course, there could be more: free lunches, sliders at work, helicopters in the corridors and lots of perks. There are programmers who love those and would do anything to get them. But there are also programmers who like riding bikes outside the office. For them, perks make not so much sense.
Hope you felt either good or bad reading the upper list. If there were no feelings, then I’m a terrible writer.