Mailinglists and Project Management

Mailinglists are quite useful as a part of daily project management. The way I use them at work is that I post rough ideas to the relevant internal mailinglist. Then my colleagues contribute with their ideas, comments and critique.

If the outcome of all the discussion is that we agree on actions and I am the one in charge to do and/or manage the implementation, then I simply group all emails in my Thunderbird inbox by the subject of the mailinglist discussion. This allows me to extract tasks from the discussions, which I store in the task tracker.

Now, I can keep track of every single issue by assigning each task to a category, giving it a priority, defining a due date, etc. Certain tasks might require some more discussion or consulting with other team members, which is done in the relevant mailinglists again – and this is where the process starts again.

In a nutshell, the approach is:

  1. Post an idea to the mailinglist.
  2. Keep the discussion going until a decision for or against actions has been reached.
  3. Extract tasks from the discussion.
  4. Discuss single tasks in the mailinglist if necessary (go to 1.)

Communication Skills

This seems to be quite simple and obvious, but in fact requires some sensitivity. The inital idea you post to the mailinglist, or the single task you want to discuss in more details, needs to be focused – otherwise you will end up with broad discussions that have no or too many results.

Then again, even a focused initial posting can lead to general questions. Either you moderate the discussion to become focused again, or you take up the raised issues because they might be critical, e.g. being a showstopper, or unclear responsibilities, or being of higher strategic importance.

As you are the one who raised the initial issue in the mailinglist, you should always feel responsible for the thread to be of value to others. Then you will automatically only post stuff which is important. On the other side, you can well invite others to help you become clear about certain problems if you got stuck.

Exchange of Information

Mailinglists are an excellent mean to distribute information within a team or even accross teams. In an ideal situation, they help to find solutions and make decisions jointly, something that fosters the support by each team member to actually implement his tasks.

The problem lies in a potential information overload, that too many people discuss too many issues in a mailinglist. The best way to avoid the overload is to apply the above mentioned communication skills.

As “overload” is also a subjective impression, it can help to learn how to quickly scan emails without reading them in details, to first spot whether they are actually of interest to me. The more subscribers are able to apply this skill, the more quality the conversation will get, as irrelevant postings will not get attention.

If in doubt, it is always better to have communication, even if too fuzzy and too much, instead of cutting it off. The question is how to canalize it in a productive way.

Other Channels

Of course, you can also apply the above said to other communication channels, e.g. forums or IRC chat. They all have their own characteristics though. A forum servers like a knowledge base automatically, similar to a mailinglist archive. Quite different compared to mailinglists, forums are not a push medium, but rather a pull medium, because you don’t get the information automatically to your email client’s inbox.

Open Company Culture

Using mailinglists as a part of project management requires an open company culture to be of benefit. This includes team members who are not afraid of telling their opinion with the risk to be challenged by others. In other words, they need to be adaptive.

In the end, being adaptive is the key of successful communication when implementing a project. Just remember that as a little baby, you were basically only able to screem. Today you can read (I asume so, because you read this blog) – and there’s always more room for the improvement of your communication skills. The main problem seems to be though, that most of us don’t remember the times when they were a baby and think that they’ve been born with ready-made communication skills 🙂

Codified Personality

In Knowledge Management, there are the concepts of codified and personalized knowledge. Wikipedia describes it as

codification vs. personalization – the trade-off between capture and storage of explicit information and making connections to people who know.

This definition was missing the fact that personalization also refers to making external knowledge part of your knowledge, thus I added “as well as to acquire external knowledge yourself” to the Wikipedia page.

Anyway, what I wanted to say is, that it struck me again some days ago, how nicely the personality of one person or a whole group can show up in software. The way how a routine or API is designed can tell a lot about the personality of a programmer and his team:

  • How accurate is the code? (You can tell from that whether they do a wholehearted job and are commited to what they do)
  • How much abstraction is in the code? (Reflects the experience of the developers)
  • How much is the overall design of the software thought through? (A criteria for how well the team can organise itself)
  • How complex is the software? (A sign for a team that can master software by organisational maturity)

This is what you can call “codified personality” – it is what you can also find in arts, in books, paintings, music, etc. Thus, the “vs.” in Wikipedia’s definition of “codification vs. personalization” is not totally correct, because the two concepts are not only opposed to each other, but can also go together nicely.

Of course, it is only a small step from here to ask: If personality is immanent in code, can code change the personality? Strictly speaking, code cannot change a personality, but as code is always the result of humans, it is the social system that those humans live in, which influences their personality. It is not the code that changes the personality of a person or group, but rather the way how the code is treated within the social system you belong to. As software code is codified personality, this is indirectly about how your social environment treats you.

Think of open source and proprietary as social (sub-) systems, and you’re encountering another interesting question: How do software licenses, as part of the regulatory system of your company, influence your personality?

Opinion and Authority

In a company based on hierarchical authority, it is much easier to have a strong opinion when you’re on a high level of the food chain. If you’re on a lower level, the problem is that you might be wrong or that your honest opinion might be something your boss does not want to hear. Thus, you act in an opportunist way and only say what’s mainstream in your company.

