Dear Readers,
For those of you working in the software industry, what career path would you like to follow?
I would say that I have followed a typical route. First, being a member of a team of developers, essentially told what to do most of the time. Second, still a member of a team, but in a more senior role, partaking in more design decisions. After that I became responsible for my own team of developers - determining the design direction at a low level, planning their work and overseeing them on a day to day basis.
Each of these roles has its own importance, but where do good developers go after managing their own team? Do good developers even wish to move into management at all? I would be the first to admit that while I filled the role of a team leader adequately, it never really grabbed my interest, and I always had this nagging feeling that the company wasn't making best use of my skills.
This leads me to a question - how do companies satisfy the aspirations of developers who wish to remain technical but who also wish to progress their careers? The disappointing answer from most companies is that they don't.
I directly asked the first company I worked for (it shall remain nameless) about my opportunities for career progression in a technical role. The answer I received shocked me -- there was no such career path. I was told that if I wished to progress I would have to move into higher level management.
In my current company, until fairly recently, this was also the case. However, I have seen my current company's development department grow from about ten developers to its current 60-strong size, and since I believed it was still small enough to make a substantial change to career structures, I and other like-minded people in the company lobbied for change. It took a long time, and we nearly lost hope, but eventually we achieved the goal of both managerial and technical career paths.
The role I have recently moved into gives me technical responsibility for products throughout the company while leaving managerial responsibility with those of my colleagues who wish to progress their careers in that direction.
It's still early days for us, but I believe that the new arrangement we have can work, especially if we're given the chance by the rest of the company. The main goal we hope to achieve is to give people within the company a range of different career paths, progressing from the early stage where you take the role of a developer, to the later stages, where you can either be responsible for technical man management or direct your technical skills towards high-level product architectural issues. This will hopefully allow the company to satisfy the aspirations of those software engineers who wish to be valued primarily for their technical skills.
I'd be very interested to hear from readers who have had experiences, good or bad, with companies and their reactions to technical career paths.
Peopleware
Now for an advert…a few years ago I read for the first time a very interesting book by Tom DeMarco and Timothy Lister called "Peopleware" (ISBN 0-932633-43-9). A friend in my first company recommended it to me as his personal software management bible. At the time I read it, it seemed that every bad technique was exemplified by my company. It made very depressing, but sensible, reading.
It covers topics such as how the working environment affects developers, how to pick the right people for your organisation and how to promote the growth of productive teams. Perhaps more importantly, it also describes exactly how to destroy good teams.
I would advise any person managing software developers to read this book very carefully. Perhaps the most dangerous thing for managers is that their staff might also read it!
An Apology
There are always better ways to start an editorship, but I find that I must make an apology for a serious editorial error in Overload 31.
I neglected to publish the correct version of Mark Radford's article, " Factories in C++: Disposing of the Product". The version that appeared in Overload 31 was an unedited draft, and I apologise unreservedly to Mark, who had provided me with the final version in plenty of time.
The correct version of the article can be downloaded from ACCU website. The URL is: http://www.accu.org/c++sig/public/ol31/Disposal.html
A New Chair For ACCU
Congratulations are due to a regular contributor to Overload, Alan Griffiths.
Alan will be taking over the role of Chair of ACCU after Francis Glassborow retires from the position.
We wish Alan all the best with his new responsibilities and hope the membership of ACCU will give him their support.
