In 1971, Harlan Mills suggested that large projects be divided into pieces that are small enough to be done by a small team.

Mills also suggested that these teams be organized like a surgical team, in which only one person wields the knife. That person is the chief programmer.

The chief programmer's assistant, or copilot, is a competent programmer but probably has less experience than the chief programmer. The copilot discusses design with the chief programmer and offers advice, which the chief programmer's free to ignore. The copilot reviews all of the code, and may even write some of it, but is not held responsible for any of it; the chief programmer has sole responsibility for code. The copilot also serves as backup, ready to take over the chief programmer's responsibilities when she leaves for a higher paying job, or when some other disaster strikes.

The administrator takes care of the finances, equipment, personnel, space, and general bureaucracy. Absent special circumstances, administration should be a half-time job; one administrator should be able to serve on two teams at once.

Although the chief programmer is responsible for generating documentation, and should write most of it, the editor takes the chief programmer's draft documentation, improves upon it, and brings it up to organizational standards.

Mills calls for two secretaries, one for the administrator and another for the editor, to handle correspondence and filing. (By modern standards, that may be excessive. We now rely on computers to handle correspondence and filing, which may go a long way toward explaining why we're so bad at it.)

The program clerk is another secretary who files code. (Modern version control systems have taken over this role.)

The toolsmith supports the group's computing systems by installing appropriate software and writing needed utilities. (There's likely to be a centralized systems staff as well, but every surgical team still needs its own systems person.)

The tester devises test cases and automated test scripts, and oversees daily testing.

The language lawyer is someone who enjoys learning the dark corners of programming languages and other software, and is willing to do the research necessary to answer any questions that may come up. Language lawyering is not a full-time job. The chief programmer should be too busy for this, but the team's copilot, editor, toolsmith, or tester might fill this role. Language lawyers may be consulted by several different teams.