Working in design teams

Almost no engineering work is done alone. Even a modest project like our community center entrance involves a civil engineer, an architect, a structural engineer for the canopy, an electrical designer for lighting and the door operator, a cost estimator, a contractor and the client. Large projects involve hundreds of people in several companies and time zones. How well those people work together often matters as much as how well any of them calculates.

Teamwork can be learned like any other engineering skill. This chapter covers how teams develop, how to set one up with a charter and clear roles, how to run meetings that produce decisions, and how to plan and schedule work using a work breakdown structure, the critical path method and a Gantt chart. It then turns to the human side: responsibility, risk, feedback, conflict and psychological safety, and finishes with design reviews.

How teams develop

In 1965, psychologist Bruce Tuckman described four stages that small groups tend to pass through; with Mary Ann Jensen, he added a fifth in 1977.

• Forming: members are polite and cautious; roles and goals are unclear.
• Storming: disagreements surface over goals, approach and who does what. Performance often dips.
• Norming: the team agrees how it works, and trust grows.
• Performing: the team works smoothly, handles problems itself, and produces its best work.
• Adjourning: the work ends, and the team hands over and disbands.

The model is a simplification, and teams can slip back a stage when membership or goals change. Its practical lesson is that storming is normal, not a sign of a bad team. Teams that set up clear expectations early (the charter, below) tend to get through it faster.

Setting up a team

The team charter

A team charter is a short document, written and agreed in the first meeting, that records how the team will work. It typically covers:

• Purpose and deliverables: what the team must produce, for whom, and by when.
• Roles: who leads, who manages the schedule, who is the main contact with the client, who owns which technical areas.
• Communication: which channels are used for what, and expected response times.
• Decision-making: consensus, majority, or the lead decides after consultation? What happens when the team cannot agree?
• Meetings: when, how long, and how minutes and action items are recorded.
• Expectations and accountability: what happens if someone misses a deadline or does not contribute.

It feels bureaucratic for a four-person student team, but most team conflicts come from unspoken assumptions that differ ("I thought we'd all edit the report together on Sunday"). Writing them down is cheap insurance.

Roles and responsibility: RACI

Confusion about who is responsible for what is one of the most common causes of dropped work. A RACI matrix assigns each task to people in four ways:

• R (Responsible): does the work.
• A (Accountable): owns the result and signs off; exactly one person per task.
• C (Consulted): gives input before decisions; two-way communication.
• I (Informed): kept up to date; one-way communication.

Meetings that produce decisions

Engineers spend a lot of time in meetings, and badly run ones waste it. A few habits help.

• Every meeting has a purpose and an agenda, circulated beforehand, with a time for each item and the decision needed.
• Start and end on time. Keep design discussions that involve only two people for after the meeting.
• Record decisions and action items, not a transcript. Each action has an owner and a due date.
• Circulate the minutes within a day, and start the next meeting by reviewing the open actions.

Planning the work

Work breakdown structure

A work breakdown structure (WBS) divides the project into smaller and smaller pieces until each piece is a work package small enough to estimate, assign and track, typically a few days to a few weeks of effort. The top level might be design, approvals, procurement, construction and handover; design then breaks into survey, concept, detailed design and so on. A good WBS covers 100% of the work, including easily forgotten items such as reviews, permits and documentation.

The critical path method

Once the activities, their durations and their dependencies are known, the critical path method (CPM) finds the shortest possible project duration and the activities that control it.

• Forward pass: each activity's earliest start (ES) is the latest earliest finish (EF) of its predecessors; EF = ES + duration.
• Backward pass: starting from the project end, each activity's latest finish (LF) is the earliest latest start (LS) of its successors; LS = LF − duration.
• Total float = LS − ES: how much the activity can slip without delaying the project.
• The critical path is the chain of activities with zero float. Any delay on it delays the whole project.

