|
Anonymous wrote:
anonymouses
Shouldn't that be anonymice?
Software Zen: delete this;
|
|
|
|
|
Years ago I used to work with two bosses who had no programming exerience. They were both directors of the company I worked for and neither was the technical director. The Technical director actually knew what he was doing, but was frequently overridden by the CEO and, indirectly, by the Sales Director who used to carp to the CEO constantly.
As a technical lead on one project the CEO asked how a certain feature was going. I replied that it wasn't due until the next release as the development plan had been signed off already. He should have known that. Perhaps he already did. But, he insisted that it be put in for the current release, which was due to go for beta in two weeks. I tried to point out that the initial "optimistic" estimate was at least three months worth of work, but he continued to insist that it go in the current release. So, patiently I tried to explain that the only way to do that was to put back the current release by at least three months. That was not acceptable as the Sales Director had promised a potential customer a beta to evaluate with that feature by the end of the month (two and a half weeks away) and that I had better work out a way to get the feature in or else.
In hindsight I wished that I had had the gaul to tell him to f*%$ himself because at the following board meeting [Edit] Information removed for legal reasons [/Edit]. You can't imagine the relief that he was gone. Unfortunately, guess who replaced the CEO. Yes... It was the Sales Director.
I now work for a great company where all the managers I've worked with have been developers or at least engineers and understand the issues. I don't feel stressed about my work any more because I don't have to defend myself against gross mismanagment exceeding dilbertesque proportions.
|
|
|
|
|
How I know the feeling....
How about having a manager asking you for a project timeline, then dropping out two weeks of testing (both system and user-acceptance) because "it's a waste of time and there will be errors in any case..."?!
As it turned out, I brought the matter up with higher management, bargained for one week of testing instead of two, and no errors slipped through whatsoever...
Can't imagine the wiiiiide smile I had on me face....extended from one ear to the other...
|
|
|
|
|
Exactly the same here, except to a worse extent. I work for a very small financial IT company where the sales director IS the managing director. No knowledge of programming whatsoever.
Tasked with created a system for a client I was asked to come up with the initial work breakdown schedule. I created with x weeks for Analysis/interviews, y weeks of design etc etc. The project was scheduled to take in the region of 18 months. The schedule was signed off and work was begun on the analysis phase until, one week later the MD came in and said that the project had to be prototyped and shown to a large client in two weeks. We explained that even a prototype at this early stage was rediculous but never got our way.
It eventually went down the road that the prototype was a good start and we were to continue developing it directly in conjunction with the client. There was no further design and no further analysis. We're now about 6 months in to the project making it up as we go, and boy do I feel like I'm paying for that decision. Frustrating is the best word for it as the client likes to keep changing their spec etc.
Sigh. 
|
|
|
|
|
I agree that it is easier to deal with superiors who are technical. However, from what you write, it seems that these people didn't trust what you are saying at all.
One of the largest reasons why working with technical supervisors is easier is that they tend to use their own knowledge to judge whether you are telling the truth or just covering your a$$. Where as most non-technical people assume that developers are always exaggerating, so therefore they tend to dismiss most of what is said.
So, ultimately I believe that the issue comes down to trust. So, whether they understand the details or not, if they trust your estimates then there should not be an issue. For example, say you need to have your car fixed and the mechanic says it will take 6 hours of work plus parts (which is going to be a hefty amount) ... do you trust his estimate or do you think he is full of $hit.
Although I do trust the people who work for me, I still use my knowledge of software development to ensure that the timelines given to me sound reasonable. So (this is where technical abilities really count) if they do sound incorrect I can then at least have a reasonable conversation to figure out why.
... however this is just a basic summary of how I look at this, so if you want my full rant on the subject just ask 
Troy Marchand
VP Softare Development
Dundas Software Ltd.
|
|
|
|
|
However, from what you write, it seems that these people didn't trust what you are saying at all.
That sounds reasonable. They, the CEO and Sales Director, could never figure out software timescales. THEY would tell US (the development team) that feature X should take, say, 3 months and feature Y should take, say, 2 weeks. In fact they were often the other way round. They were not very mathematical so when they tried to esimate the time anything mathematical was very pessemistic everything else (i.e. anything thay was easy for a human to do) was overly optimistic. However, if they had listened to the Technical Director then things might have run more smoothly and less stressfully.
If there was any reason for compensating my estimates due to lack of trust they should have been increasing mine because at that time I was usually overly optimistic by a third (I would estimate 3 months and it would actually take 4) rather than taking my estimate of 3 months and collapsing it to two weeks.
Anyway, don't let me stand in the way of a good rant. It's good to get it off your chest.
|
|
|
|
|
You really shouldn't blame lack of technical ability for poor management skills. Even a skilled programmer could have made that call.
Managing a project or staff is not a technical issue, guiding or mentoring staff is. This is a regularly confused issue by more technical managers.
I often find better managers are exactly that, professional managers, not programmers that have risen through through the ranks over a period of time. Obviously you have found someone who is a good manager to work under now, wouldn't be so quick to atribute it to his technical ability.
|
|
|
|
|
The project manager that is in charge at the moment has lots of experience programming, but that doesn't necessarily mean that he is good at managing projects. Unfortunately, some people just aren't cut out for this type of work and only want the job because it pays more and makes them feel important.
|
|
|
|
|
Very wise move! After all, the "boss" with extensive programming experience may be a CP member!
|
|
|
|
|
That's it exactly!
..so what's you're excuse?
|
|
|
|
|
Anonymous wrote:
Very wise move! After all, the "boss" with extensive programming experience may be a CP member!
 Chris I want the IP of this one!!
... so we can go out and have a beer toghether!
|
|
|
|
|
I have no comments here because of that...
John
|
|
|
|
|
I was offered the position as software manager in our company, but turned it down because:
1. I wanted to stay at the sharp(er) end of programming 
2. I hate managing people - sometimes I can barely manage myself 
3. Too much other crap keeping me from doing what I love
As it turned out, the guy they employed to manage me and the others turned out OK (and thats not butt kissing either)
Roger Allen - Sonork 100.10016
If your dead and reading this, then you have no life!
|
|
|
|
|
but the group manager talks as if he does, and makes some appalling decisions as a result of this. It is fortunate that our software competitors act the same too.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
