I’ve just finished reading Managing the Flow of Technology, a book which synthesizes the results of several studies done in the 60’s and 70’s by Thomas J. Allen which analyzed the production of new technologies in the aerospace industry. Although the book reproduces some of the problematic aspects of the corporate culture it describes (overwhelming whiteness and maleness, and an obsession with quantitative analysis), and some of Allen’s suggestions seem dated (open office layouts), many of his insights into how technical knowledge moves within and between organizations seem useful, so I thought I’d try and summarize the main points of the book, and draw some connections to the work of the D-Team.

Allen examines the behavior of engineers, which he is at pains to distinguish from scientists because they work in different organizational/professional contexts with distinct norms and rewards structures. Whereas scientists pass information between each other (and between organizations) through professional literature, Allen argues that engineers communicate primarily using unpublished reports and informal, personal channels. This resonates with my experience of the past ten years of working in library and archives technology - communities like Code4Lib have been incredibly important because they foster personal connections between folks doing similar work. Although there are some technology-focused journals, most of what I’ve learned has come from more informal conversations and from informal project reports or artifacts.

He also introduces the notion of “technological gatekeepers,” or individuals who bring technology into the organization via informal connections to the outside. In the information world, many of us have negative associations with the concept of a “gatekeeper” because it’s a term often associated with censorship or impediments to the flow of information. Allen’s conception of a “technological gatekeeper” is somewhat different - the role he describes is someone who is perceived to be a high technical performer, values working in a team with other people, is broadly engaged in professional activities like conferences and task forces, and is typically a low-middle manager. In other words, it may be more of carnival barker and less of an ogre under the bridge. Again, this concept resonated with me in thinking about the D-Team’s role at the RAC, and provided some useful validation and rationale for the amount of time we spend building relationships outside of the organization and remaining connected to developing trends and technologies.

Things start to get really interesting towards the latter half of the book, where Allen looks at why certain projects are successful, and others are not. Success here is defined as whether or not a project produced a reliable technical solution to a problem. After examining a number of possible factors, Allen argues that communication - particularly internal communication with individuals outside of the technical project team - is the primary marker of successful technical projects. However, despite this clear correlation, he also notes that internal communication on technical problems (which he terms “internal consulting”) is quite rare, which Allen believes is because the perceived costs of that communication (particularly for the information seeker) are far higher than the perceived benefits.

Allen defines these costs pretty broadly to include “physical effort, tedium, any loss of self-esteem, or other difficulty encountered in asking someone else for help or information.” He observes that individuals used some common tactics to minimize these costs:

  • Self-denigration, or minimizing their own knowledge and expertise in an attempt to generate empathy.
  • Reading the literature, in an attempt to make sure they didn’t ask dumb questions
  • Interacting exclusively with technically knowledgeable individuals they know socially, since they were less likely to get brushed off or made fun of by those people.

Any of these sound familiar? I know I’ve both used many of these and, perhaps more importantly, had them used on me. This is, for me, a useful reminder that technical knowledge is a form of power, and as holders of that power, simply saying that we want to collaborate and work with others is not enough. We have to actively work to undercut that power and to realign relationships with our colleagues along values of mutuality and humility.

To this end, Allen also proposes some tactics that can be used to systemically manage the costs of asking for help.

  • Time-bound ad-hoc groups and task forces which are aimed at solving particular problems. Allen notes that these groups are probably the most effective means of promoting internal communication, with their effects lasting even after these groups are disbanded. We’ve seen this play out with a number of recent projects: the DIMES-TNG team, the Web Analytics Owners group that Hannah just wrote about, and the ArchivesSnake utilities development team. Going forward, I want us to be more explicit and strategic about pulling these teams together so we can take advantage of both the short and long term effects.
  • Technical discussion sessions, which cover general topics of interest and support knowledge transfer without putting individuals in the position of having to ask for help. In the last few years, the D-Team has been running internal Knowledge Shares where we each take responsibility for presenting to the rest of the team on a technical topic in which we have expertise. These have been pretty effective at spreading knowledge among the team, but this book has me thinking about broadening the audience for those presentations.
  • Technical review panels which provide oversight of key technical problems. Allen emphasizes that these panels must exclude most managers other than low-middle managers, and that the project team must select members of the panel based on who they feel can be the most helpful to them. This is something I want to do more of. Some of our efforts with the usability testing observers group gesture towards this approach, but in general we haven’t been very explicit or intentional about employing this tactic.

More generally, Allen points to some shifts that need to be made around expectations and organizational culture. As a manager, this was the section of the book that spoke most directly to my experience and priorities.

  • Structure organizational rewards systems to reflect the importance of bilateral communication. Bake cross-departmental and cross-unit communication into job descriptions, reporting and evaluations. Employees should be confident that seeking information will be seen as a positive thing - “an attempt to increase their own competence” - not as a reflection on their lack of knowledge.
  • Reframe values around the exchange of information, or as Allen put it “Efforts must be directed towards changing the attitudes of the people involved in such a way that they will weigh the values of problem-related and solution-related information equally. The project members must be viewed not merely as information seekers but also as suppliers of valuable technical information on the nature of the problems to be solved.”

These are both things that will require concerted and sustained effort at all levels of the organization, and in some cases may not be entirely achievable. Still, articulating these as areas of long-term effort is useful for the D-Team. More generally, the insights of this book are an excellent reminder of the power that is embedded, whether we like it or not, in all our work relationships, particularly when they involve specialized knowledge. Instead of putting the onus on others to come to us with problems to solve and opportunities to collaborate, we need to proactively diminish the real and perceived costs of those interactions.