Skin in the software game

Joel Kemp
Staff+ Engineering Learnings
2 min readJan 13, 2021

Nassim Taleb’s concept of “skin in the game” has had a profound impact on me. It states that risk should be symmetric: as in, you cannot subject others to risk that you do not take on yourself (e.g., you must eat the food that you cook).

From observations over the years, here’s how I think this maps to software:

  • Architects should help code the systems they devise. The “ivory tower” architect is one who does not have skin in the game.
  • Engineer managers should stay up with their teams during incidents/firefighting.
  • Engineers should use the products they build, or regularly talk to the customers that use the products. You cannot expose your customers to bugs/risks/outages that you are not exposed to.
  • Engineers must be on-call (part of a rotation) for the systems they build.
  • Leadership (particularly VPs) who set rules should sit with the teams that must follow them.
  • Engineers should stay with their projects at least through one major refactor, to see the mess they’ve created.
  • If you firmly believe that a different technology stack should be used for a problem, you must put your reputation on the line for it and you must help prove it out.
  • Don’t tell an engineer which stack to use if you won’t also maintain the code yourself.
  • You cannot subjectively criticize software that you didn’t write yourself. Objectively (using patterns, known refactoring techniques, existing solutions) is fine.
  • A front-end engineer that does not know how to write backend code cannot say “we can just do it on the backend.” And vice versa. More generally, don’t make decisions for a part of the stack you can’t contribute to yourself; otherwise you’re pushing risk on others without being able to take it on yourself.
  • Folks who don’t code should not estimate or criticize how long software takes to build.
  • Platform teams need an engineer that sits with an integrating stakeholder. You can’t push complexity to stakeholders without feeling their pain.
  • Don’t force yourself into a leadership position without some skin in the game (having built complex/risky projects or actually contributed to the majority of the team’s systems). People can easily sense when you don’t really know what you’re talking about and they’ll resent you for taking credit or stealing the air in the room. Teammates respect others who have skin in the game.

--

--