Many new team leaders are compelled to organize their own team's work based on the experience they got when they were programmers. Sometimes, the lack of alternative viewpoints or simply a negative past experience leads to the usage of a "trial and error method" and that, undoubtedly, is a very expensive approach in any industry. In this article, I list several rules I've acquired with my experience; they help me manage my team of developers and projects we work on together.
When a former developer becomes a team leader (I mean that he or she possesses a team to manage, not merely a title), additional duties arise. The duties are from the management realm and even some bright and clever programmers are not acquainted with them prior to their starting to carry them out. There is no know-how in the article, although it may prompt a leader to consider ideas it describes or find an alternative approach. The advice is placed without any order of preference or importance.
1. Log Your Self
You're not an independent developer anymore. You're not a player in a jazz band where the art of improvising is a measure of your skills. A part of your duties is to be able to tell the project's current and coming tasks and what each of the team's developers is doing now. Write down all such records, as in in a chess game where every turn is recorded. This is a rule I fought against most when I became a team leader. My project manager was a pretty inquisitive person (from my point of view), and he came and asked me a few times a week what each of my team members was doing. On the face of it, I found it very disturbing and even annoying because my approach was that the project manager had to communicate to the team leader and not to go deeper.
Now, I see that he was right, (Ezra, many thanks to you!) All his demands finally made my administrative work brighter and clearer for myself. I became able to estimate the quality of my colleagues' work on a more precise level and they started looking at my requests with greater responsibility. Scrawling a plan on a slip is not enough for a manager, although it might be suitable for a sole developer. Ask your programmers once in a while to update the status of their tasks and you'll always possess a very up-to-date status of the project. Besides that, separate all your tasks into several groups (features, bug-fixing, research, improvement, and so on) and when a task is originated, assign one of them. It makes the whole picture easier to understand, and when a task is completed, add a coming release number of the project to trace when the task was finished. This facilitates composing an update/history report from release to release.
If your OS is Windows-based, a handy tool is MSOutlook. Its standard Task has a category field, or you may create your own form. There are dozens of free issue-task-bug tracking systems, among which I can list old good Bugzilla and Scarab (see the Resources section for links).
2. Explore Open-Source Projects
Sourceforge, the biggest open-source project (OPS) portal, reports about 60,000 such projects it's holding and about 600,000 programmers from all over the world participating in those projects. Some of the projects are extremely stable, robust, reliable, and are being used in a production environment. Many of them have the kind of license that allows their usage in commercial products. They're very useful when you develop a non-unique task. Every time you make a new request for a module, node, or functionality, try to figure out whether something similar is done by a community. First, you'll gain in development time and second, an OSP is usually being developed faster then yours. Its bugs are found and fixed quicker and new features are introduced more actively.
Lack of such knowledge leads to re-inventing the wheel and the wheel sometimes isn't as round as one wished. When you find a project that looks suitable for your needs, pay attention to its pulse, namely, how much it's alive—send a simple question to its mailing list and see how fast you get a response. Also, find out about its competitors and analyze all pros and cons. Sometimes, the number of similar projects may be pretty big and such research takes time, but you'll be generously repaid for your work. This rule applies most of all to developers and not managers. But, when you're entitled to choose approaches and technologies to accomplish a target, it affects you as a manager to a greater extent.
3. Work in a Sandbox
Put your project in a version control system (VCS), create a working directory on your local disk, and don't allow anybody to work outside of the sandbox. Force your team members to update the code frequently. For a big feature or refactoring that can't be integrated into the working trunk on a daily basis, create a separate branch and work from it. Don't allow any code to be just-on-your-local-disk. Create a system of naming your releases and don't grudge labels (or in some systems, they're called tags). Write a set of automated scripts that do all the job on their own. I like the idea of nightly builds—a scheduled procedure building a product version out of the latest source. My projects are built and deployed automatically during the night so anyone can work with the most current version of the product. Add supplementary server scripts (if your VCS system allows) that help you check code policy on every commit and alert you by mail in a certain case.