Bruce's Company

In my last post, I talked about an employee having an Army of One mentality. Imagine an entire company: hundreds--even thousands--of people strong, every single one of which is working in their own area as an Army of One--building, perfecting, honing, even expanding their area.

"I'm imagining that," you say, "and all I see is chaos."

Ah. But you need to see it with the team structure superimposed on it. But that sounds pretty traditional, doesn't it? Not much innovation here at Bruce's Company, after all, eh?

Well, yeah, I'm not really looking for innovation here; I'm looking for what works. And I'm not here to say toss away all structure or management hierarchy. To be sure, things should be relatively flat and flexible, but somebody's got to be the boss (more on that in another post).

The main trick is to keep the Army of One mentality in each employee of the company while keeping everyone moving in the same direction. So let's talk about the next unit up the structure hierarchy: the team.

The ideal team should be small. 3-5 people, I think, is about right. (The founder of my first full-time company, TenFold, Jeff Walker, said that a 2-man team wasn't really a team; they were just "buddies.") This is the first and most critical aspect of a team. It must be small enough that everyone feels themself a critical part and cannot get lost in the shuffle. If a team is much larger than 3-5 people, then it simply needs to be broken up into smaller teams, where each team has a defined role. Obviously, multiple teams can then be combined into a larger unit, with its own manager over the multiple teams, if necessary, but the sovereignty of the individual teams must be respected.

If a team is small enough, and its sovereignty is respected, then it effectively becomes an Army of Five, or whatever the number is. That is, it collectively has the same mentality that each individual person has as an Army of One. The manager divvies up the overall responsibility of the team among the different members of the team--according to area, remember, not task lists. Each member of the team views himself as master of his domain, with the view toward presenting the best possible performance to the manager. The manager makes sure that all of these efforts mesh together to form the best possible product to be presented to the rest of the company, or to his manager, or whatever.

It is essential that the team members be answerable to primarily their own manager, and not anyone else. If other managers at the team level have a problem with our team, or even a specific member of our team, they complain to the manager of the team. If the manager's manager is not pleased with the performance of the team, he talks to the manager to find out what the problem is. He does not pick out individual members of the team and complain that they're not doing a job.

Here we see why it is so important that the team be small. Beyond 3-5 members, a manager can't possibly truly evaluate how well an individual employee is doing. Having a team of 8-10 members is dangerous, because a manager probably thinks that he can do effective individual evaluation, but he can't. He can't, because at that level, he has to resort to analyzing numbers, and numbers typically are meaningless, especially if not backed by an intimate familiarity with the process that produced them.

In the software development business, effective employee evaluation means that the manager needs to be able to look at the code that each programmer produces. It is not enough to just look at short-term results, because the results may just be a facade concealing fundamental problems that may not pop up for a very long time. The company that is intent on long-term success will care deeply about the condition of the underlying code, and the only way to ensure that is to have team managers that reward good code done "the right way."

This, of course, implies that the manager must be technically proficient. And this is the Second Great Commandment of the ideal team: the manager must be technical. Ideally, he should be familiar with all the code in the team's product. On my first team at TenFold, the manager was one of two people who wrote the original product, and you couldn't get away with putting any bad code in that product, period.

Admittedly it is not always possible to have a manager who is so well-versed in the product. Sometimes you just have to bring in somebody from the outside. But the new guy should still be someone who has previously done the job that his underlyings are doing, and, in software development, he should still try and familiarize himself with the code and review new code as much as possible. The manager must get his hands dirty!

Now, I am sympathetic to the protest that actually, the short-term results could very well be more important than the computer scientist's aesthetic view of the beauty of the underlying code. I've known many programmers who over-engineer their code and allow their obsession with doing things "the right way" to slow their real productivity down to a crawl. Believe it or not, I would even allow that this could very well be just as big a problem as shoddy code that comes back to bite a company in the long term. Ultimately, it's the manager's job to decide and direct the level of abstraction that should be assumed in writing code and how important the long-term view is for a given project. This is, in fact, possibly his most difficult job, and yet another reason why the manager must be technical.

Now let's go back and talk about the sovereignty of the team some more. When I was at Digital Harbor, there were basically two teams working on the PiiE product (yeah, great name, I know), which we'll call the client team and the server team. I was on the server team. We shipped a new version of the product about every six months or so, and every single time, without fail, when we got down to the last couple of weeks before shipping and we were just trying to clean up the last several bugs, it was the client team that was swamped with bugs while the server team had nothing to do.

(There was no shortage of excuses for this state of affairs, of course: the client team had a harder job, the nature of the client's product was more prone to bugs, etc. Nobody ever suggested that, regardless of what the excuses were, the client team really ought to start adjusting their project estimates from the beginning.)

So, faced with one team working and the other team largely done, what did the managers' manager who was over the two teams do? Well, he did what any manager would do: he grabbed people from the server team and assigned client bugs to them.

Now, this sounds perfectly reasonable. And it is possible that it is justified, given the circumstances. But let me point out the harm that this does, and then you decide if it's really reasonable.

First of all, I cannot overemphasize how painful it is in software development for a programmer to be asked to fix a bug in someone else's code, that he has never seen before, and that he will likely (hopefully) never see again after fixing the bug. Particularly if the guy who wrote the code is sitting right over there--he's just busy with yet another bug. It's not so much that the programmer is doing somebody else's job--onerous as that is. The truly exasperating thing is that it will take that programmer at least ten times longer to fix that bug, because he's not familiar with the code. Maybe a hundred times longer! He could very easily spend all day, or even days, trying to fix this bug that the original programmer could find in ten minutes. I am not exaggerating. Any software developer will say the same.

Second of all, grabbing someone from one team to work on another team's bugs violates the sovereignty of the first team. It disincents the first team from completing their product on time. If you have a choice between (A) working hard to finish your product on time, or early, and thereby earning the reward of fixing somebody else's code for the next few weeks, which as I mentioned above is about as pleasant as passing a gallstone; or (B) taking it easy and making sure that your code is done with all bugs fixed at exactly the same time as everyone else's; which choice would you take?

On top of all this was Digital Harbor management's slavish devotion to these ridiculous bug numbers that the process produced. In brief: the more bugs you fixed, the more you were rewarded as a programmer. If you checked in code that was relatively bug-free nobody cared--there weren't any numbers that tracked that. On the contrary, you were now at a disadvantage because you weren't going to be able to fix very many easy bugs in your own code. In order to build up your bug-fixing numbers, you were going to have to go fix them in someone else's code. If you complained about having to do so, of course, you were not a "team player."

Hence, for release after release after release, despite the fact that the client team always ended up with more bugs toward the end of the process, it was that same client team that ended up coming out of the process smelling like a rose because it had these fantastic bugs-fixed numbers, while the server team looked like they weren't "team players" because they complained about having to fix someone else's bugs--and oh by the way, they didn't even end up fixing that many bugs either.

So we see that while reallocating resources to fix a temporary problem may seem like a sensible thing to do, there are all kinds of long-term disadvantages to such an approach. The sovereignty of the team must be held sacred, because each time it is violated, it damages the whole Army of One mentality that is essential to overall company productivity. And the team should be judged by the quality of their own product, period. Over time, a successful team will develop their own personality, a reputation for quality, and increasing pride in what they produce. The "team" mentality follows individual achievement, not the other way around.

I can hear the bureaucrats saying already: "The employee should be willing to do whatever it takes to make the company succeed! We're all in this together!" First of all, we're not all in this together. That's your point of view. This is the classic mistake that companies make when they fail to look at things from the employee's point of view. The employee is not "in this together" with his boss. He's "in this" for his family, period. Or, if he's single, for himself--and there's nothing wrong with that. If you want to run a company where you demand every employee's complete and utter devotion as the #1 priority in their life, then be my guest. But that's not Bruce's Company.

If you're not convinced, then look at Digital Harbor. They thought they could straddle the line and say that "we're all in this together" while simultaneously denying that the company demanded that they be the employees' #1 life priority, and the morale there was the worst of any company I've ever worked at.

Respect your teams' sovereignty. If they do a good job, pat them on the back and tell them to go home. If they don't deliver, make them deal with the consequences themselves.

After a pretty good start, I stopped updating this blog, partly because I got sick of writing stuff, and partly because I got paranoid about someone discovering it. But I still think about important principles of running a company, and I'm more convinced than ever that these ideas need to be written down, even if I myself never use them.

But I'll try not to use any more examples from my current job, for fear of reprisal. (Why not delete them? I just can't bring myself to do so. Some of it's pretty good, actually!)

So today I want to talk about what I think is my most important idea. No more of this "saving the best for last" business; if I take that approach, odds are good that I'll never get to it. This idea is what I call the "Army of One" idea, although it has little to do with how they do things in the Army (actually, I think that the Army internally intended that ad campaign to be entirely ironic, knowing that no one would get it until it was too late). But first a tangent--er, some background.

One thing that I've complained about over and over is how companies frequently are so short-sighted with respect to the customer. Many companies brag about being customer-focused. I'm amazed that anyone thinks that this is worth bragging about. Hello! Of course you're customer-focused! That's where all the lettuce is! If you didn't have customers, you wouldn't have a business. This is not rocket science. My bank, Zions Bank, currently has an ad campaign that says "We haven't forgotten who keeps us in business." Well, that's mighty gratifying! I think in one of their commercials they even once said that they haven't forgotten whose money it is sitting in their accounts (almost in those exact words, mind you). My goodness. Where did they find all those geniuses that are running that enterprise? You mean I could walk into any branch of Zions in the state and they could tell me who was the owner of any given account I'd care to name? Wow!

Okay, enough sarcasm. The point is, a business is nothing without its customers, and so any action that they take must always be considered from the point of view of the customer. Everything must work out for the best for the customer. Now, I'm not saying that companies shouldn't occasionally make hard choices that may perturb or even alienate some or all of their customers. The long-term view must be maintained. But ultimately, the customers will be your business, period. I know this all seems pretty obvious, but the fact is that businesses are constantly violating this principle for reasons large and petty. I'd give examples, but I need to move back to my main point, and you probably agree with me here anyway.

So. Businesses exist because of their customers. They serve their customers, of course, through their employees. And they have a similar relationship with their employees as they do with their customers; that is, a combination of synergistic and adversarial. Both parties are trying to get as much as they can out of the other without having to pay too much. The "pay too much" side of the equation causes companies to lose sight of their employees' point of view, just as they sometimes lose sight of their customers'. Once a company loses sight of that, they can easily start heading down a path where the "synergy" part of the relationship is increasingly forgotten and the "adversarial" part of the relationship is dominant. This results in an us-versus-them management environment, which is the worst possible scenario for a company's productivity.

In an us-versus-them environment, the employee does the absolute minimum to avoid getting fired. His presence in the office is primarily intended as a ruse to give the impression that he's working. He may even put in some pretty long hours! Not working, mind you, but seats in chairs is still the number one metric for measuring work performance. The primary work that he does is to try to give the impression that he is working. These guys just love the modern taboo against firing people. They bet that their boss doesn't have the bergertis to fire them, and most of the time, they're right.

In us-versus-them offices, the smarter the employee, the better he is at gaming the system, and so the less work he does. (This is why some companies don't like hiring people who are too smart. Yes, there really are companies like that. Trust me. And any company that does not put a premium on smarts is an us-versus-them company.) Think Wally in Dilbert. He's my favorite character in that strip. I think that he's absolutely brilliant! He's a lot smarter than the token female engineer in that strip, whatever her name is, who is a great programmer but yet kills herself over and over to no avail as regards her standing in the company.

Here's an example of Wally's brilliance:



It should be pretty obvious that companies with employees like this are not going to be terribly productive, but just to be explicit, allow me to give an illustration. I think I read this in the excellent management book Peopleware. In Australia, I suppose there's some law against workers in "essential" industries going on strike, so the workers in those areas have come up with a way to go on strike without really going on strike. They call it "working by book." That is to say, everything they do is exactly, to the letter, according to what the relevant manual calls for. The effect of this is that productivity grinds to a halt. Air traffic controllers, for example, only allow planes to land or take off once every seven minutes, which causes the entire air transit system to become gridlocked. What can the management do? They can't fire these people; they're doing their job, after all! In fact, they're doing it exactly how their management wants them to! In theory.

Here's my point. The whole point of this long and tedious article. In many, many jobs, especially knowledge worker jobs, especially software development jobs, it is entirely possible for your employees to "work by book." Maybe not in exactly the same way as the air traffic controllers, but the effect is the same; that is, the gap between employees' maximum productivity and their actual productivity under us-versus-them management is a yawning chasm that will cripple your business. And you can't do anything about it. Because the software development process is so opaque, and the metrics are so fuzzy, that you cannot substantially prove that one developer is that much more productive than another. Or, perhaps more importantly, you can't prove that all of your developers aren't as productive as they ought to be. Oh sure, you might know. But you can't prove it. And if you're the type that won't fire people, you're stuck. Of course, even if you do fire people, you're still taking a huge loss each time you try and replace an employee.

Us-versus-them management cripples productivity. And yet it runs rampant in the business world, because it's so easy. A company that can truly master the alternative, which I call "Army of One" (the point! At last!), can gain a big competitive advantage.

Here is the Army of One management philosophy, in a nutshell:

Pay your employees lots and lots of money.

Ha ha ha! Just kidding! Needless to say, that's not a solution. That's the opposite of a solution, in fact; it's the "default choice," which is what you make when you can't come up with any real ideas. Any time you have a problem, and somebody comes back with a solution that essentially amounts to spending more money, that just means that they didn't come up with a solution. Because anybody can spend money; the whole objective of being in the world of business is to not spend money. Otherwise, it would be like playing a board game in which there are no rules. Each participant would just yell out "I win!" and the game would be over.

So. What's the Army of One management philosophy? It is the practice through which each employee feels like he and he alone is in charge of a certain slice of the universe. That slice may be big or small, but the crucial point is that the health of that slice (over the long term) is entirely a function of how well that employee does his job. He is an Army of One in that slice of the universe.

That's it. That's all! Just give an employee an area to be in charge of (note that I did not say "an assignment"; I'm talking about space, not time) and say, "This is yours." Then leave him alone for a while (whether an hour, or a week, or a month, depending on the job), come back, and see how things are. If it's well in hand, give him some more. Repeat. The employee will gain great satisfaction from knowing that there is a slice of the universe that he is in charge of, and by golly, that slice is humming along like a fine-tuned machine. As that slice gets bigger, the satisfaction increases, and inevitably the salary will too, because you'll naturally pay people with larger responsibilities larger salaries. But note that the raise follows the prior job satisfaction; it's not doled out as a measure to promote satisfaction to begin with.

Once an employee is an Army of One, what happens? He gets to work early to work on his kingdom. He works hard all day long. He might even stay late. Working, mind you, not just putting in the appearance of working, because what good would that do? Also, crucially, there's never a time when the employee doesn't have anything to do. Do you own your own house? If so, have you ever looked around and said, "Yep, it's all done! There is absolutely nothing else I can do to improve this house." Of course not. There's no such thing. Similarly with an employee working on his kingdom.

Of course, the manager may still need to occasionally advise the employee concerning his priorities to ensure that they align with the company's. Also the manager may need to clear the road in front of the employee to make sure there aren't insuperable obstacles blocking his path. The kingdom that the employee is building also actually has to mean something--no "busy work" kingdoms.

Now I suppose that this may still be pretty obvious to people reading this. But it certainly hasn't been obvious to most of the managers under which I have toiled. Most of them take a strictly us-versus-them approach to management and hand me one task after another without any regard to my point of view. I want to be a good employee, so I do it. And what do I get? Another assignment. This is perfectly reasonable, of course; after all, they're paying me to do something, aren't they? This is the trap that management falls into. And soon it all devolves into a game of us-versus-them.

Now, I know you're raising objections. And there are definitely difficulties in trying to implement this management style. What about teams? What about one-off assignments? What if the company isn't growing? These are all legitimate concerns, and I plan to address them in future entries. The Army of One management style isn't necessarily easy to pull off in all situations. That's why the us-versus-them style is so much more common. But as I detailed above, the trade-off is a huge win.