Pro Developer : Throwing Money Out the Window
-
I wonder how those of you who became managers, how you became so?
Were you formally trained or did you come into the office one morning and realise that most of your colleagues were older than your album collection?
I suspect it is more the latter. Don't laugh, I have colleagues who were born AFTER the birth of CD's!
The problem is that, as a technical person you beaver away for a few years, get asked to guide less senior staff, become a lead developer, and final end up as a project manager or similar.
I have friends who are in the awful position of having gone down this path and found that their managerial duties mean that they have no time to maintain their technical skills. They end up in the position of becoming technically obsolete whilst not really having the qualities(?) for management.
They either have to learn the skills for management or get very good at the "Why did you leave your last position?" question.
The problem they face is that they can't go back. By the time you have walked the path you will probably have gained wife/kids/mortgage and need the managerial salary to support them. You can't say "Sod it, I'll work for the joy of the experience".
I don't know how it works in the USA but in Britain there is a horribly short sited attitude that demands a cheap temporary fix that lasts forever. This explains the British railway network.
The tendency is that managers do not get the training and back-up they need to do their jobs. No-one has grasped that a good manager is not born, he/she is created.
Natural talent will get you so far but its a long hard road to discover best practices from first principles.
What we need is for technical people who have become managers to be trained as managers. Get project management accreditation. Learn people skills. Read "How to win friends and influence people" and "I can see you naked". If your in a dark mood read any project management book by Edward Yourdon, "Death March" being a particular favourite.
One thing I have learnt is that, with very few exceptions, there are very few bright stars in the management world.
Remember, people get promoted to the level of their own incompetance, and we all know people who have excelled in this.
-
Bill Gates has fronted Microsoft for 25 years.
Microsoft is on-and-off the most highly valued company in the world.
Bill Gates knows business.
Bill Gates is a techie.
Bill Gates listens to his techies.
Maybe he's onto something...
Edited by - jonreade on 12/18/2002 07:58:06 AM
Jon -
A very apt description, David, And follows what I see in the world very closely. Sums up exactly why I refuse management positions. I don't mind taking lead roles, but it would only take 6 months or so (maybe longer) to start forgetting all the gotcha's that need to be considered.
For your statement:
I don't know how it works in the USA but in Britain there is a horribly short sited attitude that demands a cheap temporary fix that lasts forever.
It's no different here. A temporary solution is put into place to get though, then as long as that's working, regardless the consequences, it's just left there until it becomes a critical situation again. After a few of these, nothing works right anymore, and the whole IT shop is scrambling to patch the patches and repair data errors created by the patch which was not designed to be permenant to start with, and they all say then that they don't have the time to look at anything else, and we have what I call an IT department of firefighters. What's really bad is when they start hiring more IT people, or buying more and upgraded hardware, to handle the ever increasing load of these, rather than just fix the thing. I used to think that eventually they would learn, but now I have decided that they have the learning capacity of a rock. Sometimes, I wonder if they handle things the same at home. Wait until the shelves are completely empty to go to the grocery store, wait until they run out of gas on the freeway to go to the gas station, wait until they are in the final statges of dying to get treated for a disease, wait until the divorce is final to make up with their spouse, etc....
Somehow I doubt it, but that brings up the question of why do they do it at work then? Is it because they are not personally affected? Have no accountability? I don't think I'll ever understand that mentality, as I'm strongly based in logic.
I have a document I wrote a while back that I use for situations such as these. It simply states, I, _______________, understand the consequences of this decision, and after being advised by my technical resource against it, have chosen to do it anyway, and take full responsibility. and then a signature line. When stupid things start occurring, I present the document to my manager, and request he sign it. I justify it to them with, I refuse to take responsibility for things beyond my control, and you just removed this from my control. Amazingly, its never been signed, but generates a huge amount of discussion on the current topic, and generally gets a new decision made.
-
quote:
I, _______________, understand the consequences of this decision, and after being advised by my technical resource against it, have chosen to do it anyway, and take full responsibility...Priceless!
Chistopher Duncan
Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
http://www.showprogramming.com/TheCareerProgrammer.asp
Chistopher Duncan
Author of (Apress) The Career Programmer
Unite the Tribes (Apress) -
Yea, but be careful. Makes em REAL mad. I just keep in mind that they didn't hire me to draw a check, they hired me to tell em the truth. Whether they like it or not. If they fire me over it (hasn't happened yet), then I didn't need to be working for em to start with. They can sit the janitor in my chair and he will be just as efficient. Just nod you head when they speak......LMAO
-
Great article and interesting discussion.
ckempste, second vote for your article. Not entirely sure what you were leaning towards on the first post, but I'd be interested to hear more.
I've had management and tech jobs over the last 12 years and I've seen successful, implemented, and failed projects. While I mostly agree with things in the article, there are some things I've noticed that I wanted to comment on.
First, most projects I've seen don't fail in that they are not implemented. Usually they are late, or implemented and thrown out much sooner than expected. Maybe I've been lucky, but relatively few projects are actually funded with some $$ and never deployed. Perhaps that's the "I've invested in this, I can't throw it out" mentality, but that's been my experience.
So it seems most projects are only some % successful (10%, 90%, ?? not sure what the number is), but are often not well received. I think lots of this goes to many things, but mainly communication.
Developing software is hard. Not only for the programmers and architect/analyst, but also for the client. It's such an abstract thing that we often don't know what we want. Even I don't know. Until I see something, I can't completely visual what would work best (or better). I think this was and still is a huge problem in software. I've started to come around that we should only aim for, build, and budget for 60% of what we want and leave a blank check (time and money) for the 40% because we will modify things after that. I'm also a big "small modules and increments" kind of programmer.
So should I run the company and make the decisions? Not all of them for sure. I like being technical and worrying about my area. I don't want to worry about sales. That should be what the upper management ponders.
However the article and posts do point out some great problems here. We are human and we drive for our own adgenda. And that is where things break down. Executives worry about their reputation and their scorecard (salary) more than the long term health of the company. Does the stock price matter if the company is making money? A little since you do have an obligation to the shareholders. But also to the employees and company. And the short sighted, Q to Q mentaility leads to decisions that "throw money out the window".
Middle managers, technical and other, have different agendas. Furthering your career - Why take on a project what has a poor reward/risk ratio. Comfortable? Why rock the boat?, Bored? why make work for yourself?
I know I'm rambling, but the human factor is important. It's what gets in the way of efficient operation. Which is what us techies want, right?
Well, that gets in the way as well. I've worked with guys that engineered to death, missing the point that we have to finish. Worked with guys who'd rather play doom/quake/etc. and didn't test code. Seen code written that worked ok, but wasn't well engineered.
<gross generalization>The dot coms were mainly filled with techies that didn't understand business.</gross generalization> And they failed, but they also built some great technology.
That could have been used elsewhere and made money.
OK, I'm rambling so I'll drop off with my ideal view of corporate workings.
The company should exist to grow itself, care for it's employees, and better society. The profit motive should be there, but has to be tempered by looking at the place of the company in society. You do have an obligation to employees that includes the need to keep their interests (security, training, etc.) in balance with those of the shareholders. A code of ethics balances the executive goals with that of the company, employees, and shareholders, so that the Q-Q view of the world is not more important than the long term. Executives are not compensated out of line with other workers (and they are in the US). Emplyoees work for the good of themselves tempered with that of the company. Keep the total objective in line. You get paid, have security, etc. and you help the company grow itself for the long term.
Lastly, everyone respects each other, both as individuals and corporations.
Crazy, but throwing money out the window happens everywhere, not just in software. And it's not anyone's fault. It's everyone's fault.
Steve Jones
-
I agree with those who realize that a great developer does not become a great manager. Those are two different creatures.
The problem is an assumption that to advance in career one needs to become a boss. In fact, one could make more money as a senior architect, designer, DBA, etc. or doing CONSULTING. Consulting is the way to go if you want growth. Consultants are the best workers. Employees (programmers) may leave at any time anyway. Consultant treats the company as a client that cannot be lost. Consultant won't ever leave you, just treat him well. Consultants are not protected against termination. They have to do a good job. The only challange for the manager is to realize the difference between a true professional and a hacker.
-
It's interesting you bring up the money aspect of it, mromm. I've actually been denied raises before on the basis that it would cause me to be making more than my manager. I was told outright that in order for me to advance ANY farther within the company, I had to become a manager, and since I wasn't willing to do that, had to be happy right where I was.
-
I've seen that too, though it's changing. More and more I'm seeing tech pros paid more than their manager. Comes a limit, however, since managing entails more responsibility at some point (arguable) and so worth more to the company.
Steve Jones
-
Steve raises an interesting point.
quote:
People don't know what they want.But they sure as hell know what they don't! Normally they demonstrate this after you've spent blood, sweat and tears delivering it!
One of the problems is the customer who thinks they are getting one thing, but actually asked (and signed the functional requirements spec) for something completely different.
I have an ancient uncle whose observations where that IT within a company goes through three itterations.
- Know one knows what they want or what is possible so the project is a disappointment
- Everyone thinks they know what went wrong last time or now has a pretty good idea of what IT can do so they ask for everything. The project overruns and is a disappointment.
- Everyone is sadder and wiser and finally there is a meeting of minds within the vacumn of corporate thought.
OK there are variations on this but as a sweeping generalisation he is spot on.
-
Sorry about the spelling in the previous post. Some swine switched the office coffee for decaff.
-
Was wondering about that post.
I think this is where what we do is more of an art than a science. Each work is unique (to a large extent) and works differently than other systems. As we give it to someone to use, they find different ways to use it and ask us to change it. It continually goes around like that as we modify, they react to our modifications and the circle continues.
My contention is you should expect this. We are dealing with a very malleable thing with software and when a client/customer/user wants to mold it, we should be ready and happy to continue to evolve it. Don't be upset, they are paying you to meet their needs. By being glad to meet their needs, you stand out and prove yourself as their developer of choice.
Steve Jones
-
quote:
Some swine switched the office coffee for decaff.Hang him!!! No, wait, hanging's too good for him. Make him the Maintenance Programmer!
Chistopher Duncan
Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
http://www.showprogramming.com/TheCareerProgrammer.asp
Chistopher Duncan
Author of (Apress) The Career Programmer
Unite the Tribes (Apress) -
quote:
<gross generalization>The dot coms were mainly filled with techies that didn't understand business.</gross generalization> And they failed, but they also built some great technology.Yeah, that's something I try hard to make programmers realize. It doesn't matter how cool your technology is if the company doesn't make money. Why should you care? Ask the out of work programmers you know whose jobs evaporated after the dot com they worked for went out of business.
quote:
Crazy, but throwing money out the window happens everywhere, not just in software. And it's not anyone's fault. It's everyone's fault.Very true. In fact, I'm planning on expanding both my writing and seminars over the next year to cover the corporate world in general for just this reason. No matter what you do for a living as a worker, productivity and corporate profitability depend on the very same issues.
Chistopher Duncan
Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
http://www.showprogramming.com/TheCareerProgrammer.asp
Chistopher Duncan
Author of (Apress) The Career Programmer
Unite the Tribes (Apress) -
I agree with David and Tom. I have only 4 years experience, but I have seen major disasters caused by programmers who don't have any social skills and therefore cannot manage a project, and also from managers with no technical background who make idiotic, short-term fix / long-term disaster decisions.
The worst kind of managers are those who listen to their developers and then ignore them in favour of what has already been decided, or managers (usually techies) who believes in the utopian view of projects where no compromises or trade-offs need to be made, documentation is an optional extra, and everything will come good in the end because they are using the latest bleeding-edge technology which is sure to make everyone's life easier.
What is really needed is for utopian developers to gain some grounding in the real world and learn to make the often painful decisions that will have a reasonable chance of satisfying the customer and the project budget!
One final point. Learning to micro-manage your work will turn you into a micro-manager, and you will stifle creativity. Never schedule a task for less than a day. Personally, unless it is a very small project, I would not schedule a task for less than 5 days - if necessary other tasks should be rolled up into one larger task.
Viewing 15 posts - 16 through 30 (of 31 total)
You must be logged in to reply to this topic. Login to reply