Skip to main content

Book review: Steve Jobs Way by Jay Elliot

I finally completed reading ‘Steve Jobs Way’ by Jay Elliot. I wanted to know how Apple became so innovative and so successful and I knew that Steve did an awesome job to bring this company to a state which is very well known today. Before I started reading this book I had a notion that this book would focus on how hard work or dedication would pay off and all that stuff that one would generally see in any book. This book was different. Different in a way that it taught me the qualities a leader in any industry should have.

Here is a list of things I learnt:

1. Self Belief – Usually we come across a situation where others would say that ‘This is not possible’ or ‘This cannot be done’ and we buy into their belief. Apple’s 1984 epic ad was first rejected by the board of directors but then Jobs and Wozniak shelled out 400k from their own pocket and bought this ad. This ad then went on to become the most popular ad of all times.

2. Good decisions – Every one of us at some point in time have to take a decision at work. For Steve it was about deciding the features that would go into a product. He would ask his Engineers to come up with a list of features that they think will delight the customers. The team would then come up with a list but then Steve would choose only the first three and ask Engineers to build the product with these features only. This is very interesting and it works because it is these three features that will the make the product sell more. The rest of the features can be baked in later versions.

3. Bad decisions – Most of us or lets say all of us have made bad decisions in life and Steve is not an exception. He hired John Sculley from Pepsi Co and later found himself out of the company. The board was not able to concur with Steve’s vision and hence Steve left the company that he founded. However, he learnt that it was his bad decision to hire the wrong candidate.

4. Experience and Design – The Engineers would come up with the product design and Steve would reject it because he felt that if he is not able to enjoy the experience of the product then their customers would also not enjoy it. Steve once said - “Design is not about how it looks but about how it works”. He would push his Engineers to create something that wows the customer.

5. Passion – Steve carried a lot of passion for the products that were created at Apple and he expected the same from his employees as well. Engineers would put in days and nights to build the product. Usually they worked even on weekends and if someone said that they can’t come on a Saturday then he would say – “Don’t bother to come the next day” meaning never come back. But at the same time he did respect his employee’s privacy. If he was curious to know about the feature he would call up the Engineer even at late at night and ask questions. But before all that he would always ask “Whether its a good time to talk?”.

6. Appreciate – When it comes to appreciation, Steve did it very handsomely. Be it celebrating an employee’s year completion, outings or anything else, Steve made sure every one is felt well appreciated. He played by the rule “When you play, play hard. When you work don’t play at all”. Also, if someone completed five years at Apple he was given a sabbatical leave. But the Sabbatical was not given so that the employee can relax and enjoy the time, but it was given so that the employee can take this time to think about new products or even think about how well he can contribute more at work. Before the Apple 2 was released, Steve asked his Engineers to sign their work just like how artists do. The inner cases of Apple 2 had the Engineers signature moulded. Though this would not be visible outside but it meant a lot to the team.

Now when I see today’s leaders (so called), I see that they are all missing this. They always find time to criticize the team members but occasionally (or never) appreciate. What’s more ‘disappointing’ is that they point to a few people in the team and acknowledge their contributions and say the rest are ‘disappointing’. I don’t know why they think quantity is more important than quality and why they don’t get the right information before making a statement or decision. Or sometimes only the vociferous is appreciated. This often affects the morale of the employee and sometimes the company looses a great resource.

It’s a nice read and I recommend every one to read this book because every one is a leader with or without a title.


  1. Have you seen some of the criticisms of Steve Jobs? Since this book seems to purport that Jobs showed appreciation "handsomely", I think it should be noted that he was notorious for taking credit for other's ideas and work. Check out this story: 

  2. @Jake M I've not read that book by Walter Isaacson. Thanks for pointing to the link. I think the book I read does show only one side of Steve and not the other.

  3. I don't think that the book has it exactly correct on the 1984 ad.  I heard Wozniak speak a year ago and someone asked him about it during the q and a.  He said when he heard that management might not run the ad he requested a meeting and said he would pay for it out of his own pocket.  But in the end the company decided to do it.  Also learned directly from Woz that he was on the Mac team before Jobs took it over which I did not know previously.


Post a Comment

Popular posts from this blog

Adding beforeRender and afterRender functions to a Backbone View

I was working on a Backbone application that updated the DOM when a response was received from the server. In a Backbone View, the initialize method would perform some operations and then call the render method to update the view. This worked fine, however there was scenario where in I wanted to perform some tasks before and after rendering the view. This can be considered as firing an event before and after the function had completed its execution. I found a very simple way to do this with Underscore's wrap method.

On GraphQL and building an application using React Apollo

When I visualize building an application, I would think of using React and Redux on the front-end which talks to a set of RESTful services built with Node and Hapi (or Express). However, over a period of time, I've realized that this approach does not scale well when you add new features to the front-end. For example, consider a page that displays user information along with courses that a user has enrolled in. At a later point, you decide to add a section that displays popular book titles that one can view and purchase. If every entity is considered as a microservice then to get data from three different microservices would require three http  requests to be sent by the front-end app. The performance of the app would degrade with the increase in the number of http requests. I read about GraphQL and knew that it is an ideal way of building an app and I need not look forward to anything else. The GraphQL layer can be viewed as a facade which sits on top of your RESTful services o

De-obfuscating javascript code in Chrome Developer Tools

I had blogged about JavaScript debugging with Chrome Developer Tools  some time back, wherein I have explained how these developer tools can help in debugging javascript code. Today Google Chrome 12 was released and my Chrome browser was updated to this version. As with every release, there have been some improvements made on performance, usability etc,. One feature that stood out for me is the ability to De-obfuscate the javascript code. What is Minification? Minification is the process of removing unnecessary characters such as white spaces, comments, new lines from the source code. These otherwise would be added to make the code more readable. Minifying the source code helps in reducing the file size and thereby reducing the time taken to download the file. This is the reason why most of the popular javascript libraries such as jQuery are minified. A minified jQuery file is of 31 KB in size where as an uncompressed one is about 229 KB. Unfortunately, debugging minified javascript f