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.

I am slowly making my way through Joel On Software's complete archive. This is a fairly large archive, and one might wonder why I am putting myself through this. As a matter of fact, I'm not "putting myself through" anything; I'm having a jolly good time doing it because the articles are so insightful and entertaining. Many of the principles that Bruce's Company will be founded on will simply be links to Joel's archive.

Today I read his article on craftsmanship. The gist of it is, craftsmanship is expensive, but worth it. In certain cases. The classic Joelism, where he likens an aspect of software development to some real-world case, occurs here:

The moral of the story is sometimes fixing a 1% defect takes 500% effort. This is not unique to software, no sirree, now that I'm managing all these construction projects I can tell you that. Last week, finally, our contractor finally put the finishing touches on the new Fog Creek offices. This consisted of installing shiny blue acrylic on the front doors, surrounded by aluminium trim with a screw every 20 cm. If you look closely at the picture, the aluminium trim goes all the way around each door. Where the doors meet, there are two pieces of vertical trim right next to each other. You can't tell this from the picture, but the screws in the middle strips are almost but not exactly lined up. They are, maybe, 2 millimeters off. The carpenter working on this measured carefully, but he was installing the trim while the doors were on the ground, not mounted in place, and when the doors were mounted, "oops," it became clear that the screws were not exactly lined up.

This is probably not that uncommon; there are lots of screws in our office that don't line up perfectly. The problem is that fixing this once the holes are drilled would be ridiculously expensive. Since the correct placement for the screws is only a couple of millimeters away, you can't just drill new holes in the door; you'd probably have to replace the whole door. It's just not worth it. Another case where fixing a 1% defect takes 500% effort, and it explains why so many artifacts in our world are 99% good, not 100% good. (Our architect never stops raving about some really, really expensive house in Arizona where every screw lined up.)

You might think that his point is that craftsmanship is not worth it. On the contrary, he thinks that it is worth it, because that's how you differentiate your product from competitors'. Differentiation from the competition is hard, therefore it should not surprise us that craftsmanship that differentiates is hard.

The company that I would most like to work for in the world is actually not Joel's (Fog Creek), or Google, or Microsoft, but Pixar. Every single thing they have ever produced, going clear back to the 80's, has been of a ridiculously high quality. And I credit one man above all for that achievement: John Lasseter. One thing that Lasseter likes to say around the Pixar offices is, "We sand the underside of the shelves." In other words, in their work, they take care of every last detail, even the stuff that almost nobody is ever going to see. That careful attention to detail permeates the whole process, the whole company, and it results in the fantastic movies that just blow away everyone else in Hollywood. (Okay, it's not the only reason, but it's a big one.)

Now. The astute reader might be saying, "Ah, Bruce, but that's exactly what Alan was doing when he was bugging you about the tiny little details in the app you were working on that you complained about so much." But there's a fundamental difference: it was an internal app. And even Joel, after his big speech on craftsmanship, acknowledges this difference in his concluding paragraph:

Craftsmanship is, of course, incredibly expensive. The only way you can afford it is when you are developing software for a mass audience. Sorry, but internal HR applications developed at insurance companies are never going to reach this level of craftsmanship because there simply aren't enough users to spread the extra cost out. For a shrinkwrapped software company, though, this level of craftsmanship is precisely what delights users and provides longstanding competitive advantage, so I'll take the time and do it right. Bear with me.

When I make software that faces the public, and I really, really care about its success, I will sand the undersides of its shelves. Some might say that if you sand the undersides of your internal apps, then that attitude will transfer over to your public-facing apps. I think there's something to be said for that, but I think there's more to be said for using time efficiently, and, after all, I know when I'm working on something internal and when I'm not, and I can make the leap.

Once again I am broadening this blog's horizons (or, in other words, diluting its purpose) with a post that is neither a rant nor sage counsel nor even funny. But I think it somehow relates to life in the working world.

I read a couple of things on the web over the last few days that struck me as similar in that they were both so typical of people from that part of the country. So here I present a quiz. See if you can tell where the authors of each of the two different blurbs are from:

