Tag Archives: Paul Graham

Don’t Ignore Customer Complaints

I find Paul Graham’s ideas very useful. I disagree with his recent tweet though.

tweets from Paul Graham

Update: See note at bottom of the post – Paul tweeted that his original tweet was wrong.

Base your assessment of the merit of an idea on the actual merit of the idea, not the category you place the person in that is expressing the idea.

His reply tweet addresses the problem with the first one in a very specific case. But you have “bugs” that are part of your management system, “policies,” products or services. Few customers will bother to voice those problems. Rather than ignoring some of what you hear, you should evaluate the merit of the complaint.

If the complaint is not something that should be addressed or explored fine. But that has nothing to do with the category of the person (“complainer” or not); it has to do with the merit of the complaint.

I understand some people are annoying because they make lots of meritless complaints. Ignoring the meritless complaints is fine with me. But just as I think ignoring advice because the person giving the advice doesn’t follow it is a bad practice I think having a policy of basing decisions on something other than the merit of the complaint/suggestion is unwise.

This is especially true since organizations on the whole do a lousy job of listening to customers and understanding customer desires. We need to greatly enhance the practice of customer focus not seek to reduce it. Every organization is unique, however, and if customer focus is exceptionally great, I can understand the idea of the tweet: that we are devoted to customer focus and each new insight, but we have taken it too far and need to discriminate better. I still think discriminating based on the merit of the complaint is a better than doing so based on our categorization of the complainer but in that case (which is very rare in organizations) the advice isn’t nearly as bad as it is for most organizations.

Continue reading

Interruptions Can Severely Damage Performance

Interruptions can severely degrade your performance. The type of work you are doing impacts the cost greatly. I have spent some of my time programming web applications. When I am doing that interruptions are huge drain on my performance (for me the costs of interruptions while programming are far higher than any other type of work I have done – many times higher). If the interruption disrupts my flow (an interruption needn’t necessarily disrupt it I found, instant messages may not, while speaking to someone else almost surely would – it is a factor of how much of your brain much shift focus I imagine) it can take a huge amount of time to get back into a high performing state. Other work I do can be interrupted with much less impact. I am easily able to slip back into what I was doing.

For me the main cost of interruptions is the time it takes to get back to where I was before the interruption. And the cost is related to how much focus is needed to address what you are working on. Most programming takes a huge amount of focus.

Another big cost of interruptions is the increased risk of mistakes. When people are distracted and then have to go back to a task, and then are distracted, and then go back and… it is more likely they will miss a step or miss noticing some issue than if they can work without distraction. One tool to help cope for distractions that can’t be designed out are checklists.

Paul Graham addressed the importance of managing the system to provide uninterrupted time very well in, Maker’s Schedule, Manager’s Schedule

One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

Paul Graham’s article also shows why managers so often fail to adequately address this issue. Manager, by and large, work in an environment where interruptions are the work. I know, much of my time as a program manager is driven by interruptions and is doable even with many interruption every day.

When managing you need to understand how big a cost interruptions have and design systems appropriate to optimize system performance for all parts of the system. The design of the system needs to take into account the costs and benefits of interruptions for those people working on various processes in the system.

Related: Understanding How to Manage GeeksExplaining Managers to ProgrammersWhat Motivates Programmers?Joy in Work – Software DevelopmentProgrammers CartoonChecklists in Software Development

Some Good IT Business Ideas

Paul Graham has some excellent ideas. I have written about some of them previously: Innovation Strategy, What Business Can Learn from Open Source and Google and Paul Graham’s Latest Essay. Y Combinator, which he founded, provides seed funding. Here are some ideas they would like to fund:

Outsourced IT. In most companies the IT department is an expensive bottleneck. Getting them to make you a simple web form could take months. Enter Wufoo. Now if the marketing department wants to put a form on the web, they can do it themselves in 5 minutes. You can take practically anything users still depend on IT departments for and base a startup on it, and you will have the enormous force of their present dissatisfaction pushing you forward.

Online learning. US schools are often bad. A lot of parents realize it, and would be interested in ways for their kids to learn more. Till recently, schools, like newspapers, had geographical monopolies. But the web changes that. How can you teach kids now that you can reach them through the web? The possible answers are a lot more interesting than just putting books online.

Off the shelf security. Services like ADT charge a fortune. Now that houses and their owners are both connected to networks practically all the time, a startup could stitch together alternatives out of cheap, existing hardware and services.

Related: Our Policy is to Stick Our Heads in the SandFind Joy and Success in BusinessInnovative Thinking from Clayton Christensen

Innovation Strategy

Six Principles for Making New Things by Paul Graham

The answer, I realized, is that my m.o. for all four has been the same. Here it is: I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly.

Great advice. Similar to the evidence Clayton Christensen documents in the Innovators Solution on how to innovate successfully. New products and services often start out simple and limited and often are dismissed as unacceptable in various ways. But they solve a real problem and over time are improved and grow market share.

Experimenting quickly and often (iteration) is extremely important and given far to little focus. The PDSA improvement cycle provides a tool to encourage such thinking but still few organizations practice rapid iteration.

Related: Deming on InnovationWhat Job Does Your Product Do?Innovation at GoogleExperiment and Learnmore posts related to Paul Graham
Continue reading

Google and Paul Graham’s Latest Essay

I like Google and enjoy reading about the company. Even so I find the number of articles about the minor moves they make strange. At some point this fascination with the minor moves Google makes will stop but for now it is hard to miss stories about Google anywhere I look.

The post on John Battelle’s Searchblog (a great bog) about Google buying Dodgeball was a great example. The entire post:

News is here. What is Dodgeball? I dunno, but is seems like Orkut + Mobile done right, I think. More later.

From the Dodgeball company web site:

As a two-person team, Alex and I have taken dodgeball about a far as we can alone. Since we finished grad school, we’ve been trying to figure out how to grow dodgeball and make it a better service along the way. We talked to a lot of different angel investors and venture capitalists, but no one really “got” what we were doing – that is until we met Google.

Today I read a new article from Paul Graham (his website has great essays – highly recommended): Hiring is Obsolete. As usual he makes many great points in the essay. The point that most strongly connected with me today was his statement:
Continue reading