[Silhouette]

Management error #1: "Move up the ladder into management, architecture, or design"

As long as management insist on perceiving themselves as superior to other people, and assuming that technical competence somehow implies management competence, there will always be a drain on the good technical guys. The reward and recognition structure strongly encourages them to change discipline. However, can anyone cite me a single source that justifies this position? I'm not sure that any company I've worked for, of any size, really got more value from its middle managers than from the senior technical people it keeps trying to turn into middle managers.

The assumption that architecture/design is more important than front-line coding is also dubious. A good architect/designer is worth their weight in gold on a large project (just like a good manager), and to be sure you probably need a fair bit of experience to be any good at all in that sort of role. But that just means the low end of the scale for that role is higher, it doesn't mean the high end of the scale for front-line coding jobs has to be lower. All the evidence I've ever seen still says an expensive, high-end front-line coder is disproportionately productive compared to a cheap, lower-end worker. You can have the best project management and the best design in the world, but if all the guys implementing it are chumps, your project is still going to suck.

Management error #2: "Even though you may be highly experienced and wise, employers aren’t willing or able to pay an experienced worker twice or thrice what an entry-level worker earns."

That's because they're dumb... Maybe because they got too many technical people to do their management instead of people who are actually knowledgeable about and good at management? Project costs scale disproportionately with team size/structure. Developer productivity scales disproportionately with experience. How is it that so many companies can't do the basic arithemtic required to see the implications?

Management error #3: "This means keeping up-to-date with the latest trends in computing, programming techniques, and languages, and adapting to change."

This is not an error in itself. On the contrary, IME most older developers who are genuinely interested in their field do keep up (and find it far easier to do so than their younger and less experienced colleagues, since the tech industry doesn't innovate nearly as fast as the PR guys would like to pretend: older guys have seen a lot of it before, and can quickly identify genuinely new things worthy of further exploration and put them in context).

However, the error is in drawing this sort of conclusion based on the statement above: "To be writing code for a living when you’re 50, you will need to be a rock-star developer and be able to out-code the new kids on the block."

Almost everyone who is keen enough to still be coding by that age will out-code the new kid with his trendy tools and methodologies in his sleep.

BTW, I'm not an "old guy" in programming terms, and there's no bitterness here. I'm just a guy who watches this sort of debate from the sidelines, wondering how so many supposedly smart management people can be so utterly, obviously, incredibily dumb for so long, and still not get it in 2010.

[cageface]

I think a lot of this makes sense when you realize that the typical tech company isn't really trying to do something that's very difficult. The average internet company is chasing some gimmicky take on social marketing or a trivial mobile fad etc and your ability to succeed in that kind of environment is going to depend more on your ability to work corporate politics than your technical skills, unless you're absolutely incompetent.

This is much less the case at companies that are tackling hard problems though.

[Silhouette]

I agree with much of what you're saying, but I don't think the "typical" tech company is anything close to the HN stereotype web start-up. Most tech companies -- and almost all successful tech companies -- are not just implementing some obvious, trivial web/social/mobile service and hoping to luck out on a quick acquisition.

[cageface]

That's probably true. I think what I'm saying holds to a large degree within companies too. For instance, you're probably going to have fewer opportunities to distinguish yourself by ability if you're administering mail servers at Intel than you are if you're doing chip design.

[pointillistic]

I have pointed this out in a comment on this thread but would like to repeat it in support of your list.

Myth #1: People hire younger workers over older workers because of the money. This is not true. Think politics and psychology first. People who move up the management ranks often have political or social skill superior to technical skill. They slimly don't what engineers who are more technically savvy or not subservient enough around. Not so the young greenhorns or even immigrants. Competent, seasoned engineers can't be as easily manipulated.

There is no substitute to experience, no matter the spin.

And often the obsessive coders pay little attention to the office politics. This leaves them exposed to the career obsessed suits. Politics and human dynamics first, money distant second, as always.

[hga]

While I suspect you're correct in your first point, why can't both be true (control and money)?

As for your last point, http://www.jerrypournelle.com/archives2/archives2mail/mail40...; it's self evidently true.

[jimbokun]

"(and find it far easier to do so than their younger and less experienced colleagues, since the tech industry doesn't innovate nearly as fast as the PR guys would like to pretend: older guys have seen a lot of it before, and can quickly identify genuinely new things worthy of further exploration and put them in context)"

This is when I like to point out that guys who were coding in Lisp or SmallTalk 20 years ago are looking at the "new" and "cutting edge" programming tools and languages today and wondering why it's taken everyone else so long to get here.

[lionhearted]

> I'm not sure that any company I've worked for, of any size, really got more value from its middle managers than from the senior technical people it keeps trying to turn into middle managers.

Firmly agree and I'll go a step further. I think the traditional org structure and traditional titles aren't well suited for emerging technologies.

Fact is, whoever is held responsible for succeeding/failing is going to get paid more. Being held responsible sucks and is hard.

I think a reasonable alternative would be smaller, largely decentralized teams that don't have traditional management, instead having two people they interface with who take over the traditional management roles - a logistics/supplies guy who checks what each team needs and makes sure they're equipped, and a planning/coordinating guy that makes sure the technical team has something sort of resembling a plan that fits in with the organization's grand strategy.

Team size would be 3 to 10 people or so, with one logistics/supplies guy and one planner/coordinating guy checking in with 5-10 teams at regular times and being on call during certain times if needed.

Something like that. As long as you've got a manager and he's held accountable for results, he'll have higher social status, be more neurotic, and expect to be paid more. I think moving to a supplies/logistics guy (similar to a servant manager type) and a planning/coordinating guy (strategist/diplomat/mediator) you could build an organization where engineers had more respect and authority and seniority, but things would be kept in check. There'd still be some friction between your planning/coordinate guy and technical people, which is natural, but ideally less so and there'd be more of a push for good engineers to lead a new team working on a new project than to become middle managers/planning guys. Largely different skillsets, engineering and planning/coordinating. Google Wave is a pretty good example of why you need a planning/coordinating guy and not just a pure engineering project, but engineers should have the most authority, social status, and prestige in a technology organization.

[Silhouette]

> Fact is, whoever is held responsible for succeeding/failing is going to get paid more. Being held responsible sucks and is hard.

Indeed, but let me ask you this: what real responsibility do all those layers of middle management in a typical big software company actually have?

Detailed planning of individual features is junior management stuff. The only estimates that are really worth a damn come from the junior managers, based on the technical data provided by their teams.

Strategic product and project management -- what products and major functionality are going to be built and when they will ship -- is senior management stuff. The technical decisions that really matter are taken by senior managers or executives. Are we going to drop major projects W and X but include Y and Z, given that this means we can ship a new version of this product in Q3? Shall we authorise a 20% increase in payroll budget for this product's team, given that this would allow us to include project Y by that deadline as well?

Obviously in a large organisation with many products, each of which is itself large, there is scope for having layers of management in between so everyone is working on a sensible scale. But you can scale out a pretty long way with just a single layer containing just a few extra managers, and I'm pretty sure that the 2/3/4/5/6 layers you often find in a lot of big software companies are mostly dead weight.

[amirmc]

Your comment on #1 above doesn't make sense to me.

Immediately after the sentence you cite, the OP says "Build skills that are more valuable to your company, and take positions that can’t be filled by entry-level workers"

Management roles may be one option. You are correct that technical competence doesn't imply management competence but that can still be learned (over the course of one's career).

