makingitclear.com
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 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.
What have your roles been? In engineering and the sciences, quiet competance is indeed (mostly) the norm. We're not talking about that.
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.
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.
* 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."
http://www.amazon.com/Three-Signs-Miserable-Job-Employees/dp...
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.
Again, all people are different when it comes to how they maintain balance or not maintain balance, for the good.
I would call it, "Looking out for #1."
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.
Feature: My software uses closures. (Who cares?)
Benefit: My software will save you tons of money. (Bullshit, show me how.)
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, 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.
...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.