Mapping Staff To Roles

You're trying to figure out how to form an organization. You know the tasks or phases of the work ahead of you. (Example: architecture, analysis, design, coding, quality assurance, system and network administration, documentation, deployment, project management, T-shirt design, picnic planning.)

Possible aggravating context: You're only responsible for forming the organization, not its eventual success or failure.

Therefore: (AntiPattern) Hire one person per role. (Example: one architect, one analyst, one designer, one coder, one tester, one administrator, one documentor, one deployment specialist, one project manager, one T-shirt designer, and one picnic planner.) Congratulations! You've just maximized the number of possible interfaces, maximized the "idle time" of many of your people, and minimized the TruckNumber. Good work; here, have some stock options. Next time, sub-divide the organization by specialties. That way, people will form connections and loyalties at complete odds with the overall success of your organization and its projects. Jerk.

(Not that I am bitter.-)

Therefore: (more seriously) Put together a cross-functional organization of cross-functional individuals. Select for a variety of core competencies. (Example: Hire an administrator who can code, an architect who's written end-user manuals, a tester with project management experience and aspirations to management, an analyst who created the winning T-shirt award on his or her last project.) Cross train! Try PairProgramming (and not just programming, either), so skills and project knowledge are shared. It can be more fun this way, too; lots of people like doing lots of different things, not just the same thing over and over again.

People in small organizations, and especially in small companies, are wondering if I'm crazy. Of course everybody does everything, and washes dishes, too, right? Could it work any other way?

-- PaulChisholm

See also ExtremeRoles (which is different, but related.)