

15 Career Mistakes - avner
http://www.makingitclear.com/newsletters/newsletter62.html#article
"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."
======
tptacek
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.

~~~
bobochan
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.

~~~
tptacek
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.

~~~
bobochan
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.

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

~~~
BrandonM
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
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).

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

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

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

~~~
BrandonM
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
_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
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.

~~~
Goladus
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.

