Today we continue our acquaintance with the book " Team Geek: The Ideal IT Company " by Brian Fitzpatrick and Ben Collins-Sussman, dedicated to communication "at work" in all its forms. Last time we started with intra-team communications and talked mainly about how the mindset of each individual employee affects them. This time we have to look at the team more broadly - as a united group with its own internal culture, which is somehow formed and needed for something.
Team culture is a set of knowledge, values, and goals specific to a particular group of programmers. This includes the methods of creating program code, and the style of communication between people, and the ways of organizing the workflow - there are a lot of components. Some of them are not too critical, they come and go easily (for example, the custom of ordering pizza and playing board games on Fridays), others form the "backbone" of the culture and can survive entire generations of programmers (for example, procedures for the processes of code inspection, testing, documentation, etc. Further).
In its original form, culture is usually set by the founders and the original technical team. Subsequently, it inevitably develops and undergoes changes, but for strong, proven teams (Google, Apple, Microsoft, Oracle can be cited as an example) most often retains its original face to some extent - the connection with the roots is not completely lost.
Contrary to popular misconception, team culture is not entirely in the hands and conscience of the leader. If it really exists (about what happens if there is really no culture, we'll talk a little later), it is broadcast by almost all employees. This becomes apparent when you look at how a newcomer team usually integrates. The new developer gets an idea of how it is accepted here, what is important and what is unimportant through interaction with colleagues: what is paid attention in his code, how and in what tone they explain the need for fixes, how conflicts are resolved.
Self-sustaining team culture: a bakery metaphor
Why work on team culture?
So, the culture of the team is a kind of diffuse mixture of different attitudes and agreements that allows people who work together to stay on the same wavelength. A natural question arises: Is it worth worrying about this? The mutual influence of employees on each other in the process of work occurs naturally, so that any culture is likely to form by itself.
The problem here is that, as with all spontaneous processes, a spontaneously evolving culture will generate more entropy and may produce unpredictable results. In other words, sooner or later there will be people who will decide with their own hands to determine "as is customary here." If they turn out to be sane and act in the same direction, the ending will be happy. But more often than not, it turns into the same good old office wars or, even worse, pockets of decay within the team.
So letting things go is not the best choice. Above, we talked about the fact that culture cannot be forcibly instilled, but you can approach its formation with awareness. If each participant not only behaves in accordance with the principles from the last chapter, but also tries to bring them to the level of the team, suppresses actions that are dangerous for cooperation, and is not afraid to negotiate common rules for everyone, the risk of unpleasant surprises decreases.
What should be the team culture?
It is, of course, impossible to answer this question unequivocally and exhaustively. Crops are extremely diverse, and the range of healthy, productive variations is wide. Well-organized and comfortable work can be both in a chaotic start-up, where everyone is “on the board”, and in a large company with clear processes and keeping a distance. Trying to set a benchmark for each of the many elements is pointless.
In the most general terms, culture should be:
- . . , , . , : .
- . , , , , . . , , – .
- . , , , : , , . , – , .
- . , , . , . , .
Communication channels are the easiest component of culture to control, and the authors pay the most attention to them. However, before going into their details, they give a couple of tips on other, more subtle elements.
When it comes to ways of making decisions, then for the most part programmers prefer democratic models. Perhaps this is due to their notorious desire for independence, or maybe the fact is that the profession is inherently creative, but the fact remains: it is important for developers to have a voice and the ability to share their own thoughts. Leaders should take this into account when organizing decision-making processes. It is not necessary to resolve all issues by a general vote, it is enough that the employees are really listened to and the system presupposes enough consensus for them to feel their ownership.
As for the manner of communication, she should gravitate towards emphasized politeness rather than aggressiveness. The problem with teams that tend to assert themselves with a shout or assertive tone is that they push away and overwhelm calmer people. A person prone to conflicts will feel quite comfortable both in an aggressive environment and among polite people. A calm, reserved person (of which there are many among programmers), on the contrary, will not be able to open up properly in an aggressive team. Accordingly, by encouraging or simply adopting an offensive manner of communication, we automatically cut off some of the potential strong employees. This is impractical.
At the same time, it should be understood that the culture of correctness and mutual respect is more fragile and vulnerable to external influences. One assertive beginner is enough to shake the harmony. Therefore, it is very important to completely suppress any attempts to go against the accepted manner of communication and prevent people from gaining victories through destructive behavior. The best way to do this is to simply refuse to communicate in an aggressive tone.
Communication channels
We have found that the fixation and transmission of information plays a decisive role in team culture. In modern conditions, many tools are available to us for this purpose; this section provides an overview of only the most common.
A common feature of successful teams is that they actively use various communication channels to ensure that everyone remains aware of both the general direction of movement and the current progress of work. At the same time, the emphasis is on those channels that, firstly, make information publicly available, and secondly, make the most of the possibilities of asynchronous communication.
Further, the authors consider a number of specific tools through which communication takes place in technical teams; clarifying their purpose and rules of use.
Mission definition
From such a title, the reader-programmer will probably cross himself, but in fact, everything is not so scary. In technical work, the mission is formulated at the level of individual projects and aims not to praise the company in vaguely ornate terms, but to clearly indicate what is being done and what is not being done. In other words, a mission statement is a laconic definition of the direction of product development and limiting its scope.
Let's say so:
GWT's mission is to radically improve the user experience of the World Wide Web by enabling developers to leverage existing Java tools to create AJAX applications for any modern browser.
As people actively involved in open source projects, Fitzpatrick and Sussman could see from their own experience how much time, energy and nerves such a measure can save for the team in the long term. When new participants are constantly joining the work, each with their own ambitions, comments and bright ideas, the “core” of the group should have a clear and uniform understanding of the essence of the project. Otherwise, the work will either go according to the scenario of the fable of the swan, cancer and pike, or it will constantly thrombus due to attempts to clarify these issues along the way.
Accordingly, a mission statement is useful in two ways. First, if there is disagreement among the key stakeholders about the goals and scope of the project, it will surface immediately and be resolved without delay. Secondly, the result of the discussion will be a document with the main theses, to which it will be possible to refer dull or overly zealous newcomers.
The mission statement gives the team a foothold in any decisions regarding the project, but it should not be considered absolutely inviolable. Sometimes it happens (primarily in startups) that the goals or circumstances of work change radically. In emergency situations, it makes sense to honestly assess whether the original mission is still relevant and amend it accordingly.
Project documentation
If the mission is designed to develop a single answer for all project participants to the question "what", then the project documentation implies a similar work on the question "how".
The project document presents a more detailed sketch of the future project and its technical stuffing. Typically, it has one owner, two or three authors, and a fair amount of reviewers contributing their comments. Writing documentation, no matter how hard it is to put up with it, should precede the work on the code - the moment when not a single line has been written is best suited to listen to criticism and adjust implementation plans. The finished project document is very convenient to use when drawing up a roadmap, highlighting stages of work, and so on.
Design documentation by its nature is much more flexible than the mission statement; it is not a dogma, but a living substance. During the development process, it is necessary to revise some details, and ideally, the documentation should reflect all these changes in real time so that the team can keep abreast. In reality, alas, it is often edited after the release of the product.
Meetings A
lot of people will think that it would be nice to make the sign of the cross here too - meetings have a rather bad reputation among developers. According to the authors, the reason is that they are poorly organized and are often used where it would be more reasonable to turn to an asynchronous communication channel.
A good example of an unsuccessful choice of the format is the “meeting”, which is held with a given regularity (usually once a week) and a lot of people. Usually important announcements are read there, general results are summed up, and so on. In fact, all the content of the flyers is very easy and productive to translate into an electronic mailing list, except for those cases when it is precisely a broad collective discussion that is needed.
As for the meetings, which you really can't do without, the following rules should be kept in mind when conducting them:
- . – , , , . « » — . , - .
- , , . , . , , .
- . – .
- (, ). , – Google .
Mailing
Lists Email is a very useful tool for documenting project history in the background. It is much easier to extract information from it than from messengers, where there is much more traffic and much less regulations. Therefore, it is advisable to send all important information in mailing lists, regardless of where it sounded before: copies of plans and notes from meetings, the results of discussions on certain problems, project documents, analysis of errors. Thus, a centralized data warehouse is formed, where at any stage it will be possible to return in order not only to find certain information, but also to trace the origins of decisions and the course of the discussion. Of course, the archive must be equipped with an indexed search.
The importance of documentation and, accordingly, mailings is determined by how compactly the team is placed in space. If some employees work remotely or show up in the office on an irregular basis, the steady practice of duplicating major project news by mail becomes an urgent need. Otherwise, most of the information that "is in the air" (discussions in corridors and near tables, oral transmission of new information to those who were not at the meeting) will pass them by.
If the team is large and the processes are turbulent, participants will soon begin to drown in a stream of heterogeneous announcements. In this situation, the documentation is divided into different thematic mailings (development, analysis of program code, user support, testing, and so on), which include interested employees. However, it is better to start with one stream - if there is a need for separation, they will quickly convey this to you.
Online messengers
Messengers stand somewhere in the middle between synchronous and asynchronous communication. They are not optimal for documentation, but they are indispensable for quickly resolving issues, especially in distributed teams. From the point of view of command culture, two aspects are important here.
First, the dividing line between private and public discussions. The overwhelming majority of both internal and commercial messengers give the user the opportunity to choose between communicating with a specific person or a group of people, and this is very convenient. However, according to Fitzpatrick and Sussman, there has been a tendency towards isolation lately - discussions are increasingly taking place in private.
In some respects, this is not bad - private issues will definitely not "clog the air" to all employees. But on the other hand, people are deprived of the opportunity to follow the course of the discussion, insert their comments, and immediately learn about the changes. Newbies also lose a lot, as they could gain a lot of valuable information simply by silently reading active discussions in the general chat. Often, discussions go into private, not because they are too niche, but all because of the same fear of vulnerability: you don't want to ask questions or make suggestions in front of everyone - what if they turn out to be stupid? Developers should catch themselves on such motivation and try not to hide what is wiser to remain in the public domain.
Secondly, you need to remember that instant messengers, despite all the instantaneous reactions, are not a complete substitute for live communication. They do not have intonations and facial expressions that could soften or clarify some phrases. This increases the risk of misunderstandings that threaten the principles of modesty, respect and trust, and this should be borne in mind.
Bug Tracking System
This tool is not as common as those mentioned above. It can be of great benefit under certain conditions:
- Availability of a procedure for processing and sorting errors, which ensures their timely registration and correction. If the debugging of the system is not given enough attention, people will either not use it, or they will abuse it in small ways.
- . « » , .
- . – .
- . , , .
Communication as part of development
Communication in the technical team takes place not only around, but also directly within the code. The main channel here is, of course, developer comments .
The authors briefly touch upon the basic rules of code commenting, which are probably familiar to everyone: explain not what is being done, but why it is being done, try to comment at the level of functions and methods, be laconic and not get carried away with details. The rest of the commenting style is a subjective thing, each team develops its own depending on the needs and general atmosphere. The main thing is that this general style should exist in principle; the very fact of uniformity in this case is more important than specific characteristics.
Another way of communication within the code is attribution , that is, the developer's signature in the file. The custom to leave your name on a document came to us from ancient times; in old programs, you can often see such autographs:
Fitzpatrick and Sussman insist that today these signatures should be considered anachronistic. From a psychological point of view, the desire to indicate authorship, of course, remains natural and understandable: this is a manifestation of pride and a sense of responsibility for the work done. On the practical side, however, this poses more problems than benefits. Now development, as we already established in the first part of the article, has become a team activity. In reality, several people can be involved in one piece of code at once, which means that solving the issue of authorship can cause controversy, resentment and, ultimately, waste of time.
In the current environment, it is more expedient to keep track of authorship at the project level, rather than directly in the code. When you need to find out exactly who to contact with questions about a particular part of the code, the version control system will come to the rescue.
Now that we have looked at the core of the "human dimension" in an IT company from all sides, we can move on to the peripheral layers: foreign elements that surround teams and users.