I love this article. I've wanted to write something like it ever since I held my first "business" role, as a product manager moving from a lead dev role.
I cannot possibly stress enough #11 on this list --- "blow your own horn". Software development is more meritocratic than almost anything else you can do in technology. Devs track each other by commits and by improvements to codebases. Some devs are loud, but even when they are, their seniority and expertise usually manifests itself in strong opinions, not outright bragging.
The business world does not operate this way. If you assume that people will notice and appreciate your accomplishments, you will get your lunch eaten. Worse still, if you call the classic geek play of being loud and authoritative as a way of expressing your accomplishments, without being explicit about why you're qualified to do that, you will alienate and offend people.
Here's a freebie from my list:
Don't write long email messages. Don't ever write documents in the form of email messages. Businesspeople use email differently than you do. They've never been on mailing lists. They never read Usenet. If you have something to say that needs to be remembered, put it in a Word document, "brand" the document ("The $XXX Plan"), and send that instead. A bunch of times, I wrote marketing copy or feature/function definitions in 4 page email messages and discovered weeks later that nobody had ever paid attention to them.
I respectfully disagree, at least in part. Despite the overwhelming number of things that I have read to the contrary I have never worked anywhere where my accomplishments were overlooked. Honestly, in many situations I've found that merely being competent has lead to being rewarded as excellent.
I find turning things around and sharing the credit inevitably leads to more allies and a bigger pool of credit going around. If someone thanks me for something that worked out then I almost invariably thank them for supporting the project, being clear and flexible and understanding the times when things did not always look so rosey. Be public in praising people that make it easier for you to do the good work that you want to do and you will be rewarded exponentially when the chips are down.
My goal is to be completely anonymous because I find it almost impossible to get any coding done when I'm the goto guy with people needing my attention all day long. Quiet reliability and competence trump grandstanding over the long haul every time.
I'm not advocating grandstanding or hogging credit for things, but "quiet reliability and competence" empirically do not trump grandstanding in the business world. See: every issue of the Wall Street Journal from today back through 1882.
What have your roles been? In engineering and the sciences, quiet competance is indeed (mostly) the norm. We're not talking about that.
I have been all over the map (literally), but most of my work has been in finance. I agree that your sentiment is the prevailing wisdom, I just have never found it to be particularly true. It is perhaps counter intuitive but in my experience showing gratitude and humility has lead to an extremely happy existence and a constant stream of bonus money and tickets to the company's suite at Fenway.
>My goal is to be completely anonymous because I find it almost impossible to get any coding done when I'm the goto guy with people needing my attention all day long.
I think you're missing the point here. Assuming you want to get promoted to something beyond coder, you'll need to be something more than a coder. Assuming you are perfectly happy doing what you are already doing, there's no real reason to be worried about advancing your career at all.
Many of the organizations that I have worked for have management and technical tracks that lead up the presidency. Organizations with a lot of money on the line are more than happy to provide advancing career paths to people that keep things working. I'm absolutely estatic doing what I am doing, thank you, but I never object to another superlative being added to my job title or another increase in my income.
Somewhat related to your last paragraph, I recently saw (on a mailing list) a diagram touting the increased productivity of using a wiki as a knowledge-base rather than informal emails with documents attached, and the way it had the workflow diagrammed, the entire productivity increase was due to not having to open Word attachments.
And? Of course Word attachments suck. Pick your battle: do you want to convert your company from Office to wikis, or do you want to influence and complete the pricing model for your product?
Caution: while you will almost certainly succeed at the latter, your odds on convincing businesspeople to stop using Office, or to respect Wiki pages (which I tried) or email messages are not good.
Wiki's work for techy people. Most CEO's and other management types don't even know what a wiki is, let alone use them for anything meaningful.
Besides, you can read a word report on the plane, or over dinner, or while waiting for your next meeting. This is upper management's environment. Cater to that.
15 is too much. I think "The Three Signs of a Miserable Job" are easier to remember. One of my mentors recommended this book to me recently. I've observed precursors of these from time to time personally. Beware. Remember conscious incompetence.
* Anonymity - "the feeling that employees get when they realize that their manager has little interest in them a human being and that they know little about their lives, their aspirations and their interests."
* Irrelevance - "which takes root when employees cannot see how their job makes a difference in the lives of others. Every employee needs to know that the work they do impacts someone’s life--a customer, a co-worker, even a supervisor--in one way or another."
* Immeasurement - "the inability of employees to assess for themselves their contribution or success. Employees who have no means of measuring how well they are doing on a given day or in a given week, must rely on the subjective opinions of others, usually their managers’, to gauge their progress or contribution."
Wow, those three things described my first job out of college perfectly.
It got really bad when I did nothing but surf the net for six months and no one noticed. That is when I knew it was time to change. My work wasn't being measured, I had no contact with my end user, and my boss didn't talk to me for weeks at a time.
But that's not exactly what this article is about. It's not about whether or not you've chosen the right career; it's about mistakes in general. Particularly, I got a lot from mistake 3: the advice to sell benefits, not features, is very good.
Hmm. You are right. Maybe my unconscious is trying to tell me something if I picked up two out of the list of 15 relating to career-limiting habits (#8 Forgetting who you work for; #11 Not blowing your own horn). But the economy is poor now (#12).
You can do everything on his list perfectly and then, when review time comes around, you'll get the standard 4% because "that's the corporate limit right now". To which I would respond, "Then it sounds like you'll have to promote me in order to pay me what I require without violating any corporate mandates."
The same thing applies to customers. If a customer says, "$10,000 is too much; I'll pay $8000," I'll say, "Fine. Which 20% of the project shall we eliminate." I never compromise quality and I never compromise my rates.
Don't ever bluff. Save that for the poker table. But always always remember:
No one will ever look out for you as well as you can for yourself.
Violate this rule and you might as well just bend over.
Follow it and save yourself a lot of stress, money, and reputation.
I've a problem with #14 - Making your career your life. Some of the most successful, radiant people are so because of their devotion to what they do professionally, i.e. because it's their life.
#3 is bad advice. It's a good observation, but really you should try to identify your audience and be prepared to go in either direction. Some people will be turned off immediately if you presume to know how something will benefit them.
If you don't know how the product will benefit the user, then what is the point of the product to begin with?
For me, if I'm writing a program for myself, it's to solve a particular problem. If I think others might find it useful, I would mention what problem it solved for me.
If the program has a particularly clever (efficient) algorithm, that would not be part of the sales pitch. Instead, I would note the effects of that algorithm, not the algorithm itself. It's the difference between, "This music player efficiently handles large music collections", and, "Only 10 songs are kept in memory at once, and indexing is done so that searches over the entire collection can be performed in constant time." The former tells the user all that is needed, while the latter is simply confusing and/or meaningless for a non-tech person.
This is what I think #3 meant, and I thought it was great advice.
If you don't know how the product will benefit the user, then what is the point of the product to begin with?
If you don't know how the product will benefit the user, it means either the product is worthless and you shouldn't be selling it, or it means that you don't know everything the product could be used for.
It's the difference between, "This music player efficiently handles large music collections", and, "Only 10 songs are kept in memory at once, and indexing is done so that searches over the entire collection can be performed in constant time."
My point is you need to identify your audience and know which to use. Even for your seemingly obvious example, it's possible there might be a user that actually does care about only 10 songs being in memory at once (and the impact that would cause to his particular needs), and may be suspicious if you try to say "oh yeah it efficiently handles large music collections."
The result is that sometimes people have evolved bullshit detectors and when you try to sell things in terms that aren't precise enough they may assume you are a waste of time.
You make some good points, but I think they are a good argument for having a "technical description" (or something like that) page for those who might be interested. I still think that the description everyone sees should focus on the benefits to the user, because that's what the average user cares about.
...or it means that you don't know everything the product could be used for.
Even for such an open-ended product, I would still say, "We developed this to solve X, but it offers other possibilities as well (link to feedback from users who have found other uses). Thanks to its extensibility, new functionality is being added all the time (link to top plugins)."
All I'm really saying is that I agree with the author that it's worthwhile to re-frame the product description in terms that will immediately tell the average user that your product is worth their time or money.
I confess I summed up my reaction a bit bluntly. Really the issue is that it's not a black and white thing. The article makes it seem like "oh yeah I should focus on benefits" when reality is a lot more complicated.
Selling features instead of benefits is one of the all-time classic marketing mistakes. He didn't just make that up. If you don't know how to describe the benefit of a feature in a way that is convincing to a technical audience, you either don't understand the feature well enough, or you shouldn't have the feature.
Which is the classic mistake, "Selling features instead of benefits" or "Selling features when you should be selling benefits?" Honestly, trying to sum it up with only the two words "feature" and "benefit" is an enormous mistake as well.
Feature: My software uses closures. (Who cares?)
Benefit: My software will save you tons of money. (Bullshit, show me how.)
In "The Art of Project Management" (http://books.google.com/books?id=q1dJZv4Ycr8C&dq=the+art...), Scott Berkun insists that a good PM write feature statements as they directly face the customer. "My software will save you tons of money" is a fine benefit statement, but the feature statement shouldn't be "My software uses closures" but rather "The order entry system will consist of a single screen." Perhaps this is because of some technical feat that only you can appreciate, but the feature statement wouldn't ever mention closures.
I cannot possibly stress enough #11 on this list --- "blow your own horn". Software development is more meritocratic than almost anything else you can do in technology. Devs track each other by commits and by improvements to codebases. Some devs are loud, but even when they are, their seniority and expertise usually manifests itself in strong opinions, not outright bragging.
The business world does not operate this way. If you assume that people will notice and appreciate your accomplishments, you will get your lunch eaten. Worse still, if you call the classic geek play of being loud and authoritative as a way of expressing your accomplishments, without being explicit about why you're qualified to do that, you will alienate and offend people.
Here's a freebie from my list:
Don't write long email messages. Don't ever write documents in the form of email messages. Businesspeople use email differently than you do. They've never been on mailing lists. They never read Usenet. If you have something to say that needs to be remembered, put it in a Word document, "brand" the document ("The $XXX Plan"), and send that instead. A bunch of times, I wrote marketing copy or feature/function definitions in 4 page email messages and discovered weeks later that nobody had ever paid attention to them.