A skill scale for developers

An unruly take on the notion of performance

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.

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

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

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

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

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.

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


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


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


  • 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 ☺