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.