Managing a team of web or software developers is no easy task. On a daily basis you are dealing with a unique set of personalities, interpretting and translating for the rest of the company, delivering product that by its nature will not be perfect, overcoming unproven and untested technologies, and usually working on multiple projects simultaneously that are under-scoped, mis-represented in requirements, and overdue. Here are my top 10 tips for creating a cohesive, productive, happy and efficient team and overcoming most frequent challenges.

1. Good people above, Good people below. While not unique to web development this mantra can't be overstated enough. Choose to work for executives who are ethical, disciplined, diligent, unselfish, kind, good listeners, and humble. Similarly choose developers of the same criteria and add values of conceptual intelligence and maturity -- those who lead balanced lives and can avoid burnout. Again, choose those you can trust and depend on over rockstar skillsets 10 times out of 10, both above and belowyou in the ladder. And it goes without saying you need to exemplify the values you seek through your actions on a daily basis. Be a people manager, 'nuff said.

2. Drive everyone on the bus ... to a place everyone wants to go. Be a leader to all of your employees, be 100% open and 100% clear with your team about directives and goals. Listen and accept their individual and team goals and meld those with your own directives -- be honest and assertive where those directives may clash and look for compromises. Respect their intelligence and have this goals conversation in an individually meaningful and forthright way that is not a motivational seminar -- we all know developers see right through that. Getting everyone on the bus to a place they want to go is the first step to creating a highly cohesive and eficient team, which in the long run is the most valuable thing you can create. The second step is showing the team you are the one in the driver's seat who can take them there ...

3. Fix the bus. Developers are highly demotivated by disconnected managers. Know how to fix the bus - earn the respect of your team by being a valuable resource to answer technical questions -- at least conceptually from a design pattern or best practice perspective if you don't know the specific technical implementation -- and then do some pair programming to implement. Similarly, you need to earn their respect as a manager by getting individual and team needs met in the critical non-development areas -- it/pmo/hr/sales/etc.

4. Eat lunch on the bus. Encourage team unity through regular development team meetings, but make them worthwhile with things like Brown Bag sessions hosted by team members demonstrating in-house work completed recently or new technologies and practical uses for your department. Limit your departmental and company directive chatter to 15 minutes if you can help it. I also like to do fun diversions like creative contests (such as "song lyrics in code") with gift certificates to a technical bookstore or computer store at dev team meetings every few months. Holding these fortnightly for 1 hr rather than weekly is a good frequency that isn't seen as an interruption. Likewise, take your team out to lunch every once in awhile, at minimum for new employees/brthdays/farewells.

5. It's report card time. Annual reviews are a must for maintaining developer motivation. I'm a fan of quarterly reviews with developer self-review along with my review, followed up by a face-to-face meeting to discuss. It takes a few days out of every quarter but is invaluable for everyone. Create a standard review sheet that measures employees in 5 objective criteria you create for each section from: job performance/skill, productivity, quality, communication, initiative. Rate them in 1-5 in each criteria with objective qualifiers for each score accompanied by evidence and comments. Take the average of all scores to get a GPA like score. Similarly, each review create 3-5 SMART goals with the employee with timelines for completion and objective scoring. Give "3" to a new goal or measurable progress, "5" is completed.

6. A place to think, a place to create, a place to leave. Developers are more sensitive to their environments and how their time is used than many other departments. To do good work, a developer should be able to have a block of 6 hours of uninterrupted time 3 days a week and 7 hours a day 2 days week -- 32 hours of blocked development time / week -- don't ask for much more than 80% billable, it's not realistic, and don't expect more than 40-42 hours per week out of developers even during launch time -- if you need more, more than 1 person wasn't doing their job, and you're the one responsible. As manager it's your duty to allocate and manage this unblocked time, run interference on disturbances, and manage progress. To encourage quality work first make sure developers have adequate computers (preferably laptops) and comfortable chairs/deskspace and allow flexibility to install their own dev software within your defined parameters. Create comfortable closed spaces with couches, books, wi-fi, and tv/vdeogames where developers can work uninterrupted without question on difficult problems. Implemented correctly this encurages both creative problem-solving and higher afternoon efficiencies. Having snacks and food available on-site and allowing developers to listen to headphones also goes a long way. Allow working from home and limited flex time, and have specific policies about communication and productivity requirements during these times. Encourage everyone to leave at a reasonable time every day.

7. Keep the bus running smooth with daily Scrum. I highly recommend a daily Scrum stand-up meeting of 15 minutes with the team at the beginning of the day (even before email is checked) with pm's to track the previous workday's progress, evaluate new and updated risks/obstacles/needs, and you/pm's dictate (not ask) what will be worked on that work day. Review weekly burn-down rates on Mondays. Before you review burn-down rates on Monday, review developer progress on Friday to ensure it matches up -- if there's nothing visible then dive into the code -- developers should always be able to provide visible progress. Do Scrum daily regardless of the software development lifecycle (SDLC) you're using on projects.

8. Methodologies: The invaluable invisible toolset. People (sales, customers, sometimes even developers) will often tout a technology as a silver-bullet. When is it ever? The real silver bullet to a successful devlopment project is choosing the right development methodology and software development lifecycle for your project. You need to know when and where to use the right methodologies and SDLC, and as manager you need to develop a department that can handle multiple disparate SDLC's and methodologies at once. Dealing with a startup? Go light on requirements and heavy on proof of concepts. Client that's never happy? 2 week timeboxes. Just ramped up a handfull or more of new developers? Paired programming. A feature-rich project with requirements pretty well set? Sashimi or phased waterfall wil do! Understand and know how to implement different methodologies and lifecycles simultaneously, know which ones will work best with your team, and don't be afraid to implement them!

