Guy Kawasaki’s Engineer Lies

by Krishna on August 26, 2009

Guy Kawasaki had a series of posts where he called out various types of people (venture capitalists, engineers, marketers, etc.) on untrue things that they are used to saying. There are situations when using a tough word is appropriate, but this is one case where Kawasaki is just wrong. Most people are truthful most of the time. Good business sense demands that you trust them, because if you are always watching out for lies from people, you are in deep trouble.

Now I understand the possible Digg-bait nature of the title. Also perhaps, one may give Kawasaki the benefit of the doubt in that he was talking about “white lies” and attributing incompetence rather than malevolence to each category of people. And that seems to be the case with the set of engineer lies, where Kawasaki says that he has a soft spot for engineers, but you shouldn’t really take them at their word.

I find the list a bit disturbing because it is a clear case of management divorced from what is happening in engineering. Every project requires good project management, otherwise it will only end in problem-hiding and finger-pointing. It is not about assigning a *project manager*, but whether the team has a grasp on the what, when and how of the project at all times.

Let’s take each of the points Kawasaki mentions (Do read the entire post so that you understand his argument):

  1. We’re about to go into final testing: If this is a lie, it means that there was no project plan. It also means that there were no regular project releases so that incremental testing could be done and pertinent user feedback rolled back into the product.
  2. Even my mother can use it: That is why you need testing by end users, as early in the project as possible. And it can be done on the cheap too.
  3. Our beta sites really love the product: If this is a lie, you need to choose a better set of beta sites and people to test the product, and find a better way of getting honest feedback. Whether users will pay for the software is directly related to how much they love the product. How you make money off it is a question for the business owner and the marketing/sales folks, not the developer of your organization.
  4. We’d save time if we’d just start the whole project over from scratch: This is probably true in some cases, but the most relevant point is that you have an engineer with the wrong skills. Usually, the engineer who said this does not have an idea of the technology, language or framework used and they express this sentiment because they would be more productive in their specialized environment. Spend time and money to find someone who has worked in the same environment. And if you find such a person and they still say the same thing, then your existing code base really sucks and you probably should start the whole project over from scratch.
  5. This time we got it right: I am puzzled why Kawasaki thinks this is a problem. If this is a lie, you have serious trust issues with the engineer.
  6. It works on my computer: OK, I grant this. I will probably write a longer post about this point, but it is a more complicated issue than it seems at first glance. The application probably works fine on more than “one computer in the world” and the developer is tired after being through many situations where the user has failed to follow some simple explicitly-stated instructions. One solution is to have customer support people field the calls from non-computer-savvy people first and let through only complex issues to developers.
  7. We have great testers and a great bug-tracking system: I suppose this lie is coming from an engineer at a startup hyping stuff to an entrepreneur, because I cannot see that happening inside a company. I would hardly think that this is a common lie even in that situation, but Kawasaki should know better with his experience in dealing with startups. In any case, once again, you need to have testing early in the game, and by testers who are independent of the developers. I believe the technical term is “due diligence”.
  8. I don’t know much about sales or marketing: I don’t know what point Kawasaki is trying to make here, but why would you care whether your engineer thinks sales and marketing are easy? I see jokes all the time about programmers and managers, but that doesn’t prevent them from doing their jobs.
  9. What I’m doing is scalable: If the engineer is clearly junior and incompetent to answer this question, why was it asked in the first place?
  10. This will take five minutes to fix: I grant this too. But this will only be a problem if you don’t have a good testing regiment. If you have frequent builds and you have a well-defined build-test-release cycle, you won’t get this answer.

Most of these “lies” seem to stem from lack of proper testing. If you release frequently and have independent testers, things will usually not get to the stage where management loses trust in the engineers. On the contrary, it will build confidence as new features are rolled out and the system becomes more stable as bugs are fixed. A regularly updated plan would also be good.

Comments on this entry are closed.

Previous post:

Next post: