There's a formula you can follow to achieve this. Select an area that is difficult, annoying, or otherwise undesirable to most of your peers. Dig in deeply to this area, and get to where you are an expert. Everyone else will run from those issues and you can step up with confidence. Management will notice this.
I had a coworker like that. He cultivated the reputation of being the go-to guy. He could confidently provide answers immediately. The problem was that his answers were nearly always wrong, to one degree or another. However, there were enough technical layers that his failures could be fudged and nobody on the 'outside' would notice. Said technical layers prevented anyone else on the team from intervening in time for the correct answer to be relevant. This was the same guy who was always busy at work, generally fixing bugs introduced by his code changes, or manually performing tasks that he couldn't be bothered to automate.
Within a few weeks of me leaving for a mail merge call and returning successful and unscathed after 30 minutes, word got around that I was the "go-to guy" for envelope printing and mail merges. All the tickets for this started to come to me.
Ah, so become the go-to guy by never documenting your findings and sharing them.
I think this is actually good (bad) advice: keep your value close to your chest. This, of course, runs contrary to software engineering principles (as well as my own), but I believe you can document and refactor your way out of a job, just as you can fail your way into raises and promotion.
By the way, I don't recommend the above at a 'true' startup, where technical output can and will be noticed. However, once you're at the oh-so-common 'startup' that's been around for the better part of a decade, it's game-on.
Those are some interesting observations. I've observed that the "go-to guy" can backfire as well. People have used it to their advantage, but others have been stuck doing the difficult, annoying, or otherwise undesirable things and not promoted because they are seen as someone who's willing to shovel the manure.
Being willing to stand up and take on jobs is important, but one really does need to communicate with management to move up at BigCo, which is what the article seems to be directed toward.
A fair point. I don't recall how much if any I documented what I learned at that time. This was when I was still an undergraduate. We didn't have a wiki or any great documentation sharing system. I probably sent a mail to our mailing list and anyone who wasn't subscribed at that time never got it. These days I spend oodles of time writing documentation for my peers.
To be clear, my point wasn't "develop some specialized knowledge and then hide it", it was just "develop some specialized knowledeg". And yes, sharing it with your peers is a good choice, but if they were scared of the issue to begin with, they may not all be very receptive to learning about it.
Comments
On becoming a go-to guy:
There's a formula you can follow to achieve this. Select an area that is difficult, annoying, or otherwise undesirable to most of your peers. Dig in deeply to this area, and get to where you are an expert. Everyone else will run from those issues and you can step up with confidence. Management will notice this.
I had a coworker like that. He cultivated the reputation of being the go-to guy. He could confidently provide answers immediately. The problem was that his answers were nearly always wrong, to one degree or another. However, there were enough technical layers that his failures could be fudged and nobody on the 'outside' would notice. Said technical layers prevented anyone else on the team from intervening in time for the correct answer to be relevant. This was the same guy who was always busy at work, generally fixing bugs introduced by his code changes, or manually performing tasks that he couldn't be bothered to automate.
Within a few weeks of me leaving for a mail merge call and returning successful and unscathed after 30 minutes, word got around that I was the "go-to guy" for envelope printing and mail merges. All the tickets for this started to come to me.
Ah, so become the go-to guy by never documenting your findings and sharing them.
I think this is actually good (bad) advice: keep your value close to your chest. This, of course, runs contrary to software engineering principles (as well as my own), but I believe you can document and refactor your way out of a job, just as you can fail your way into raises and promotion.
By the way, I don't recommend the above at a 'true' startup, where technical output can and will be noticed. However, once you're at the oh-so-common 'startup' that's been around for the better part of a decade, it's game-on.
Those are some interesting observations. I've observed that the "go-to guy" can backfire as well. People have used it to their advantage, but others have been stuck doing the difficult, annoying, or otherwise undesirable things and not promoted because they are seen as someone who's willing to shovel the manure.
Being willing to stand up and take on jobs is important, but one really does need to communicate with management to move up at BigCo, which is what the article seems to be directed toward.
A fair point. I don't recall how much if any I documented what I learned at that time. This was when I was still an undergraduate. We didn't have a wiki or any great documentation sharing system. I probably sent a mail to our mailing list and anyone who wasn't subscribed at that time never got it. These days I spend oodles of time writing documentation for my peers.
To be clear, my point wasn't "develop some specialized knowledge and then hide it", it was just "develop some specialized knowledeg". And yes, sharing it with your peers is a good choice, but if they were scared of the issue to begin with, they may not all be very receptive to learning about it.