By Rob Keefer

In his book Hackers, Steven Levy details the history of hackers from their roots in the late 1950’s at MIT, through the 1980’s. In the early days at MIT, two roles emerged from the groups of people who worked with and around computers: Planners and Hackers. The Planners were interested in the goals of computing; the Hackers were focused on the computing process itself. The Planners made sure everyone was working on the right thing; the Hackers made sure it was done ‘right’.

At first glance, it would have been difficult to tell the Planners and Hackers apart. They all had a great deal of knowledge, and they all wrote good code. In fact, the first Hackers were not interested in breaking into systems, stealing information, or any of the modern evils currently associated with them.

Digging a bit deeper, however, you find major differences between them. One of the better-known Planners from that era is Marvin Minsky (known his work in Artificial Intelligence). Minsky would either begin a project himself or wonder aloud whether something might be possible. If the project interested the Hackers, they would implement it. Minsky was the voice of the team by writing grant proposals and publishing papers.

Another well known character from MIT is Richard Stallman (known for his open source work in UNIX). His passion for technology is well-known, and his focus in the early part of his career centered on writing fast, optimized code. Stallman could take a project and churn out thousands of lines of bug-free code in short periods of time.

The Planners and Hackers had a mutual respect for each other that grew stronger as they worked together. The Hackers needed the Planners to obtain project funding. The Planners needed the Hackers to execute the plan. The two groups worked well together because the Planners would make sure they were doing the right thing, and the Hackers would make sure it was done ‘right’.

Organizations may implement this concept differently based on their product or service. The innovation teams at POMIET are staffed with roles that are very similar to the Planner and Hacker roles found at MIT in the 1960s. For their projects, two people lead the team, each with a different focus. One person is focused on interacting with the client, understanding the research deliverable, and generally making sure the team does the right thing (the Planner). The other person is focused on the implementation, the technical quality, and making sure things are done correctly (the Hacker). The results delivered with this pair leadership model are generally a huge success.

For POMIET this shared leadership model works very well. Both leads interact with the client and both equally share responsibility for deliverable. Neither one reports to the other on an organizational chart. The team understands the project direction and priorities because of the Planner’s role, and equally understands the implementation expectations because of the Hacker’s role. Since the Planner is an active member of the team, he or she can easily communicate requirements to other team members, and limitations to the client. Since the Hacker interacts with the client, he or she can easily communicate any assumptions to the development team, and deliver estimates to the client.

To further understand the nature of these two roles on our teams, note that the Planner is responsible for communicating with everyone on the team and external to the team. The Planner is the primary point of contact for the people who provide the research direction, and the voice of the team to all layers of management. He or she is also responsible for tracking the schedule, and setting priorities and tasks for the team members.

The Hacker on our team communicates also with the customer and helps define the research deliverable. However, this is just one small part of the Hacker’s role. The Hacker is primarily responsible for the integrity of the research deliverable at every level – research, design, and prototype. To ensure this integrity, the Hacker reviews every design decision and every line of prototype code developed. The Hacker is also the primary point of contact with the client development team, and evaluates all third party products used in the system design.

There is a practice in Extreme Programming called Pair Programming. This practice calls for two people to work on the same piece of code at the same time – one focusing on the code itself, the other thinking at a more strategic level. The Hacker/Planner model of team leadership is a natural extension of this same practice.

Like Pair Programming, pair leading is a subtle skill that is set squarely on mutual respect and trust. When two experienced developers pair program, sparks may fly when both have strong opposing opinions on implementation issues. When two seasoned professionals lead a project, a prepackaged fireworks display could be in the works.

Pair leading is not simply one person being in charge, and the other acting as a secretary. Pair leading is most effective when both people are actively involved and responsible for the success of the deliverable.

Pair leading does not call for two people to attend every meeting. Planners go to the planning oriented meetings; Hackers go to the implementation and development oriented meetings. There are times when both need to be at a meeting, but this is rare. Both leads are copied on all email, but they tend to know who is responsible to respond. Once in a while the other lead will jump into an email thread to add clarification, but never to undermine the partner.

Pair leading only works if the two leads are willing to set aside their egos for the benefit of the project. While this may be difficult to achieve, experience has shown that when this does happen, the barriers that often exist in communication fall away. The conversational nature of pair leading enhances the whole work process. The two leads can talk at many different levels, because to varying degrees, both understand the research requirements and the development environment. Each problem that arises can be addressed quickly and accurately since the pair brings full knowledge of the project to bear on the problem.

The great successes of MIT in the 1960s may have resulted from the planner/hacker roles. I wonder if we would know the names of Marvin Minsky or Richard Stallman if they hadn’t worked together to create something bigger than themselves. I also wonder how successful our teams would be without either the Planner or Hacker. Somehow I don’t think any of it would happen if one piece of the puzzle was missing.

---