I recently read the book: “Super-Flexibility for the Knowledge Enterprises” by Homa Bahrami and Stuart Evans. It discusses the concept of a knowledge enterprise being super-flexible to harness the inevitable uncertainty. This is highly applicable to start-ups that have to go through uncertain periods as well as to any organization being affected by the current economic environment.

The book is not an easy read, and it does not provide prescriptive actions similar to 10 steps to building your start-up. However, it has a lot of insights that you would be able to apply, if you read carefully with your organization in mind.

Follow me on Twitter

How to hire good software engineers, is a problem which I have had to face for a long time. How can you really gauge the ability of a candidate during an interview? This is further made difficult by the fact that there are no standard requirements to be met for a software engineer. Anyone who could learn a programming language and do a bit of programming can call (and they do) himself or herself a software engineer.

A few months ago, I read the book: Peopleware, Productive Projects and Teams by Tom DeMarco and Timothy Lister. In Chapter 15, the authors draw an analogy between hiring a juggler for a circus and hiring an engineer or designer. No one would hire a juggler based only on an interview without seeing him perform. The same should be applicable to engineers. Yet how many engineers (in our case software engineers) are hired based only on an interview?

In the past, I have suffered due to bad hiring decisions at interviews. In order to prevent this, recently we decided to make it mandatory for the each candidate to go through a pre-interview test that consists of an exercise to write working code on a computer to solve a given problem, and to come up with designs on paper for a few given software problems. Today’s the first time we tried it. So far two candidates have taken the test, and we can already see that it gives us much more information about their skills than an interview.

I am getting closer to the end of the book: “Dreaming in Code”. Chapter 11 is titled “The Road to Dogfood”. Eat you own dogfood is a concept that recommends using your own products. Chandler team had taken more than three years before they had a product that could be shipped or at least could be used internally. In my view, they were too ambitious in trying to ship a great product in the first attempt.

This reminds me of the commencement speech made by Guy Kawasaki at the Carnegie Mellon Silicon Valley graduation last summer. One of his advice was “Don’t worry be Crappy”. The following is taken from his blog:

An innovator doesn’t worry about shipping an innovative product with elements of crappiness if it’s truly innovative. The first permutation of a innovation is seldom perfect–Macintosh, for example, didn’t have software (thanks to me), a hard disk (it wouldn’t matter with no software anyway), slots, and color. If a company waits–for example, the engineers convince management to add more features–until everything is perfect, it will never ship, and the market will pass it by. - Guy Kawasaki.

On hindsight, a similar vision coupled with an agile development methodology would have helped Chandler. An agile methodology like Scrum or Exreme Programming would have made the team focus on releasing the most essential features of the product early without waiting for all the functionalities to be in the product. This would have been ideal for Chandler as its vision was only defined at a very high level. Early releases of a usable system with less features would have expedited the process of fixing bugs as well as enabled the feature definitions to take shape with more early feedback from the user community.