1. [This appeared on Oddpost's FAQ list]
Where did the name Oddpost come from?
It’s the usual story really. Iain and Ethan were at the ’99 mandala sand painting retreat in Tengboche when the bang lassis they’d enjoyed in Chitwan finally started to kick in, and as they knealt on the cold stone floor of the monastery a yak outside began choking on some grass, making a noise like “ahd! ahd! ahd!” at the very moment their rinpoche began chanting in another room “pohhhhhhhhh stuh! pooooooohhhhhhhh stuh!” Ethan glanced over at Iain’s canvas. Iain looked over at his. They’d both of course painted the very same thing: ODDPOST.

2. I never go to a certain fake-Italian art-themed restaurant, because once I ate there and the waiter, who had gone beyond rude well into the realm of actual cruelty, mocking our entree choices, literally chased us down the street complaining about the small tip we left him.

I stopped going to another hole-in-the-wall pizza-pasta-bistro because the owner would come sit down at our table while we ate and ask for computer help.

I really, really loved the food at a local curry restaurant with headache-inducing red banquettes and zebra-striped decor. The katori chat was to die for. I was even willing to overlook the noxious smell of ammonia wafting up from the subterranean bathrooms. But the food inevitably took an hour to arrive, even when the place was empty, so I just never went back.

Answers:

1. That's right! San Francisco! Where else could it be? Where else are you going to find people who are just so darned pleased with the "multi-cultural opportunities available" and the "amazing diversity of ethnicities" that "enrich the community" in so many ways? And of course they need to share it with the world by working it into their FAQ, regardless of how contrived an excuse they need to come up with. And by so doing they have enriched me, their humble reader. How special is that?

2. The anwer is Manhattan. Although of course San Francisco also would have been an excellent guess. But Manhattan is really the place with the world-famous reputation for cuisine. If you ever need a reason to vomit, just ask any Manhattan denizen what their favorite eatery is. They will wax rhapsodic for the next 15 solid minutes (at least!) about that Brazilian place on 43rd and Lexington or the Ethiopian bistro at 12,000th and Hickory. And don't forget the deli with the amazing turkey pastrami on rye. The whole point, of course, will be to show how truly cosmopolitan they are with their sophisticated palatte and diversity of preferences together with their open mind concerning all languages and cultures. And oh by the way, it's a darned good thing they live in Manhattan, because you just can't get these things in flyover country. And it goes with saying, there's nothing worse than a chain.

Now, it so happens that I've been in Manhattan a few times, and had, oh, maybe a dozen or so meals there. I admit, not necessarily a huge sample size. But the funny thing is, I've really never had a memorable meal there. Nothing that I would ever consider to even approach the average meal that I've had at Outback or, say, The Cheesecake Factory. I mean, sure, the meals have been okay. Nothing wrong with them per se, other than paying about twice as much as what they're worth. But nothing memorable. I'm sure it's just been bad luck more than anything, and if anybody out there wants to give me a recommendation, I'd be very open to it, and I might even hop on a plane right now just to try it out. But just to show you that I'm not the complete rube I sound like, it so happens that there is a restaurant in the tri-state area where I've had some of the best meals of my life, called Fornos of Spain. But it's located in (gasp!) Newark. The horror!

But there's another interesting thing about #2. It comes from the blog Joel On Software, which is one of my favorites, and which I plan to quote extensively on this blog, because Joel is a software guy who truly gets it. Now, this particular quote came from the foreword that he wrote for a book on his bug-tracking system, and his point with the restaurant example is that he ended up always going to a place called Isabella's, not because the food is good, you see, but because you never have a bad experience there. And the reason you never have a bad experience there is because they have completely debugged the dining experience, through years of perfecting the process and writing things down in manuals and training employees. In other words, they're a chain. They may have only one location (I don't know), but they act like a chain, they smell like a chain, and they quack like a chain. That's what makes a chain a chain: they've debugged the entire process and they've got everything written down in manuals so that it can be duplicated over and over in restaurant after restaurant. Joel, of course, would never admit it, but that's what he's praising: a chain.

