During the holiday I read a book mentioned to me by Pim Elshoff: "Skin in the game", by Nassim Nicholas Taleb. Discussing this concept of "skin in the game" with Pim had made me curious about the book. It's not such a fat book as one of Taleb's other books, which is possibly more famous, called "Antifragile". "Skin in the game" is a much lighter book, and also quite polemic, making it an often uncomfortable, but fun reading experience. I can easily see how people could get mad about this book or aggressive towards its author (not that I'm encouraging or approving of that aggression!). While reading it, it reminded me of Nietzsche, and his despise of the "common man", who Taleb calls "the intellectual" - someone who has no "skin in the game", let alone "soul in the game". Taleb's ideas are interesting, just like Nietzsche's are, but they could easily be abused, and probably so by misinterpreting them.
Intolerance wins
Something that's controversial, yet interesting for me as a developer in a team - from Chapter 2, "The Most Intolerant Wins: The Dominance of the Stubborn Minority":
Society doesn't evolve by consensus, voting, majority, committees, verbose meetings, academic conferences, tea and cucumber sandwiches, or polling; only a few people suffice to disproportionately move the needle. All one needs is an asymmetric rule somewhere—and someone with soul in the game. And asymmetry is present in about everything.
Taleb, Nassim Nicholas. Skin in the Game: Hidden Asymmetries in Daily Life (p. 83). Penguin Books Ltd. Kindle Edition.
This made me aware of something that I had observed several times before, whenever I was part of a software development team - or "software development society": the biggest impact on quality (to be interpreted in many different ways) isn't made by reaching consensus, or voting, or being tolerant to other people's opinions or ways of coding at all. What makes the biggest impact is the opposite: being intolerant of all those different styles, approaches, and being stubborn about your own way. As the title of the chapter says: "the most intolerant wins".
For example, how do you improve the coding style of a project? Maybe by discussing which styles you all like, and agreeing on one, then agreeing that all of you will apply it from now on? No, you can only achieve a consistent coding style by enforcing it everywhere and being very intolerant about it (that is, only allowing commits that conform to this particular style).
Another example: would you leave it up to your fellow developers to decide whether they will use static methods to fetch dependencies, or they inject all dependencies as constructor arguments? If you allow both, the result will be a mess. You can't even rely on a single class using either of these options - a class may even use both at the same time! (See also "Negative architecture, and assumptions about code"). You will be considered a tolerant developer, but it's not for the good of the project. Again, intolerance is needed to drastically improve and guard the quality of your project.
One more example: if you know that the project would be better off with a Docker setup, do you ask management for permission to make it so? Do you vote? You won't get the minority vote, let alone get scheduled time for it during regular work hours. It may very well be that you have the biggest chance of success when you just do it. There's one rule though: if things become messy, take full responsibility and adapt: you made a mistake, just roll it back (or don't roll it out in the first place). This is where you make sure you have skin in the game.
Do more than you talk
This leads me to quoting Taleb again:
[...] always do more than you talk. And precede talk with action. For it will always remain that action without talk supersedes talk without action.
Taleb, Nassim Nicholas. Skin in the Game: Hidden Asymmetries in Daily Life (p. 122). Penguin Books Ltd. Kindle Edition.
Over the past 20 years I've had lots of conversations with developers and managers, that eventually turned out to be just talk, no action. I don't know about your experiences (would love to hear about them though!), but this is a very common characteristic of "conversations in tech"; lots of meetings, lots of discussions, cool ideas, great plans, but none of it is going to happen. For many reasons of course, like:
- The managers in the meeting just want to keep the developers happy, so they allow them to make great plans, which will never be executed.
- The developers are not happy about their job anymore, so they construct this shared dream about how things could be, "if only...".
- Everybody realizes that the great plans are to great to ever be finished, so nobody even dares to start doing the work.
- The people who talk, feel that they must reach consensus for everything. They never reach it.
I'm sure that, from experience, you can add several more reasons to this list.
I find that some of my most impactful work on projects in the past has been when I preceded talk with action. I did something, believing it was the right thing to do, putting in some of my own time, and proving "that it could work". I did this work outside of the system of employer-employee, in unbillable time, and without (a lot of) consensus. Without exception, starting a change resulted in other people jumping in, supporting, and completing the work.
In fact, this is what I recommend people to do, when I get asked (and I often get this same question): "How can I change X in my team?" My first advice is always: don't ask, just do it. Of course, this comes with certain ethical clauses, like:
- you shouldn't be wasting your employer's time,
- you shouldn't do what you know will harm your relation with other team members,
- etc.
Still, within these margins you can easily accomplish much more than you thought was even possible, given the current project and the project team.
Having skin in the game, being antifragile
When reading "Antifragile", I was struck by something Taleb writes about being self-employed:
Further, for a self-employed person, a small (nonterminal) mistake is information, valuable information, one that directs him in his adaptive approach;
Taleb, Nassim Nicholas. Antifragile: Things that Gain from Disorder (p. 85). Penguin Books Ltd. Kindle Edition.
I always thought this to be a good reason to be freelancing: the mistakes you make force you to adapt, to learn. You get immediate feedback from what you do, and use it to become a better freelancer. Because you want to make your business sustainable and not end up with a bad reputation, becoming unhireable.
However, reconsidering this, I think it's not smart to link "being self-employed" to "learning from mistakes". What matters is the feedback loop involved in the work. If you could make a mistake, but it will never be linked to you, or you will never hear about it anyway, there's no way you could learn from it. And this is what may very well happen to any freelance software developer: a mistake you made (a bug you produced, a bad design you imposed, a coupling issue you introduced), may surface years after you made it. Since companies usually can't pay (a team of) freelance developers for longer than one or two years, you are very likely to miss the mistakes that you make, and therefore not learn from them. You'll likely even make the same mistakes in other projects for years to come.
So, do I recommend you not to start freelancing? Well, no. But I do recommend you to look for ways in which you can tap into the mistakes you produce, to evaluate how things are going, and to look for ways in which you can improve.
Antifragile and Skin In the Game are both books that I previously heard about and had an interest in reading, and this reminded me to add them to my reading list (and I do actually work my way through this list). The thought about a freelancer getting feedback is interesting. It reminds me of stuff I read in Benjamin Hardy's books "Slipstream Time Hacking" and "Willpower Doesn't Work". In both he talks about getting payed based on results, and how the really financially successful people do this. Some people do this by being self-employed, or starting a company. Others make sure they get held accountable in other ways. The key is that for many office jobs, the environment encourages you to not be too different from everybody else. There is a tendency to not want to take risks or stand out so you don't risk losing your job. That goes both for low level employees and managers alike. Instead of getting payed based on results, you are often payed based on showing up, putting in a set number of hours, and staying at your desk continuing to do something on your computer. One big problem is there is often very little or only no consequences for not getting much of anything done on a particular day.
So you have to learn to get out of that mentality and change the environment where you work, from the inside out, if you are going to work in an office or knowledge work environment and want to get payed based on results. I am exploring how to make this happen more so where I work. I just successfully negotiated and achieved my first results based bonus. I was very explicit about defining what would cause me to not get the bonus, and made sure it was actually possible to go down either way, and that I could only get the bonus if I achieved a very specific result. It worked well enough, but I think going next time I will try to make it more goal based in addition to being deadline based. So next time, it won't be about completing the development work by a certain deadline so much as getting a business/user result by a certain deadline. I want to actually have to release the project, get feedback, apply it, release again, and keep doing that until the ultimate user experience/business goal is achieved according to the judgement of people not incentivized by a bonus. Going forward I also want to experiment with flipping the standard way of thinking about deadlines. Normally in programming, the longer the deadline, the more a manager might expect to have to pay as a bonus, if they are even thinking about bonuses. But that way of thinking punishes improvement. If we improve, and therefore can complete a new project in one week instead of one month, and we estimate it as such, the manager will think they should pay only a small amount as the bonus. It should be flipped. The faster we get it done, the larger the bonus should be, otherwise you are incentivizing long estimates, poor performance, and a lack of improvement.
Of course with all that you have to be careful not to incentivize poor internal code quality. We have a system where we are on a certain "level of the game". We have certain rules that determine our team score for the iteration. The only way to get a higher score and beat the level is to improve the internal quality of the code and system. Then after we beet the level we fight a boss, which is a bonus incentivized large project that is important to complete for the progression of the company, but historically difficult to achieve amidst the other maintenance work that has to be kept up with. So then the shift changes from improving the internal quality to beating the boss. Then we move on to the next level of the game. At that point, all of our automatically enforced quality metrics are still enforced, and you can't release without meeting them, but we add new ones that start taking away more points, or new types of quality improvement that will add more points to the extent we achieve it. All of these rules keep getting redesigned to make sure we are incentivizing the right things, but even more than that we are really careful about who we hire, since any score or bonus system can be manipulated in a selfish way if that is really what someone wants to do.
Thanks for your elaborate post. I can totally relate to your story here.
I recently had a nasty experience with a bonus clause in the contract, where I was about to be paid when X features were done by a certain date (of course, the they weren't finished, and not by that date). I think that a bonus isn't a good idea at all, since it implies I won't do my very best to deliver _without_ an extra incentive. I'm ready to give much of myself anyway and usually don't want to think about money. I only hate it when a client starts to tamper with my fee; it will always feel like they don't appreciate my work. I actually find this a good sign that it's about time to go; since apparently paying me is starting to press their own financial situation and I can never fight against that).
Still, there's an important clue in that: I think the maxim for contract work should be: what I'm doing for them should add value (still pretty abstract, I know). Sometimes having something before a deadline is valuable, because that date is meaningful to their business (e.g. Christmas season). Sometimes a particular feature is most valuable, since it allows them to reach out to more potential customers. By the way, I think this is important for all software developers, freelance and employed.
It sounds like you might benefit from that book I mentioned "Willpower Doesn't Work". The idea that you won't do your best work without an extra incentive is actually mostly likely true, but let me clarify. Even if you really care about your work, and your not just in it for the money, and even if you have a good work ethic, and even if you always try to put in your best effort, an extra bonus for a specific result probably will push you even further than that. It can be a way of shaping your own environment where you are trying to have everything about it push you in the direction you want to go. So if you already want to accomplish the result the bonus is attached to, then the bonus is just an added tool in your environment giving you extra motivation to achieve it. Now of course it can be a bad thing if you don't trust the person offering the bonus, or if they try find lame excuses to say you don't qualify for it. That is actually part of what I don't like about contract work, you have to start over with those relationships every time. If you work for a single employer, you both can gain/earn each others trust and respect, although this tends to take a long time, which is why I prefer to stay at one place instead of switching jobs. The best benefit I have seen so far from having a bonus attached to a result, is not so much about pushing me to put in extra hours or to work harder, but to further fully align my actual incentives with what I mentally already wanted them to be. So then when I am working, I am less likely to over prioritize things that really should be put off, and I am more likely to prioritize the things that really will get the best results in the shortest amount of time. I'm not saying we should build up technical debt in the code in pursuit of a bonus. I'm saying the bonus makes it easier not to jump into cleaning up every little piece of technical debt that was already there along the way. Even to the extent you could already achieve this, the bonus helps you to achieve it even more.
As far as deadlines go, I have always felt really negatively about them, but the book Willpower Doesn't Work has changed my perspective on that. Now I see a deadline as a tool I can use to motivate myself to complete something faster. Work tends to expand to fill the time it is allotted. If it is allotted an unlimited amount of time, even more so. Things that are really not that important somehow begin to feel very important when you have lots of extra time. Part of the key to making all this work is for it to be self directed. You have to bring up the idea of the bonus and time limit, not the person paying you. This can be the difference between good stress and bad stress, or between ustress and distress. If they force or coerce you into this type of contract, it will probably feel like they are imposing stressful burdens on you. Some people are naturally good at viewing their bodies response to stress as a tool they can use. They see it as their body giving them what they need to do the job well. But most of us feel like our bodies are just freaking out and getting sick. But you can, to a certain extent practice seeing it the former way, and it largely how you see it that determines if the stress is good or bad for you. Of course there is still a limit to how much you should put on your plate and how much pressure you should put on yourself. But part of what helps you to be able to take on larger burdens is to really maximize your relaxation time. After completing a large project, take some time off. When it is time to rest and relax engage in very relaxing and restful activities. Sleep as long as your body will let you. Take bubble baths with essential oils and relaxing music, or whatever relaxes and rejuvenates you. Get out of your normal environment for a time and experience something inspiring. Then when you are back to work, learn from your previous experiments to take on an even more amazing goal/project, and set yourself up to benefit from it tremendously, or get really hurt if it doesn't work out. Then you will have "skin in the game".
Very interesting, thanks for taking more time to share your thoughts. I like it. I'll also check out that book.
"Intolerance wins". In the long term? Do you have a neutral source of information that allows you to measure the impact of that kind of decision within a team? I feel like this is a dangerous path that is likely to produce toxic individuals, and the reason why more and more companies introduce a "no jerk" policy.
While I assume you really mean this in a soft way, I would refrain from proclaiming technical choices that would likely be seen as personal preferences. There's no place for subjectivity since we are all different in this regard, you have to find what gathers people. It basically discredits ideas of other employees with no technical justification, and will eventually diminish their enthusiasm, hinder personal development, and the whole shebang.
I know that reaching consensus is not easy but it's the way to go because imposing controversial decisions systematically produces frustration. If you don't have a consensus amongst your peers then examine the situation more closely, you may have missed something in your argument (either the substance of it or the way it is presented) and pushing it inappropriately. Use techniques like reverse reasoning using proof by contradiction, emphasize on the context, document the question with thorough research and eventually fall back to known consensus that makes authority amongst a larger amount of individuals that the one you are trying to convince with your argument, not your personal choice (for instance your code style is surely driven by a programming language's community guidelines and you should use them instead of trying to impose different rules that your team doesn't largely approve).
Yep, I share your concerns. This is by no means a call-to-jerkiness :) For me, being not a jerk (I think), this advice is merely meant to get software projects unstuck. It happens all too often that things could easily be much better, but nobody dares to make the first move, or nobody gets a "go" from their "superiors".
For most everyday work I agree with you. You do need healthy discussions, proper arguments, and de-personalize technical decisions. Otherwise, I hope, people will just start ignoring you.
"putting in some of my own time", "outside of the system of employer-employee, in unbillable time", "shouldn't be wasting your employer's time"
Can I get all the time that will be won by the change over the coming years as extra (paid) holiday then? ;)
I agree with pretty much all of the article, but improving your infrastructure / quality level / ... should just be part of the job, not something people should do after they are done doing their job.
I agree that it's very counter-intuitive. I've found that it helps to put some of my time into radical change. The skin-in-the-game aspect of it is: I'll be extra careful about wasting time (since it's my time ;)). But to be clear, I don't put in more than just a few hours for the proof of concept. At that point I can show that it's going to work, and I can sell it and get more support from team/management. Because I also firmly agree with you here: it *should* be part of the job. On the other hand, I know many people who are stuck because they aren't allowed to do any of this, so they may need some encouragement to "just do it".