Прощай, оружие

Joel Spolsky говорит goodbye блоггингу:

What we need now, I feel, is not another essay repeating No Silver Bullet for the 18,000th time. We need something that is more objective (based on measurable truth and falseness rather than just lists of anecdotes about successful projects and failed projects). We need something that reflects the best new ideas about what authorship means in 2010, not just electronic forms of 18th-century pamphlets. We need to stop rewriting the same things again and again (fail fast! NDAs are worthless! Execution matters, not ideas! Use the right tools for the job!). Instead we should start filling in the long tail of knowledge.

---

Although I appreciate that many people find Twitter to be valuable, I find it a truly awful way to exchange thoughts and ideas. It creates a mentally stunted world in which the most complicated thought you can think is one sentence long. It's a cacophony of people shouting their thoughts into the abyss without listening to what anyone else is saying. Logging on gives you a page full of little hand grenades: impossible-to-understand, context-free sentences that take five minutes of research to unravel and which then turn out to be stupid, irrelevant, or pertaining to the television series Battlestar Galactica.

(in toto)

Обратить внимание: Mercurial, опен-сорсовый контроль версий, к которому Джоэль пишет туториал.

Joel Spolsky — Why testers?

{...} A great tester gives programmers immediate feedback on what they did right and what they did wrong. Believe it or not, one of the most valuable features of a tester is providing positive reinforcement. There is no better way to improve a programmer's morale, happiness, and subjective sense of well-being than a La Marzocco Linea espresso machine to have dedicated testers who get frequent releases from the developers, try them out, and give negative and positive feedback. Otherwise it's depressing to be a programmer. Here I am, typing away, writing all this awesome code, and nobody cares. Boo hoo.

---

Signs of a good tester:

• Scientific
• Loves a good puzzle, even the kind that takes days to solve
• Likes to think about things methodically
• Generally likes working with software and computers

...tester {...} who write automated test suites {...} reflects a misunderstanding of what testers are supposed to do, which is evaluate new code, find the good things, find the bad things, and give positive and negative reinforcement to the developers. Sure, automated test suites are a time saver, but testing software covers so much more than that. If you put too much emphasis on those scripts, you won't notice misaligned text, hostile user interfaces, bad color choices, and inconsistency. Worse, you'll have a culture of testers frantically working to get their own code working, which crowds out what you need them to do: evaluate someone else's code.

(in toto)

Joel Spolsky — When and How to Micromanage

  “Managers today are taught not to micromanage their employees. But there comes a time in every business when you need to step in and master the details.”

  “Five Whys is a problem-solving technique developed by Toyota after World War II to improve its manufacturing process. The idea is to ask "Why?" five times to get to the root of any failure, so you fix the core problem instead of the symptoms.”

---

  “Isn't today's modern leader supposed to hire brilliant people, give them a little direction, and just let them go to work? Doesn't micromanagement turn smart people into robots?
   Yes, maybe. But here's my new theory: At the top of every company, there's at least one person who really cares and really wants the product and the customer experience to be great. That's you, and me, and Ryan. Below that person, there are layers of people, many of whom are equally dedicated and equally talented.
   But at some point as you work your way through an organization, you find pockets of people who don't care that much. For them, it's a job. They just want to get through the day and don't find it upsetting that ... If you're lucky, none of those people are employed by your company. But the minute you begin to rely on outside vendors, you expose yourself to their people, some of whom inevitably just won't care enough or know enough or have the right skills to deliver the awesome experience you're trying to deliver.”

  “The minute you cross that line, from the people who care to the people who want to go home, that's when you have to micromanage.”

  “You know what? Getting good Wi-Fi in a room with hundreds of laptops is very, very difficult. Usually, it takes a couple of weeks of preparation, specialized equipment, and two or three dedicated technicians who have extensive experience in this exact problem. Almost nobody knows how to do it. ...”

(in toto)

Joel Spolsky — The Day My Industry Died

  “My theory was that if I could start a company and be only partially incompetent instead of entirely incompetent, I would be ahead of the game.”

  “So this was my business plan: We'd start out as a plain-vanilla Web consulting business. We'd look for situations in which we had several clients asking for the same basic thing. Then, using consultants who weren't currently working on gigs, we'd build an application to suit the group's needs. Over time, this product could be licensed far and wide. Eventually, the software side of the business would eclipse the consulting side of the business. That was the theory. Sounds good, right?”

