Tag Archives: Good to Great

Audio Book Recommendations

Posted on by
Reply

I make use of my commute time to listen to podcasts and audio books from audible.com. A coworker recently asked me about my favorite titles. Here are some of my favorites that would be of interest to software professionals.

Developing Software

The Lean Startup by Eric Ries: This is a fantastic book about how to develop a product in a lean/agile manner. Ries’s description of the build-test-learn loop is worth the price of the book.

 

Rework by Jason Fried and David Heinemeier Hansson: I found some interesting stuff here from the 37signals guys. My biggest complaint about this book is that the authors are way to quick to assume that all of their success is due to the choices they made. Just because they did something and had some success with it does not mean that the success was caused by the particular behavior in question.

Product Management

The Innovator’s Dilemma by Nathan Christensen: Christensen describes how disruptive technologies overthrow established technology when those incumbents believe they are least vulnerable to such a disruption.

The Innovator’s Solution by Nathan Christensen: Christensen continues where he left off. Another must-read for anyone who manages a technology product or company.

 

The Design of Everyday Things by Donald Norman: Norman wrote this back in 1988 (and you can tell), but it is an enduring classic and a product management must-read for good reason. A surprisingly fun listen.

General/Management

Good to Great by Jim Collins: This is one of my favorite books of all time in any category. Collins describes the common attributes his research team found behind successful company leaders. I found the book to be quite inspiring and have made the attributes of leadership Collins describes personal goals for my own leadership.

Leading Change by John Kotter: Kotter describes eight steps to successful organizational change. I’ve seen these principles play out in commercial and social settings—sometimes where the leaders follow these steps and create effective change, but more often where they did not and the change efforts failed.

The Goal by Eli Goldratt: I first read The Goal in the late 1980s as an Industrial Engineering student. It is a good read and helps to clarify the folly of local optimization–in manufacturing or any complex system. This has become a favorite of proponents of Lean Software Development.

There are many more audio books that have really enjoyed, but I’ll save those for another day.

First Who… Then What

Posted on by
Reply

One of the first things I’ve been occupied with on the new job is interview candidates for software development openings we have. In recent years, I’ve been drawn more and more to get involved in the hiring process. I believe there is no more critical, leveraged action you can take toward making a software company successful than finding and hiring the right people. Having the right people is more important than programming language, platform, or methodology. The best people will overcome poor technology choices. The wrong people will eventually fail no matter what technological advantages they have.

In Good to Great, Jim Collins lays out a principle he calls “First who… then what.”

Executives who ignited transformations from good to great did not first figure out where to drive the bus and then get people to take it there. No, they first got the right people on the bus (and the wrong people off the bus) and then figured out where to drive it. They said, in essence, “Look, I don’t really know where we should take this bus. But I know this much: If we get the right people on the bus, the right people in the right seats, and the wrong people off the bus, then we’ll figure out how to take it someplace great.”

To a large extent, I think it is the same way with software. Assemble a great team, then decide what to create. In the world of commercial software, it rarely works quite that way. There is almost always a product in mind before the team is assembled. So, it’s not feasible to get the right team, then decide what to build, but it is realistic to get the right team in place, then decide how to build it. The how is always what separates good software from bad anyway.

As I’ve been immersed back into the hiring mindset, I continue to be struck by how many people who make their living developing software are so weakly grounded in the fundamentals. More on that later…