RHEA’s experts have been using concurrent design for nearly two decades to accelerate the early phases of complex engineering projects such as space programmes, defence systems, factory design and luxury yachts.
In this blog series, they share their insights into how you can ensure concurrent design sessions are rigorous and the outcomes are high quality.
By Gwendolyn Kolfschoten, Concurrent Design Expert
7. How to deal with naming and shaming
When issues are revealed in concurrent design sessions, it is inevitable that some blaming and shaming will take place – or at least that one or more team members will perceive feedback that way. This tends to happen despite any preventive measures we take as team leads. What should we do when this happens? And how can we repair the damage to trust and safety, which are important to maximize success?
Constructive criticism vs assigning blame
Constructive criticism is necessary to reveal mistakes and misunderstandings, as well as trade-offs between risks and inconsistencies. But there is a thin line between constructive criticism and blaming and shaming. Therefore, when an issue surfaces, it usually means some extra work for the team lead and/or making tough choices.
When participants get frustrated because of issues that have been revealed, it is important to recognize their frustration. This may relate to extra work they need to do or a trade-off that needs to be made; either way, frustration is a sign that people care about the project – they want the best but feel they cannot achieve it. However, that is better than when they ‘do not care’.
That said, negativity is not good for the overall atmosphere during a project and can cause participants to be shy and less forthcoming about any future problems they identify. Team leads therefore need to keep a balance and separate problems from people.
Keeping a balance and avoiding negativity
Several tips can help to achieve this:
- Help the team to see a different perspective: For example, “I can imagine that from the Domain X point of view, this is a difficult decision.” Allow participants to explain the impact and help the team understand why an outcome is not desirable.
- Acknowledge frustration in a neutral way: “I can see you struggle with this” or “I understand I am asking a lot from you.” You do not need to comfort or apologize; explicitly recognizing the frustration is sufficient to ensure that people feel heard and understood.
- Recall the joint goal of the study: “We are all working very hard to make sure this design passes the first gate” or “This is a challenging project – if it was not, they would not have asked us to do it.” Shared pain is much easier to bear.
- Challenge assumptions because they can be wrong: “This sounds like a big problem – let me see if I understand what you are saying.” Testing if you understand the impact of what people are presenting helps them to sharpen the statement.
- Ask the expert to think in terms of solutions: “What do you suggest we do to resolve this issue” or “What would be possible, given your view of these constraints?”
- Offer help: “How can we help you to solve this issue?” or “Who in the team could help you with this?”
- Keep expectations realistic. Yes, we want to increase efficiency, and yes, we ask people to work in between sessions to prepare things and calculate outcomes for the next iteration. But we should not expect them to do this around the clock for several nights. If it really cannot be done this fast, it needs more time.
Find out more
In this series of blog posts on concurrent design, we present techniques to improve rigour and quality. These offer a toolbox for concurrent design team leads to support their teams effectively in improving and testing the design. We cover aspects such as how to handle validation when working with rough estimates, how to capture the wisdom of the whole team of experts, and how to keep the team on track and motivated.
