In this article
Before you start
This question belongs to the people questions in the engineering manager interview guide; the people management round shows where it sits.
Why interviewers ask this
A candidate who answers "more meetings" or "a shared chat channel" has told the interviewer that communication means volume, and the next question exposes it. Candidates report this question in people-management rounds for engineering manager roles. It separates managers who diagnose a cause from managers who apply a habit.
A weak answer lists tools: a weekly sync, a chat channel, a shared document. A strong answer names the kind of break (people will not speak, people do not know who decides, or information has no route), applies one fix to that break, and says what signal shows it worked. A Staff-level answer also changes the structure around the people: ownership boundaries, written decisions and the number of pairs who must coordinate. Interviewers can then ask about two engineers in conflict, a silent team or a dependency on another team, and the same diagnosis carries over to each.
Getting people to communicate better from first principles
- Communication path
- A communication path is one pair of people who may need to stay in step with each other, so a group of n people has of them. It counts who might need to talk, not how many messages are sent, and it grows much faster than the number of people.
In plain words
Think of the plumbing in a building. Water reaches a tap only if a pipe exists, the pipe joins the right tap, and nobody has closed the valve. Communication works the same way. People need a route, a clear destination and an open valve. Pumping more water into a closed valve changes nothing, and more messages into a team that feels unsafe change nothing either. The analogy breaks in one place: people decide what to send, and they weigh the risk of speaking, which pipes never do.
In one precise sentence, communication between people improves when speaking is safe, expectations are clear and information has a route to the person who needs it.
The five steps run in order: find the break, make speaking safe, clarify owners, route information, check the result.
Step 1: Find the real break
A team with a communication problem usually has one of three breaks: people do not speak, people do not know who decides, or information exists but does not arrive. Each break needs a different fix, so you name the break before you act.
Input: what you hear in one-on-ones and in meetings. Ask each person the same three questions: what did you know but not say, who decides this, and where would you look for it. Compare the answers for one recent decision. If two people name different deciders, the break is clarity. If people say they held back, it is safety. If the facts were known to someone but not to the person who needed them, it is routing.
The Project Aristotle study of Google teams found that how a team worked together mattered more than who was on it, which is why you diagnose the working pattern and not the individuals. Output: one named break. You now know which of the next three steps to start with.
Step 2: Make speaking up safe
Psychological safety is "a shared belief held by members of a team that the team is safe for interpersonal risk taking", in the definition by Amy Edmondson (1999 paper) as quoted by Google. The same source lists it first of five team dynamics, ahead of dependability, structure and clarity, meaning and impact, and notes that even a basic question such as what the goal of a project is can feel risky.
Input: a team where people stay quiet. In her TEDx talk, Amy Edmondson suggests three things anyone on a team can do, as summarised by Google re:Work: frame the work as a learning problem, not an execution problem; acknowledge your own fallibility; and model curiosity by asking lots of questions. In practice, as the manager, ask for objections by name, thank whoever brings bad news, and say what you got wrong first. In the culture typology of the DevOps Research and Assessment (DORA) page, messengers are punished in a pathological culture and trained in a generative one.
Safety does not mean being nice or lowering the bar. Google's re:Work guide lists dependability and clear goals as separate dynamics. Output: people raise problems early.
Step 3: Make goals and owners clear
Structure and clarity means each person understands the job expectations, the process for meeting them and the consequences of performance, according to Google's team-effectiveness research. The same source says goals must be specific, challenging and attainable. When ownership is unclear, people stay silent because they cannot tell who needs to hear.
Input: a break of the "who decides" kind. The tool is a working agreement, written by the team in one short session: who decides what, how fast people answer, where each kind of message goes, how disagreement is raised. Keep it to a page and revisit it when something goes wrong.
An illustrative case: a backend team and a mobile team each assume the other will warn users about a retired interface. Nobody is careless; nobody owns the notice. The fix is to name one owner and one route in the agreement, not to schedule a joint meeting. Output: for each recurring decision, one named owner and one route.
Step 4: Give information a route
Information has a route when the person who needs a fact can find it, or is told, without asking for it. The DORA page cites Ron Westrum on what good information looks like: it answers the questions the receiver needs answered, it is timely, and it is presented so the receiver can use it. It also says a culture that is high-trust and emphasizes information flow is linked to software delivery performance. Managers of delivery teams meet this theme in DevOps manager interview questions.
Input: a break of the "does not arrive" kind. Write decisions as decision records in one place, and name one channel for each kind of message (urgent, decision, question). Then cut the number of people who must coordinate. A team of 12 has 66 communication paths, while two teams of 6 have 15 each, 30 in total, plus one path between their leads for 31.1
| Team shape | Communication paths |
|---|---|
| 3 people | 3 |
| 5 people | 10 |
| 8 people | 28 |
| 12 people | 66 |
| Two teams of 6, linked by their two leads | 31 |
Output: facts reach people without a request.
Text description of the diagram
- A team of 12 has 66 communication paths.
- A team of 3 has 3 communication paths.
Step 5: Check that it worked
You check by repeating the diagnosis. Ask the Step 1 questions again after a few weeks (illustrative interval) and compare: do two people now name the same decider, do problems surface earlier, and can a new person find a past decision without asking?
Input: the same questions, the same people. A check closes the loop, and each fix targets one kind of break. Google ran this kind of check with team-member surveys, and leads received aggregated, anonymized scores to share with the team and inform a discussion, supported by a People Operations facilitator or a discussion guide, according to the re:Work guide. You can do a lighter version with one-on-ones and the team health measures an engineering manager uses.
The honest boundary: the sources show that team dynamics and information flow are linked to team and delivery outcomes. They do not show that any one practice, such as a working agreement, fixes a given team. You test it on your team and keep what the check supports. Output: a decision to keep, change or drop each fix.
Step-by-step description
- Name the break first.
- Ask for objections by name.
- Write a working agreement.
- Keep decisions in writing.
- Repeat the same questions.
- The five steps run in order: find the break, make speaking safe, clarify owners, route information, check the result.
- A check closes the loop, and each fix targets one kind of break.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
How would you get teams or people to communicate better with one another?
I start by working out which kind of break it is, because the fix differs. If people do not speak up, I work on safety: I ask for objections by name, thank whoever brings bad news, and say what I got wrong. If people do not know who decides, I have the team write a working agreement that names owners.
If information exists but does not arrive, I add a decision record and one place where each kind of message goes. Then I check with the same questions a few weeks later. More meetings is my last resort, because it adds contact without fixing the cause. A team of twelve has sixty-six pairs, so I reduce how many must coordinate.
What makes it Staff-level: it diagnoses before it prescribes, it changes structure and not only behavior, and it ends with a check. Say it in this order: the diagnosis, the three fixes, the check, then the cost of more meetings.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Correctness | Lists tools and meetings | Names the kind of break and one matching fix | Treats safety, clarity and routes as separate causes with separate fixes |
| Depth | Says "be transparent" | Explains how the fix works, such as a written decision | Explains why paths grow with team size and cuts them |
| Trade-offs | None given | Admits meetings and documents cost time | Compares fixes by cost, and says when to stop adding process |
| Communication | Vague and abstract | Gives one concrete example | Gives an example and the exact sentence you would say to the team |
| Follow-up readiness | Stalls on "how do you know" | Names a signal to watch | Names the signal, the interval and what you would change if it fails |
This is a study aid for building an answer, not a rubric from any company.
Three variants of this question
How would you get teams or people to communicate better across two teams?
Find which break it is, then fix the interface instead of adding contact. Name one owner per shared decision, agree one channel for each kind of message, and keep decisions in a written record both teams can read. Cross-team talk goes through that interface, not through everyone.
What if the problem is two people, not the whole team?
First check whether it is the pair or the structure around them: unclear ownership often looks like a personality clash. Then use one-on-ones with each, and a joint conversation about the work. The full approach is in two engineers who can barely stand each other.
How would you get a quiet team to speak up?
Treat it as a safety break. Ask for objections by name, thank the first person who disagrees, and admit your own mistakes first. Then watch whether questions arrive earlier. If one person's own habits are part of the pattern, coaching is covered in growing engineers.
Common mistakes
- "I'd add a weekly sync." (wrong) A meeting adds contact but does not fix safety or ownership. (right) "I'd find the break first, and add a meeting only if the break is routing."
- "It's a personality issue." (wrong) It ignores structure; Google's study found how a team works mattered more than who is on it. (right) "I'd check ownership and safety before I judge individuals."
- "Psychological safety means being nice." (wrong) Google's re:Work guide lists dependability and clear goals as separate dynamics. (right) "Safe to disagree, and still held to a clear goal."
- "I'd tell everyone to over-communicate." (wrong) More messages do not help information that has no route. (right) "I'd decide what is sent where, and keep decisions in writing."
Follow-up questions
What do you do if the team already has too many meetings?
Find what each meeting is for. Replace status meetings with written decision records and keep meetings for decisions and disagreement. This cuts contact but keeps the route.
How do you know communication has improved?
Repeat the Step 1 questions after a few weeks. Two people naming the same decider, problems surfacing earlier and a new person finding a past decision alone are all signals a strong answer names. See also measuring team health.
What changes if the team grows from eight to twelve people?
The number of communication paths rises from 28 to 66, so a team of eight does not scale by habit.1 Split into smaller teams with named owners and one interface between them.
Is poor communication a personality problem?
Sometimes, but check structure and safety first. Google's research found how a team works together mattered more than who is on it. Your management philosophy answer should say how you separate the two, and growing engineers covers coaching a person who does contribute to the pattern.
- Name the break first: people do not speak, do not know who decides, or have no route for information.
- Safety, clarity and routes are separate fixes, and more meetings fix none of them by default.
- Write down owners, working agreements and decisions so information does not depend on who was in the room.
- Pairs who may need to coordinate grow faster than headcount, so reduce interfaces as teams grow.
- Check the result with the same questions, and say what you would change if it did not work.
Sources
- Understand team effectiveness (Project Aristotle) — Google re:Work, 31 Mar 2026
- Psychological Safety and Learning Behavior in Work Teams — Administrative Science Quarterly 44(2) (Edmondson), 1 Jun 1999
- Generative organizational culture — DORA (DevOps Research and Assessment), 26 Oct 2026