I do understand the rest of your points though.

ETA: You say ... can anyone cite me a single source that justifies this position?

Exactly what kind of citation would you need? You can probably look at successful companies and see how they handle the problem.

[Silhouette]

> Immediately after the sentence you cite, the OP says "Build skills that are more valuable to your company, and take positions that can’t be filled by entry-level workers"

It is the implication that newly learned management skills are "more valuable" than high-level technical skills that I question. I'm not saying a good manager isn't valuable; on the contrary, I think good management is essential. I'm just saying it's a different, parallel track to technical work, but a lot of people (particularly not very good managers) seem to see it as a technical track that stops at about the level where the management track starts.

[lsc]

this is something I'm currently experimenting with at my company. My theory is that most of the management role can be done by empowered secretaries. Keep track of shit. Kick our chairs, make sure we are actually working on what needs to be worked on and not distracted by shiny. Talk to people and make them feel better when there is social bullshit.

Now, traditionally, middle management has also made high-level technical decisions, which I think is just stupid. you should have technical people make those decisions, and /if required/ have the management types help interface with other stakeholders. Quite often the best people to make technical decisions don't have very good 'soft' management skills, and the people with the soft skills don't have the technical qualifications. (I mean, some people have both, but those people become very expensive, very quickly.)

Middle management does valuable work; the thing is, I think that the soft skills required to be a good middle manager are more common than the skills required to be a good front-line programmer, so really the management role should be done by someone who is paid less.

The question is, how do I carry this off? I mean, part of the managers toolbox is that they can get your ass fired... traditionally, management getting paid more has been part of the power dynamic that makes the programmer quit slacking off when management is nearby.