---

  “We were lucky. We started late, and we hadn't had a chance to hire very many people yet, so we didn't burn through cash as quickly as others. And we were fortunate enough to have a software product under development, so that when the Web consulting industry disappeared, we still had money coming in. Because if you can survive the death of your industry, well, you can survive just about anything.”

(in toto)

Joel Spolsky — Figuring out what your company is all about

What is your company about?

Recently I got inspired by Kathy Sierra, whose blog Creating Passionate Users and Head First series of books revolutionized developer education. She kept saying the same thing again and again: help your users be awesome.

---

Kathy taught me that if you can't explain your mission in the form, "We help $TYPE_OF_PERSON be awesome at $THING," you are not going to have passionate users. What's _your_ tagline? Can you fit it into that template?

(in toto)

Joel Spolsky — Capstone projects and time management

* It appears to be a permanent part of the human condition that long term deadlines without short term milestones are rarely met.

---

* It’s taken me a while, but I finally learned that long-term deadlines (or no deadlines at all) just don’t work with professional programmers, either: you need a schedule of regular, frequent deliverables to be productive over the long term. The only reason the real world gets this right where all-student college teams fail is because in the real world there are managers, who can set deadlines, which a team of students who are all peers can’t pull off.

(in toto)

Joel Spolsky — The Duct Tape Programmer

* Sometimes, you’re on a team, and you’re busy banging out the code, and somebody comes up to your desk, coffee mug in hand, and starts rattling on about how if you use multi-threaded COM apartments, your app will be 34% sparklier, and it’s not even that hard, because he’s written a bunch of templates, and all you have to do is multiply-inherit from 17 of his templates, each taking an average of 4 arguments, and you barely even have to write the body of the function. It’s just a gigantic list of multiple-inheritance from different classes and hey, presto, multi-apartment threaded COM. And your eyes are swimming, and you have no friggin’ idea what this frigtard is talking about, but he just won’t go away, and even if he does go away, he’s just going back into his office to write more of his clever classes constructed entirely from multiple inheritance from templates, without a single implementation body at all, and it’s going to crash like crazy and you’re going to get paged at night to come in and try to figure it out because he’ll be at some goddamn “Design Patterns” meetup.
   And the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”


* Zawinski:

“At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

   My hero.

---

* Zawinski didn’t do many unit tests. They

“sound great in principle. Given a leisurely development pace, that’s certainly the way to go. But when you’re looking at, ‘We’ve got to go from zero to done in six weeks,’ well, I can’t do that unless I cut something out. And what I’m going to cut out is the stuff that’s not absolutely critical. And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that.”

* Zawinski popularized Richard Gabriel’s precept of Worse is Better. A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature. A really important feature. Your product must have it.


* One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project. Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain.

(in toto)

Joel Spolsky — The eternal optimism of the Clear mind

Clear just closed down. {...} The actual business plan was that Clear would do detailed background checks on travellers, who would then be trusted to bypass security completely because they were extra-super-trustworthy.

Now, the TSA doesn’t even trust pilots, who go through the same screening as the rest of us to make sure they’re not bringing something extraordinarily dangerous onto a plane like a 3.5 oz bottle of shampoo. Because, of course, with a little bottle of shampoo, they could make a bomb, which they could use to fly the plane they are piloting into a building, something that is impossible for mere pilots sitting at the controls of the jet.

The environment changed. It turns out that Clear’s business model of prescreening wasn’t going to be possible. But they kept doing it anyway. What kind of organizational dysfunction does it take to completely ignore the changed circumstances and keep at a money-losing business?

---

What’s even funnier is that Clear could probably have been profitable if they had just skipped the one unnecessarily stupid part of their business model: the detailed background checks on all their customers.

Nobody at Clear did any thinking. They had a business model, the business model wasn’t actually possible, everybody knew it, and they still plugged away at it. Thoughtless optimism. I don’t know whether to salute ‘em or laugh.

(in toto)

Joel Spolsky — Platform vendors

