Project Management For Programmers?
welshdave asks: "I'm a senior web developer in a medium sized company where the project managers have no programming experience of any sort. I'm of the opinion that project managers should understand the projects that they're managing and want to move into project management myself. I'm aware that I may meet resistance from the current project managers - many of them have been hired with no previous experience of anything. Previous suggestions to senior management that myself and other developers would feel better with a technical person running projects have been dismissed. As a result we are routinely told to skip testing or to implement the impossible, with an emphasis on how things look rather than how well things actually work. Has anyone else found the barrier to project management is their technical knowledge. How did you get past it?"
If your "managers" have no technical experience who writes the specifications that you aim to implement?
If they present you with some kind of brief, insufficient description of the project, you need to write out something more specific, that you can actually work too. You learned, as I learned, in cs 101, that you shouldn't start working on a problem until it has been clearly defined. You learned, as I learned, that if you start programming without a clear goal in mind, you won't know when you "finished".
So you write this description. Get your fellow team members, if you have any, on side. Then take it to your manager, and get them to read it, and sign off on it. If their original design has some impossible "feature" in it, maybe this is where you explain, in writing, where it is impossible. If it isn't really impossible, just very difficult, and in your technical opinion, of marginal utility, this is where you present your bosses with an honest prediction of the cost of their pet feature. If you explain to them that their pet feature will make the project take twice as long, or three times as long, will they really still want you to do it? Or will they say, "Oh shit, well in that case forget it."
If they really don't know what they are doing, then they will probably fear a paper trail that documents that you warned them the pet feature would double the time to implement.
If your boss is an asshole, and says something like, "If you can't do it I will get someone who can!" Or, "If you can't do it within this time constraint I will get someone who can!" Call his or her bluff. If their pet feature really is impossible to implement, they won't find anyone else who can do it.
Revise your document to reflect the choices they made. Then work to this document. If they wanted you to implement their pet feature, even though you explained it would double the time to implement, you have protected yourself against the complaint that you are behind schedule. Document your work. Each time you complete one of the milestones in your original memo, refer back to your memo.
So, are you doing tasks which are really the job of the technical manager? Without getting a corresponding raise? Well, yes. But you did, after all, want to move into management, didn't you?
If you do a good job implementing what you promised in your memo will they reward you with a promotion, a raise?
I don't know. But you have acted with integrity.
If it comes time for your annual performance review, is this the time to explain that you have already been shouldering responsibilities that are really management responsibilities?
It wasn't that the techies were doing poor work, or slacking off on the job. Far from it - we worked our asses off. But a lack of knowledge about what was and wasn't possible resulted *directly* in impossible task assignment, with the entirely predictable consequent frequent outages and customer dissatisfaction.
Oh, and remember how I said we had layoffs? All the project managers were laid off save one. The surviving PM was universally held as being technically competent and a gem among mud.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
The other benefit of this is that the other guy doesn't get called a "Non-technical PM", which you have to admit isn't a very good job title.
In the (quite large, 12k staff) company I work for, the pinnacles of career (at least for most people's career paths) are
- Programme Manager - these are the guys the Project Managers work for
- System Architect - career progression here is measured in terms of the criticality or size of the project you run/work on
- Principal Consultant - your job here is to be your organisation's main expert on some specific thing (deep skills rather than the wider skillset which is more usual for a system architect)
We do have some career positions above those, but they're mainly line-of-business and divisional management, Managing Directors of various business units, and so on. We have a dozen or so members of technical staff who are more senior than the System Architects for large programmes and the principal consultantts, but they don't really have specific job titles (as you might expect at that level, people know them by their name and reputation alone).We have a group Technical Director (used to be the deputy Technical Director of the BBC), but he doesn't sit on the executive comittee - that may be something it would be best to change.