Ideas to Steal

Software engineering is different but it is not that different. What ideas can we steal from the broader world?

• people don't do what they are told
• all performers get the right consequences every day
• small, immediate, certain consequences are better than large future uncertain ones
• positive reinforcement is more effective than negative reinforcement
• ownership leads to high productivity

people don't do what they are told

In Bringing out the Best in People, Aubrey Daniels notes "If we always did what we were told, we would eat only nutritious foods, never drink too much alcohol, and exercise regularly." There is thus a natural limit on the effectiveness of written policies and management by telling then nagging.

A corollary to this principle is that people do what you reward them to do, not what you hope they will do. Often, when you look at what is truly rewarded in an organization, you find it is different than what you think is rewarded. Do the managers have an engineering background? If not, they'll probably be unable to perceive when a programmer is accomplishing nothing. So the programmer who does nothing gets a paycheck at the end of the month. Having thus been rewarded for doing nothing, the programmer tries it again the next month...

all performers get the right consequences every day

The natural way to manage is to spend time with people who aren't doing a good job. You help them out. You remind them of the good things that can happen to them if they finish a project or raise the spectre of their being laid off the next time the company needs to improve its profitability. These are probably the right consequences for someone who is underperforming. But what about the people who are performing? What if you ignore them day-to-day? Unless they are getting positive reinforcement from another source, they may stop coming in on the weekends to get a release out the door earlier, stop documenting their code, stop writing journal articles. A top performer won't sink to the level of a problem employee but that person may become average. And in the long run a company with average workers will at best earn an average return on equity.

small, immediate, certain consequences are better than large, future, uncertain ones

An annual review and bonus is not classically considered a very good way to motivate people. It is too far away, especially in a dotcom economy. Even if a worker is able to keep the bonus goal fixed in his or her head for the 365 days preceding the bonus allocation, there is uncertainty attached to it. What if the company is doing really badly at the end of the year? Will there still be a bonus?

positive reinforcement is more effective than negative reinforcement

Like most schools worldwide, MIT practices negative reinforcement at the undergraduate level. If student does not do a problem set by a certain deadline, we give him or her a bad grade. This has turned out to be extremely effective at ensuring that an MIT graduate has achieved some minimum standard. However, the students don't accomplish all that they could. The first term that we taught 6.916, we gave the students one week to do Problem Set 1. It was pretty tough and some of them worked all night the last two nights. Having watched them still at their terminals when we left the lab at 4:00 am, we wanted to be kinder and gentler the next semester. So we gave them two weeks to do the same homework assignment. The first week went by. The students were working on other classes, playing sports on the lawn, going out with friends. They didn't start working on the problem set until a few days before it was due and ended up in the lab all night just as before.

We thus proved the management adage that a deadline just gives someone an excuse to procrastinate and do nothing until the very end.

Graduate school at MIT is different. We want the students to do research, write up their results, publish them in journals, and graduate with a reasonably interesting PhD thesis. If a student finishes some research, the most effective faculty advisors immediately provide positive reinforcement by paying attention, helping design the next experiment, helping to draft a paper outline. If the student finishes a write-up, he or she is positively reinforced by being sent to a conference to present it. If the student finishes a PhD thesis, he or she is positively reinforced by being given a 3-7X pay raise.

The lesson from MIT? Negative reinforcement can work if the organization is extremely tightly managed, if the consequences are small and immediate (usually a problem set is due every week and only represents a part of the final grade), and if the goal is to make sure that everyone comes up to a reasonable level. However, the worldwide fame of MIT rests on research achievements by graduate students. This innovation is mostly supported by positive reinforcement.

ownership leads to high productivity

A related issue to positive/negative reinforcement is ownership. Non-ownership systems discipline those who are not working up to the minimum standard, but they do not offer enough of an upside to truly motivate people. Morever, non-ownership systems demand a very accurate setting of standards. Ownership-oriented systems include contingent rewards with an almost unlimited upside, and are thus effective at getting as much discretionary effort out of workers as possible.

As an example, in the early days of ArsDigita we had only a handful of customers: America Online, Environmental Defense Fund, Hewlett-Packard, Levi Strauss, Oracle Corporation, and Siemens. We had only a handful of programmers as well and hence the easiest way to divide the work was to give a programmer total responsibility for one project. The programmer owned that customer. If the project went well and the customer wrote us a big check, we gave nearly all of the money directly to the programmer. If any project had gone poorly and we'd been fired by a customer, we would not have had to think very hard to figure out who was responsible (fortunately this never happened while I was running the company!). People worked insanely hard to make their projects successful and their clients happy. More importantly, the programmer who did an entire project by him or herself learned enough to train new people, lead a larger project, etc.

After we grew beyond the 40-person mark, pressures to dilute the ownership aspects of our organization grew. We wanted to grow rapidly--nobody wants to buy enterprise software from a small company, even if the software happens to be open source. As our reputation grew, customers came to us with larger projects. We believed that many of our developers were too junior to handle complete responsibility for these large projects. Our costs went up because we had to coordinate the diffused responsibility. In the summer of 2000, when we had 200 or so employees, one of our clients was unhappy. It took a week just to arrange a meeting among the five managers who bore collective responsibility for the project! Meanwhile, individual productivity fell. It was taking more programmer-months and more calendar months to get things done. On weekend mornings you could walk naked through an entire floor of our headquarters building without fear of embarrassment.

(At the time of this writing, there is a proposal on the table to consolidate some of the separate management pyramids, thus taking us back closer to our original structure.)