In addition to the usual litany of technical problems, every programming organization must continually grapple with other issues that can be quite formidable, and if not addressed may become destructive. However, if recognized and properly handled, these issues provide opportunities for growth for individuals within the organization as well as the stature of the organization itself. In our experience, one critical component is participation. Organizations where members distance themselves from each other, or from issues, tend to languish, while organizations where members actively participate tend to flourish.
In our environment, the development of new drugs and vaccines requires lengthy clinical trials, during which the new entity is administered to humans. Voluminous data is collected, analyzed, and reported as we help conduct this work as members of the statistical programming department at a major pharmaceutical company. Although elaborate plans are made to guide the programming work, that work remains akin to a classical job shop.
The actual work consists of a mixture of large systems development and implementation, sizable programming tasks to support statistical analyses of the clinical trial data, and ad hoc programming tasks to support short-term requirements. Our department comprises about 45 people who are divided into smaller groups based upon therapeutic categories; each of these groups has a manager. Various ethnic groups are represented in the department. Educational backgrounds are also diverse, but a master’s degree is typical and doctoral degrees are common. The field of study varies greatly, and includes statistics, computer science, engineering, and physics, as well as different branches of the biological sciences such as medicine and epidemiology.
With this number of people—divided therapeutically, culturally, and by education—interaction and communication tend to be limited. Thus, it seems the opportunity for professional growth is constrained. Various articles have explored this lost opportunity and ways to overcome it, but our observations suggest the results are not universally successful.
We also recognize the infamous Hawthorne effect. Regardless of the exact interpretation of that phenomenon, it is intuitive that interaction among peers and attention from authority figures are factors in improving both the perceived quality of work life and overall productivity.
We have informally identified three important components of our growth: teamness, leadership, and quality. Attention to these components tends to enhance job satisfaction, promote professional growth, increase productivity, and foster customer satisfaction. We anticipate that staff retention will also be improved.
Teamness obviously refers to the ability of the individual to function as part of a larger team. Although the entire team working on a specific project may encompass dozens, or even hundreds, of people, the typical programmer has close interaction with only a handful of people—a handful that may or may not include other programmers.
Although many organizations claim to promote leadership, ours delineates 60+ characteristics of leadership that further both individual competencies and the company’s goals. We believe that technically oriented people, such as programmers, tend to ignore leadership and other "soft" skills, but these skills are vitally important.
Organizations where members distance themselves from each other, or from issues, tend to languish, while organizations where members actively participate tend to flourish.
Our department’s software development life cycle helps ensure the quality of our work, but challenges arise regularly. Although any specific individual certainly believes that his or her technical solution is high quality, situations occur that allow solutions to be implemented without rigorous peer consultation.
Team-building workshop. There is a myriad of public classes, seminars, and workshops purporting to build teamness, and we recognize that many of those can be valuable. However, the size of our department and the nature of our work allowed us to structure a workshop to meet our specific requirements. Our staff was queried about needs, and the responses allowed an external consulting firm to customize a two-day workshop, but the days were not consecutive, thus minimizing the interference to our regular work and allowing the participants to focus on the workshop. Throughout the workshop, the level of openness and candor was high, which was both surprising and a positive indication of its success.
Paramount to the workshop’s achievements was management followup. The programming management team collected notes during the workshop and subsequently categorized issues. Quick fixes were rapidly resolved. Some issues required further investigation, and this work is ongoing. Other issues were not readily resolvable, perhaps due to financial or similar considerations. Overall, the keys to the workshop’s success were relevancy to programming, participation and candid input, and management follow-up. However, many of the comments were high-level departmental or administrative issues (such as the duration and frequency of meetings) and did not expose small-team programming concerns.
Technically oriented activities. Recognizing the team-building workshop did not directly address technical concerns, a smaller-scale activity was designed involving about six technicians and lasting about two hours. The participants were divided into teams of two or three, and the group was presented with a technical problem. Each team worked independently on a solution, which was then presented to the group for discussion and critique. The limited time required each team to focus on providing an approach for a solution, rather than a complete and comprehensive solution. Lastly, the facilitator presented a complete solution for discussion.
Central to this activity is the ability to work collaboratively, and to work toward a hypothetical solution rather than actual code. Planning and communicating are paramount. Within each team, consensus must be reached on a single approach that will be presented. During the activity, no actual coding is performed, and the presentation consists of pseudocode, an outline of the logic needed to resolve the problem, or something similar.
Also key is the specific technical problem, and a practical constraint on this activity has been our ability to find or invent problems relevant to our work, a mix of theoretical and practical considerations, appealing to various technical levels, conceptually simple but challenging, and so on.
One interesting twist with this activity has been the request to eliminate the working managers. It has been surmised that the presence of a manager may impede a participant from sharing ideas or challenging points presented. Although the original facilitator, a manager, has been replaced by a member of the technical staff, the problem is the managers are also working technicians and would benefit from participation. A practical solution to this dilemma has not been found.
In an effort to focus more on technical collaboration, this activity has been modified to allow each team to actually code their solution to the problem. This has required some creative thinking to devise problems that not only meet the earlier criteria, but also allow for actual coding. Each team is allowed one computer, and that in itself tends to force collaboration.
With actual code, the participants tend to emphasize technical excellence, but the team building and leadership components are not lost. As with the former activity, management has been excluded, and the sessions are facilitated by a member of the technical staff.
In addition to these activities, individuals are pushed to communicate technical tips to the entire department, to make conference presentations, and to present their work in-house to various audiences. We believe this level of participation helps build a well-rounded technician. This kind of activity is beneficial to not only the participants who want to further develop their technical skills, but also to the facilitators who want to build their leadership skills.
The Next Step
We believe we have seen improvements in our department resulting from these activities, but these are not one-shot solutions. Group activities will continue, and we will work toward improving the content. The larger organization, to which our department belongs, sponsors a continuous process improvement team, and we are working on ways to collaborate with that team and look at additional ways to make improvements to our processes and methodologies. The open format of the activities also offers the possibility of conducting such activities with customers outside our own department.
As individual and departmental abilities grow, it is natural to seek a link to recognition and rewards. Our overall organization has a formal mechanism for tying this type of feedback to our activities; thus we believe that active participation will be rewarded both tangibly and intangibly. We also seek to learn from others, for example, SEI, and to apply those learnings.
It should not be surprising that one significant hurdle has been the objective measurement of the results of this work. Subjective feedback is supportive, and we have decided that objective measurement is not warranted at this time.
Conclusion
We have presented three ideas for building a participatory programming environment, along with anecdotal support for having such an environment. We believe these approaches can be readily adapted for use in other organizations, and the results will be increased teamness, a growth of leadership skills, and improved technical quality.
Although our work seems quite intuitive, our aggregate experience shows that other organizations are reluctant to take active steps toward building a participatory programming environment.
We hope our programming environment experience will provoke discussion within other programming organizations.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment