A while ago I wrote this post about the elusive hunt for “rockstars”
In it I had this table which showed things from the employers perspective:
Good at doing Bad at doing Like to do “Rockstar” Sweet spot
“future rockstars”Hate to do Short-timer Stay away
The same table from the employee’s/job-seekers perspective looks like this:
| Good at doing | Bad at doing | |
|---|---|---|
| Love to do | Rut | Growing |
| Hate to do | Pain | Suicidal |
My general rule of thumb is that every job should be ideally 50% in the “Bad at doing/Love” region. The only thing the other regions are good for is getting you that opportunity to do stuff in the
“Bad at doing/Love” region.
Now what goes in each region?
- Put all tasks or descriptions that are as fundamental as possible.
- Ideally, are not job- or position- specific.
For example, your chart may look like this:
| Good at doing | Bad at doing | |
|---|---|---|
| Love to do |
|
|
| Hate to do |
|
|
Tailor your resume so that it gets you that learning opportunity that minimizes “Detail-orientated tasks” and leverages your ability with “Repetitive tasks” and “Communicating with people outside company” to get that opportunity to “Lead a team of 3 people”.
Obviously a quick post like this cannot be a detailed career guide, but I have found this quick-and-dirty matrix a good interview tool to help filter out jobs that are not a good match for me.
Notes:
- this chart does not apply to self-delusional people who are “bad at doing” but think they are “good at doing” the task.
- it is easy to be harsh on yourself so have some perspective about how bad you really are at something.
- Ask others to add to the regions
Love to do and good at doing:
— Effectively apply my expertise to solve technical problems, e.g. creating back-ends for RIA.
— Make an OO decomposition for the problem domain.
— Produce a readable, self-explanatory, well-structured code.
Love to do and bad at doing:
— Non typical software and architectures like CQRS, nosql.
Hate to do and good at doing:
— Explain to pseudo-technically-experienced customers what is technical debt and why it should be minimized.
— Hear about business-value as of some features. Software quality and security is also a business value as for me.
Hate to do and bad at doing:
— accompany software projects that are slowly approaching chaos by continuously fixing bugs without a chance to add more order (refactoring, rewriting, redesign).