Having ‘skin in the game’ is a pretty trendy concept nowadays, recently popularised by Nassim Nicholas Taleb (the controversial author of The Black Swan) and subject of his next book to be published later this year.
What is ‘Skin in the game’?
In short, to have ‘skin in the game’ means you have something to lose from your opinion, forecast or actions - leading you to be more thoughtful about them, and thus coming across as more credible.
Quick example: we’re back in 2016 and despite my dislike of Trump and against all odds, I foresee that he is going to win the presidential election. Is that a genuinely insightful thought? Not quite - if he loses, I’m more than relieved, if he wins, I look smart. So a win-win for me, i.e. zero skin in the game.
Now, if I was to bet $1,000 on a Trump win, then that would genuinely mean something. I could lose out, so credit to me for getting it right.
Can this apply to teams and individuals?
I had a few discussions recently around whether this principle could apply to developers and their teams, and a few ideas came up:
For startups, to give share options to developers so they stand to benefit (or lose) if the startup does well (or not)
Making individuals, and teams, fully responsible for what they do. E.g. if they develop a product or service, make them support it too - they will make sure the product is stable if any failure wakes them (rather than someone else) up at night
Get developers to be users of their product. That’s not always possible, but when it is, it is a pretty straightforward way to close the developer/user feedback loop. Any time they (the developers) cause a bug or botch a new feature, they will feel the pain and do what they can not to do it again
Performance reviews as a counter-example
Most people I know get reviewed once (or twice) a year by their team or project lead. That lead with whom they work everyday, towards similar objectives, and whose performance will get judged based on the team members’ own performance.
Effectively this is skin in the game, and can lead to conflicts:
The lead sits too close to the reviewee to see the person’s whole contribution (which usually goes well beyond one single project or team)
The lead’s own performance and behaviour will often end up being part of the review discussion
Thus the lead is both ‘juge et partie’ - judge and party to what is at stake. Too much skin in the game.
When I get to do performance reviews nowadays, as a consultant (thus to some extent an outsider), I find myself easily sidestepping all of these issues. With little or no skin in the game, it is more natural to criticise constructively, easier to get a more complete view of the person and be frank about all areas where improvement is needed.
All of which is, to be fair, possible with a really good manager. But the harsh reality is that most companies and teams don’t have that luxury. Hence why it makes sense to not have team or project leads conduct performance reviews, as suggested here.
Need advice for your technology business? I can help