Shortening the project means shortening critical activities, a process called crashing. Adding a second crew might cut construction from 6 to 4 weeks, bringing the project back to 19 weeks (on the original durations), at extra cost. Shortening a non-critical activity achieves nothing. And there are limits: adding people to an activity also adds coordination, and in software development Fred Brooks famously observed that "adding manpower to a late software project makes it later" (Brooks's law, 1975).

The Gantt chart

A Gantt chart draws the schedule as horizontal bars on a timeline, one row per activity. It is the most common way to communicate a schedule, because anyone can read it. Critical activities are usually highlighted, float is shown as a thin extension, and milestones (zero-duration events such as "permit issued") are diamonds.

Risk

Every schedule and budget rests on assumptions that may turn out wrong. A risk register lists each identified risk with its likelihood, its impact, an owner, and a response: avoid it, reduce it, transfer it (for example to an insurer or contractor), or accept it with a contingency. ENGG-100 used a risk matrix for safety; the same tool works for project risks. A simple way to size a contingency is the expected cost: probability times impact.

The human side

Psychological safety

Research by Amy Edmondson (1999) introduced the idea of psychological safety: a shared belief that the team is safe for interpersonal risk-taking, such as admitting a mistake, asking a "stupid" question or challenging a senior person's idea. Google's Project Aristotle study of its own teams (published in 2015) found it to be the most important factor distinguishing effective teams. In engineering, it is a safety issue as well as a performance one: many of the disasters studied in ENGG-100 involved someone who saw the problem but did not feel able to press it.

Leaders build psychological safety by inviting dissent ("What am I missing?"), responding to bad news with thanks rather than blame, admitting their own mistakes, and separating the person from the problem.

Giving and receiving feedback

Feedback should be specific and about behavior and its effect, not about personality. One widely taught structure, from the Center for Creative Leadership, is Situation–Behavior–Impact (SBI).

Receiving feedback is a skill too: listen fully, ask for examples, thank the person, and decide what to act on. Defending yourself in the moment rarely helps.

Handling conflict

Conflict about ideas (task conflict) can improve designs. Conflict about people (relationship conflict) almost always hurts. The Thomas–Kilmann model describes five ways people handle conflict, arranged by how assertive (pursuing their own concerns) and how cooperative (attending to others' concerns) they are.

• Competing: firm on your position. Right for safety-critical issues and code compliance, where you must not give way.
• Collaborating: working to find a solution that fully satisfies both. Best for important design decisions when there is time.
• Compromising: each side gives up something. Useful under time pressure when goals are moderately important.
• Avoiding: postponing. Reasonable for trivial issues or when tempers need to cool; harmful if it becomes a habit.
• Accommodating: giving way. Appropriate when the issue matters more to the other person, or when you realize you were wrong.

Design reviews

A design review is a planned, structured examination of a design by people who did not create it, held at defined stages: typically a concept or preliminary design review (PDR) before detailed design begins, and a critical design review (CDR) before construction or manufacture. Reviews catch errors while they are still cheap to fix, and they are the gates of the stage-gate process from Lesson 1.

A good review has a clear scope and checklist, materials sent in advance, reviewers with the right expertise and independence, and a written list of findings, each with an owner and a resolution. The designers' job during a review is to explain and listen, not to defend. In professional practice, independent checking of calculations and drawings is routine, and some jurisdictions require it for higher-risk work (New York City, for example, requires structural peer review for certain large or unusual buildings). Even so, the engineer who seals the work is responsible for it whether or not a reviewer missed something.

Inclusive and distributed teams

Teams that bring together different disciplines, backgrounds and experiences consider a wider range of users and failure modes, which is exactly what design needs. Getting that benefit takes deliberate effort: making sure quieter members are heard (silent brainstorming, round-robin input), rotating less visible tasks like taking minutes, and checking that decisions do not rest on assumptions only some members share. Distributed teams add the challenges of time zones and text-based communication: write things down, keep a single source of truth for documents (with version control), and make decisions visible to everyone, not just those on a particular call.