Learn from the mistakes of others

Any successful software company is going to consist of a thin layer of developers, creating software, spread across the top of a big abstract administrative organization.

The abstraction exists solely to create the illusion that the daily activities of a programmer (design and writing code, checking in code, debugging, etc.) are all that it takes to create software products and bring them to market. Which gets me to the most important point of this essay:

Your first priority as the manager of a software team is building the development abstraction layer.

The Development Abstraction Layer, Joel Spolsky, Joel on Software, April 11, 2006

Having done both jobs, I agree with Joel. Most programmers work best when they can just get on with the job of programming.

That's one reason why promoting good programmers into management positions is not always such a great idea. Management and programming are very different activities.

Good managers, like good coders, are hard to find. They ought to be nurtured and looked after - the managers and the coders.

Again, having done both jobs, I find myself wondering if I wasn't a better manager than coder. Whether I was/am a good manager, I leave that for others to answer. I do, however, feel pretty confident about my flexibility, and my ability to help get things done/fixed.

Anyway, back to the point of this post: when a team works well, everyone does their job well, with their colleagues in mind. Things begin to happen like magic. A magic that is hard to replicate without the whole team. Even harder to "make" happen without the cooperation of every team member.