As summer interns at Microsoft, my friends and I used to take “field trips” to the company supply room to stock up on school supplies. Among the floppy disks, mouse pads, and post-it notes was a stack of small paperback books, so I took one home to read.

The book was Peopleware, by Tom DeMarco and Timothy Lister. This book was one of the most influential books I’ve ever read. The best way to describe it would be as an Anti-Dilbert Manifesto.

Ever wonder why everybody at Microsoft gets their own office, with walls and a door that shuts? It’s in there. Why do managers give so much leeway to their teams to get things done? That’s in there too. Why are there so many jelled SWAT teams at Microsoft that are remarkably productive? Mainly because Bill Gates has built a company full of managers who read Peopleware. I can’t recommend this book highly enough. It is the one thing every software manager needs to read… not just once, but once a year.


So, you have to make a schedule. This is something almost no programmer wants to do. In my experience, the vast majority just try to get away with not making a schedule at all. Of the few that make a schedule, most are only doing it because their boss made them do it, halfheartedly, and nobody actually believes the schedule except for upper management, which simultaneously believes that “no software project is ever on time” and in the existence of UFOs. Read today’s article Painless Software Schedules and be enlightened.

Arg! BellAtlantic DSL is doing that annoying thing where you only get about 500 bytes through per hour. Good thing I have dial up backup.

Good news! You can still burn flags! Yay!

NDAs and Contracts That You Should Never Sign

Over time, I’ve signed a lot of NDAs (non-disclosure agreements)… they seem to be the Silicon Valley equivalent of the Japanese business card. Some of them are short and simple, others are quite elaborate.

There is, however, one clause I’ve seen in a lot of NDAs that I consider quite unacceptable. It is a clause which forbids you to hire anybody who works for the company that is making you sign the NDA. Presumably, they think that while you are visiting them, you will hire away all their employees and put them out of business. Well, you know what? If your employees are so eager to leave, that’s your problem, not mine. You need to keep your employees loyal by treating them well, not by creating arbitrary obstacles in their career. In some cases it’s quite ridiculous; I recently signed this clause in a 3 page NDA by a startup company that consisted of exactly two founders, and no employees. So the founders, by putting this clause in the NDA, are doing nothing but guaranteeing that if their business doesn’t work out, none of the people they met while working on the business will be able to give them jobs.

On a similar note, a lot of companies have the audacity to put non-compete clauses in their employment contracts. Typically, this says that you agree not to work for one of their “competitors” or even “potential competitors” (which is never very well defined) for a period, usually 1 or 2 years, after leaving the company.

This is completely outrageous. I signed such a contract at Microsoft without paying too much attention. When I left, I realized that because Microsoft has a finger in everything related to software, technically I could not work in my field AT ALL for 12 months after leaving Microsoft.

Of course, it is extremely rare for Microsoft to enforce this clause. Among other things, it is considered legally unenforceable in some states, like California, although in New York I have heard it can sometimes be enforced. If they are not going to enforce it, why is it in there?

At Juno, management tried to add such a clause to the contract. Of course, there was a bit of an uproar, and guess what? The employees won! The clause was removed from the standard contract.

You can win on this one. Highly skilled technical employees are in too much demand, and it’s too easy to get a job. You don’t have to accept this clause in your contract. If the employer absolutely, positively insists that you promise not to go work for a competitor when you leave your job, you can tell them: “fine. You don’t want me to work for a year after I leave, that’s fine, but if I’m going to be ‘on the beach’, I want you to keep paying me my salary for one year after I leave, until I can legally get a job that you approve of.”

Another dangerous clause says that you agree not to hire, or cause to be hired, anybody from the company if you leave for a period of x months (usually 12 to 24). The idea is to prevent a group of people from leaving en-masse, and it’s to protect against the standard practice of a manager leaving a company and taking his team along with him.