When independent software developers create utilities, add-ons, or applications that fill a hole in their platform vendor’s offering, they like to think that they’re doing the vendor a huge favor. Oh, look, the iPhone doesn’t have cut and paste, they say. Business opportunity! They might imagine that this business will be around forever. Some of them even like to daydream about the platform vendor buying them up. Payday!

The trouble is ...

---

... that only a tiny percentage of iPhone users are going to pay for that little cut and paste application. With any kind of add-on, selling to 1% of the platform is a huge success.

Filling little gaps in another company’s product lineup is snatching nickels from the path of an oncoming steam roller.

(in toto)

Почему я никогда не обсуждаю повышение зарплаты

By Joel Spolsky

Что случится, если однажды вы придёте на работу, зайдёте на кухню и обнаружите листик, прикреплённый к холодильнику, и на этом листике будет список ваших сотрудников с указанием их зарплат? Взбеситесь? Не станете ли вы ожидать, что половина вашего персонала рыдает, в то время как вторая половина ждёт вас у дверей вашего кабинета с вилками наперевес?

Поскольку числится, что информация о доходах – штука чрезвычайно чувствительная, работники зачастую идут на всё, лишь бы удержать ее в секрете. Некоторые компании рассматривают обсуждение зарплаты сотрудниками в качестве предлога для увольнения, или же они добавляют в текст стандартного договора с сотрудником пункт, запрещающий ему разглашать подобную информацию. (Кстати, в Штатах, такое правило является сугубо добровольным, но некоторые боссы надеются, что их подчинённые этого не знают.) Вся тема про удержание в секрете информации о зарплате обычно используется для того, чтобы избежать честной оплаты труда работников. И это не есть хорошо ни для сотрудников, ни для самой компании.

---

Когда мы с моим партнером начинали Fog Creek Software, мы знали, что хотим создать такую сетку зарплат, которая была бы максимально объективной и прозрачной. Я исследовал различные системы [оплаты] {...}

Я запостил первый драфт в моем блоге и получил тонны замечательных откликов, которые я использовал при написании второго драфта. С тех пор основная система оплаты остаётся неизменной.

В системе оплаты Fog Creek каждый сотрудник получает свой уровень. В данный момент эти уровни начинаются с 8-го (для студента на летней практике) и заканчиваются 16-ым (для меня). Ваш уровень рассчитывается по формуле, основанной на трех параметрах: опыт, границы ответственности и набор скилов (умений / квалификаций / опыта). Как только ваш уровень определен, вы тут же начинаете получать столько же, сколько получаются ваши коллеги одного с вами уровня.

Часть, касающаяся опыта, очень проста: она основывается на количестве лет полной занятости в той области, в которой работаете. Работы, выполненные в школе, не засчитываются. Также определенные типы вспомогательных работ не могут быть засчитаны более чем за 1 год опыта работы. Например, если вы работали на приёме посетителей в течение 6 лет, вы получите лишь 1 год опыта за эти 6 лет.

Границы ответственности также достаточно простой для определения параметр. Для начала, помогаете ли вы кому-либо сделать его/ее работу? Есть ли у вас собственная область ответственности? Или же вы отвечаете за выпуск целого продукта? Границы ответственности для большинства должностей мы можем определить достаточно объективно.

Определение количества скилов чуточку сложнее, но нам все же удалось определить достаточно объективное множество наборов от программиста-новичка ("который осваивает основные принципы разработки ПО; работает под постоянным наблюдением; от которого не ожидают написания работающего кода") до эксперта-разработчика ("который последовательно добивается успеха во всех областях, участвуя в малых и крупных проектах, и который является неотъемлемой частью успеха этих проектов").

Поскольку мы определились с терминами, мы можем создать маленькую табличку, которая определяет уровень сотрудника на основе его опыта, скилов и уровня ответственности. Затем мы создаем еще одну табличку, в которой прописаны базовые зарплаты для каждого уровня. Вот так мы и вычисляем, сколько каждый из сотрудников зарабатывает.

