I finally had a chance to finish up reading the Delivering Happiness book I’ve been reading and writing about for the last few weeks. In all, I do recommend the book both to startups, and to those running a larger company. The book is almost two books in one. The first half, as I covered in my posts, Discovering Happiness and Now This is Real Passion, are about Tony’s early startup experience and the path he was on that led to his personal discovery of what his passions really were. This was the part of the book that I enjoyed the most as it focuses on my situation and on one of my favorite areas of interest: internal motivation and discovering one’s passions.

The second part of the book deals with the management of Zappos, as Tony transitioned into running and growing a company. Here, he discusses how he built the now famous Zappos culture. He discusses this in detail, including many internal memos and company letters, and even including 24 pages of the company’s Core Values Document. I touched on this in my previous post The Zappos Culture Book. This is all very interesting, but since I’m more involved in the early startup days, it’s a bit beyond where I need to be. It was still helpful and I identified with many of the core values, and felt like I would be comfortable adopting the entire thing, as-is, for my own company, though with some personal changes here and there.

I do think that overall, the book could have been better with an editor reviewing and chopping out maybe 25%. For that reason I gave it 4/5 stars, compared with 5/5 for both Rework and Gary Vaynerchuk’s Crush It. If you remember, with Rework, between the next-to-last and final draft they cut the book in half, down to 27,000 words from 57,000. Delivering Happiness would have been better a bit shorter and more focused.

In this second part of the book, spanning sections 2 and 3, you will learn what it is that Tony believes are the only competitive advantages they have, “everything else can be copied”. You’ll read examples of how the company stood behind its culture and core values and how they developed what those would even be. Tony will discuss the number one driver of growth: customer service and word of mouth, and how that is more than a marketing scheme, but a way of life for the entire team at Zappos. Tony also discusses the importance and value they place on their call center, and how differently they handle that than most other companies, and how other companies can instill excellent customer service at their companies.

As I mentioned earlier you’ll be able to read the entire Core Values Document of the company with helpful example stories where they put it in practice and how it effected the people and the company. Tony will discuss his experience with beginning to speak publicly and how he changed his approach on how to prepare for speaking and how freeing the new approach was. He concludes with a discussion on the science and study of what happiness means and the frameworks of happiness.

I would summarize the entire book into one main theme: Do what you are passionate about, embrace your passions, and share them with others, focusing, in all you do, to make others happy in every opportunity, using all your skills, experiences and passions.

Remember to post a comment on any of my Zappos posts to be entered to win a free copy of the book. I’ll name the winner on Monday. You could share an idea, ask a question, share a related quote or experience as well.

Update:I’ll be shipping a copy of Delivering Happiness to the winner of the free book, Amber Weinberg. Thanks for reading Amber!

Life isn’t about finding yourself. Life is about creating yourself. ~ George Bernard Shaw

It is amazing what you can accomplish if you do not care who gets the credit. ~ H.S. Truman

We either make ourselves miserable or we make ourselves strong. The amount of work is the same. ~ Carlos Castaneda

What lies behind us and what lies before us are tiny matters compared to what lies within us.~ Ralph Waldo Emerson

I recently received this question about the Agile method of developing software and thought I’d share it and my answer.

Q. I am doing some research on agile methods, and wanted to know what you think about the use and application of agile methods? Will they continue to be used more in the next decade in internet software development? And what agile methods do you use?

A. Many startups have been using a more “agile” project management methodology without really knowing it. It’s the formalness of the “official” Agile and Scrum practices that are gaining in adoption now. As to if that official set of rules will stay around for a long time it’s impossible to predict, but judging from history, I think certain exact sets of guidelines come and go in popularity. The principles behind what is considered Agile however, I believe will last a long time. Many of us have seen the failure of planning out year long projects, holding daily hours long meetings to discuss statuses, and building 100 page analysis documents before anything is ever built.

Small, lean, flexible teams, working on shorter production cycles will always produce better software than rigid, bloated teams working on long drawn out project timelines. But most teams will do so without ever getting certified as a Scrum master or some official title for following some group’s rules as to how to manage a project. They do it because they observe the failures of the opposite through experience, particularly if they ever worked in a large corporation and had to follow the time wasting mess of project management that typically emanates from such places.

For me, following rules for how a project should go is not agile enough in itself. Guidelines are great, and I recommend understanding the Agile method so you can learn from it’s principles, but true agility comes from fitting the process to the specific team and project at hand. So I recommend never becoming allegiant to a certain methodology of project management, nor even to a certain development process. Use them as guidelines, but adapt them to your specifics and let them grow with you as you learn and experience more. Ensure the team shares in the understanding of why the agile process is better versus things like the water fall approach. Once they do, wether you stick to the Agile Manifesto or not will not be the significant deciding factor in the efficiency of your software development. It’s the underlying principles that matter, and those I believe will be with us for a long time.

