Question 2 of 7: The Team Approach to Design

Question 2: The Team Approach to Design (15 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part A — Advantages and disadvantages of a team approach

The case for a design team is that no individual holds all the knowledge a modern product requires. A team brings the manufacturing engineer, the industrial designer, the electrical engineer and the service planner into the same conversation early enough for their constraints to shape the concept rather than to arrive as objections to a finished one. That is the whole basis of concurrent engineering: decisions taken with downstream knowledge present are cheaper than decisions taken without it and corrected later. A team also generates a wider concept set, catches errors through independent review, spreads ownership so the design survives an individual leaving, and develops people who would otherwise learn only their own discipline.

The costs are real and are usually understated. Coordination consumes engineering time that is not spent designing, and it grows faster than the team does — a point part C makes numerically. Responsibility diffuses, so a decision everyone touched can turn out to be a decision nobody made. Groups converge prematurely on the first plausible concept, and social pressure suppresses the dissent that would have caught the flaw. Consensus tends to produce compromise designs that are acceptable on every axis and outstanding on none, which in a competitive market is a losing product. And teams are slower on well-understood work: if the problem is genuinely routine, a competent individual with a reviewer beats a committee on both cost and elapsed time.

Part B — Characteristics of a high-performing design team

High-performing design teams share a recognisable set of properties. They are small and cross-functional — large enough to hold the necessary disciplines, small enough that the communication load does not dominate. They have a single owner of each decision, with the team informing the decision rather than voting on it, so authority and accountability sit in the same place. They work to a shared and explicit goal expressed as measurable specifications rather than as intentions. They practise psychological safety: a junior engineer can say the concept will not mould without career risk, which is the mechanism that converts diversity of expertise into better decisions instead of into unspoken reservations. They maintain a single source of truth — one release-controlled model and one requirements document — so that disagreements are about substance rather than about which revision someone was reading. They iterate deliberately and early, treating a cheap failed prototype as information rather than as embarrassment. And they have stable membership across a phase, because most of a design team's productive knowledge is tacit and leaves with the person.

Parts C and D — Three challenges of a distributed team, and a solution to each

Before the qualitative discussion, two calculations make the problem concrete, because distributed working is usually argued about in adjectives when it is in fact structural.

1. Quantify the communication load. The number of pairwise links in a team of $n$ people is $$L=\frac{n(n-1)}{2}$$ A twelve-person team has $L=66$ links to maintain. Organised instead as three co-located pods of four with one liaison each, the count is $3\times 6$ internal links plus 3 liaison links, $$\boxed{L:\ 66\ \longrightarrow\ 21\ \text{links, a 68 per cent reduction}}$$ This is why architecture partitioning matters more than communication tooling: the team structure should mirror the product’s module boundaries so that most traffic stays inside a pod.
2. Test whether a synchronous meeting exists at all. Map each site’s 09:00–17:00 working day onto one UTC axis. Calgary (UTC−6) occupies 15:00–23:00 UTC, Kraków (UTC+2) occupies 07:00–15:00, and Shenzhen (UTC+8) occupies 01:00–09:00. The pairwise intersections are 0 h, 0 h and 2 h respectively, and the three-way intersection is $$\boxed{0.0\ \text{hours}}$$ Extending every site to a ten-hour day leaves the three-way intersection at 0.0 h. Searching over all whole-hour start times, no schedule with displacement of 3 h or less produces any three-way overlap, and displacing all three sites by 4 h buys only 2 h — at 05:00 in Calgary, 07:00 in Kraków and 13:00 in Shenzhen.

With that established, the three challenges and their solutions follow directly.

Challenge 1 — there is no common working hour, so synchronous coordination is unavailable. The calculation above shows this is not a scheduling inconvenience that goodwill can fix; it is arithmetic. A daily stand-up across these three sites either does not happen or is paid for by someone working nights indefinitely. Solution: design the process to be asynchronous by default. Decisions are made in writing against a stated deadline, with a named decision owner and a default outcome if no objection arrives; the rare genuinely synchronous event is scheduled deliberately, with the burden of the awkward hour rotated between sites rather than always falling on the same one. Follow-the-sun handoffs are used where the work decomposes, with a written handover note as the deliverable of each day.

Challenge 2 — latency turns a short exchange into a long one. A question from Calgary to Shenzhen is answered on the next Shenzhen working day, so a single round trip costs about one working day. A design issue that a co-located pair would resolve in a forty-five-minute conversation of six exchanges takes six working days, or more than a calendar week. Solution: reduce the number of exchanges rather than the latency of each. That means partitioning the product so each site owns a module outright, defining the interfaces between modules as controlled documents that change only at a gate, and requiring questions to be posed with the asker's proposed answer and supporting analysis attached, so that most round trips are a confirmation rather than a negotiation.

Challenge 3 — loss of shared context, informal knowledge and trust. Co-located teams transfer an enormous amount of information incidentally: the half-heard conversation, the model on someone's screen, the prototype on the bench. Distributed teams lose all of it, and what replaces it is a partial written record plus assumption. Trust degrades in the same way, and the failure mode is that sites stop raising problems across the boundary. Solution: make the invisible explicit and invest deliberately in the relationship. One release-controlled model and requirements document as the single source of truth; recorded design reviews with written decision logs that state the alternatives rejected and why; shared dashboards of open issues and specification status; and periodic face-to-face contact concentrated at the points of highest ambiguity — the start of a phase and the design-to-manufacturing handoff — with engineers physically exchanged between sites for those periods.