Managing the Java DB 10.2 Project
By MortazaviBlog on Jun 22, 2006
Managing and leading the Java DB 10.2 project, which involves the coordination of Sun's contributions and involvement in the Apache / Derby 10.2 effort, has taught me some valuable lessons regarding medium size projects composed from large global distribution of resources and effort crossing national as well as firm boundaries.
To begin with, when some 25 highly talented, technical and professional people from Sun work full or part-time in three major time zones (San Francisco Bay Area, Bangalore, Trondheim), the project manager as well as many of the leads and participants have to split and extend some amount of their working hours among all these zones. (For example, this week while working from my brother's apartment in Wiesbaden, Germany, my own work day has extended most fully, spanning both the Bay Area and Trondheim and a good chunk of the time in Bangalore. When we first released our Java DB package for Mustang, we coordinated qualification, evaluation and anticipation of JDBC 4 API changes across all three geos. The sense, desire and volunterism for collaboration was astounding.)
There are always communication challenges and misunderstandings that demand various types of solutions. E-mail, instant messaging, regular conferences and 1-on-1s as well as small, task-oriented one-time meetings bring together our focused attention on the goals of the global project and the larger community. However, these are simply the basic elementaries with which the team begins in order to bridge the gaps, build concensus and create group purpose. Other means involve conferences and meetings (e.g. JavaOne and ApacheCon) which bring us together in closer proximity to intensify the dialogues and create a more effective conversation within the team. Interactions of the less formal and ordered type prove particularly useful. The more random type of engagement, when possible, has tremendous effect in increasing harmonization of the "vibrating team strings" in all dimensions: personalities, tasks, external contacts, mini team and short-lived task force engagements, etc.
I've seen how people invited to a large room, in one of our global meetings or conferences, meander about to engage in conversations with many of their colleagues generating subtle but lasting effects on the project.
When it comes to the wider team of people who collaborate, on a larger scale, with various functions such as management, engineering, marketing, sustaining and support, the project demands a more formal and broad-based weekly meeting in which the team properly handles and swiftly generates and dispatches necessary action items on the path to successful coordination. The ultimate goal are the deliveries of the project and a quality release.
When this happens, the sense of elation and team accomplishment produces the greatest, most fulfilling rewards for everyone involved, and those who have sat by the wayside either miss the opportunity to be part of it or mistake what is going on for some sort of cult feeling, which it is not. Full engagement in the work of the team and the community becomes necessary in order to understand its work and to appreciate and partake of its accomplishments. It is wonderful and most rewarding to see this when it happens.
The ideal team works like a watch. Conflicts are resolved and lines of communications are clearly set. Perhaps, no place other than a battle field, the proper placement of these lines of communications within the organization are more important than we see in a global project of appreciable size involving more than a couple of dozen people and interacting with even a larger community that goes beyond the members drawn from one's own firm.
The challenges of the open source environment are only matched by the rewards offered by the whole community engaged in veting and examining one's own biases and intentions as well as reaching out to offer help and share knowledge.
Sharing is economically valuable because of the "excess" intellectual powerhouse that exists in all organizations.
In many industries, the high-tech firm has stopped being the absolute work boundary because no firm can fully and optimally deploy the complete impact of its employed intellectual powerhouse due to cognitive limitations of the form noted by transaction cost economists--limitations that have to do with coordination of complex projects and activities, as these activities grow in their intensity, depth of intellectual requirement and fullness of impact.
The sharing environment of the "open source" movement literally brings to life that "excess" capacity that is only "excess" because within the boundaries of the firm it lacks the complete opportunities offered in a larger-than-any-firm community context that can increase and multiply the value of that intellecutal capacity.
More, later ---