Раз в год команда наших менеджеров усаживается поудобнее и обозревает работу каждого сотрудника и перерасчитывает его уровень. Затем мы смотрим, что делается у наших конкурентов на рынке, используя такие онлайновые инструменты, как сайты Salary.com и Glassdoor.com. Сюда же мы добавляем наши знания о рынке труда в течение последнего года рекрутирования новых сотрудников. И проверяем, что зарплаты, которые имеет каждый уровень, как раз такие, как нам и хотелось.

Поскольку на одном уровне все сотрудники получают одинаковую зарплату – без балды! – мы иногда оказываемся в затруднении. Одной из проблем нашей системы является ситуация, когда мы пытаемся взять на работу человека, который хотел бы договориться о более высокой зарплате. {...} Обычно мы гарантируем новичку больший бонус за первый год работы, чем он получил бы в общем случае. {...}

Наша система прошла тестирование на протяжении последних 8 лет, когда рынок труда был достаточно суров. Легко понять почему: предположим, вы наняли 100 водителей яков по цене $10 за час работы, но затем тибетская экономика пошла резко вверх, и стало затруднительно найти дополнительных водителей яков. Рыночная ставка могла вырасти до $15 за час. Малодушный начал бы нанимать новых работников по цене $15 за час и надеялся бы, что ведущие сотрудники его фирмы не обнаружат, что новобранцы получают больше, чем они.

На жаргоне много о себе думающих кадровиков это явление называется инверсия зарплат (salary inversion). Инверсия зарплат может привести к конфликтам внутри организации. Она также полностью деформирует взаимоотношения менеджеров, отдела кадров и сотрудников. Это может показаться смешным и выглядеть байкой, но я на самом деле однажды слышал историю про то, как менеджеры в одной крупной корпорации сказали своим ключевым подчиненным уволиться, а затем тут же подать заявки о приеме на работу на свои старые должности, потому что бюрократия сделала практически невозможным повышение им зарплаты до рыночного уровня. В Fog Creek мы решили, что правильным будет одновременное и одинаковое повышение зарплаты всем сотрудникам в периоды, когда рынок труда сильно сокращается. Это может оказаться болезненным и дорогим решением, но альтернативы такому шагу еще хуже. Не знаю, как вы, а я боюсь внезапных повышений.

Не могу гарантировать, что наша система удержится, если ситуация будет ухудшаться, но я достаточно уверен, что сотрудники вполне могут согласиться на незначительное снижение зарплаты в условиях, когда а) система оплаты будет оставаться прозрачной и честной, и б) всем будет ясно, что есть необходимость приспуститься с дерева.

В то же самое время, если вы слышите много жалоб по поводу зарплат, вы не должны смотреть только в сторону вашей системы оплаты. Из своего опыта я осознал одну вещь: счастливые, мотивированные сотрудники, которые делают любимую работу и чувствуют, что с ними обращаются, как со взрослыми людьми, не станут жаловаться на свою зарплату до тех пор, пока она не будет совсем уж нечестной. Если вы слышите много жалоб о зарплате, я подозреваю, что это, возможно, проявление гораздо большей проблемы: ваши служащие не получают достаточного удовлетворения от своей работы, или же они несчастны еще по каким-либо причинам.

Требуется очень большая зарплата, чтобы человек примирился с бессердечным боссом или с жалким рабочим местом. Чем регулировать оплату, вы могли бы сфокусироваться на каких-нибудь не денежных способах сделать своих подчиненных счастливее. Счастливые сотрудники делают лучшие продукты и лучше обслуживают ваших клиентов, в конечном итоге они делают вашу компанию успешной и прибыльной. В свою очередь, успех компании позволяет вам платить сотрудникам большую зарплату. Такой вот замкнутый круг, который работает у нас в Fog Creek.

Why I Never Let Employees Negotiate a Raise in toto

Бонус-трэк: Профессиональная лестница Fog Creek для практического использования.

Как быть программным менеджером

Хороший program manager — один из ингридиентов секретной формулы для создания действительно великого программного обеспечения. Вероятно, в вашей команде его нет. Потому что его нет в большинстве команд.

Чтобы работать program manager-ом не требуется быть ветераном с 14 годами опыта в программировании. На самом деле, с таким опытом вы знаете чересчур много, чтобы стать хорошим адвокатом для пользовательских запросов.

