Linchpin: Book Review
I’ve read a couple of Seth Godin’s other books - Tribes and The Dip - and found them fairly readable so I figured his latest offering, Linchpin, would probably be worth a read too.
This is the first book that I’ve read on the iPad’s Kindle application and it was a reasonably good reading experience - I particularly like the fact that you can make notes and highlight certain parts of the text.
It’s also possible to see which areas of the book other Kindle users have highlighted and you can see your highlights/notes via the Kindle website.
The Review
The sub-title of the book: 'Are you indispensable? How to drive your career and create a remarkable future' didn’t really appeal to me all that much but I’ve found that these types of things are often just for provocation and don’t necessarily detract from the message.
As with the other Godin books I’ve read, he spends a lot of time making his original point and in this one it felt like I’d already agreed with what he was saying for at least 50 pages before we moved onto something else.
Despite that I think there were some good points made in the book. These were some of the more interesting ones for me:
-
One of my favourite quotes from the book is the following about fire:
Fire is hot. That’s what it does. If you get burned by fire, you can be annoyed at yourself, but being angry at the fire doesn’t do you much good. And trying to teach the fire a lesson so it won’t be hot next time is certainly not time well spent. Our inclination is to give fire a pass, because it’s not human. But human beings are similar, in that they’re not going to change any time soon either.
One of the things I’ve noticed over time is that it’s very unlikely that the core way a person behaves is likely to change regardless of the feedback that they get from other people. Pat touches on this in a post where he points out that we need to be prepared for feedback to not be accepted. I don’t think this means we should stop giving feedback to people if we think it will help them be more effective but it does seem useful to keep in mind and help us avoid frustration when we can’t change a person to behave in the way we’d like them to.
-
Godin makes an interesting point about the value of the work that we do:
A day’s work for a day’s pay (work \<⇒ pay). I hate this approach to life. It cheapens us.
This is exactly the consulting model - billing by the hour or by the day - and although I’ve come across a couple of alternative approaches I’m not sure that they work better than this model. Value based pricing is something which I’ve read about but it seems to me that there needs to be a certain degree of trust between the two parties for that to work out. The other is risk/reward pricing and I’ve heard good/bad stories about this approach. It seems to me that we’d need to have a situation where both parties were really involved in the long term outcome of the project/system so if one party is only invested for a short % of this time then it’s going to be difficult to make it work.
-
Shipping is another area he touches on in a way that makes sense to me:
I think the discipline of shipping is essential in the long-term path to becoming indispensable. The only purpose of starting is to finish, and while the projects we do are never really finished, they must ship. Shipping means hitting the publish button on your blog, showing a presentation to the sales team, answering the phone, selling the muffins, sending out your references. Shipping is the collision between your work and the outside world.
While this is just generally applicable, in software terms this would be about the sort of thing that my colleagues Rolf Russell & Andy Duncan cover in their talk 'Rapid and Reliable Releases'. I also had an interesting discussion with Jon Spalding about the importance of just getting something out there with respect to the 'Invisible Hand' browser plugin that he’s currently working on. Jon pointed out that it’s often best to ship and then rollback if there are problems rather than spending a lot of time trying to make sure something is perfect before shipping.
-
Godin spends a lot of time pointing out how important human interactions and relationships are and I think this is something that is very important for software delivery teams. One of the most revealing quotes is this:
You might be parroting the words from that negotiation book or the public-speaking training you went to, but every smart person you encounter knows that you’re winging it or putting us on. Virtually all of us make our living engaging directly with other people. When the interactions are genuine and transparent, they usually work. When they are artificial or manipulative, they fail.
I attended a consulting training course when I first started working at ThoughtWorks 4 years ago and I’ve always found it impossible to actually use any of the ideas because it doesn’t feel natural. It’s interesting that Godin points out why this is!
Overall this book feels to me like a more general version of Chad Fowler’s 'The Passionate Programmer' which is probably a more applicable book for software developers.
This one is still an interesting read although it primarily points out stuff that you probably already knew in a very clear and obvious way.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.