Managing a team to work effectively and efficiently is one of the most common problems that managers have to face and I am no exception, as I currently work as R&D Director.
Effectiveness and efficiency of working teams are probably some of the most studied and debated issues in the field of management theory. [1] Tons of papers and books are available. However, the majority of the studies address large companies, where the hierarchical structure is usually clear and the roles are well defined.
In general, this may not be true for the small companies like the one I work for nowadays. In these firms, teams are often understaffed and, consequently, everyone has to develop a good mental flexibility in order to deal with different kind of tasks. The team I manage is a good example of this condition. My company designs and manufactures electronic devices (aka embedded systems) for a variety of markets, including but not limited to automation, transportation, industrial, telecommunication, and biomedical. If we were a large company, the R&D team would probably consist of highly-specialized technicians (i.e. hardware engineers, software engineers, system architects, etc.) and each one would operate in a well defined area. Instead, over the years we have developed engineers who can deal with different issues, although each one is of course particularly skilled in one or a few fields. This choice has proven to be a winner in the medium term because it improves the individual productivity dramatically. When it comes to the embedded systems, in fact, hardware and software are closely linked and there is no a sharp border between the two. The capability to cope with both hardware and software issues (to a reasonable extent) allows the engineers to achieve a good level of independence when it comes to troubleshooting and debugging.
An effective sharing of information is another relevant goal that the majority of the teams—and the organizations in general— pursue. In the context of my team, this means to bring to the notice of every member the specific problems each one had to deal with and how they were solved. When anybody has to face the same or a similar problem, he will retrieve such information which will help to solve the issue more quickly and more effectively ,avoiding to reinvent the wheel. At the end of the day, sharing such information allows again to increase the overall performance of the team.
Now, the question is: how to put into practice the pursuing of these goals in a resource-constrained environment? I’ll try to answer this tough question by describing what I do with my team. Everything started last year when I attended a course whose name in English should sound something like: “Gym of … psychology and software development”. The course was held by two university professors and entrepreneurs who deal with software engineering and by one psychologist who has specialized to collaborate with work and sports teams. The classes focused on the most important aspects related to the building of software development teams. These kind of courses are very valuable because they provide helpful information that is based on years of on-the-field experience. However, I think that you can’t expect to take what you learned and apply it “as is” to your work context successfully. Each team and each company has its own peculiarities and the manager is required to fit the methods that he studied to its specific context.
In my case, I put all of this into practice by “inventing” and formalizing what I called sharing meeting. The primary objective of such meeting is the sharing of information, as previously described. From the formal standpoint, I conceived it to be very flexible in order to fit the easy structure of a small company. This is how it works. Each member of the R&D team is free to note down everything that he thinks should be brought to the notice of his colleagues. These notes are written in an open-access page of our internal wiki site. From time to time, I have a look at this page and when I think there are enough topics I set a sharing meeting for all the members of the team. During the meeting, everyone who wrote down anything illustrates to the other persons the problems he dealt with and how he managed to solve them. This brief presentation is generally followed by a short spontaneous Q&A session in which some aspects are explained in more detail and also different standpoints and opinions are compared. All of this, combined with the use of a wiki-based documental system, leads to a sort of constantly-growing common-knowledge repository that is shared across all the team and from which every member can draw on.
I take the opportunity of the sharing meetings to achieve another goal that I think is extremely important: the sense of belonging. Projects’ deadlines are typically very tight and my team is often under pressure to meet them. As a consequence, my colleagues are usually focused on the tasks that have been assigned for weeks or even months. This may tend to “isolate” them from the rest of the team. For instance, it may happen that one is not even aware of what the colleague sitting in front of him is working on. Therefore, at the beginning of each sharing meeting, I spend about ten minutes to illustrate all the projects the team—considered as one entity—is working on. Instead of describing in detail the technical aspects of the projects, I prefer to contextualize them in order to show the results that the company has been able to achieve thanks to the efforts of the R&D team too. For instance, I talk about a new design for the customer A operating in the biomedical market that the company was able to win thanks to the product that we developed a year ago for customer B that operates in the telecommunication world. My experience taught me that such examples are very gratifying for the tech guys who spend most of their working time in the laboratory and rarely have the chance to see the final applications where the products they laboriously made are utilized. Also, this makes everyone feel part of something bigger and shows how the R&D team operates with the other departments harmoniously.
In general, I don’t schedule the sharing meeting on a regular basis. Instead, I set it when we have enough matters to be discussed in about 90 minutes. I feel that one hour and a half is a good trade-off, even I admit that I would like it to last longer.
So far, I can state that the sharing meeting has proven to be a very effective tool to improve the overall performance and to consolidate the team, as confirmed by the feedbacks that I received from my team-mates. What surprised me most is the positive effect related to the team-building aspect. Although these meetings were not born to address this specifically, it is probably the most important result they allowed to achieve.
[1] For example, see the activities collectively knows as team building.
LLandre.com 