If I were to run a software startup, I’d require every new hire spend the first week doing nothing but read everything he wrote. Then whenever he makes a new post, the whole company takes a break to discuss it.
I started to read his new posts sometime last year, and lately got some free time to read from the beginning. The sad thing is that his 2000 posts are all so relevant to my last job, which I started in January 2001 and ended after close to 5 years of struggle. If only someone told me about Joel…
It’s superfluous to say that I like his writing as well, especially when he puts a one-line paragraph between two long paragraphs, or says “Where was I” after a long digression. Great pace. Normal man.
At Microsoft, if you’re the Program Manager working on the Excel macro strategy, even if you’ve been at the company for less than six months, it doesn’t matter – you are the GOD of the Excel macro strategy, and nobody, not even employee number 6, is allowed to get in your way. Period.
This sends a really strong message. For one, it makes everyone that much more conscientious about their jobs. They can’t hide behind the idea that “management approved their spec,” since management really didn’t look too closely at their spec. All management did was hire smart people and gave them something to do. For another, it makes for an extremely nice place to work. Who doesn’t want to be king of their own domain? Software, by its nature, is very easy to divide into smaller and smaller components, so it’s always possible to divide up responsibility among people and let people own an area. This is probably THE reason why software people love working at Microsoft.
The goal of your software company is not to solve some specific problem, but to be able to convert money to code through programmers. That’s a little bit strange, but bear with me. A software company has to think of recruiting the right people as its number one problem. If you are successful, this can solve any other problem. Hire smart people, and they will produce good stuff that you can sell and make money off. Then everything else follows.
One of the most important things that made Microsoft successful was Bill Gates’ devotion to hiring the best people. If you hire all A people, he said, they’ll also hire A people. But if you hire B people, they’ll hire the C people and then it’s all over.
Nobody at Juno owned anything, they just worked on it, and different layers of management happily stuck their finger into every pie, giving orders left and right in a style which I started calling hit and run management because managers tended to pop up unannounced, give some silly order for exactly how they wanted something done, dammit, without giving any thought to the matter, and leave the room for everyone else to pick up the pieces.
Hit and run management is but one symptom of what I would call Command and Control Management… something right out of the General Motors 1953 operations manual. In a particularly political company, it even becomes worse — more like Command and Conquer management. It’s completely inappropriate because it makes people unhappy, it causes the person with the least information to make the decisions, and it doesn’t allow a corporation to take advantage of all the talents of the people it hired.
When is Command and Conquer management acceptable? Well, it might work where your company is a Herd of Coconuts — a bunch of underqualified morons who need herding.
Probably the worst thing you can do is to decide that you have to be an Amazon company, and then act like a Ben and Jerry’s company (while in denial all the time).
1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?
- The most important function of a spec is to design the program.
- Giant reason number two is to save time communicating (among all departments).
- Without a detailed spec, it’s impossible to make a schedule.
Program manager’s role:
- Gather requirements, figure out what the code is supposed to do, and write the specs. There are usually about 5 programmers for every program manager.
- Coordinate marketing, documentation, testing, localization, and all the other annoying details that programmers shouldn’t spend time on.
- Have the “big picture” of the company in mind, while programmers are free to concentrate on getting their bits of code exactly right.
Things to avoid:
- Don’t promote a coder to be a program manager: a good coder is rarely good in writing clear English, diplomacy, market awareness, user empathy, and good UI design.
- Don’t let the marketing people be program managers. All program managers need to be very technical. They need to get along with a wide variety of people.
- Don’t have coders report to the program manager, so that the spec has to be convincing, not forceful.
How to write a spec that others like to read:
- Be funny. e.g. be overly specific.
- Make it understandable by human, not as if writing code.
- Be simple: use simple words, short sentences, avoid full page of text, use pictures.
- Do NOT use template: over normalization, daunting to write/read, no fun
Man it’s tiresome to copy things like this, plus Joel specifically forbids excessive quotes. So from now on only, er, excessive quotes without the original article links.
Beware of Methodologies. They are a great way to bring everyone up to a dismal, but passable, level of performance, but at the same time, they are aggravating to more talented people who chafe at the restrictions that are placed on them.
Never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done.
80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. Unfortunately, it’s never the same 20%. Everybody uses a different set of features.
It’s very hard to get them (Architecture Astronauts) to write code or design programs, because they won’t stop thinking about Architecture. They’re astronauts because they are above the oxygen level, I don’t know how they’re breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line. … Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve.
We’ll focus on improving our product, and we’ll focus on staying in business, by listening to our customers and eating our own dog food (use our own product).
Make a ten year plan. Make sure you can survive for 10 years, because the software products that bring in a billion dollars a year all took that long. Don’t get too hung up on your version 1 and don’t think, for a minute, that you have any hope of reaching large markets with your first version. Good software, like wine, takes time.
If it’s a core business function — do it yourself, no matter what. The only exception to this rule, I suspect, is if your own people are more incompetent than everyone else, so whenever you try to do anything in house, it’s botched up.
Getting Things Done When You’re Only a Grunt:
- Just Do It (yourself)
- Harness the Power of Viral Marketing (show people how good it is)
- Create a Pocket of Excellence
- Neutralize The Bozos (give them something busy themselves with so they can’t bother/mess with you)
- Get Away From Interruptions
- Become Invaluable
In infantry battles there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can’t fire at you. For small companies like mine, it means two things. You have to have time on your side, and you have to move forward every day. Sooner or later you will win.
For most software, there’s a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers. The secret is that People Who Aren’t Programmers Do Not Understand This. Corollary:
- If you show a nonprogrammer a screen which has a user interface that is 90% worse, they will think that the program is 90% worse.
- If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.
- The dotcom that has the cool, polished looking web site and about four web pages will get a higher valuation than the highly functional dotcom with 3700 years of archives and a default grey background.
- When politics demands that various nontechnical managers or customers “sign off” on a project, give them several versions of the graphic design to choose from.
- When you’re showing off, the only thing that matters is the screen shot. Make it 100% beautiful.
Product vision statement should have:
* For (target customer)
* Who (statement of the need or opportunity)
* The (product name) is a (product category)
* That (key benefit, compelling reason to buy)
* Unlike (primary competitive alternative)
* Our product (statement of primary differentiation)
Design-the-Box: the entire team, including users, breaks up into groups of four to six (this works best with cross-functional participation). The team makes the assumption that the product will be sold in a shrink-wrapped box, and their task is to design the product box front and back. This involves coming up with a product name, a graphic, three to four key bullet points on the front to “sell” the product, a detailed feature description on the back, and operating requirements.
All else being equal, demand for a product increases when the prices of its complements decrease. Smart companies try to commoditize their products’ complements. If you can do this, demand for your product will increase and you will be able to charge more and make more.
All non-trivial abstractions, to some degree, are leaky.
Revenue, # employees, PR, and code quality (product quality?) should grow together following relatively the same curve.
Software pricing: segmentation (charging different people with different prices) can maximize profit, but angers users and can be easily cheated. Site license (unlimited use) forgoes consumer surplus at large companies. Salesman pricing (no show until you call) can be cheated. Low price suggests low quality. Not a clue in the end.