- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Good article, but for those of us in certain countries you forgot one word that throws a spanner in the works ...
Unions!
Bane of my bloody life and I've had to put up with them protecting the morons here in Sweden and while I was working down in Oz ...
Admin
One method sometimes used to ensure turnover is the practice of forcing each department to get rid of the bottom 10% of their group. Sounds great in theory (just like Alex's does), but in reality can leave to ineffective and inefficient cliques...
The company I used to work for was getting ready to implement the 10% plan. Problem was, the bottom 10% in my department was the manager. Does anybody really think that he'd look at his group, see himself in the mirror, and say "wow - I really suck!" Come on now. In reality, he would have gotten rid of the person who stood up to him the most. That would have led to other skilled workers quitting or transferring out to other departments (keep in mind those other departments just had openings in 10% of their positions!), so after a year or two all that would have been left in that department would have been the incompetent manager and his subjects/sycophants.
As is - he did not have to worry about that. He was so bad that within a year of his taking over he lost every worker who had over 1 1/2 years in that department.
Admin
TRWTF is that there is no WTF!
Admin
Excellent article. I've been in that "value apex" curve more times than I care to remember.
But the "culture of quitting" is just a solution to the larger software management problem. Genuinely talented people find their value falling off, as the apex curve indicates, because the company places little or no value on excellent software. So it's no wonder the engineer is of decreasing value once the software reaches a "good enough" state.
I'm betting there isn't much of a turnover or "culture of quitting" at a place like Google.
Admin
Great article. You have very effectively described the US military. As a 17-year member of the Air Force, I find that "culture of quitting" describes us perfectly. Even though a member may spend 20 years "in the Air Force", part of the culture is that we never spend more than a few years in a single job or place. Because we are always aware that we'll be leaving our current assignment eventually, we are encouraged to "document" our job so that the next shmuck can take over after we leave.
Of course, such a culture has its own problems. For us, "up or out" applies, but not in terms of technical knowledge. Generally, an Air Force member is encouraged to learn more about "leadership" and "management skills" than the technical aspects of their current job, because it is assumed that if they stay in that they'll move into a management position. "Up" in this context is equivalent to "supervising more people".
Admin
That's precisely my point. If I were only in it for the money I would be a lawyer. But my desire not to be a lawyer is far greater than my desire to make an enormous amount of money.
Admin
Oh wow, this is formal VERY interesting!
Admin
Anyone want a peanut?
Admin
Well that particular snippet you quoted is more aimed at management's fears that you'll be the one to leave. Regardless, sometimes management does hate their staff and want to get rid of them - they're a whiny bunch of geeks in a cost center and that TV report they saw the other night says there's tons of people in this country or others willing to do their job for much less money. Yes, these are the poorly managed companies with very flawed logic but it does happen, and probably more often than you think.
But yeah I agree with the irreplaceable=unpromotable bit.
Admin
@Iago
You may want to consider reading "Putt's Law and the Successful Technocrat." Every technological infrastructure eventually gets to a competence inversion. All the people that know how to get things done are on the bottom keeping the business alive while the management ranks are filled with...you know.
Admin
The Dilbert Principle:
Companies tend to promote the least competent employees to management, in order to reduce the amount of damage they can do.
http://en.wikipedia.org/wiki/The_Dilbert_Principle
Admin
Best article ever on this site.
I misread Value Apex for Value Alex when I first read it.
Admin
Actually, Ph.D's in Computer Science are often seen as damaged goods by industry.
(The best compsci folks I know are Ph.D's, but you have to vet them carefully.)
Admin
This article has some good things to say, but it's relevance isn't universal in our industry.
New roles within a company can push the value ceiling up. In other words there is no apex, since there is no decline.
Now, I realize that not all companies aren't like this (I know, I've worked for some) but moving from short-term job to short-term job isn't necessarily a walk in the park either. I mean, how much self-actualization do you get from building a Shopping Cart Application, or a Corporate Intranet, or an internal CMS over and over and over...
I won't address the "Mercenary vs. Citizen Soldier" mentality. Machiavelli and others have written better about it than I could ever write. Different strokes for different folks.
Admin
Why I don't want to leave my job...explained in a wayne's world quote...
(Benjamin and Garth are in some kind of lab away from the set of the show, with lots of wires, and a hand on the table.)
Benjamin : Garth, you and I, we've never really talked.
Garth : (Stares blankly)
Benjamin : We're thinking about giving Vanderhoff a weekly spot on the show, how do you feel about the change?
Garth : We fear change... (the hand starts to move its fingers, so Garth picks up a hammer and starts smashing it in until it stops.)
(They both stare at each other)
Admin
Admin
Save for one small problem - those companies that are not the "good guy, focused on what is good for the employees and themselves" types. These are the "users" that hire skilled talent, push them to their limit and smile happily when they depart in disgust. The hallmarks are poor pay, extreme lack of management within the team as well as without, no documentation in the code, poorly written code, tolerance of truly obnoxious personnel (One company comes to mind where the "top individual" is a lousy coder, has no respect for himself or his coworkers (his cube actually stinks from the trash) and is kept on mainly because he has been there the longest and has cowed his manager into believing that the company will collapse without him. I have to give credit to the manager however, he promised a great deal and I was inexperienced enough with lousy bosses that when the offer letter that spelled out all those promises didn't come, I just blew it off as a "too much going on right now" incident and went to work there anyway. BAD IDEA! The company delivered on none of the promises and I left as soon as I was able to garner other, suitable employment. The upshot of all this is that the proposed system is fine so long as everyone plays by the rules and doesn't LIE to its employees!
Admin
Cravath and similar systems are intended as filters. The design goal is to weed out people who are not suited to the type of work by imposing a set of rules that most benefit the types of people who are most suited to the work environment. Those systems are specifically adapted to competitive steady-state jobs... in other words, industries that keep doing the same thing over and over again (like lawyering... there is no real difference between a lawyer 100 years ago and a lawer today) in competition with very similar people (there are always lawyers). They are not adapted to developing industries where there are new challenges every year. They are not adapted to attrition industries (entertainment, wartime soldiers, etc) where external factors or natural ability will cause a constant loss of tallent.
To take it a step further, Cravath and similar most benefit employers with workers whose goals and methods are innately (by the nature of the work) aligned with the employer. Where the employee is a microcosm of the employer. A lawyer does the same work as a law firm... the law firm just does more. In other words a situation where self-interest and corporate interest are, by the nature of the work, parallel. Look at a salesperson. Their personal goals (make money by selling) and work goals (make money by selling) are parallel. Consider a lawyer.... their personal goals (make money, gain respect and influence, by winning) are convergent with their employer's. The individual worker's goals are just a smaller version of the employer's goals.
Are those conditions true in IT? Is IT steady-state? Do the goals of IT workers and IT employers naturally converge?
No and NO.
The IT industry is constantly evolving. Skills I learned 15 years ago are, for the most part, laughably obsolete today. That's true for a lot of engineering... the joke about the teacher saying, "I don't change the test because every year the answers are different," really holds true. While it is possible to attach yourself to some technology and ride it for a while, eventually it will go away and there is never a guarantee you'll be able to ride it to retirement or even to the end of a normal car loan. This isn't even like doctoring where an old doctor may not be up on the latest treatments but can still do some good... an old IT person used to dealing with delay line memories and so on simply cannot get a job without retraining... it's like being a doctor in a world where humans can fundementally change how they work from year to year. Not steady state.
Workers in the IT field rarely have a true interest alignment with their employers. This isn't bad... it's just the reality of IT. IT departments exist to serve the needs of others. The IT department is always and only there to fulfil the business needs of the larger entitity (or customer) and success for the larger entity/customer is often bad for the worker. The trivial example is that a truly successful IT roll-out reduces the employer's need for IT workers... so IT workers who do a really good job are courting unemployment an reduced income. The larger example is that many IT workers get into IT for personal reasons... they want to play with technology, they enjoy writing code, and so on. A worker who enjoys writing code will tend to encourage code-based solutions even when the company is best served by some other approach. A worker who enjoys managing big iron will encourage the company to buy enterprisey hardware even when the employer doesn't need the extra overhead. These conflicts of interest are innate and you really don't want to eliminate them... often the best coders are the guys who love to code, the best sysadmins are the guys who love to tinker with big computers, and so on... but they affect the viability of an "up or out" model.
We've all seen it... the guys who spec technologies based on how they'll look on their resumes, the guys who spec hardware based on the fact that it gives them jollies to be in command of such a huge machine... the guys who write convoluted and buggy code because they think it will give them job security... what drives them to do those things? The FACT that their interests are divergent from their employers. Personal ambition and corporate goals don't align... but the results, when everything works, can be spectacular. The guy who really loves to design a good UI can single-handedly push a company foreward, the guy who wants big iron can save the day when an unexpected load comes up. Can doesn't mean will though... and on average what you have in inefficiency.
Can the goals align? Yes. Some IT workers do understand and gain satisfaction from furthering the business needs of their employers. However, those employees are often the ones that propose more modest solutions. They use the tried and true methods, the modest hardware, the sensible technologies... and at the end of the day they have a string of unexceptional successes on their resume.
A Cravath type system is most likely to push out the "mediocre" people who deliver acceptable but non-flashy (non-enterprisey) solutions and elevate the people who build flashy high-risk solutions that aren't in the best interests of the company as a whole. That doesn't seem like such a good long term plan to me.
I understand the desire to solve some of the real problems that have developed with the IT workforce... but this solution isn't really going to cut it. Why don't we just use some common sense and fire the people who are leaching, encourage the people who are helping, and accept that not everyone has the same goals or mindset? It is less radical but it might just work.
Admin
Awesome article. This explains an awful lot :)
Admin
Great article!
Admin
I recently(within the last 8 months) took a job at "a large security contractor" as a rock watcher. Within two months my bosses approached me to help with a transition as the lead web developer was leaving the company. I was then promoted to the tech/communications side of the business and now maintain several code bases and have a better salary.
All of this wouldn't have been possible if the company I work for hadn't had the Up or Out mentality and took the time to document even 'non-relevant' skills to the original job I was hired for. I think each job is subjective but most larger jobs are advantaged by using some version of this system at least with many of us Younger workers
Admin
Admin
It's been estimated that "generalists" lose about 20% of their relative worth every year, if they aren't recieving any training or supplemental education. For "specialists" the value can be up to 40%.
The point is, once you get past your apex, you will slowly start to approach the convergence point, where your value is no longer based on your individual skills, but on your knowledge of existing systems.
It's true that updating your skillset with new training, once you are already settled in, can slow the decline past the apex point, but in reality, you are still approaching the point of convergence.
As some have mentioned, you don't necessarily have to change which company you work for, as long as you change which project/team/division you are in. This is the reason Google is so good at retaining their employees.
If you are arguing that stability is more important to you than professional development, then chances are you are in the lower curve already. Another thing worth noting is that "up" doesn't have to mean higher in the management hierarchy, it could also mean more challenging/demanding tasks.
Admin
Just because someone comes in and learns something and then moves on doesn't mean they have no commitment. You can still learn and not produce crap; it just takes you longer. And that time is usually done at nights and on weekends.
Since you sound so arrogant and condescending to those who change jobs often, I'll throw it back at you: the non-ADHD types are just slow learners who can't pick things up quick enough...that's why you stay there for years. And you're also control freaks who have to hoard your knowledge to feel good about yourselves.
Admin
Hmmmm.
So. The best way to run an IT department is to hire recent college graduates, work'em hard and be really jolly when they leave?
Isn't that Microsoft? Isn't that how we ended up with Vista?
Admin
I could not disagree more. Self actuation? BRAHAHAH!!! How about paycheck actuation. Bring back Mandatory Fun Day!
Admin
Agreed. But hey - the derivative in the beginning looks high enough, doesn't it?
Admin
Stability is an awfully broad term. As you alluded to, professional development doesn't necessarily mean moving from company to company (see: Google) but stability also doesn't necessarily mean that you have no professional development.
Sitting in one job and hoarding knowledge is the kind of stability that stunts development.
Admin
Alex, is this your way of saying you're getting tired of maintaining this site?
Admin
What are you talking about? It's concave down throughout the entire function, so it's clearly never growing exponentially. Something like "ax - bx^2" fits just fine left or right of the apex. The constants would differ, so it does seem to be two different functions, but I see no reason to believe the left is exponential or the right is logarithmic.
Admin
Actually, in many industries the final step is for the experienced staff to spin-off their own businesses (often on good terms with their old company) becoming the next generation of senior partners at the top of a little money-making engine.
Admin
Admin
That's something I always felt and now I see that it's something that happens with everyone, not just me.
That was a good reading.
Admin
This article is the biggest load of nonsense I've ever seen posted here. Thanks for the laugh; keep up the good work.
Admin
I think Asiago Chow (above) has a good point, though again it's painted in broad strokes. I'd counter it's possible to have well-aligned values at the same time as the drive to be innovative.
Re the value curve, should that really apply when we're talking IT? The text describes value as a combination of learning the company, and bringing external ideas (implied as a fixed quantity learned from previous employers). With just a little reading and training, and a rapidly evolving field of expertise, we of all people should be able to step up the value every few years. Company size likely is an issue, re-inforced by the comment on the US Air Force, but Alex still described it as the length of the curve rather than shape.
I'm in my 12th year at an manufacturing company with agriculturally seasonal business and ~120 permanent staff. In that time, our management has flattened somewhat, a few departments were spun off and outsourced (to themselves) including all of IT apart from myself; leaving me answering to CEO. Some of the outsourced work has been brought back in, including half of IT. I still answer to CEO but could easily be under the current IT mgr. Doesn't matter. I'm still in the same role as when I started; but have earned more trust from management over the years. I'm still adding value to the company, innovating, involving newer technologies to improve overall efficiency and flexibility in a changing market. I guess if my employer was in a more stagnant market I wouldn't have the same opportunities, and would have moved on, but how many markets really are that stagnant? How often is it the company directors choosing whether to evolve or just sit still and hope for the best? Last year we started using web services to integrate on-site and central systems. Now I'm rapidly learning about RFID. Every few years we've had a significant change in WAN technologies, as telcos deliver new services and speeds and as our requirements grow. (We're not city-based, so have only recently got above 64kbps at most locations). My knowledge of the company is still increasing, as is my technical experience, and I see plenty of scope to continue.
Regarding documentation, I've been through that one on both sides. Some years ago the IT manager got on my case to "start documenting some of that immense knowledge" (he was also an HR type so knew how language can be used positively, though he did mention the proverbial bus). Thing is, mostly it was general technical training plus familiarity with the environment. It seemed I was being asked to write a textbook on TCP/IP, SQL, and a few off-the-shelf products, in addition to more relevant site notes, internal standards etc. Documentation in our department has improved quite usefully. It did, however, take a while to make the point that documentation!=understanding, and there are some jobs that just cannot be done by monkeys with documents. I haven't been hit by a bus yet, nor left. Our turnover of juniors seems to have vanished too.
Company-wide, we have lost a lot of people with corporate knowledge through regular turnover. The productivity loss depends on how many longer-standing staff remain, and which specific people they are, so the indirect cost of turnover can't be a fixed figure.
I agree that turnover should be managed in the knowledge it will continue to happen, but that doesn't mean every position is compulsorily short-term, nor should IT staff be bound to the "value curve" presented.
Admin
This is why I love Microsoft. Every two years you can "quit" and change to any other team in the company (there's a LOT to choose from), while maintaining the seniority you have.
Admin
The "beachheads of bad code" statement is the best line I've read in a LONG time. It just brightened my day that little extra that I need to be happy :)
Admin
Then consider yourself lucky. In a long-ago job, the "Director of IT" required us to document every maintenence task in mind-numbingly concise detail. We're talking "cookbooking" how to do everything.
The reason why this idiot needed the level of detail was because his actual knowledge level was nil. He could only do things by rote, so he needed scripts in order to get anything done when one of the skilled people (i.e., everyone else) was not available. Yes, you're right: the only reason he got the position was by virtue of being related to the president of the company.
The rest of us eventually revolted against his idiotic requirements. My breaking point came when he told me to cookbook how to check out a prior release, build and deploy it. I provided a document that had every other branch as "contact the developer."
Compile the program: type the word make and press the enter key.
If you see any output that starts with WARNING: or ERROR:, Contact the developer. --- STOP ---
(etc)
The server guy's came when he was asked to cookbook how to solve MX record (mail) issues with the company's ISP.
Eventually all the skilled IT workers (i.e., everyone else) left, and the company outsourced all their development and server management, paying easily 5x the cost of staff as a result.
Admin
Actually, I took that statement to mean, "This company and its management and policies are such utter crap, you'll be scrambling for the exit within a year."
Admin
And you want to label this guy a super high skilled developer. Not because he develops quality programs but because he is able to convince a competitor to pay him more and grease the way for him to bolt from them next year.
Admin
While it is a good thing to say "Document the procedure so the next guy can do it", the actual thing you should do is to document the procedure (program, etc...) so that YOU understand it. In my work, I have found that if I'm away from code for about 6 months, it starts looking funny. Those comments I wrote a while ago that explain the (then current) thought process were the only way I could continue. Now I make it a habit to "document for self" as if I can write the information on how to do it given my own skill level, than I consider it a success. If others aren't up to my level, then they need to be infused with the "base knowledge". I can't provide that!
Admin
Someone doesn't remember their calculus. That's definitely not an exponential curve. If anything, the red one is logistic.
Admin
QFT.
In addition, I find the whole premise of "Why the skilled quit first" is flawed. Bruce is full of crap. He doesn't take into account many of the other psychological factors that drive a person.
The unskilled often don't know they are unskilled. They muddle through the day and think they are good. Some will loudly proclaim so.
It's more about self-confidence and how you sell yourself, not skill. How often on this very site do we here about utter morons who managed to pass the interview? Yet, the poor guy with Asperger's could be turned down because he's 'odd' - even though his skills may be better.
So, just whacking it down to 'skilled people leave, unskilled stay' is plain wrong.
Admin
Amen! And I'd like to add that this whole "Up or Out" bullshit is not more than "Hire & Fire" with some pretty lipstick smeared on.
"Value Apex", my ass! Must be from the same book where terms like "Human Capital" are coined, right?
This article proves yet again that there's indeed a whole industry dedicated solely to researching how the last bit of "performance" (read: lifeblood) can be squeezed out of a worker in the shortest time possible.
What annoys me most is the premise of these suggestions and so-called "best practices". They have long given up even trying to pretend an intention of forming a longterm relationship with you or god forbid offering a fair reward.
So, you have a "Dead Sea" Problem? Two words: Revenue Share.
I happen to be one of these high profile workers and am in the process of quitting my job for precisely this reason: You want me to spend 60hrs a week building and maintaining "your" product? That's cool, then give me n% (in relation to my contribution) just like the "boss" gets and don't try to fuck me over with bullshit like "Agile" or "Up or Out" philosophies.
Good people get stuff done. Better yet, good people naturally find the process that helps them to get stuff done. They don't need to read books about processes that were only written so that the consultant breed has something to talk about.
Hire top notch and you'll be google. Hire bottom barrel (because "how hard can it be") and you get what you deserve.
Fortunately no artificial process will change this fact of life. Unfortunately the "process book-writers" will never die out either so we'll keep reading about the latest new "optimization in leveraging your human capital" every year...
Admin
The thing about the problem of the dross staying in while the skilled move on, is that most companies are prefiltering out the good developers with bad job ads, which have basic elemental mistakes. If they fixed those, you'd see a higher intake of good people, and there's your key factor in having more skill at the top - because the more good people feeding in, the higher the quality of those who remain, even if you change nothing else.
Admin
I left a 80K job for exactly the reasons you describe; I hoarded my knowledge of the company and am now making 150K, doing the same thing except as a consultant. Your analysis sounds moral and sweet but, bottom line, make yourself irreplaceable and then quit. You will be happy you did.
Admin
Personally, I prefer "I need you to document this in the way that you wish it was documented before you started"
I have both started and finished but one project in my current job. Every component built with the idea that it will probably be replaced with a better one at a later point, or expanded, without breaking the rest of it [much].
Other projects I've worked on were started before my time and will probably never be 'complete'. Yet I find in these ones haphazard spaghetti code, hacks, patches, and general bad stuff. I spend more time cleaning up and rewriting than actually building. Who the heck puts a try/catch around Application.Run()?? And what little documentation there is, has either expired or is relevant to the function three declarations down because some auto-generated code cut in and no-one cared to move it back. I found a labour-saving function that would have saved on hundreds of lines of code had it been used wherever it was needed rather than once. Yes, just once. Where was the documentation that said that function existed?
Case in point, when I write documentation, I write it as I wish it had been written before I started working on it. That way the next guy doesn't have to say "where the hell did this come from? I could've used that". [/rant]
Admin
well this seems to be true in every industry not just programmers. most people if they do make and save up enough money go out then start fun business's or do what they want to do in life. my personal goal is to open a tanning salon but that just me (and im sure 1000's of other programmers). take the Norton Antivirus guy...he sold his business and started a art collecting/selling business. a friend of mine made millions when his startup sold and now makes documentaries. programming for must of us is a ways to a means and surely is not our life.
Admin
An exponential doesn't have an apex, this function looks more like t*exp(-t)... but that's really pessimistic, as it tends towards 0 as t -> infinity!
Admin
What you are describing is the Peter Principle - The tendency to promote people beyond or outside of their skill set. This happens in education too: when a good teacher is recognized, they tend to be promoted into management. But a good teacher is not always a good manager, and they probably would prefer to be a teacher. So they quit and find a job where they can do what they like to do - teach.
Alex is pointing out that a good technician will, after a few years, get bored of the same old thing, and will probably quit. Promoting him to a management position will only guarantee that he will quit sooner: he wants to code, damnit! So, we have to see how to use this inevitable turnover to our advantage. Tricky, but doable.