21.2: Group Dynamics

Group Dynamics

In engineering groups of engineers and other interested parties are assembled to solve problems. Most significant engineering and science problems require multiple inputs from a variety of people. Group dynamics are generally reflected in periodic meetings. In this context, properly run meetings are a very useful technique to help work through problems. Unfortunately it is possible for meetings to be poorly organized for a variety of reasons.

• Some reasons for poorly organized meetings
  • Different motives with each individual
  • Conflicting motives for each individual

The premise here is that effective group dynamics is the best way to solve complicated problems. This is borne out by experience by the authors at least.

• Effective group dynamics requires a level of professionalism
  • Members of a group must take responsibility and share of the work
  • Members must be dedicated and engaged
• Effective group dynamics requires a "schedule of things that should be done"
  • Define the problem (this is not as easy as it sounds)
    • There must be a clear and specific definition that is able to be solved, not a vague definition such as "build a bridge"
    • A purpose needs to be considered as part of the definition of the problem (what is the purpose of the bridge?)
    • Conditions must also be part of the definition of the problem (we need to build a bridge in a swamp, say)
    • Material limitations would be part of the conditions
  • Explore solutions to the problem
    • Research previous solutions or similar problems that have been solved or partially solved
    • Read peer reviewed papers that related to the problem
  • Plan how to implement the solution
    • Design based off previous works with maybe some innovative changes
    • Innovative changes are always welcomed BUT will delay projects due to the need to prototype before implementation
    • Note sometimes innovative changes are previously tested and investigated in other projects that eventually rejected them for time or money; so don't hesitate to do research...
  • Do the work
  • Did the project work as designed by your group?
    • Evaluate periodically and write reports (these can be used for future projects)
    • It is quite possible a project will work perfectly for many years but then a unforeseen flaw will be discovered...documenting is important for future projects
    • Documenting is important in all aspects of engineering from "hardware" to "software"
• Effective group dynamics requires full participation
  • Each member must define, explore, plan, and evaluate through research and discussion
  • Depending on the situation each member should be involved in the actual hands-on work, BUT only to the level of their expertise
  • Discussion is done before work is started
    • Get everything straight on paper in theory first
    • Don't rush to hands-on work (think first or to put it in a more classical way "measure twice THEN cut")
    • Prototype if necessary
  • Document (ALWAYS!!!)
• Effective group dynamics requires proper leadership and defined roles
  • Each member should have a role (some roles can have more than one person)
    • Coordinator (leader)
    • Checker (the thinker?)
    • The recorder
    • The skeptic (asks questions; doesn't accept - "we all know this")
    • Various "experts" or coordinator of experts (vice-leaders?)
  • Key to this is a leader - a leader must not stifle the though process and discussions however he must make sure the discussions do not get "out of hand"
    • Keep the meetings flowing
    • Don't allow one subject to dominate for months
      • Leader A: Ok this discussion has gone long enough, lets call it with the solution most are agreed upon
        • Good, but must not do this immediately - make sure every important detail is fleshed out
      • Leader B: Oh I don't want to make a decision, let's just keep on talking until we all agree years from now
        • Bad, nice that the leader tries to get everyone to agree, but at some point things must be decided

Let us take a closer look at the various roles:

• Leader
  • Organizes assignments and assigns tasks
  • Keeps group on the task at hand
• Checker
  • Monitors the groups comprehension of the subject at hand
  • Monitors the solution process
  • Checks "facts"
• Recorder
  • Monitors consensus on solutions
  • Writes solution (or edits and annotates)
  • In charge of documentation but does not write all the documentation (all members do that)
• Skeptic
  • Plays "Devil's Advocate"
  • Makes sure the group does not reach a conclusion without a full understanding
  • Suggests alternative solutions
    • The idea is that the skeptic would say that he might disagree but also presents an alternative solution
    • Does NOT just say "why?" or "prove it" but says "why do you think this bridge concept will not sink due to its enormous weight?"

Sometimes it is suggested that roles be rotated though there are problems with this concept.

• Roles should rotate but doesn't necessarily have to rotate if one member is "gifted" at the process
  • Some people just can't lead, though most should be able to do this role
  • Skeptics are generally skeptics by personality so rotating this seems to be counterproductive

For meetings there is a delicate balance of getting work done and going to meetings. If your day is filled with meetings it will be impossible to get any of your detailed expert work done. Meeting should have a gradient of scheduling that represents how far the group have progressed.

• Group meetings
  • Group meetings should be targeted and not general
    • With general meeting many people just should not be attending as it is not relevant for them
    • Large meetings are difficult to control and tend to be dominated by the loudest voice rather than be expert opinion
    • Group members can be in more than one group meeting
  • Scheduling of meetings depends on where in the solution or completion process you are at
    • Initially meetings should be one to two times a week
      • This is when the problem needs to be defined clearly and initially solutions need to be worked out
      • Requires more meeting to keep everyone on track
    • As time moves on meetings should spread out to one meeting a month
      • Need time for details to be worked out which usually take longer then initial solutions
    • After a solution or solutions have been implemented meetings should still continue with a meeting every three or four months
      • Monitor the final project for future projects
      • Note problems in design which need to be documented so future projects won't repeat these problems

Finally accountability is very important.

• Each individual is accountable for participation
  • Member should be informed early if it is believed they are not contributing
  • Each member is expected to contribute even if it is outside their realm of expertise: you should have sufficient academic training (physics, chemistry, system and signals, computers, and mathematics) to discuss any engineering discipline knowledgeable (but not as an expert unless, of course, the discussion is in your actual discipline)
  • If a member expects to just sit in on a meeting but not contribute they should be removed from the group (after given a warning to reform their ways)