Some would say that a softer approach is better, anyhow; I mean, like it or not, you pretty much have to treat your programmers well; they have options.

[d4nt]

> "Move up the ladder into management, architecture, or design"

The ability to convert detailed specs into code is a fungible commodity. Management, architecture and design, on the other hand, are areas of software development where you need multiple complementary skills; technical ability, good communication, understanding of your customers and industry area, an ability to influence others, etc. People like that cannot easily be replaced, hence the higher price. In some cases technical guys appear to need those things too, but that's just because they're unofficially doing the job of an architect, manager or designer.

> Even though you may be highly experienced and wise, employers aren’t willing or able to pay an experienced worker twice or thrice what an entry-level worker earns.

Define wise. That sounds a lot like "capable of being an architect/manager/designer". If you're capable but resisting the promotion then I'm suspicious of your claim to deserve more money.

I agree with you that an experienced coder will be more productive than a less experienced one. But I would also say that 20 years experience will never make up for a lack of natural ability. I've interviewed programmers with decades of experience who failed the most basic of our technical tests (think FizzBuzz). I'll bet for every old timer who's excellent and just wants to stay a coder, there are 5 who are just below average and have never been offered a promotion.

I see the issue more as a failure by the good experienced coders to differentiate themselves in the marketplace than a conspiracy against old people. If you've been doing something for 30 years but all you're selling is "5 years python experience" just like everyone else then why should I pay you more? Tell me why you're worth more. Convince me you're lack of promotion comes from a passion for your craft and not just down to a lack of ambition or ability.

[Silhouette]

> The ability to convert detailed specs into code is a fungible commodity.

I strongly disagree. The point of a commodity, in the economic sense I assume you meant, is that one item is just as good as another. You pay a certain amount of $$$, and you get a certain amount of Stuff.

IME, one piece of code implementing a particular requirement is very much not the same as another. Assuming otherwise is the kind of naivety that leads managers to make the sort of mistakes we've been discussing.

> I see the issue more as a failure by the good experienced coders to differentiate themselves in the marketplace than a conspiracy against old people. [...] Tell me why you're worth more.

If you believe code is a commodity, you don't want to hear and won't believe the answer anyway.

[datapimp]

I love that you're fighting the good fight, but to these people who run things, code is in fact a commodity and so is the person producing it. From the owner's perspective you buy coders low, you maximize their output and sell it high, accumulate the difference, and repeat. If you're a more liberal owner, you buy them free lunches and build up a "culture", let them wear sandals, send them to conferences, tell them they're not little units to be counted, but at the end of the day these pretty lies are just costs -- costs, which may or may not yield profit over the long run.

As a coder, and somebody who loves the craft and identifies strongly with it, I "disagree" with this relationship ( as much as that is possible, since nobody asked me to vote on it or anything ) and I think it is dehumanizing. But wishing it away or romanticizing what we do, avoiding the fact that we are commodities just like every other worker in a corporate enterprise is just a terrible strategy for overcoming it.

I like what the guys at http://www.bettermeans.com are doing with the open enterprise governance model. I don't want human activity to continue the process of commodification, and this is a big step taken to change course.

[Silhouette]

Oh, I understand the problem; it was "management error #2", I think. And I understand that discussing it here will have little real impact on the managers concerned. I got off that train personally and no longer work as anyone's employee.

I hope that my contributions to discussions like this will encourage others to do the same, and that maybe, if those people one day have employees of their own, they will be a little smarter than the managers of today and the industry will be better for it.

In the meantime, I don't see why we should place any faith in the established practices of managers who, as an industry, run more projects that fail than projects that succeed. Can you name any other industry where it would be considered acceptable by the market if over 50% of the products bought failed, even if the costs ran to millions? I sure can't, it's just that the management idiocy is so widespread in IT that the market seems resigned to the inevitability that whatever they pay for will be crap that doesn't work properly.

[jimbokun]

"The ability to convert detailed specs into code is a fungible commodity."

If you have a good programming language, the code should be the "detailed specs."

"But I would also say that 20 years experience will never make up for a lack of natural ability."

20 years of "experience" won't, but 20 years of dedicated practice will.

[j_baker]

"I'm not sure that any company I've worked for, of any size, really got more value from its middle managers than from the senior technical people it keeps trying to turn into middle managers."

I think tech companies see this as the lesser of two evils. Would you rather lose a good programmer and gain a decent manager, or would you rather keep the good programmer and gain a PHB who will drag down the performance of that good programmer and their entire team?