Большей частью, становление program manager-а проходит через изучение: изучение технологий, изучение людей и изучение того, как быть эффективным в политической организации. Хороший program manager сочетает в себе инженерный подход для проектирования технологии со способностями политика приходить к компромиссам и объединять людей вместе.

---

Program manager:
    1. проектирует UIs
    2. пишет функциональные спецификации
    3. координирует команды
    4. служит адвокатом пользователей и
    5. носит "бананы".

Хорошее правило: нужен один program manager для каждой четвёрки программистов. {...}

Моя работа (в качестве program manager) была не в том, чтобы решать проблемы, но в том, чтобы постичь, что нужно пользователям, и убедиться, что программисты нашли решение этих проблем.

Лучшие программисты печально известны тем, что не могут себе представить, как остальные люди не способны запомнить 16 однобуквенных опций командной строки. Эти программисты склонны приклеиваться к первой посетившей их идее, особенно, если они уже успели ее немного покодировать.

Одна из лучших вещей в работе program manager-а заключается в возможности высказать собственное мнение в процессе дизайна программного обеспечения относительно того, как вещи должны быть спроектированы.

Хороший program manager приходит со своими собственными идеями по поводу того, как должен работать пользовательский интерфейс, и эти идеи могут быть лучше, а могут быть и хуже, чем идеи разработчика. И тогда начинаются долгие споры. Обычно program manager хочет чего-нибудь простенького и лёгкого для понимания конечным пользователем. С использованием телепатии, 30-дюймового экрана, который тем не менее должен помещаться в кармане пользователя. В то время как разработчик стремится к чему-то, что достаточно просто закодировать, с интерфейсом командной строки ("не понимаю, что такого анюзибл в командной строке?!") и связыванием в стиле Python.

Для того, чтобы споры проводились вежливо и основывались на фактах, абсолютно необходимо, чтобы program manager-ы и разработчики были равны. Если разработчики должны отчитываться перед program manager-ом, то в какой-то момент дискуссии program manager-у она надоест и он просто скажет: "OK, хорош болтать. Сейчас мы сделаем это так, как я предложил".

Быть эффективным в роли program manager-а означает: (a) быть правым, и (b) заслужить уважение программистов, чтобы они могли признать вашу правоту.
Как заслужить это уважение?
Этому может помочь то обстоятельство, что будучи program manager-ом, вы еще и неплохо умеете кодировать сами. Да, это нечестно. От program manager-ов не ждут, что они будут писать код. Просто программисты скорее зауважают другого программиста, чем не-программиста, вне зависимости от того, насколько умны они сами.

Другой способ заслужить уважение команды программистов заключется в том, чтобы выказать интеллект, открытое мышление и справедливость в дискуссиях. Если program manager говорит тупые вещи, программисты начинают держать его за клоуна. Если program manager начинает лично или эмоционально относиться к тому, как делаются некоторые вещи, вплоть до того, что его мнение становится необсуждаемым, он рискует потерять доверие команды. Обе стороны, но program manager в особенности, должны избегать эмоций во время дискуссий и быть готовыми рассмотреть новые данные и изменить своё мнение, когда факты этого требуют. Наконец, если program manager замечен в политических играх, в приватных беседах с шефом или в попытках использовать прием "разделяй и властвуй", чтобы выиграть спор, вместо того, чтобы спорить по существу, такой program manager теряет существенную часть доверия программистов.

(у целом)

Joel Spolsky — How I Learned to Love Middle Managers

You have to be careful when it comes to embracing the latest business idea. A single anecdote filtered through the eyes of a journalist about a new cool philosophy for running a company has to be considered in the light of other evidence, such as the way thousands of other companies are set up and operate.