Knowledge companies cannot afford to have this kind of behaviour, they need everyone to have a clear opinion. Or put it like this: knowledge companies need to provide the freedom to their employees to have or form their own opinion and communicate it within the company.

An egalitarian organizational structure and predictable working conditions are thus a prerequisite for a successful knowledge company. They cannot afford to have the management rule by verdicts and fear. Instead, it needs to be trust and mutual respect, what drives the management to motivate the staff.
The more quality the opinions have, the better the decision-making within the company, and the more it can act realistically in the market.

Linux goes Management

The way how the Linux community is organised gets growing awareness in management, not only in that of software companies. Harvard Business Review published an article entitled Collaboration Rules, were the Linux community is being compared with the organisational structure of Toyota. The article is in general worth to read. I have read the
German version which is published in the current issue of Harvard Business Manager.

The authors’ basic statement is: “Corporate leaders seeking to boost growth, learning, and innovation may find the answer in a surprising place: the Linux open-source software community.” And they continue: “Specifically, Toyota and Linux operate by rules that blend the self-organizing advantages of markets with the low transaction costs of hierarchies.”

Management will indeed be able to learn a lot from Linux or the FOSS movement in general, as it can be regarded as the prototype organisational form of knowledge work. Today, most products are knowledge-based, even if it is simply the design of your coffee cup. Thus, the culture of open sources can be applied to various companies of any kind.

The article analyzes what I’d call a company culture of open sources, where information is freely shared between various stakeholders of a production process, be it software (Linux) or industrial goods (Toyota). Such a company culture is very much one that gives community members or employees the freedom to develop their skills and personality.

Unfortunately, the article deals with the aspects of knowledge companies for individuals only marginally. It could nicely be approached from the notion of humans as open sources as elaborated in the latest book of Gunter Dueck: Topothesie (German only). Then it becomes obvious, that doing it the Linux way also means a change of management styles and human interaction at work in general.

Informatik 2004 & KI 2004

Now that summer’s over, the second half of this year’s conference season starts. For me, conference hopping resumes in Ulm/Germany, which is just around the corner of my new home town Biberach. Actually, it’s two conferences in one from September 20-24: Informatik 2004 and the other on artificial intelligence.

I will definitely attend the following two workshops (because I am interested in the topic, but as well because I help out the organisers):

Algorithms and Protocols for Efficient Peer-to-Peer Applications

Open Source Software in an Industrial Environment

Haven’t decided yet which other sessions to attend, there are just too many interesting things going on…

Thanks to Alexander Kaiser who made me aware of this fantastic event and who helped me get the ticket 😉

An Introduction to Radical Constructivism

By chance, I found An Introduction to Radical Constructivism online. This article is part of the excellent book “Die erfundene Wirklichkeit” (edited by Paul Watzlawick) that influenced me a lot during my university studies.

Call constructivism my theoretical mantra 😉 It’s the only theory that does not attempt to explain reality and defines truths, but explains why we explain reality the way we explain it – and why we fight for a certain truth. It also serves as a perfect theoretical basis to understand “knowledge” as a social phenomena.

Scientific Publications: "It is the author's work, it is his or her right"

Want to have a deep look inside of major changes in society? This transscript of a discussion on scientific publications in the UK Science and Technology Committee of the House of Commons indicates that the knowledge society is in full swing and that the scientific community is slowly moving towards a more open and free approach towards scientific research and knowledge transfer in general.

This transscript is also a wonderful manifestation of how knowledge mediaries like publishing houses step by step lose power and impact and how the authors of scientific works, the producers of the knowledge goods traded in the scientific community, gain power.

Session at LOTS, the 'Swiss LinuxTag'

ZZ/OSS CEO Sandro Zic will present a session about Free Software in the Knowledge Society at the first LOTS event, a kind of Swiss LinuxTag.

Come to Bern at February 18th and hear about the following:

This talk will concentrate on an often neglected aspect that the Free and Open Source Software (FOSS) community introduced to society: A new organizational form of knowledge work in networks of excellence. Due to the fact that FOSS developers and projects act in distributed and heterogenous knowledge networks and furthermore collaborate in self-organised groups, they serve as the prototype elements of the emerging Knowledge Society.

Sandro has presented this talk at LinuxTag 2003 – but don’t expect it to be the same, because the presentation style is interactive, with Sandro discussing most of the aspects with the audience. Thus, the session itself is a show case of impulsive knowledge work inspired by the spirit of the FOSS community.

Stigmergy is the Answer

Ever wondered why the Web works? Not from a technical, but from a sociologic viewpoint: Why do human beings still invent and use the Web?

Stigmergy is the answer, says Joe Gregorio:

The World-Wide Web is human stigmergy. The web and it’s ability to let anyone read anything and also to write back to that environment allows stigmeric communication between humans. Some of the most powerful forces on the web today, Google and weblogs are fundamentally driven by stigmeric communication and their behaviour follows similar natural systems like Ant Trails and Nest Building that are accomplished using stigmergy. The web is new. In the context of written human history is barely a blink of an eye. Yet as new as the web is, it is already showing it’s ability to support complex human interactions that mimic natural systems use of stigmergy. And were just getting started…

Now you wonder what Stigmergy is? It’s all explained in Joe Gregorios blog entry on Stigmergy.