9. Tisk-tisk, uncalculated risks. It always amazes that our risks as people are evaluated for car/home/life insurance, and public companies will go a long way to manage larger corporate risks, but risk management is always non-existent or eventually falls by the wayside on software development projects. Why? At the very least to being a simple risk management process, at the onset of every project create a Top 10 risks sheet. List out each risk name, date added, desired/required resolution date, owner, potential hours/budget it will impact the project, percent likely to occur, and next steps to reduce/eliminate the risk. Now multiple he risk hours/budget column by percent-likely to occur, and add that in to your project's budget. Yikes! Keep this list updated weekly by reducing likely-to-occur (but not hours/budget) and review it weekly in Friday's scrum mtg.   

10. Tiers prevent tears. For every project, no matter how small, have at least a 3-tiered and no more than a 4-tiered environment of development, uat/testing/staging, and production. Have formal policies and signoffs to encourage accountability in promoting between tiers. Automate the promotion between each tier through Continuous Integration (I'm a big fan of Hudson these days). If you can, always have a policy to promote nightly builds to encourage thoughtful daily-timeboxed development. Never deploy on Monday's or Friday's, EVER.

11. Last night the repository saved my life. Have formal policies for your version control system (VCS) and require every project to use SVN/CVS or your preferred VCS for development no matter how small. Have policies for requiring check-in of working code at a certain time each day to again promote thoughtful development and continuous integration. Make sure you allow time weekly or bi-weekly for maintaining the repository as needed. Have a consistent directory structure across projects, such as "artifacts, build, docs, src" and "branches, tags, trunk" under src.

12. From Jedi to Padowan to Jedi. One of the best things a development manager can do to encourage knowledge sharing and team unity is switch up project roles in every project. If Jolene .NET wants to learn CSS, put her as a backup resource with a GUI developer, and put the GUI developer on a small 8-hr component development task if she's interested in .NET. You'll need to incporate this ramp up time into your estimates and may get resistance, but a little knowledge sharing and pair programming goes a long way.

13. Knowledge is power. Sometimes the above method of knowledge sharing isn't always real-world practical. Technology is always changing. The best investment you can make in your team is allowing them to go to seminars, conferences, get reimbursed for books, etc. Encourage ramping up 3-6 months before it's needed in a practical project and allow internal time for proof of concepts on real internal projects using new skills before they are needed on a production project. Since you've aready hired the right people with the right conceptual understanding of software development (design patterns and such), the devil is just in the symantics, and $1500 for a 3-day seminar is a lot cheaper than $90k for a new developer.     

13. QA? NO TIME! NO TIME! QA is always the first thing cut. Please, for everyone else's sake, make sure your QA never gets cut. Make sure you have dedicated QA resources outside of the project team and client -- and never ever rely on developer's to QA! However, always keep working to promote an environment where all developers QA their own work every day before submitting to VCS and allow time for fixes, before nightly build.

14. There is no I in "I got hit by a bus". No matter how small the project, always have more than 1 developer on a project and spread tasks around so that project knowledge is reasonably equally shared among tech leads and supports. Always maintain a Trac site, Wiki, project blog or some other centralized resource for essential project information and communication. 

15. "Paper coding." Developers tend to see everything in terms of problems they've resolved previously and prefer to dive into code. Always spend the time to produce tech specs and development plans before beginning a project. The dev plan should be almost a MS Project-style task list of development tasks, resources needed, dependencies, and grouped into timeboxes, sprints, or whatever methodology you are using. I like dev plan's that go as deep as breaking out components into individual model, view, and controller files needed, for example, but no further detail at the onset of a project. From their, the development resources can further define class files and produce skeleton code.

16. Standards & Code Reviews. Make sure you have a centralized resource for coding standards and documentation standards with concrete exmaples that everyone knows to abide by. Have tech leads on projects sit down with support resources and conduct code reviews on a weekly or bi-weekly basis. As manager, you should be looking into the code unannounced with the same frequency to make sure it is keeping to your published standards. 

17. Test-Driven Development. Make sure you schedule time to build unit tests into your project and that your project is built from the ground up with unit test code and that your build files don't skip over these tests. It never fails someone will look past a unit test that keeps failing thinking it's good and it will come back to be a larger, more epensive issue later on. Similarly, the more you can use additional automated testing such as Twist or Selenium for web projects, the better off you'll be.

18. On wheels and reinventing. There's no need for it. Research before you develop. Use third-party tools, components, and software that is readily-available, well-documented, currently maintained, and will accelerate not decelerate your production schedule. Make sure you are adequately accomodating for ramp-up time for each and every third-party tool, component, or software used.

19. Manage classic mistakes, implement best practices. There's the misconception that since we are dealing in software, this field is all new and different. Quite the contrary, the fundamentals of software projects goes back 2000 years to classical engineering projects, and software development processes, mistakes, and improvements have been documented for over 50 years. Take advantage of this breadth of knowledge that's out there by doing your research. The classic books I recommend are:

20. Celebrate your wins. Take time out to celebrate your successes - even if they are just so-so, with your team. Every launch is an accomplishment.