6 ms·

15 Career Mistakes

59 points by avner 18y ago

"I’ve made a lot of these career mistakes myself, and it’s hard for me to admit my failures. But in the interest of helping others avoid some of the mistakes I’ve made, I’ve decided to go ahead and create a list of the major career mistakes that I’ve made or that I’ve seen other people in IT make."

Goladus 18y ago
#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.
- tptacek 18y ago
  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.
  - Goladus 18y ago
    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.)
    - wensing 18y ago
      In "The Art of Project Management" (http://books.google.com/books?id=q1dJZv4Ycr8C&dq=the+art+of+project+managemente&pg=PP1&ots=_KlIPLlTqm&sig=b487NMWqqBfeCq_4-DWTROkJQrY&hl=en&sa=X&oi=book_result&resnum=1&ct=result 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.
- BrandonM 18y ago
  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.
  - Goladus 18y ago
    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.
    - BrandonM 18y ago
      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.
wallflower 18y ago
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." http://www.amazon.com/Three-Signs-Miserable-Job-Employees/dp/0787995312 http://www.amazon.com/Three-Signs-Miserable-Job-Employees/dp...
- BrandonM 18y ago
  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.
  - wallflower 18y ago
    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).
- Xichekolas 18y ago
  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.
jobeirne 18y ago
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.
- avner 18y ago
  I think what he is trying to inference is that one must not sacrifice his sanity, family and friends at the expense of his work. Again, all people are different when it comes to how they maintain balance or not maintain balance, for the good.
tptacek 18y ago
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.
- run4yourlives 18y ago
  Your last paragraph is priceless advice. In fact, I'd recommend to anyone that they present new ideas or innovation in this manner.
- bobochan 18y ago
  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.
edw519 18y ago
Nice list. Except that I think he missed one. 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.

15 Career Mistakes

59 points by avner 18y ago

Goladus 18y ago

#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.

tptacek 18y ago
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.
- Goladus 18y ago
  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.)
  - wensing 18y ago
    In "The Art of Project Management" (http://books.google.com/books?id=q1dJZv4Ycr8C&dq=the+art+of+project+managemente&pg=PP1&ots=_KlIPLlTqm&sig=b487NMWqqBfeCq_4-DWTROkJQrY&hl=en&sa=X&oi=book_result&resnum=1&ct=result 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.
BrandonM 18y ago
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.
- Goladus 18y ago
  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.
  - BrandonM 18y ago
    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.

wallflower 18y ago

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." http://www.amazon.com/Three-Signs-Miserable-Job-Employees/dp/0787995312 http://www.amazon.com/Three-Signs-Miserable-Job-Employees/dp...

BrandonM 18y ago
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.
- wallflower 18y ago
  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).
Xichekolas 18y ago
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.

jobeirne 18y ago

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.

avner 18y ago
I think what he is trying to inference is that one must not sacrifice his sanity, family and friends at the expense of his work. Again, all people are different when it comes to how they maintain balance or not maintain balance, for the good.

tptacek 18y ago

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.

run4yourlives 18y ago
Your last paragraph is priceless advice. In fact, I'd recommend to anyone that they present new ideas or innovation in this manner.
bobochan 18y ago
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.

edw519 18y ago

Nice list. Except that I think he missed one. 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.