Teams with long histories have a leg up on competing teams in that they can leverage experience in their decisions. There are many ways a team can learn from past successes and failures. This page outlines a few of the ways teams can leverage past activity to best inform current and future development.

Teams are charged with discovering and integrating information from a variety of sources to solve the problems they face. There are no hard set rules for how to best do this; indeed, many problems can be solved with information from a variety of competing sources—some better, more efficient, or more correct than others.

If only we knew then what we know now.

In many instances, the tools and resources required to solve a problem are already known by the team in some form. Tapping into this internal knowledge base is not easy, however, and, in larger organizations in particular, such collective amnesia can be a large problem.

Here are a few ways teams discover, remember, and forget information they should probably already know.

Team Documentation

In the course of a its work, a team will usually generate a lot of artifacts and information valuable to its own experience and that of future teams. Documenting and storing this information is a complex process.

Many teams have to produce formal documentation to enter a competition or to meet course credit requirements. These reports can be a valuable source of information.

Teams should realize, however, the limitations of this sort of information, especially as an exclusive source. Some engineers are simply not good writers and do not enjoy spending time to create proper documentation. Their reports can be slipshod and quickly dashed off to meet certain requirements; if so, their utility can be compromised.

It is also easily possible to become overwhelmed with too much information. The FSAE team, for example, has personal and technical reports dating back to the team’s early operations 17 years ago. This database of 1500+ reports is a valuable resource, but finding particular details is like searching for the needle in the  haystack. The team has dedicated time and resources to digitize this information and is looking at ways to implement full-text searching on this database, but this is understandably a project that takes time and isn’t a short-term core goal for most team members, who are, in the end, engineers, not information scientists.

Even well-written reports are often not the best way to represent the full complexity of information. Formal reports are by definition edited documents, which suggests some information is necessarily left out to make the main points. Having access to the raw data behind the reports (e.g., test data, design notebooks, general notes) can often help fill in the gaps.

In addition, some processes and procedures aren’t easily documented. A report on welding, for example, will not simply transfer all required knowledge to the reader. Much knowledge and skill in welding is experientially based, and no report, no matter how well written, can faithfully replace hands-on experience with the art.

All this noted, it is still essential that the team’s practices are faithfully documented and stored for future teams’ investigations. Team documentation can be an excellent base from which to begin investigation, but team members should be cautioned that this, as with other sources of information, has limitations.

Learning from Team Members

Regardless of the team’s approach to documentation, a lot of key information exists as the experience of fellow team members. Sometimes the quickest and most effective means of discovering information can be a simple e-mail or phone call.

Team leaders and faculty advisors are an obvious first source of information. Team leaders are usually experienced with the team and its operations and, by acting as systems integrators, may have relevant knowledge from other subteams’ work. Faculty advisors are often even more experienced and able to share information from their own research; they can also refer team members to their colleagues for additional support and advice.

Despite this, it is sometimes difficult to solicit team leader and faculty advisor advice and guidance. New team members in particular may find it intimidating to reveal their lack of knowledge, and so they question the best available sources much later than they should. Team leaders and faculty advisors can help mitigate this by engaging team members in discussion and making themselves available to share information. This can be done through structured access opportunities such as office hours (in teams such as Solar Decathlon, team leaders also hold office hours regularly) and by leaders’ and advisors’ filling in gaps in their knowledge (e.g., asking questions and providing input in design reviews, providing lectures on core topics, etc.).

Although senior members and faculty advisors are valuable sources, good information also comes from listening to the experiences of newer team members. Many people have gained experience from other sources (e.g., hobbies, jobs) that can be very valuable. Teams should try to ensure that organizational hierarchy does not interfere with information flow; the quality of the information is more important than its source.

A team’s alumni network can also be a valuable source of information. Many team alumni are happy to keep in touch with the team and its activities and are willing to provide background information on how and why they did what they did. In terms of team documentation, contacting the initial author if possible is usually the most efficient and correct way of resolving any issues with a particular report.

Learning by Doing

Sometimes, the best way to truly understand a given problem is to immerse oneself in it, even if others have already done so. This is particularly important for tacit, intangible sources of knowledge, such as the welding example noted above. No amount of research or consultation with experts will replace learning to perform a proper TIG weld by doing one.

Learning by doing is sometimes dismissed as a waste of time. If the team reinvents the wheel, it can be. But in some instances it can be valuable to gain practical, experiential knowledge concerning a given problem, and providing the time and resources to do so is a worthy investment. Given that learning by doing can take a considerable amount of time, however, it is something that should be encouraged early in a team’s schedule and perhaps limited as key deadlines approach.

You might not know everything...

No matter how skilled the team members, leaders, and advisors are, inevitably the team cannot know everything internally and must seek advice, information, and feedback from external sources. This note explains how to do this.