Archive for the ‘Books’ tag
I started reading Kathy Sierra’s new book ‘Badass: Making users awesome‘ a couple of weeks ago and with the gift of flights to/from Stockholm this week I’ve got through the rest of it.
I really enjoyed the book and have found myself returning to it almost every day to check up exactly what was said on a particular topic.
There were a few things that I’ve taken away and have been going on about to anyone who will listen.
Paraphrasing, ‘help users acquire skills, don’t throw knowledge at them.’ I found this advice helpful both in my own learning of new things as well as for thinking how to help users of Neo4j get up and running faster.
Whether we’re doing a talk, workshop or online training, the goal isn’t to teach the user a bunch of information/facts but rather to help them learn skills which they can use to achieve their ‘compelling context‘.
Having said that, it’s very easy to fall into the information/facts trap as that type of information is much easier to prepare and present. You don’t have to spend much time thinking about how the user is going to use, rather you hope that if you throw enough information at them some of it will stick.
A user’s compelling context the problem they’re trying to solve regardless of the tools they use to solve it. The repeated example of this is a camera – we don’t buy a camera because we want to buy a camera, we buy it because we want to take great photographs.
There’s a really interesting section in the middle of the book which talks about expert performance and skill acquisition and how we can achieve this through deliberate practice.
My main take away here is that we have only mastered a skill if we can achieve 95% reliability in repeating the task within 1-3 45-90 minute sessions.
If we can’t achieve this then the typical reaction is to either give up or keep trying to achieve the goal for many more hours. Neither of these is considered a useful approach.
Instead we should realise that if we can’t do the skill it’s probably because there’s a small sub skill that we need to master first. So our next step is to break this skill down into its components, master those and then try the original skill again.
Amy Hoy’s ‘doing it backwards‘ guide is very helpful for doing the skill breakdown as it makes you ask the question ‘can I do it tomorrow?‘ or is there something else that I need to do (learn) first.
I’ve been trying to apply this approach to my machine learning adventures which most recently has involved various topic modelling attempts on a How I met your mother data set.
I’d heard good things about the MALLET open source library but having never used it before sketched out the goals/skills I wanted to achieve:
Extract topics for HIMYM corpus -> Train a topic model with mallet -> Tweak an existing topic model that uses mallet -> Run an existing topic model that uses mallet -> Install mallet
The idea is that you then start from the last action and work your way back up the chain – it should also act as a nice deterrent for yak shaving.
While learning about mallet I came across several more articles that I should read about topic modelling and while these don’t directly contribute to learning a skill I think they will give me good background to help pick up some of the intuition behind topic modelling.
My take away about gaining knowledge on a skill is that when we’re getting started we should spend more time gaining practical knowledge rather than only reading but once we get more into it we’ll naturally become more curious and do the background reading. I often find myself just reading non stop about things but never completely understanding them because I don’t go hands on so this was a good reminder.
One of the next things I’m working on is a similar skill break down for people learning Neo4j and then we’ll look to apply this to make our meetup sessions more effective – should be fun!
The other awesome thing about this book is that I’ve come away with a bunch of other books to read as well:
- The Cambridge Handbook of Expertise and Expert Performance
- Mindset: How you can fulfil your potential
- The power of habit
In summary, if learning is your thing get yourself a copy of the book and read it over a few times – so many great tips, I’ve only covered a few.
I came across ‘The Hard Thing About Hard Things‘ while reading an article about Ben Horowitz’s venture capital firm and it was intriguing enough that I bought it and then read through it over a couple of days.
Although the blurb suggests that it’s a book about about building and running a startup I think a lot of the lessons are applicable for any business.
These were some of the main points that stood out for me:
The Positivity Delusion – CEOs should tell it like it is.
My single biggest improvement as CEO occurred on the day when I stopped being too positive.
Horowitz suggests that he used to be too positive and would shield bad news from his employees as he thought he’d make the problem worse by transferring the burden onto them.
He came to the realisation that this was counter productive since he often wasn’t the best placed person to fix a problem e.g. if it was a problem with the product then the engineering team needed to know so they could write the code to fix it.
He goes on to suggest that…
A healthy company culture encourages people to share bad news. A company that discusses its problems freely and openly can quickly solve them. A company that covers up its problems frustrated everyone involved.
I’ve certainly worked on projects in the past where the view projected by the most senior person is overly positive and seems to ignore any problems that seem obvious to everyone else. This eventually leads to people being unsure whether to take them seriously which isn’t a great situation to be in.
Lead Bullets – fix the problem, don’t run away from it.
Horowitz describes a couple of situations where his products have been inferior to their competitors and it’s been tempting to take the easy way out by not fixing the product.
There comes a time in every company’s life where it must fight for its life. If you find yourself running when you should be fighting, you need to ask yourself, “If our company isn’t good enough to win, then do we need to exist at all?”.
I can’t think of any examples around this from my experience but I really like the advice – I’m sure it’ll come in handy in future.
Give ground grudgingly – dealing with the company increasing in size.
Horowitz suggests that the following things become more difficult as a company grows in size:
- Common Knowledge
- Decision Making
If the company doesn’t expand it will never be much…so the challenge is to grow but degrade as slowly as possible.
He uses the metaphor of an offensive linesman in American football who has to stop onrushing defensive linesman but giving ground to them slowly by backing up a little at a time.
I’ve worked in a few different companies now and noticed things become more structured (and in my eyes worse!) as the company grew over time but I hadn’t really thought about why that was happening. The chapter on scaling a company does a decent job.
The Law of Crappy People – people baseline against the worst person at a grade level.
For any title level in a large organisation, the talent on that level will eventually converge to the crappiest person with that title.
This is something that he’s also written about on his blog and certainly seems very recognisable.
His suggestion for mitigating the problem is to have a “properly constructed and highly disciplined promotion process” in place. He describes this like so:
When a manager wishes to promote an employee, she will submit that employee for review with an explanation of why she believes her employee satisfies the skill criteria required for the level.
The committee should compare the employee to both the level’s skill description and the skills of the other employees at that level to determine whether or not to approve the promotion.
Hire people with the right kind of ambition
The wrong kind of ambition is ambition for the executive’s personal success regardless of the company’s outcome.
This suggestion comes from the chapter in which Horowitz discusses how to minimise politics in an organisation.
I really like this idea but it seems like a difficult thing to judge/achieve. In my experience people often have their own goals which aren’t necessarily completely aligned with the company’s. Perhaps complete alignment isn’t as important unless you’re right at the top of the company?
He also has quite a neat definition of politics:
What do I mean by politics? I mean people advancing their careers or agendas by means other than merit and contribution.
He goes on to describe a few stories of how political behaviour can subtly creep into a company without the CEO meaning for it to happen. This chapter was definitely eye opening for me.
There are some other interesting chapters on the best types of CEOs for different companies, when to hire Senior external people, product management and much more.
I realise that the things I’ve picked out are mostly a case of confirmation bias so I’m sure everyone will have different things that stand out for them.
Definitely worth a read.
I first came across William Zinsser’s ‘On Writing Well‘ about a year ago, but put it down having flicked through a couple of the chapters that I felt were relevant.
It came back onto my radar a month ago and this time I decided to read it cover to cover as I was sure there were some insights that I’d missed due to my haphazard approach the first time around.
What stood out in my memory from my first reading of the book was the emphasis on how words like a bit, a little, kind of, quite, pretty much and too dilute our sentences and I’ve been trying to avoid them in my writing ever since.
Other things that stood out for me this time were:
- Avoid unnecessary words e.g. blared loudly or grinned widely. It’s difficult to blare in any other way and if you’re grinning it implied that your mouth is open widely.
- Delete troublesome phrases. If you’re having trouble working out the structure for a sentence, it might be beneficial to get rid of it and see if the rest of the paragraph still makes sense. Often it will.
- Rewriting. The author emphasises over and over again the importance of rewriting a piece of text until you’re happy with it. This consists mostly of reshaping and tightening previous drafts. The way it’s described sounds very similar to code refactoring. My colleague Ian Robinson recommended ‘Revising Prose‘ as a useful book to read next in this area.
- Assume the reader knows nothing. The advice in the chapter on science and technology was probably the most applicable for the type of writing I do and I thought this section was particularly apt:
Describing how a process works is valuable for two reasons. It forces you to make sure that you know how it works. Then it forces you to take the reader through the same sequence of ideas and deductions that made the process clear to you.
I’ve found this to be the case multiple times although you can achieve the same benefits by presenting a talk on a topic; the benefits aren’t unique to writing.
- Explain your judgements. Don’t say something is interesting. Instead explain what makes it interesting and let the reader decide whether or not it deserves that label.
- Use simple words, be specific, be human and use active verbs. I often fall into the trap of using passive verbs which makes it difficult for the reader to know which part of the sentence they apply to. We want to minimise the amount of translation the reader has to do to understand our writing.
- Use a paragraph as a logical unit. I remember learning this at secondary school but I’ve drifted towards a style of writing that treats the sentence as a logical block. My intuition tells me that people find it easier to read text when it’s in smaller chunks but I will experiment with grouping my ideas together in paragraphs where that seems sensible.
I gleaned these insights mostly from the first half of the book.
The second half focused on different forms of writing and showed how to apply the lessons from earlier in the book. Although not all the forms were applicable to me I still found it interesting to read as the author has a nice way with words and you want to keep reading the next sentence.
My main concern having read the book is ensuring that I don’t paralyse my ability to finish blog posts by rewriting ad infinitum.
I came across this book while idly browsing a book store and since I’ve found most introduction to algorithms books very dry I thought it’d be interesting to see what one aimed at the general public would be like.
Overall it was an enjoyable read and I quite like the pattern that the author used for each algorithm, which was:
- Describe the problem that it’s needed for.
- Explain a simplified version of the algorithm or use a metaphor to give the general outline.
- Explain which bits were simplified and how the real version addresses those simplifications.
The first step is often missed out in algorithms books which is a mistake for people like me who become more interested in a subject once a practical use case is explained.
Although the title claims 9 algorithms I counted the following 8 which made the cut:
- Search Engine Indexing – this chapter covers how you’d go about writing the part of a search engine which works out which pages are applicable for certain search terms. It effectively describes Lucene.
I didn’t realise that Sergey Brin and Larry Page had published a paper back in 1998 titled ‘The Anatomy of a Large-Scale Hypertextual Web Search Engine‘ which explains the initial PageRank algorithm in more detail.
- Public Key Cryptography – this chapter mostly covers Diffie-Hellman key exchange which I realise is quite well explained on wikipedia as well.
- Error-Correcting Codes – I took the checksums included in somewhat for granted but in this chapter MacCormick goes through the problem of data getting lost or corrupted in transfer and iterates through potential solutions. The further reading from this chapter is ‘A Mathematical Theory of Communication‘, Hamming code and Reed-Solomon error correction.
- Pattern Recognition – this chapter covered a variety of machine learning algorithms initially focusing on digit recognition – something that Jen Smith and I spent a chunk of time working on last year for the Kaggle problem. The three algorithms covered are nearest neighbours, decision trees and neural networks, all of which we attempted! I recently came across the concept of convolutional neural networks and deep learning which I’ve yet to try out but are apparently even more accurate than plain neural networks.
- Data Compression – I imagine data compression would be one of the more familiar algorithms on this list since everybody knows how to ‘zip up a file’ and send it around. The author covers lossy algorithms such as ‘JPEG Leave it Out‘ which reduces image quality as well as size, as well as lossless algorithms such as LZ77, Shannon-Fano coding and Huffman coding. The latter is covered in Stanford’s Algorithms II and I think the explanation there is actually easier to understand than the book’s.
- Databases – this section mostly focused on how ACID compliant relational databases work and covered things like the write ahead log and index lookups. The recommended reading from this chapter is Transaction Processing: Concepts and Techniques. Given the fact that many of the popular websites that people use tend to use NoSQL stores these days I thought there might be some mention of that but it was left out.
- Digital Signatures – this chapter ties in quite closely with the one on public key cryptography. It focused on signing of software with a digital signature rather than the signing of emails which is what I expected the chapter to be about. The RSA algorithm is described and the link between the difficultly of factoring large numbers and the security of the algorithm is explained.
I enjoyed the book and I’ve got some interesting articles/papers to add to my reading list. Even if you already know all the algorithms I think it’s interesting to hear them described from a completely different angle to see if you learn something new.
Nate Silver is famous for having correctly predicted the winner of all 50 states in the 2012 United States elections and Sid recommended his book so I could learn more about statistics for the A/B tests that we were running.
I thought the book was a really good introduction to applied statistics and by using real life examples which most people would be able to relate to it makes a potentially dull subject interesting.
Reasonably early on the author points out that there’s a difference between making a prediction and making a forecast:
- Prediction – a definitive and specific statement about when and where something will happen e.g. a major earthquake will hit Kyoto, Japan, on June 28.
- Forecast – a probabilistic statement over a longer time scale e.g. there is a 60% chance of an earthquake in Southern California over the next 30 years.
The book mainly focuses on the latter.
We then move onto quite an interesting section about over fitting which is where we mistake noise for signal in our data.
It’s not a problem when we combine lots of decision trees together and use a majority wins algorithm to make our prediction but if we use just one of them its predictions on any new data will be completely wrong.
Later on in the book he points out that a lot of conspiracy theories come when we look at data retrospectively and can easily detect signal from noise in data when at the time it was much more difficult.
He also points out that sometimes there isn’t actually any signal, it’s all noise, and we can fall into the trap of looking for something that isn’t there. I think this ‘noise’ is what we’d refer to as random variation in the context of an A/B test.
Silver also encourages us to make sure that we understand the theory behind any inference we make:
Statistical inferences are much stronger when backed up by theory or at least some deeper thinking about their root causes.
When we were running A/B tests Sid encouraged people to think whether a theory about why conversion had changed made logical sense before assuming it was true which I think covers similar ground.
A big chunk of the book covers Bayes’ theorem and how often when we’re making forecasts we have prior beliefs which it forces us to make explicit.
For example there is a section which talks about the probability a lady is being cheated on given that she’s found some underwear that she doesn’t recognise in her house.
In order to work out the probability she’s being cheated on we need to know the probability that she was being cheated on before she found the underwear. Silver suggests that since 4% of married partners cheat on their spouses that would be a good number to use.
He then goes on to show multiple other problems throughout the book that we can apply Bayes’ theorem to.
Some other interesting things I picked up are that if we’re good at forecasting then being given more information should make our forecast better and that when we don’t have any special information we’re better off following the opinion of the crowd.
Silver also showed a clever trick for inferring data points on a data set which follows a power law i.e. the long tail distribution where there are very few massive events but lots of really small ones.
We have a power law distribution when modelling the number of terrorists attacks vs number of fatalities but if we change both scales to be logarithmic we can come up with a probability of how likely more deadly attacks are.
There is then some discussion of how we can make changes in the way that we treat terrorism to try and impact the shape of the chart e.g. in Israel Silver suggests that they really want to avoid a very deadly attack but at the expense of there being more smaller attacks.
A lot of the book is spent discussing weather/earthquake forecasting which is very interesting to read about but I couldn’t quite see a link back to the software context.
Overall though I found it an interesting read although there are probably a few places that you can skim over the detail and still get the gist of what he’s saying.
I came across the work of Chris Argyris at the start of the year and in a twitter conversation with Benjamin Mitchell he suggested that Bill Noonan’s ‘Discussing the Undiscussable‘ was the most accessible text for someone new to the subject.
In the book Noonan runs through a series of different tools that Chris Argyris originally came up with for helping people to handle difficult conversational situations more effectively.
I really like the way the book is written.
A lot of books of this ilk come across to me as being very idealistic but Noonan avoids that by describing his own mistakes in trying to implement Argyris’ ideas. This makes the book much more accessible to me.
He also repeatedly points out that even though you might understand the tools that doesn’t mean that you’ll be an expert in using them unless you spend a significant amount of time practicing.
These were some of the ideas that stood out for me from my reading over the last few months:
- Advocacy/Inquiry – Noonan suggests that when we’re discussing a topic it’s important to advocate our opinion but also be open to people challenging it so that we can learn if there are any gaps in our understanding or anything that we’re missing.
This seems quite similar to Bob Sutton’s ‘Strong Opinions, Weakly Held‘ which I’ve come across several times in the past.
One anti pattern which comes from not doing this is known as ‘easing in‘ where we try to get the other person to advocate our opinion through the use of various leading questions.
The problem is that they tend to know exactly what we’re doing and it can come across as being quite manipulative.
- The Ladder of Inference – I’ve written about this previously and it describes the way that humans tend to very quickly draw conclusions about other people based on fairly minimal data and without even talking to the other person first!
When Jim and I worked together at ThoughtWorks University we were constantly pointing out when the other was climbing the inference ladder and it was quite surprising to me how often you end up doing so even when you don’t realise it!
What I find most interesting is that even when I was absolutely sure that my inference about a situation was correct it was still frequently wrong when I discussed it with the other person. They nearly always had a different perception of what was going on than I did.
I think it’s a step too far to believe that I won’t ever climb the inference ladder again but it’s useful to know how frequently I do it so at least I’m aware that I might need to climb down from time to time.
- Recovery time – There is constant reference throughout the book to our recovery time i.e. how quickly do we realise that we’ve made a mistake by participating in a defensive routine.
Argyris’ tools are quite useful for helping us to reduce our recovery time because they are reflective in nature and when we reflect on a situation we tend to see where we’ve gone wrong!
Noonan suggests that it’s inevitable we’ll make mistakes but the key is to try and detect our mistakes sooner and then hopefully reduce the number that we make.
Of course there are several other tools that Noonan describes, such as the left hand right hand case study approach, double loop learning, espoused theory vs theory in action and the mutual learning model.
I still make loads of the mistakes that the book points out and I’ve noticed that I only really reflect on how my conversations are going when I’ve been flicking through the book relatively recently.
It’s also useful to be hanging around other people who are studying Argyris’ work as you can then help each other out.
One of the initial books that Chris Argyris published describing these tools was ‘Action Science‘ (available as a free PDF).
I initially tried reading that before this book but I found it a bit hard to follow but I’ll probably try it again at some stage.
I read Dan Pink’s A Whole New Mind earlier in the year but I hadn’t heard of The Adventures of Johnny Bunko until my colleague Sumeet Moghe mentioned it in a conversation during ThoughtWorks India’s XConf, an internal conference run here.
The book is written in the Manga format so it’s incredibly quick to read and it gives 6 ideas around building a career.
I’m generally not a fan of the idea of ‘building a career’ – generally when I hear that phrase it involves having a ‘five year’ plan and other such concepts which I consider to be pointless.
I much prefer to just focus on what I’m most interested in at the moment and then have the flexibility to be able to focus on something else if that interests me more.
Luckily this book is not at all like that and these are the ideas Dan Pink suggests:
There is no plan
The most interesting part of this piece of advice is Pink’s suggestion that when we make career decisions we make them for two different types of reasons:
- Instrumental reasons – we do something because we think it’s going to lead to something else regardless of whether we enjoy it or think it’s worthwhile.
- Fundamental reasons – we so something because it’s inherently valuable regardless of what it may or may not lead to.
I think this pretty much makes sense – it’s very difficult to predict what’s going to happen so you might as well make sure you’re doing what you want at any given time.
Think strengths not weaknesses
Marcus Buckingham has several books on this subject but the general idea is that we should look to focus on things that we’re good at or are really motivated to become good at.
By inference this means that we want to avoid spending time on things that we’re not good at and/or not interested in becoming good at.
I recently came across a blog post written by Robbie Maciver where he suggests that we can use a retrospective to help us identify team member’s strengths and work out how best to utilise them.
I think there’s sometimes a reluctance for people to volunteer their strengths so we end up with people working on tasks that they hate that other people in the same team would enjoy.
It’s not about you
Pink then goes on to point out that even if we do work out how to play to our strengths we still need to ensure that we’re focusing on our customer/client.
Pink calls this focusing outward not inward.
In terms of working in technology consulting that would therefore be along the lines of ensuring that we’re focused on solving our clients’ problems in the best way for them rather than the most interesting way for us.
Persistence trumps talent
The underlying idea is that people aren’t born brilliant at any skill, it only comes through practice and if we’re intrinsically motivated to do something then we’re much more likely to put in the time it requires to become really good.
To add to that I think intrinsic motivation is highest when we’re focusing on our strengths so this piece of advice is linked with the earlier one.
Make excellent mistakes
Pink talks about making excellent mistakes which he describes as ‘mistakes that come from having high aspirations, from trying to do something nobody else has done’.
I think this is somewhat linked to the idea of failing fast although it seems to be perhaps one level beyond that.
Sumeet gave a talk at XConf where he described the new approach to ThoughtWorks University and pointed out that one of the most important goals was to allow attendees to make ‘excellent mistakes’
One observation I have here is that smaller companies seems more willing to make excellent mistakes. As organisations grow the aversion to risk because of worries about loss of reputation increases which makes excellent mistakes less likely.
I find Eric Ries’ lean startup ideas particularly interesting with respect to failing fast and my former colleague Antonio Terreno recently linked to a video where the General Manager of Forward 3D explains how they do this.
Leave an imprint
Pink talks about the importance of doing work which actually has some meaning or leaves the world in a better place than it was before.
This is probably the one that I can relate to least. I’m writing software which is what I’m passionate about but I wouldn’t say the problems I work on are having much impact on the world.
This one therefore leaves me with the most to think about.
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 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.
In this book Ricardo Semler, the CEO of Semco, tells the story of the company and how he helped evolved the organisation into one which is more employee led and embraces ideas such as open & self set salaries while encouraging civil obedience in the workforce as a necessity to alert the organisation to its problems.
These were some of the ideas that I found the most interesting:
- Early on Semler points out that Semco doesn’t have a culture of looking busy. He describes how a sales manager spends a lot of his day just reading the newspaper but then as soon as there’s a problem for him to handle that’s when he earns his salary. Even though this book isn’t specifically about systems thinking, the description of this situation suggests to me that they are able to look at the bigger picture at Semco.
In software teams we can often feel quite guilty if we’re not busy but a bit of slack time is often useful for thinking about better ways to do things or to spike out new ideas.
- Semler emphasises the need to have small business units of under 150 people while matches up quite well with research done by Robin Dunbar which indicates that 150 is the ‘theoretical cognitive limit to the number of people with whom one can maintain stable social relationships.’ Semler also adds that keeping the units small ‘keeps them human’.
I know ThoughtWorks keeps this in mind with respect to our offices and will look to open a new one if the number of people in one is getting close to the 150-200 mark.
- Semco have a culture of what Semler refers to as ‘absolute trust‘ which he suggests is a more natural way. They implemented this at Semco by removing security checks on the gates into/out from the plants.
He almost then predicts the inevitable question in the reader’s mind with the following statement:
2 or 3% will take advantage of an employer’s trust. Is this a valid reason to subject 97% to a ritual of humiliation?
Have thefts increased or decreased?
I don’t know and I don’t care. It’s not worth it to me to have a company at which you don’t trust the people with whom you work.
He promotes an approach of common sense amongst his employees, suggesting that ‘rules freeze companies inside a glacier; innovation lets them ride sleighs over it’.
The general idea seems to be that the small details aren’t really that important and only serve to distract from the bigger objectives that the company are trying to achieve.
I was quite surprised to read how strongly Semler recommends job rotation:
Man is by nature restless. When left too long in one place he will inevitably grow bored, unmotivated, and unproductive. The cure, I believed, was to encourage managers to exchange jobs with one another
He goes on to point out that this type of rotation forces people to learn new skills which makes them more valuable but also discourages empire building because people don’t stay in the same place for too long.
I think we do this to some extent in the software industry between some roles but probably not as much as we could do. Having said that there is a lot to learn as a developer anyway so perhaps it’s not so applicable here.
- Perhaps the most controversial idea in the book is that of transparent/self set salaries. There was initially resistance to the latter idea as cynics believed that a few people would take advantage and award themselves massive pay increases. However, they found that having those salaries public served as a strong disincentive.
He also identifies the fact that people have a stake in the success of the company as being key for allowing this to work:
The third reason our people tended to be modest about salaries has to do with self preservation…Our people know salaries account for most of our operating costs, and they think about our budgets when they set them. It’s easy to solve a budget problem by eliminating a salary that seems too high, and noone wants to stick out.
The underlying reason behind why a lot of the ideas Semler implements seem to be about unhiding information as described by the following quote:
There is power in knowing something someone else doesn’t…but when cards are held close to the chest, communication will be faulty and anxieties, misunderstandings, insecurity, and eventually hostility will manifest itself…which is why when we started sharing information at Semco it has such a profound effect. People in the higher echelons could no longer rely on the conventional symbols and had to develop leadership skills and knowledge to inspire respect.
Spreading responsibility for problem solving across the organisation is another idea Semler strongly encourages and I think this partly explains why it’s more fun working in an agile environment.
Information in general is more accessible and because of that people have more opportunity to solve problems than they otherwise would.
- Semler discusses the need to keep the organisation lean even when times are good which he acknowledges is much more difficult than trying to keep it lean when times are hard! For Semco this involves being careful when hiring people to work on product lines which they knew had a short life span as well as ensuring that they didn’t add any unnecessary roles just because sales were strong.
Towards the end of the book Semler suggests that his goal with Semco was to ‘make people look forward to coming to work in the morning‘ which seems like quite a noble objective!
I found it quite interesting that although a lot of these ideas seem a bit radical, they made sense in Semco’s context because they were introduced incrementally and only after some other ideas had been introduced which helped smooth the way.
It’s certainly an interesting read and the ideas expressed at quite different than what is typical in most organisations.
I recently watched Randy Pausch’s ‘Last Lecture: Achieving Your Childhood Dreams‘ and read the corresponding book and although it’s not directly related to software development I think that some of the points that he makes are really intriguing.
These were some of the parts that particularly stood out for me:
- Introduce the elephant in the room – whatever it is that people are really thinking about, put it out in the open. I think on development teams there is often a distrust of the way that other people write code because it’s different to the way that we do. If we can get this out in the open more frequently and agree on a shared approach then it should result in a more consistent code base.
- Get the fundamentals down – Pausch suggests that we need to understand the fundamentals because otherwise the fancy stuff isn’t going to work. In Apprenticeship Patterns Ade Oshineye and Dave Hoover suggest that we should ‘Study the Classics‘ which is a similar idea.
While I think they’re certainly right I’m not sure that learning theory before putting it into practice is the most effective way to learn. I think we need to do a bit of both at the same time alternating between the two so that we actually have a frame of reference when we’re learning the fundamentals.
- The brick walls are there for a reason – Pausch describes how we’ll often come across obstacles stopping or blocking us from what we want to do but that we shouldn’t be discouraged, they are there so that we can see how much we really want something. I think this is just generally true and not just related to software development.
- The skill of self assessment – Pausch suggests that we need know what we don’t know which I think is perhaps the best advice in the book. We need to recognise our true abilities but also have a sense of our flaws and create feedback loops to allow this to happen.
My colleague Liz Douglass has come up with the idea of Feedback Frenzies to help create this feedback loop and this is one of the best ideas I’ve come across for doing this.
- One of my favourite quotes from the book is the following which I believe was originally from Dan Stanford:
Experience is what you get when you didn’t get what you wanted
It’s a phrase worth considering at every brick wall we encounter, and at every disappointment. It’s also a reminder that failure is not just acceptable, it’s often essential.
I think we can do this much more in the software world. There sometimes seems to be a stigma with identifying things which fail but I think it’s really useful for others to learn from mistakes that have been made.
The Last Lecture is one of the best presentations I’ve had the chance to watch – I’d certainly recommend it.