This post is neither a rant nor sage counsel; just something funny that happened in a meeting last Friday. The Four Developers, Scott (the "product manager" or something like that), and Jim the Consultant were talking (at length, naturally, and somewhat aimlessly) about how we're going to implement this massive credit card processing system over the next few years. At one point somebody asked Scott if any applications built for this sytem were going to have to support the briefcase model.

"Talk about 'briefcase model,'" Scott responded.

Yes. He really said that. "Talk about 'briefcase model.'" He did not say, as any other reasonable human being (including me, since I'd never heard of it either) would have said, "So, uh, what's a briefcase model?" He said, "Talk about 'briefcase model.'"

Of course, the critical question to be asked at this point (but which, I regret to say, I failed to do), is "Has Scott seen What About Bob?" Because of course, that's where that's from. Dr. Leo Marvin "psychoanalyzes" Bill Murray (Bob) at the beginning of the movie by simply saying "Talk about" whatever the last thing was that Bill (Bob) said.

If Scott has seen What About Bob?, then why in the world would he try to emulate the guy that the movie mercilessly lampoons as a pretentious, over-credentialed windbag, especially when Scott's job title is one that is particularly prone to allegations of being filled by pretentious, over-credentialed windbags? "But Williams," you say, "he was trying to funny!" Ah, but he was not. Scott is a funny guy (even "ha-ha" funny), but I know him well, and he was not trying to be funny. Particularly in meetings like this, he takes himself very seriously.

If Scott has not seen What About Robert?, then where did he get it from? Do people actually say this? If so, then what's wrong with all those people, that they've never seen What About Bob? And how come the have-seens don't tell the haven't-seens? In any case, how could such a transparently pretentious verbal tic survive for so long? Is it one of those things like "dude," where you start out saying it because you're being funny, but then it works so well that eventually you're just saying it out of habit, even when you're being serious?

So what we end up with, here, is Two Americas. On the one hand, you have people who have seen What About Bob?, and on the other, you have the people who haven't seen it, and so they still say "Talk about 'X'," and the former are secretly snickering at the latter, who are going to very angry when they find out about it, I can assure you.

As you can see, Scott's saying this completely blew my mind. I still don't know what to think.

Anyway, the conversation went on. Dave offered an explanation. Apparently it's an application where you can work offline for a while, and then later on come back online and the data automatically syncs up with the centralized database, or whatever.

"In other words," said Dave, "can the user still work on the application without any connection to any network at all--with his ethernet cable completely unplugged."

"Or any wireless access or anything like that," added Alan.

Again: Yes! He really said that! He actually thought it was necessary to specify: oh, by the way, and no wireless network access either. As if he was afraid that Scott was going to come back a couple of days later and say, "Hey guys, I figured out a way to get this briefcase model thingie to work without an ethernet cable. You just configure all the computers with wireless access! Bahda-bing bahda-boom!"

Oh, my. Hilarious. Perhaps there will be more entertainment in this new job than I'd thought. And by the way, I'm using a new, wrong spelling for Alan, for, uh, privacy purposes.

Okay, all that patience-and-tolerance stuff that I preached last time about how Allen's email ticked me off, but then he followed up with and long and reasonably convincing face-to-face explanation? Forget it. Well, maybe don't forget it, per se, but there are certainly limits to that approach.

I made a few more additions and improvements to the Requirements tab yesterday, and asked Allen this morning if he had any feedback on it. "There's your first mistake!" I hear you saying, but in reality, it was inevitable. As I said last time, I can't very well expect to just do everything myself how I jolly well please and then expect everyone else to like it or lump it. And by actually asking for the feedback, I look like a "team player." I also asked him to email the feedback to me so that I'd have a written record to refer to (but the real reason was that I didn't want to put up with him talking at me for another half-hour).

Well, I got what I asked for, all right! 16 bullet points, 31 lines, and 316 words (according to Word's Word Count feature). My favorite, I believe, was the suggestion that I make the the "minimum size" for the Add dialog bigger so that it doesn't look dumb when people resize it to the minimum amount. They can, of course, immediately resize it so that it's larger again, but apparently we don't want to subject them even for a moment to the horrific sight of having to see the dialog smaller than it was ever intended to be. Remember: this is an internal app!

My least favorite suggestion concerned the moving of the Other Requirements text box from the Requirements tab to the Add dialog box. We had discussed this earlier; he favored putting it in the Add dialog, while I favored the Requirements tab. Since I'm the one doing the implementation, by golly, I put it in the Requirements tab. A reasonable person, finding themselves disagreeing with my decision, would have either talked to me personally, or, since I asked for an email, said something to the effect of, "You know, I really think that the Add dialog is a better place for that, because of blah and also blah and blah."

Did Allen do this? He did not. Instead, he wrote this:

- Remove the button labeled 'Remove "Other"'
- Change the "Other" checkbox to a label
- Move the "Other" label and associated edit field to the "Add Requirement" dialog
- In place of using a checkbox to determine the presence or absence of an "Other" field, use the presence of text in the "Other" edit box to signify the presence of an "Other" requirement.
- When there is text (such as "This is sample requirement") in the "Other" edit box on the "Add Requirement" page, make it show up in the list of Requirements and make it look something like the following: ("Other Requirement: This is a sample requirement")
- Decide between using "Other" or "Other Requirement" for the label as well as the text shown in the list view
- Consider using a descriptive label that explains how to use the "Other" edit field

In other words, he simply gave me step-by-step instructions for moving this feature one item at a time from one form to the other. Are you kidding me?! This man is insane! I mean seriously, what normal person would do this?

Sure enough, a few minutes after the email arrived, he came by and wanted to talk about the items. I was still fuming from the email itself and in absolutely no mood to discuss it, so I told him I was leaving for lunch in a few minutes. He said okay, just come get me when you get back. Needless to say, I did not come and get him, and fortunately he didn't bug me all afternoon.

The interesting postscript to all this is that after the email I went over to Jamie and asked her which way she preferred, and without any prompting, designed a solution that was essentially exactly like Allen's. So I switched it over. The point, however, is Allen's extremely oddball way of reiterating his suggestion to me.

Lately I have been working with Allen on a "quick Windows app" that is supposed to be a better, more usable version of the "BackOffice" (not to be confused with anything Microsoft does; this is a credit card agent app) product that we bought from Lighthouse software. The original BackOffice app was a truly awful mess from a usability standpoint, and we didn't use the vast majority of its features, so coming up with some kind of an improved app is pretty much a slam-dunk. I have been working on the "Requirements" tab, the details of which I won't get into.

I figured I was about 90% done with it and ready to move on to another part of the app this morning when I got an email from Allen giving me some feedback on my work. Here is a sample of some of what he said:

- make the "Add" dialog an always-on-top style form
- make the "Add" dialog resizable
- set anchors on buttons so they will move with the form when the form is resized
- set minimum size for form
- where feasible, make buttons a consistent size (I've been doing 68x21 for a lot of them, many I still need to standardize, for some that size is too small)
- include merchant Internal ID and merchant DBA in titlebar
- standardize size of border around the controls (8 pixels?)

I don't mind saying I was a bit ticked off on receipt of this feedback In the first place, I didn't ask for it. In the second place, it deals almost exclusively with these ridiculously small details that the average person could not possibly care about. This is an internal app, for crying out loud! Not only that, but the project is on a highly compressed schedule--the whole darned thing is supposed to be done by the end of this week, and there are huge chunks of functionality yet to be developed. And lastly, it set off my highly sensitive turf-infringement alarm. I believe in ownership. This is my thing, so I should be able to implement it how I want.

Oh yeah, and at the bottom of the email, he said the following:

Changes that you agree and don't mind doing, just go ahead and change; changes you don't agree about, let's discuss until we have consensus; changes you think would be fine but don't know how to do or don't want to spend time doing, let me know and I can help.

This was actually quite a brilliant little addendum on his part, because it was effectively a pre-emptive strike on my favorite method for dealing with such feedback: to ignore them.

Now, there are a number of problems with my initial, primal response, but we won't go into that just yet. The main point of this post is thus: shortly after I received the email and commenced stewing about it, Allen came into my office and talked to me about it. Now, he wasn't there to apologize for it or anything. Of course not. Why should he? Instead, he went through and talked to me about each item, explaining why he wants it and what the other possible options may be. After he (finally) left, I realized the following:

(a) You have to have a consistent look and feel across the application. Sure, I might want to "own" a piece, but obviously that doesn't mean I can just make it look any way I like.
(b) If I "own" a piece of a project, but I never ask for feedback on it, then I simply must expect to receive unsolicited feedback. It is unacceptable for a developer to expect to have carte blanche over feature implementation.
(c) Some of the suggestions were better ideas than I had originally thought.

There are still plenty of caveats, here. The whole internal app argument I think is still a pretty good one, and there's lots of time being wasted. But the point is, had Allen just sent off the email and assumed I'd take it with grace and gratitude, I not only wouldn't have done any of it, I would have been exceedingly ticked off and added that incident to the memo I'm preparing internally for when I leave because "I really can't work with these guys." But since he followed up the email with a personal visit, I am considerably less offended by its contents and a lot more open to implementing several of its suggestions.

Feedback in an organization is essential. Four eyes are always better than two, etc. But the delivery of that feedback is absolutely crucial. Delivered wrong, it offends the feedbackee and makes him feel like his ownership has been undermined. Here is how feedback has been handled at my previous companies:

1. At Tenfold, they made a conscious effort to have a very abrasive culture. They get smart people with big egos but who aren't afraid to back down from a fight. The reason why this works is because everybody's smart, and so everybody respects each other. That's understood. The reason why it doesn't work is that it just gets real old getting yelled at. Also, 99% of companies can't bring together the kind of brainpower that TenFold had.

2. At Digital Harbor, things worked okay at a developer-to-developer level within the Utah office. Nice guys. Also, there was a formalized testing team and process where they would log bugs to the database. There were two very big problems though. One was that the local (Utah) guy over developers just wasn't very smart and didn't know beans about the code. Having to take feedback from him was just ludicrous. The other big problem was that the head of development over the whole company was in Virginia, and he was just about the biggest jerk I've ever known in my life. He was smart, but not practical, and he assumed that everyone was dumber than him.

3. At BullySports, I had an ideal situation working with Grant, who was essentially my dev manager. But there were only two of us, and we were friends anyway, so we worked together well. There were never turf battles; each knew that the other owned certain areas of the code, and frankly had no desire to intrude on the other's territory. Mutual respect, in other words. We also had a lot of power within the company (though far from absolute, as I'm sure you'll see in future blogs) and so when feedback came from other, non-technical parties, we were free to ignore it.

I notice that as I write this, I'm blurring the lines between feedback and management in general. Obviously it's hard to draw a line, but in general I'm talking about feedback in situations similar to that described at the top between Allen and me.

So what's the ideal method? Well, first of all, you need to be working within the structure of Bruce's Ideal Software Team, which I will delineate in a future post. But beyond that, you need to be very careful about the way you deliver feedback. Be nice. Humble. Leave the door open for other viewpoints. And choose your battles. And unless you have specific authority in the context of the company, you must achieve by persuasion, not by executive fiat.

Last month I started working at the 4th company in my 6-year career. Which sounds worse than it is; not counting this one, which I'm still at, that averages out to close to a 2-year average per company. But the point is, I'm starting to get to be a bit of an expert at different cultures in mostly small companies. And they're all wrong. Which leads me to believe that the only way I will ever be happy is if I start some company. Unless I go and get my Ph.D. and become a researcher somewhere and get a nice chunk of autonomy, but I doubt that will happen because I no longer have the patience for school (that ran out with about a year to go in my masters program), and I also believe that I also need the profit motive to be present in order to be happy. I could be wrong, though.

Since I believe that inertia is the greatest force in the universe, I must concede that most likely I will never start my own company. But in case I do, I will want to remember the wisdom I collected while bouncing around all these other companies and make sure that I do the good things and (more often) not do the bad things. And if I don't, then maybe somebody else will someday see these postings and find the advice valuable. Or perhaps someday I will be in a position with a discernible sphere of influence in the which I can make a difference. We shall see.