|Just another Perl shrine|
Re: Making the Business Case for Developer-Run Developmentby Elgon (Curate)
|on Aug 10, 2004 at 09:57 UTC||Need Help??|
An interesting line of thought; I've read some of Paul Graham's essays and handed them to people with whom I work, with varying results. My thoughts are below...
A large part of this debate seems to come from a gradual drift in what it means to be a manager; IMEAO opinion, a manager is someone who exists to enable people to do their job as well as they can. This can be taken in several ways, but largely this can be divided into technical and nontechnical management...
Non-Technical Management; The manager has a non-technical background or has little understanding of the technical issues faced by developers. Please make a careful mental note here - Just because these people do not have the technical skills which developers have, does not mean any of the following things...
a) That they are stupid
What these people can bring to a technical team is their ability to communicate to upper management in a language that they will understand, while being close enough to the people at the coalface to see a vaguely accurate picture of the situation. A manager or leader who represents you well can be worth their weight in gold if they understand when to butt out and leave the technical work to those with the appropriate skills.
Technical Management; The manager is technical, that is to say, they have a good understanding of the general nature of the problems being faced by the people who work "under" them. This understanding or appreciation for technical issues means that they are capable to act as a mentor, arbitator and someone who can direct the actual work of a technical department. This should not be taken to mean any of the following things...
a) That they cannot appreciate business issues
People such as these are very important, for they not only direct the technical flow of a department, but they also help train up the newer folks in the department and, for this reason, their experience and skill in helping others can far outweigh the possibility that their skillset may not be up to date. The possibility that they have been around for a while can also make senior management listen to them a little more. But, just as the nontechnical manager has to butt out occasionally, so too, the technical manager has to realise that business reality can override "good practice"; It can be very easy to end up rearranging the deck chairs on the Titanic if you don't keep half an eye on the bigger picture.
Bottom Line: If the technical and nontechnical halves of a department try and work together, seeing each others views of a given situation or issue, you will be able to achieve a hell of a lot more than if the techical folks start whining about "clueless management" and nontecnical leadership try to impose their view of the world on technical staff.
Let the flamefest begin!
"Stercus! Dixit Pooh. Eeyore, missilis lux navigii heffalumporum iaculas. Piglet, mecum ad cellae migratae secundae concurras."