# A skill scale for developers

- Link: https://www.andreidraganescu.info/2014/06/26/a-skill-scale-for-developers/
- Published: 2014-06-26T08:43:23+03:00
- Author: Andrei Draganescu

#### An unruly take on the notion of performance

![](https://draganescu.files.wordpress.com/2014/06/98168-1uf7igyvitdrztarqbeqpig.
png)

In building this scale of skill, the units I am considering are as follows:

 * **Amount of effort** — the quantity of individual time (based on a pondering 
   coefficient) that the person is spending on the test task.
 * **Outcome** — how much procentually did the person accomplish from the assignment.
 * **Cadence** — how often are the best effort over outcome results seen in time.
 * **Environment** —what is the amount of stress that the person needs to handle
   aside from solving or completing a task.
 * **Time** — each task is part of some set and each set has some deadline, a slot
   of time, which is more or less the time required to work on the set because of
   external factors. can the person fit in the slot?
 * **Social** — this tests team engagement levels and is related on how much there
   is a need for the team to support the individual, and how much does the individual
   support the team.

Here is the definition of the standard ideal* types:

*ideal is like … unicorns, reality is like, you know, … a horse.

---

**MasterThe least amount of effort with the maximum of outcome, on a regular basis,
under stressful conditions, with results visible none later than the deadline.

**Rockstar**
The ideal outcome with solely individual effort, on a regular basis,
in extreme urgency conditions, with results spot on the deadline.

**Expert**
The maximum of outcome, within the initially planned effort, on a regular
basis, under normal conditions, with most results meeting the deadline.

**Proficient**
The best outcome, with hard to plan in time variable effort and above
average success rates, meeting deadlines.

**Senior**
The expected results, correlated with team efforts, which often fails
under strong pressure, missing deadlines.

**Mid level**
Work done with results, depending on the sustained team efforts to
be on deadline, often missing them and with fault diluted in the organigram above
and below.

**Junior**
Long waiting for some expected results, based on individual effort and
usually uncorrelated with any deadline planned.

---

And here is some ideas on how to implement the above levels in working day to day
projects

**Axioms**

 * You can’t make a team with a master and a rockstar at the enterprise level.
 * Master and rockstar is the dream team for the startup.

**Always**

 * Prefer proficient to expert if the team is small
 * Prefer junior to mid level if the project is new or interesting.
 * Choose mid level if you have on going maintenance to do.

**Remember**

 * Real talent jumps from junior to proficient very fast and has only a brief stop
   at expert level.
 * People from academia become masters late in life, mostly because:
 * People from academia spend a (too) long time in the land of expertise.
 * Rockstars from academia is a rarity mostly because of the peer review system (
   think of R. P. Feynman from another field as an example)
 * Proficient people will generally mistakenly target an expert level income.

**Never**, never say never, however:

 * Never assign team leading to rockstars, they can do it but its rarely something
   they’d enjoy, like writing staff reviews.
 * Never have the expert report to more than one manager, as experts have very carefully
   planned time and repetition kills their agenda
 * Never involve juniors in more than one project at once, well maybe unless they
   are interns, in which case you’re doing them a favor
 * Always give blurry, loosely defined tasks to mid-levelers and sharp, clearly 
   defined tasks to proficients.
 * Then again, never say never

---

What am I supposed to do with this? Well self assess, assess others, read CVs and
stories with these glasses on when choosing partners and co-founders etc. Lots of
useful situations ☺