For years I’ve questioned the stubbornness with which companies cling to the Industrial Age’s workplace environment and management strategies. In an age of new technology, new work skills, and a new desire by employees for an opportunity to go beyond being simple workers, to creative influences with input and ownership of their projects, so many companies and managers continue to treat their employees like expendable resources that can be burned down to ash and simply replaced with a new job posting. As well, work environments are stale, don’t inspire creativity, and fail to treat the workers as responsible adults (which, by the way, inspires them to trust you and perform at a higher level).

Two articles were published this week on these topics. First, from Robert Dempsey of Rails for All and Atlantic Dominion Solutions, with his article The Changing Role of Managers, in which he discusses how his role as Project Manager has evolved through trial and error, and describes his main role as PM with these words:

The main role of the scrum master [project manager] is to remove impediments that hold back the development team from being productive. Impediments might be lack of tools or clients taking a long time to respond. The scrum master also ensures that there is as little outside interference as possible.

He goes on to say that the manager’s role is that of leader, and that trust is a major element in team success. He provides a list of books he read as well on the topic.

In the second article, from Jason at 37signals, titled, Workplace Experiments, he discusses some of the new benefits they are experimenting with to keep their team fresh and happy, and thus in the end, far more productive than the teams that work away their lives (not to mention cutting down on the high hidden cost of employee turnover). 37signals is experimenting with:

• four day work weeks
• helping pay for their employees to learn new things and expand themselves; everything from learning to fly to learning to cook
• credit cards for discretionary spending (books, conferences, software)

Not all experiments may work, nor be affordable forever, but I loudly applaud the effort to shake things up, treat the employees like you really value, respect and trust them, and make an effort to look for new ways to enrich their lives and help them fulfill their passions.

Remember:

How we spend our days is, of course, how we spend our lives.
~ Annie Dillard

My favorite web development company, 37 Signals, recently added a post by one of their team members, Jason. He discussed some of the decisions and process that went into a recent functionality addition to their product Highrise. They set out to provide import functionality that their customers were asking for, but in their pursuit of a solution they got off track due to thinking too large.

Sometimes development and design teams can think too small, and not see the forest through the trees, but at other times, and I see this a lot in the IT industry, development teams think way too big. They see a problem and instead of focusing on the important issue, they attempt to provide functionality just in case they might need it some time down the road. But just in case development is very costly, and from my experience, most times that “case” never actually occurs.

The point of Jason’s post is that in this instance, not only did they waste time, but they also didn’t even provide the needed functionality, because they lost focus on the particular problem that really needed the must urgent solution.

In Jason’s words:

…don’t lump a bunch of related small problems together—it just makes one big problem. One big problem requires one big solution, and big solutions take a long time (and often don’t go right). You’re better off chopping big lumps of problems into smaller chunks until you’re able to knock them off one at a time.

Read the entire post, “Design Decisions: Highrise import“.

Recently, Matt at 37signals wrote a post about taking a break from your programming task after four hours.

The comments of the post took a detour from the main point, which was to stop and take a look at the task and your direction with it. However, most of the comments seemed to focus on taking a break when you are stuck. It’s true if you hit a wall, you should take a walk and try to get some distance from the problem. You’ll often then be able to see over or around the wall, or realize the wall is actually only a figment of your imagination.

But I think the point to this post was to take a break from your task, after you’ve spent about four hours on it (though the time should be in relation to the size of the task), and reassess your current status and direction, and most importantly, if the task should even continue to be done.

Sometimes we think of a solution, but while working on it we hit road blocks; things that we weren’t aware would be a problem. An example might be using a new technology we thought would solve the problem, but in doing so we introduced new problems. As programmers, as thus problem solvers, we get so focused on solving the problem at hand, we need to take a step back and realize that the direction we are going is more work than our nifty solution was worth. Adding this new technology, for example, might turn out to add far too much complexity, and require too many other solutions to get it to work.

There may be times where, after taking a break and re-evaluating, we have to go back to the Project Manager, Team Leader, or whomever you report to, and let them know the task is not nearly as simple as you thought, and more time needs to be allotted. After reporting this, you may find that the task you are assigned to is no longer quite so important to management, knowing it will cost them more.

I’d like to add, that taking breaks from tasks, and taking time to clear the mind, and step away, is such a vital part of being a problem solver, and yet it is discouraged by the very nature of the 8 hour work day modern IT management stubbornly continues to conform to. My personal belief, is that some days should be 5 hour work days, and others might be 10. Or, you may work four hours in the morning, and four in the evening. We need to be free to stop what we are doing when it becomes clear that we are no longer making progress for whatever reason. We could be tired, we could have hit an unexpected wall, we could have a personal issue that is distracting us. In many of these cases, its much more efficient to stop, and do something entirely different and come back to your work later, than to attempt to press through, and possibly waste countless hours making absolutely no progress.

This requires management to assess your effectiveness by what you accomplish on the project and with the team, as opposed to what hours you are sitting in front of your computer monitor. For some reason that shift in people management has been very slow in coming. I know some companies, teams, and managers that understand it, but I think the majority are still far behind; still stuck in the industrial age of management styles.

Read the entire 37signals article, “Four hours upfront and then reevaluate“.