---

    Ten years ago, while I was working at Juno... I noticed too many situations in which members of top management happily issued an executive fiat even though they were the least qualified to make a decision. I'm not saying that they were stupid, mind you. Most of the managers at Juno were quite smart. But they had hired even smarter people to work for them: people with advanced degrees, raw intellectual firepower, and years of experience. And these people would work on a problem for a long time, come up with a pretty good solution, and then watch in surprise as their bosses overruled them. Executives who did not have specific technical knowledge and who had not studied a problem in depth would swoop down and issue some random, uninformed decree, and it would be implemented -- often with farcical results. ...

    ...my partner and I ... we wanted to hire great people and then get out of their way. My instinct to do away with middle management was further encouraged when I read an article in one of those glossy business magazines...

    And for a while, the Everybody Reports to Me system worked just fine. ... [But] last year, we began to realize that things had changed. ... Another programmer came to us and said bluntly "I thought you should know that people are really unhappy, and it's starting to make it so that people just complain all day, instead of doing their work, and that's not good."

    I spent a week having long talks with everyone and figuring out what was really going on. ...we appointed leaders for two of the programming teams -- in effect, creating that layer of hierarchy that I had tried to avoid.

    And frankly, people here seem to be happier with a little bit of middle management. Not middle management that's going to overrule the decisions they make on their own. Not symbolic middle management that only makes people feel important. But middle management that creates useful channels of communication. If my job is getting obstacles out of the way so my employees can get their work done, these managers exist so that, when an employee has a local problem, there's someone there, in the office next door, whom they can talk to.

    The lesson is, Don't believe everything you read in a business magazine. Not even this one.

(in toto)

Joel Spolsky — The Four Pillars of Organic Growth

    When you build a company, you have to choose between two very different ways of growing. Bootstrap: goal – to grow slowly, organically, steadily, and profitably. By contrast, a lot of the flashy companies, especially high-tech companies, believe in the "big bang" model, with very fast growth fueled by lots and lots of outside investment.

    In our case, we always wanted to be a software company, selling off-the-shelf software to thousands of customers at a low price. But that kind of company takes a while to get going--it takes years to write code and build a large customer base. ...

---

    Bootstrapped companies start on somebody's credit card. And in their early months and years, they do whatever it takes to break even, even if it means they have to take a few diversions along the way. ...

    When you bootstrap, things move very slowly and in sync. Your revenue grows only about as fast as you can hire skilled workers. The degree to which customers are aware of your business never outstrips the quality of the goods or services you are able to provide to them. ...

    One of the benefits of this model is that it's pretty cheap. According to the company history published on the website of Ben and Jerry's, the partners started with a $12,000 investment, in 1978. ...

    Compare our humble way of doing business with the approach of big-bang, high-burn-rate companies that raise money almost as quickly as anyone on their staffs can spend it. They are in a terrible rush. If they are in a new field with no competitors, they feel as if they are in a land grab and that they have to get big superfast. Every minute matters. And there are lots of fun ways to spend money to try to speed things up. Having trouble hiring quickly? Offer BMWs as starting bonuses.

    But in the rush to win a land grab, one thing that usually gets left behind is a company's culture. ... Ben and Jerry's exists because of the socially conscious values of its founders. Fog Creek Software exists because we believe in treating programmers well and developing friendly software using highly reliable engineering practices.

    If you raise capital and go for the big bang ... all sorts of growing pains will ensue. For example:
  1. Let's say revenue grows faster than the rate at which you can hire. The result: poor customer service. ...
  2. What if you hire employees faster than you can reasonably expect the quality of your product to improve? The result: New hires don't have a chance to learn the company culture and the founder's values from experienced hands, so the quality of work they do and the quality of service they provide are inferior. The fastest you should hire employees is the rate at which they can learn to do their jobs.
  3. And if PR grows faster than the quality of your product? Because you haven't worked out the kinks, a lot of people who are interested in your business become tire kickers rather than paying customers. Many of these customers will be permanently convinced that your product is simple and inadequate, even if you improve it drastically later on. I've taken to calling this the Marimba Phenomenon. ...

    It's even worse to get publicity before there's a product people can buy, because then, when the product really comes out, the news outlets don't want to do the story again. I call this the Segway Phenomenon...

    Let your reputation spread by word of mouth. Save your marketing dollars for when your company is mature and in a position to blow people away.

(in toto)

Joel Spolsky — A Real Cool Customer

  "Say, Joel, do you have any advice for start-ups?"
  "Yes! You should raise all your prices!"

    When I started the company, ... we would have a serious conversation about every expense. A hundred dollars was a lot. ... We ordered cheap, ugly business cards over the Internet. I designed the first logo myself. It consisted entirely of the name Fog Creek Software in lowercase letters and underlined like so: fog creek software. Did you catch the creative part? You see, the g isn't underlined! Think of all the money we saved on toner.

