You Gotta Own It

One of the frustrations I've experienced with offshoring projects is the diminished sense of ownership. We're still responsible for the software put in front of the end users, and yet we're not allowed to put our hands on the code. Instead, we draw UML diagrams, we enter tickets, we send emails back and forth. In short, we do everything except the only work that actually produces a software product: writing code.

As a result, my interest in these projects has dipped precipitously close to zero. Why should I care? I'm a middleman. I have no ownership stake in the project. And neither do the offshore developers, except in terms of fulfilling their contractual obligations. What happens when nobody owns a project? Well, that's why lots of internal software sucks pretty badly. Renters don't take pride in their homes. Only homeowners do.

In their defense, sometimes you make the conscious choice not to own something. Attempting to own everything is another kind of failure mode. However, if you do want great software, you have to let the developers own what they're building. The developers are inevitably the ones who have the most control over the success or failure of the project. Creating an environment where your developers have no emotional attachment to the project they're working on is a recipe for mediocre software-- and job disillusionment.

The notion of "egoless programming" is dangerous and wrongheaded. It's even listed in Robert Glass's Facts and Fallacies of Software Engineering as Fallacy #3: Programming can and should be egoless:

The first best-selling software engineering book was The Psychology of Computer Programming (1971). There was a peculiar idea among the many excellent ideas in that book-- the idea that programming should be egoless. Programmers, the author said, should not invest their ego in the product they were building. Too many programmers, the author said, get so ego-invested in their product that they lose all objectivity. They see error reports as personal attacks. They see review sessions as threats. They see any questioning of their accomplishments as counterproductive.

What's the alternative to an ego-invested programmer? A team player. The team player sees the software product as a team effort and a team achievement. Error reports and reviews and questions become team inputs to help improve the product, not threatening attacks to derail progress.

At first glance, it's hard to argue with the notion of the egoless programmer. Certainly the defensive programmer, caught up in his or her ego, is not open to the changes that he or she must inevitably make to improve the product. But, after further thought, this notion begins to unravel. It's easy to advocate egoless programming, but it's difficult to find find people who can-- or even should-- divorce their ego from their work. Consider the notion of an egoless manager. That idea, of course, is preposterous! The ego of the typical manager is the driving force that makes him or her effective. We can no more divorce ego from the average programmer than we can from the average manager. We can, however, strive to keep that ego under control.

Smart organizations cultivate this sense of ego-driven ownership with with an implied trust: they go out of their way to hire smart people, and then they get out of the way. Microsoft, by all accounts, does this extremely 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.

This is something Peopleware calls the "Open Kimono" approach to management:

This Open Kimono attitude is the exact opposite of defensive management. You take no steps to defend yourself from the people you've put into positions of trust. And all the people under you are in positions of trust. A person you can't trust with any autonomy is of no use to you.

One of my first bosses was Jerry Wiener, who had run a development team for General Electric on the Dartmouth time-sharing project. He later formed a small high-technology company. At the time I came along, the company was about to enter into a contract that was larger than anything it had ever done before. The entire staff was assembled as our corporate lawyer handed Jerry the contract and told him to read it and sign on the last page. "I don't read contracts," Jerry said, and started to sign. "Oh, wait a minute," said the lawyer, "let me go over it one more time."

The lesson here is not that you should sign contracts without reading them (though that may not be a terrible rule in cases where you pay counsel to look out for your interests). If you've got the wrong counsel, you're in deep bananas anyway. Managers who are most proficient at getting the work done are likely to be way out of their depth in evaluating contracts for the work. Reading contracts may be little more than a conceit. Jerry had taken great pains to hire the best counsel he could find. He'd certainly looked over other instances of the man's work. This was not the time to be defensive; it was the time to make it clear to everyone that the boss was assuming and depending on competence around him. It's heady and a little frightening to know that the boss has put part of his or her reputation into the subordinates' hands. It brings out the best in everyone. The team has something meaningful to form around. They're not just getting a job done. They're making sure that the trust that's been placed in them is rewarded. It is this kind of Open Kimono management that gives teams their best chance to form.

If you're not working in an environment where ownership is encouraged, either wrest control from the powers that be, or start looking for another job. You gotta own it.