This is something you’re really going to regret. Among other things, if you leave a company, then six months later someone else leaves and uses you as a reference for a new job, technically, you can’t give them one. That’s not nice.

And if somebody from the company leaves to do a cool startup, you can’t go work for them! By signing this, you’re basically cutting off this whole branch of possibilities in your career.

Suppose you want to leave to do your own startup. Your single best source of potential partners and employees are the people you know professionally. It is definitely not in your best interest to sign this clause.

I think that companies need to keep their employees loyal by treating them well, not by enforcing blind loyalty though a contract. I am not going to make the mistake of signing this clause again. Fortunately, with today’s shortage of qualified programmers, the balance of power today is sharply in your favor when you start a new job, and I think you have a very high chance of getting a job without signing restrictive employment clauses.

I’m not a lawyer, and this is not legal advice!


Yikes! The US Senate will vote on the proposed constitutional amendment to outlaw flag “desecration” on Wednesday. The vote on the amendment is expected to be very close. Even if you have already written to your Senators, it is imperative that you write and call today! (More info at the ACLU web site: http://www.aclu.org/congress/congress.html)

NDAs and contracts that you should never sign.

An issue which comes up a lot in start up companies is how to divide up the ownership fairly. The best article I’ve ever read on this topic is by Jim Clark, founder of SGI, Netscape, Healtheon, myCFO, et al. You can read it here

Command and Conquer and the Herd of Coconuts

Recently I’ve been thinking a lot about what made Microsoft a great company to work for, and why working at Juno was so frustrating. At first I attributed the difference to the east coast/west coast thing, but I think it’s a bit more subtle than that.

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. This was certainly true at Microsoft. There were huge branches of the Microsoft tree filled with great people; these businesses were perennially successful (Office, Windows, and the developer products). But there were also branches that were just not as successful: MSN failed again and again and again; Microsoft Money took forever to get going, and Microsoft Consulting Services is full of airheads. In each of these cases it’s pretty clear that a B leader built up a business unit full of C players and it just didn’t work.

So: hire smart people who get things done. (See The Guerrilla Guide to Interviewing) It’s so important there’s a web page all about it and it’s one of PaxDigita’s most important goals. And when it worked, it worked quite well at Microsoft.

When I first went to interview at Juno, I wasn’t sure that this was the company for me. The software looked a little bit goofy. The whole company smelled like a bunch of Wall Street Jocks who heard that the Internet was the New New Thing and they wanted in. So I called them up and said, “well, I’m not sure if I want to work there, but I’d like to learn more about your company.”

In typical arrogant manner, they proceeded to schedule me for a whole battery of interviews and made me prove that I was good enough to work there. At first I was a little bit miffed, because I hadn’t really decided that I was interested in the job in the first place. But then I realized that any company that has such a rigorous hiring process as Juno does has got to be full of smart people. This alone impressed me enough to take the job. Sure enough, Juno (and D. E. Shaw, the corporate parent) were full of geniuses. The receptionists had PhDs. The place was full of people like Dr. Eric Caplan, a former associate professor from U. Chicago who was writing technical documents for the intranet for heaven’s sake. Talk about overqualified.

For a couple of years, I was very happy at Juno. It seemed like a dream job. (I even got interviewed for a website called dreamjobs.com talking about how dreamy Juno was). One thing was a little bit strange — after about a year, I was promoted to be in charge of exactly 2 people on my little team of 6. In fact the average manager at Juno has about 2 reports, a stunningly vertical organization by any standard.

The next thing that I started noticing was strange is that a lot of people were leaving. In the wired wired world of Silicon Alley that’s not uncommon. What was weird is how consistent their reason for leaving was: none of them felt any possibility of moving up in the company.

So what we had here was a company that was already as vertical and hierarchical as imaginable, with about 50 managers for a total of 150 employees, and people were complaining because there was no hope of moving up

What’s going on here?

At Microsoft, for some reason, lots of people at the lowest rung of the hierarchy were completely satisfied with their jobs and were happy to go on doing them forever. Whereas at Juno, people in the same positions rapidly got frustrated and wanted to leave because they couldn’t get promoted.

I think the crucial difference here was in the corporate culture, specifically, in the way management worked.

At Microsoft, management was extremely hands-off. In general, everybody was given some area to own, and they owned it. Managers made no attempt to tell people what to do, in fact, they saw their role as running around, moving the furniture out of the way, so their reports could get things done. 

There were some great examples of this. Managers always refused to resolve conflicts. Typically what would happen is that a designer would get into an argument with a developer over what a feature should look like. They would argue back and forth, discussing the issue for an hour, and eventually, failing to reach agreement, they would stomp into some manager’s office hoping for a resolution. Now you’ve got three people in the room: a designer, a developer, and a manager. Who’s the person who knows least about the problem? Obviously, it’s the manager — who was just hauled in at the last minute for Conflict Resolution. At Microsoft, the manager would usually refuse to make the decision. After all, they have the least information about the problem. The manager would generally force the designer and developer to work it out on their own, which, eventually, they did.

At Juno, quite the opposite was the case. 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. The most egregious example was the CEO and president of the company, who would regularly demand printouts of every screen, take them home, and edit them using a red pen. His edits were sometimes helpful (spelling and grammar corrections), but usually, they demonstrated a complete lack of understanding as to what went into the screens and why they said what they said. For months later, we would have meetings where people would say things like “Charles [the CEO] doesn’t like dropdown list boxes,” because of something he had edited without any thought, and that was supposed to end the discussion. You couldn’t argue against this fictional Charles because he wasn’t there; he didn’t participate in the design except for hit and run purposes. Ouch.

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. If, like Juno, the corporation had been careful only to hire the brightest, most talented people, then it squandered an incredible resource and made those talented people frustrated as all hell.

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. Perhaps something like the workfare corps that does the raking in Central Park. But software companies aren’t Herds of Coconuts, and Command and Conquer doesn’t cut it.

PaxDigita Culture

So this is why I’m concerned with creating the right culture of hands-off management at PaxDigita. In general:

  • everybody owns some area. When they own it, they own it. If a manager, or anybody else, wants to provide input into how that area is managed, they have to convince the owner. The owner has final say.
  • every decision is made by the person with the most information.
  • management is extremely flat. Ideally, managers just don’t have time to get their fingers in the pies of their reports. You may be interested to read about a GE plant in North Carolina that has 170 employees who all report directly to the plant manager.

As a result, we will build a democratic culture where everybody runs the company. On a day to day basis, PaxDigita people have no boss — they run themselves.


Today, two pieces I wrote as a blueprint for PaxDigita.

The Guerrilla Guide to Interviewing. I originally wrote this for Microsoft, and edited it a couple of times in my career; now it’s the PaxDigita interviewing manual.

Recently I’ve been thinking a lot about what made Microsoft a great company to work for, and why working at Juno was so frustrating. At first I attributed the difference to the east coast/west coast thing, but I think it’s a bit more subtle than that.

History in the making:

pope at yad vashem:


I’m convinced that most people think about software companies in an upside-down way. The common belief is that when you’re building a software company, the goal is to find a neat idea that solves some problem which hasn’t been solved before, implement it, and make a fortune. We’ll call this the build-a-better-mousetrap belief. But the real goal for software companies should be converting capital into software that works. If you understand this, its easier to make the right strategic decisions.

Two Stories

I want to tell you two stories from my career which I think are classic illustrations of the difference between tech companies that are well-managed and tech companies that are disasters. It comes down to the difference between trusting employees and letting them get things done, versus treating them like burger flippers that need to be monitored and controlled every minute, lest they wander off and sabotage everything.

My first assignment at my first job was working at Microsoft, where I was told to come up with a new macro language strategy for Excel. Pretty soon, I had the first draft of the “Excel Basic” spec (which later evolved into Visual Basic for Applications, but that’s another story). Somehow, this mysterious group of people at Microsoft called the “Application Architecture” group got wind of my spec, which must have concerned them, because for some reason they thought that they were in charge of things like macro language strategies, and they asked to see my spec.

I asked around. Who’s the Application Architecture group? Nobody seemed to think they were very serious. It turns out that they were a group of just four people, recent hires with PhDs (very unusual for Microsoft). I sent them a copy of my spec and went to meet them, in case they had something interesting to say.

“Blah blah!” said one of them. “Blah blah blah, blah blah blah!” said another. I don’t think they quite had anything interesting to say. They were very enamored of the idea of subclassing and sort of thought that people making macros in Excel wanted to subclass a lot of things. In any case, one of the fellows said, “Well, this is all very interesting. What’s next? Who has to approve your spec?”

I laughed. Even though I had only been at Microsoft for a few months, I knew that there was no such thing as somebody approving my spec. Hell, nobody had time to read my spec, let alone approve it. The programmers were bugging me every day to get them more pages so that they could write more code. My boss (and his boss) made it very clear to me that nobody else understood macros or had time to work on macros, so whatever I did, it better be right. And here this PhD working in a strange research group at Microsoft assumed that things were a bit more formal than that.

I pretty rapidly realized that the App Architecture group knew even less than I did about macros. At least, I had talked to a handful of macro developers and some Excel old-timers to get a grip on what people actually did with Excel macros: things like recalculating a spreadsheet every day, or rearranging some data according to a certain pattern. But the App Architecture group had merely thought about macros as an academic exercise, and they couldn’t actually come up with any examples of the kind of macros people would want to write. Pressured, one of them came up with the idea that since Excel already had underlining and double-underlining, perhaps someone would want to write a macro to triple underline. Yep. REAL common. So I proceeded to ignore them as diplomatically as possible.

This seemed to piss off a guy named Greg Whitten who headed up the App Architecture group. Now, Greg was something like Microsoft employee number 6. He had been around forever; nobody could quite point to anything he had done but apparently he had lunch with Bill Gates a lot and GW-BASIC was named after him. Greg called a BIG MEETING and proceeded to complain about how the Excel team (meaning me) was screwing up the macro strategy. We pressured him to come up with some specific reasons but his arguments just weren’t convincing. I thought it was nice that here I was, a new hire pipsqueak right out of college, arguing with employee number 6 and apparently winning the argument. (Can you imagine that happening at a Grey Flannel Suit company?) My programming team, headed by Ben Waldman (now a VP at Microsoft) backed me up completely, which was all that really mattered, because the programming team wrote the code and thus had the final say on how things got done.

I would have been perfectly happy to leave it at that. If the Apps Architecture team needed care and feeding and wanted to argue about stuff, that was OK, I would argue with them as much as they wanted as long as they left the programmers alone to do their work. But then something even more interesting happened that blew my mind. I was sitting at lunch with some coworkers, in the Redmond sun, when Pete Higgins came up to me. At that time Pete was the general manager for Office — I knew who he was, of course, but didn’t expect that he knew me very well. 

“How’s it going, Joel?” he asked. “I hear you’ve been having some issues with the App Architecture group.”

“Oh no!” I said. “Nothing I can’t handle.”

“Say no more,” he said, “I understand.” He left. By the next day the rumor had gotten back to me: the App Architecture group was disbanded. Not only that, but each member of the group was sent to a different department at Microsoft, as far apart as possible. I never heard from them again.

I was blown away, of course. 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.

Years passed. I found myself working at Juno, an online service and free email provider. This time, the experience was the exact opposite of my work at Microsoft. I had two programmers reporting to me, but my own manager constantly undermined my (limited) authority by going directly to my reports and giving them things to do, often without even telling me. Even for trivial requests like days off, my manager thought that it was his job to approve or disapprove the request.

After a couple of years at Juno I was working on the new user signup feature. For Juno 3.x, a major release, I was going to be in charge of a complete overhaul of the signup process. By this time, I was a relatively senior member of the technical team; I got great performance reviews, and my managers seemed to appreciate the work I was doing. But they just couldn’t bring themselves to trust me. Command and control.

One part of the signup process asked the users to type in their birthday. This was just one small bit of a lengthy signup process that went on for something like 30 screens as Juno grilled you about your income, your favorite sports, how many children you have and how old they were, and about 100 other things. To make the signup process a little bit easier, I wanted to change the birthday field to be free format, so you could type “8/12/74” or “August 12, 1974” or “12 Aug 74” or whatever. (Have you used Outlook? It would work like Outlook, where you could type dates in just about any format and it would accept them).

Without going into too much detail, my manager decided he didn’t like this. It became an issue of ego for him. First he yelled at the designer who was working on that page (without even telling me). Then he yelled at me. Then he reminded me every single day that I had to change it to the way he wanted it. Then he got the CEO of the company to review it, and made a big show out of getting the CEO of the company to criticize my new design. Even the CEO at Juno is perfectly happy to interfere in work done at the lowest level in the company, in fact, it’s standard operating procedure.

I was furious, needless to say. It was a small thing, a matter of taste, really. Some people would prefer my way. Some people would prefer his. In either case, the message was clear: you WILL do as you are told here, dammit. It was a very command-and-conquer mentality that was more of a battle of cojones than a discussion of user interface design.

I won’t say that this is the reason I left Juno, but it does illustrate the reason I left Juno: it was the idea that no matter how hard you work, no matter how smart you are, no matter whether you are ‘in charge’ of something or not, you have no authority whatsoever for even the tiniest thing. None. Take your damn ideas, training, brains, and intelligence, all the things we’re paying you for, and shove it. And at Juno, there were plenty of managers, something like 1/4 of all the employees, and so they had plenty of times to stick their fingers into every single decision and make sure that they were in control. The contrast with Microsoft, where VP’s descended from Building 9 to make it clear that you have the authority to get things done, was stark.

Hanging Tree in Jaffa, Israel

To some extent, Juno’s hopelessly inept management process is a factor of being a New York City company, not a West Coast company, so modern styles of management haven’t quite permeated. It’s also a problem caused by the deep inexperience of Juno’s managers, and it originates at the top – the CEO, a 29 year old who has never worked outside D. E. Shaw, who interferes in everything he can get his fingers into, including the wording on error messages that come up when things go wrong; the CTO regularly screams at his reports if they dare to question his wisdom; they take it out on the programmers, who go home and kick their dogs. Compare this to Microsoft, where things are done at the lowest level, and most managers act like their most important job is to run around the room, moving the furniture out of the way, so people can concentrate on their work.


I want to tell you two stories from my career which I think are classic illustrations of the difference between tech companies that are well-managed and tech companies that are disasters. It comes down to the difference between trusting employees and letting them get things done, versus treating them like burger flippers that need to be monitored and controlled every minute, lest they wander off and sabotage everything. (My second feature article).

Don’t even get me started about what a bad brokerage PaineWebber is. They actually sent me a check (to close the account) for $7 which bounced! They had put a stop payment on it! This is the kind of service you get for paying $1000 commissions.

More on Sabbaticals…

I took a self-funded sabbatical in 1995, and I’m taking another one now. I think they’re great.

In 1991, I graduated from college and set off on my first cross country journey, by Ryder van, to Redmond, Washington. My first job was at Microsoft. This was, I would like to point out, before everybody hated Microsoft. In those days, only college kids and UNIX weenies hated Microsoft because it made “toy” products and boring office software for suits. One of the kids in my class was offered a job to work on OS/2. “No way I’m going down with that ship,” he said, and went to law school instead.

I was, to say the least, unhappy at the prospect of being out of school. I thrived on the social atmosphere of dorm life and was dreading the prospect of living in a dull apartment in a grey city where I didn’t know anybody. Of course, that’s the trick at Microsoft: most new hires are recent graduates from around the country who arrive in the waterlogged suburbia of Redmond without too many friends or social life. For the average geek, this formula means that you spend all your time at work. A typical day consisted of: wake up, walk to work (try not to step on any slugs), work until late at night, go home, watch TV, go to sleep, repeat.

My version was a little bit different, because I’m not a totally hopeless geek; I went to the gym in the evening instead of watching TV, and spent my weekends biking around Lake Washington to the U. District where I hung out at bookstores, libraries, and coffee houses and felt grumpy about not being in college anymore. But after a couple of years of this, I noticed that I wasn’t developing much of a social life; I didn’t have a boyfriend; everybody I knew was from Microsoft. Drabsville.

Needing a change, I moved to New York to work for Microsoft Consulting Services. At some point, I want to write a book-length treatment about that horrible hellmouth of incompetence. For now, suffice it to say that I didn’t last for long. A quick calculation of my stock options showed that I had accumulated about $120,000 in 2 1/2 years at “the soft”, and, by my calculations, I thought I could afford the risk of working at a startup.

I got a job offer from Pipeline, an early ISP in the New York area, and quit Microsoft. But talking to the founder and owner of Pipeline gave me some bad feelings, and thus began my first sabbatical.

Over the next 9 months or so, I did a couple of things. First, I learned. It was 1994, the Internet was starting to happen, and I had some catching up to do after living in the insular waters of Microsoft Before The Memo when it was assumed that MSN was going to compete with, and subsume, the Internet totally.

I also went through the exercise of thinking about my own startup – twice. Both exercises fell apart after a few weeks work because I didn’t have the right partner, and I didn’t know what I was doing, but I would like to compliment myself with the thoughts that the first startup could have become Yahoo! and the second startup could have become Vermeer (the company that became Microsoft Front Page.) I have specs somewhere on my hard drive for products that, if we had actually created them, really could have been huge Internet companies. But it’s not the idea that matters, it’s the execution — an idea I will return to many times in this weblog.

Another idea that had been itching in the back of my mind was to take a cross-country bicycle trip. When these startup ideas fell through, I started planning to take a trip in the spring, as soon as the weather was warm enough. (This was before I knew that it rains a lot in the spring.) The trip was great, you can read my web log (from way back in 1995!) here.

Somewhere in Idaho, riding through an empty road, my mood changed; I felt totally rested and eager to get back to work. Sitting in the library at Boise State, I read all the computer industry trade rags enthusiastically, and was excited to see how much was changing and how many new things there were to learn. When I got home and checked my bank account, I was happy to discover that the $7000 dollars it took for the 10 week bike trip had been magically replaced through the mystical power of Microsoft stock; being out of work for eight or nine months had barely depleted my savings.

So that was sabbatical one. It took about 2 days to find another, interesting job, and I spent the next four years working: first at Viacom, then at Juno.

Last November, some of the really bad management over at Juno had just worn me down. I found it impossible to be excited any more. It was increasingly difficult to ignore the subtle and unsubtle ways that Juno managers at all levels were screwing up. Worse, the intense politicalness and arrogance of management there convinced me that I had almost no chance of changing things. I joined the flow of talented, frustrated people streaming for the doors.

I really like the formula of working for four years, and then taking one year off. This time I’m pretty convinced that when I go back to work I want to work in a real startup, as a founder. I’ve learned a lot about this over the years, and I’ve gradually come to realize that there is nothing really risky about starting a company these days. There are billions of not-very-smart venture dollars out there looking for somebody to spend; even startups pay good salaries (they have to); and the chance of having a “liquidity event” – IPO or selling the company — is high enough that over the average career, say, working at 4 startups over a 10 year period, there is a fantanstic chance that you will make a big buttload of moolah.