---

    ...almost every start-up I have ever seen has set its prices too low. Founders usually imagine that they are selling their wares to people more or less like themselves--which is to say, smart, discriminating consumers. But they would do well to remember that there is a stark difference between selling to consumers and selling to businesses. And if you ask me, all things being equal, start-ups should almost always opt to sell to other businesses.

    FogBugz is used to coordinate teams of developers, so the real audience is almost exclusively established businesses, rather than individuals like me or impoverished, bootstrapped start-ups. In fact, to corporate buyers, the higher the price, the more respectable FogBugz appeared to be.

    As the business grew, our definition of the word expensive began to change. Should we buy a $400 off-the-shelf firewall? If it saves a few hours of time, why not? Later on, when we were looking for a domain name for a new line of business, we splurged and spent $10,000 to buy the URL Copilot.com. And we thought it was money well spent. ...

    As I was discovering, businesses spend money at rates that seem profligate, even obscene, to normal people. ... Copilot.com taught me: Businesses will happily spend large sums of money on fixed costs, because those costs can be spread out across so many of their customers.
Consumers, though, are a different story. On the whole, they tend to be very thrifty and price sensitive. They'll choose the $18 cell phone plan instead of the $21 plan if they believe they can live without the extra $3 in features. ...

    ...volume [of consumers] doesn't come easy. At the very least, a company will need to do something to reconfigure the brain cells of millions of humans so that 1. They know the product exists and 2. They want to buy it. This particular brain-cell reconfiguration takes a lot of work, and success is exceedingly unlikely for many start-ups. ...

    ...some companies sell to businesses and to consumers, but this is a tricky balancing act. If you raise prices too fast, you will lose consumers. But if you continue to charge low prices, businesses may think your product is cheap--and you won't be extracting very much money out of precisely the customers who are most willing to pay.

    To successfully sell to businesses and consumers, you need to realize that you're building two companies, not one. You need separate product lines. Cisco does this well, selling home versions of its business products through its Linksys division.

(in toto)

Joel Spolsky — Good System, Bad System

    The objective is to make our customers feel as if they are having a real human interaction -- that they are not just dealing with cogs in a big machine. As a smaller entrepreneurial company, we have this luxury, and we exploit it
    we usually reply to a customer complaint with an e-mail that includes a discount offer on the purchase of another product. But rather than automate the message, we have opted instead to create a written template that staff members have to manually cut and paste into the body of an e-mail.

---

    There's an internal deployment manual [at Starbucks] that has instructions for where every employee should stand and what he or she should be doing at any given time. According to the anonymous posters on Starbucks Gossip, if you follow the instructions in that manual carefully, your branch can make more drinks, faster, and this will cause Starbucks HQ to allow you to hire even more people, and then there's less work for everyone.

    All of this fancy optimization stuff is called operations research. It's what Michael Gerber talks about in his best-selling book The E-Myth Revisited. If you're planning to expand your business to a certain scale, you must first establish procedures and build systems to get predictable outcomes so that your employees can produce decent results even when they're not having a great day. It's a real academic field of study, and it's really hard and really important. You need to hire pretty smart people to do studies and experiments and collect the statistics and then figure out what it all means.

    ... as it has grown, Starbucks seems to have lost its knack for figuring out whether the policies dreamed up at HQ are really going to work in the field. Indeed, most of the people posting on Starbucks Gossip seem to agree that Starbucks HQ is hopelessly naive about the reality of the employees' daily work lives. Those icy blended drinks might bring in more customers in the summer, but they take too long to make, so the lines are crazy. And when the lines are crazy, the staff has a hard time keeping the store clean. Hence, my local Starbucks branches are consistently dirtier and messier than the average McDonald's. That's one problem among many.

    Systems need to be flexible, and managers need to be wary of procedures that, applied blindly, can cross the line into something that looks more like antagonism toward customers. When we put a customer service policy in place at Fog Creek Software, we always deliberately leave a lot of room for our frontline people to use their own judgment -- heck, we require it.

(in toto)