This blog post is all about: "divide & conquer" rule's applicability for compensation considerations :), why getting down to individual skills is a waste of time, what's the point of rewarding loyalty, how to incentivize people so they specialize, what to do with project heroes (& their reward expectations) and why you should read the forthcoming posts in the series :)

Part I of the series can be found here.

Let's summarize how far did we get until now: one can't always determine directly how much (tangible) value an individual brings, so as human beings are poor in absolute evaluations, it's probably better to take a comparative approach - but how to compare pears and apples?

There are probably zillion ways to do that, here's my one - I prefer to split individual's compensation into few separate INGREDIENTS, based on independent factors (calculated with different variables). Here they are (simplified version, for the sake of clarity):

1. [CTX] Contextual factors
2. [MAT] Maturity
3. [TEN] Tenure
4. [USP] Unique Spice
5. [BOH] Badge(s) of Honor

[CTX] Contextual Factors

These are pretty much constant for all the individuals playing the same role (e.g. all the Front-End Engineers or all the System Analysts) within the same location (the same geo-political & economic situation).

CTX reflects the differences between particular profiles (based on job market, talent access & effort to enter the role) and particular locations (based on cost of living & other economic conditions).

Basic stuff. People in SF earn proportionally more than their pals in Kolkata (for the same work done) - that's the world we're living.

[MAT] Maturity

MAT is a the sum of role-applicable skills & their "depth". We believe that the depth of the skill is roughly 10% theory & 90% practice - so relevant experience is a game changer here.

Skills are of all the kinds applicable for a certain specialty:

• starting with a fundamental engineering common-sense, abstract thinking, problem decomposition, ...
• ... through communication clarity, assertiveness & pro-activeness, ...
• ... ending with technical expertise related to particular technology(ies)

E.g. someone's maturity can grow if (s)he gets visibly better in building web applications with Rails, but also when someone grows as a team player & is able not only to contribute her/himself but also coach & tutor 2 juniors. Technical proficiency will likely grow when you're exposed to varying problems (over a period of time - because it "stretches" you), but doing the very same thing for 5 consecutive years in a row probably won't make any real difference.

[TEN] Tenure

TEN (aka loyalty) is a measure of your familiarity with company-/team-specific problems & solutions. By working for longer & longer in the same place (on the same project/product) you gain more "tribal" knowledge, you earn local "scars", you absorb all the rationale behind tiny, undocumented decisions made every day - so you build a company-specific solution context, which is:

• very valuable for this particular company/team
• pretty much useless for any other company/team (if/when you decide to change jobs)

So it makes perfect sense to reward tenure/loyalty - as it's the knowledge that will inevitably perish once an individual leaves (e.g. if lured by someone else with a bold paycheck promise) & re-building this expertise (within another person) is very expensive, time-consuming & ... there's always some knowledge lost in the process.

[USP] Unique Spice

Having company-specific knowledge is one thing, but sometimes our T-shaped/E-shaped engineers have very narrow, yet super-useful industry expertise (that is not put in the MUST-HAVE section of their role description) in their skill portfolio - something that is unique (& valuable!) enough to be worth paying for that extra. This is their unique spice - USP.

Examples?

1. Front-End Engineer may be a certified security expert (e.g. CISSP)
2. Back-End Engineer may be a cloud infrastructure expert (e.g. AWS Solution Architect)
3. System Analyst may have a prior SME experience within a particular domain (e.g. financial services - worked for 3 years on consumer banking risk models)

These specialties do not have to be confirmed with any certificates, BUT they have to be practically applicable. There has to be a PROMISE related with each one of them - an expert should be able to handle a certain level of challenge associated with her/his specialty.

[BOH] Badge(s) of Honor

One-man-armies. Project heroes. Super-ninjas. Developer Rockstars.

Everyone knows them. Individuals able to save the day just by themselves. Who push everyone else aside, so no-one interrupts their majesties. Shush, you need to tiptoe, otherwise you may distract their hyper-productivity, you meager mortal.

Rewarding them is very tricky. On one hand, it sounds suicidal not to reward someone who may have just saved your ass (& numerous other buttocks as well). On the other hand, the context is king - if heroism is built upon knowledge siloing, if rockstar cares more for personal acomplishment than actually improving things (e.g. avoiding similar problems in future), if her/his behavior is anti-team & egocentric - rewarding that will end poorly.

That's why I propose something else - BOH - Badges of Honor.

Monetary expressions of gratitude awarded by ... team mates. What leadership does is just setting up the categories (that promote the values beneficial for organization culture), e.g.:

• Best Gardener - person who contributes most to grow others (people developer)
• Top Community Advocate - person who does most to make the team visible (in a positive sense) in the external community
• Kaizen Master - person who did most to introduce small, yet frequent day-to-day improvements (in tooling/process/architecture)
• Remarkable Scribe - person who strives most when it comes to knowledge sharing & documenting in a smart way (what's really worth putting down alongside code)

Such a badge is unique (only one of a given category can be held at a given time), awarded for a given time (e.g. 6 months) & a single person can hold badges of more than one type. Salary premium (due to such badge) is not overwhelming, rather symbolic, but people value high everything that comes from their peers.

One more thing - badge doesn't have to have a holder. If there was no-one exceptional in people development, such badge should be put in the freezer.

Questions, questions, questions ...

Wait! There are things to clarify:

1. What about actual performance (whether someone does well or not)? Shouldn't it be a factor?
2. This "maturity" thingie - how is it measured? Who decides on someone reaching the next level?
3. How to verify whether "unique spice" is real value or just a promise without coverage?
4. How to make sure that a "badge of honor" doesn't become a popularity contest?
5. Having these few ingredients sounds great - but do people know ratios between them? How much they can earn due to MAT & how much due to TEN?
6. Are you OK with people trying to game the system (optimize their efforts for the coefficients which are potentially most benefactory)? What is made visible and what is not?
7. What if performance is subliminal? Is there any place to motivate people to try harder?
8. Formulas & ingredients are OK, this is a model, but models are nothing else than a simplified reality - sometimes they do not reflect the real state of matters. What about person's (e.g. leader's) subjective judgment - where is it applied?

These are all valid questions ... If you want them answered, you need to check the next post(s) in the series :)

Coming soon.