Recognizing Team Dysfunction Signals

Welcome back. In the previous lesson, you learned to make decision authority explicit: who decides, who contributes, what constraints apply, and when a manager should retain or delegate authority. Clear delegation is one protection against a deeper team problem: people can be capable and hardworking yet still fail to deliver because ownership is fuzzy, concerns stay unspoken, or commitments do not translate into completed work.

This closes the first module by giving you a practical diagnostic lens. You will learn to identify signals of unclear ownership, low trust, and weak execution in delivery situations—without jumping from one awkward meeting or missed deadline to a judgment about an individual. This is a core technical-manager skill: observe patterns, separate likely causes, and create enough clarity and safety to learn what is actually happening.

---

Treat signals as evidence, not verdicts

When an initiative slips, a new manager can easily reach for an individual explanation: “Someone is not accountable,” “This engineer lacks ownership,” or “The team does not care.” Sometimes performance is part of the picture, but team-level failures are often produced by the operating system around people: vague roles, unclear decisions, unsafe interactions, unrealistic plans, or unresolved dependencies.

A signal is a repeatable observation that suggests something may be wrong. It is not proof of a cause.

For example:

• A decision is repeatedly reopened. That may signal unclear authority, but it may also mean new evidence genuinely changed the decision.
• Nobody challenges a proposal in a meeting. That may signal low trust, but it could also reflect insufficient preparation time, a language barrier, or a meeting format that rewards quick speakers.
• Work misses dates. That may signal weak execution, but it could reflect an unowned dependency, a sudden incident, or an estimate based on incomplete discovery.

Your task is to notice the pattern, form a hypothesis, and verify it with evidence and respectful inquiry.

Google’s re:Work research provides a useful baseline. It frames team effectiveness primarily in terms of how people work together, not merely who is on the team. Three of its five team-effectiveness factors map directly to this lesson:

1. Psychological safety: people can ask questions, acknowledge mistakes, disagree, and offer ideas without fear of humiliation or punishment.
2. Dependability: people reliably complete quality work on time.
3. Structure and clarity: people understand expectations, goals, roles, and how decisions are made.

The important distinction is that these dimensions can reinforce one another. A team may have good intentions but weak execution because no one owns cross-team decisions. A team may appear dependable until people begin hiding risks because earlier messengers were blamed. So diagnose each dimension separately first, then look for the connections.

---

Signals of unclear ownership

Ownership means that a person or defined group has the authority and obligation to move a specific outcome forward. It includes more than “who is writing the code.” An initiative usually needs clear ownership for:

• the business or engineering outcome;
• decisions and trade-offs;
• execution tasks;
• dependencies and stakeholder communication;
• acceptance criteria and final completion.

In the previous lesson, DACI clarified decision ownership. A related tool, RACI, distinguishes the person who performs work from the person accountable for its completion. The labels vary across frameworks, but the practical question remains: Can the team name one owner for each consequential decision and deliverable?

Common signals of unclear ownership include the following.

What you observe	What it may indicate
Multiple people believe they have final approval authority.	Competing decision rights; decisions may stall or be reopened.
Everyone assumes “someone” is handling a task, integration, risk, or stakeholder update.	No execution owner, especially at a team boundary.
A meeting ends with agreement but no named owner, decision date, or next check-in.	Discussion has been mistaken for commitment.
Work moves quickly within teams but stalls at handoffs.	An interface or dependency has no coordination owner.
Engineers seek manager approval for routine decisions, or make decisions later overridden by the manager.	Delegation level and decision boundaries are unclear.
Two engineers independently solve the same problem, while another important task is untouched.	Work allocation is ambiguous or invisible.
The same question returns every week: “Who is driving this?”	Ownership was never established, or the owner lacks authority and support.

A useful warning sign is decision latency: the time spent waiting for a decision after the team has enough information to make one. Long decision latency often appears in software work as waiting for a schema choice, AWS budget approval, a security interpretation, or an API ownership decision. It can look like engineering delay, even when engineers are ready to proceed.

The RACI video offers a quick visual inspection method. It is particularly useful when a delivery plan feels crowded with participants but strangely light on progress.

A RACI or DACI artifact is useful only if it reflects real behavior. A document that lists a single owner while everyone still waits for a manager’s informal approval has not solved the problem. Ownership must be visible in decisions, meeting notes, work tracking, and day-to-day escalation behavior.

---

Signals of low trust: silence can be costly

For teams, the relevant form of trust is not simply “I can predict what my colleague will do” or “we are friendly.” It is closer to vulnerability-based trust: people can say, “I do not know,” “I made a mistake,” “I disagree,” or “I need help,” without expecting punishment or loss of status.

Psychological safety does not mean lower standards, avoiding hard feedback, or agreeing with every proposal. In fact, a high-trust team can debate architecture, challenge a risky release, and hold one another to commitments. The difference is that conflict stays focused on the work rather than becoming a threat to the person.

Watch how Patrick Lencioni connects trust to healthy disagreement, commitment, and accountability. Treat this as a practical causal hypothesis: if people cannot speak candidly, decisions receive weaker input and accountability becomes much harder.

Low trust often shows up indirectly. Look for recurring patterns such as:

• Artificial harmony. Meetings contain quick agreement, but objections appear later in private messages or after a decision has been made.
• Bad news arrives late. Risks, missed estimates, defects, and dependency failures surface only when they are already difficult to address.
• Questions disappear. Engineers stop asking for clarification or help, especially after prior questions were treated as incompetence.
• Ideas dry up. The team generates few alternatives, particularly after someone’s proposal was publicly dismissed or mocked.
• Updates become performative. Status reports say “on track” without naming uncertainty, blockers, or trade-offs.
• Only high-status people speak. A manager, staff engineer, project lead, or vendor lead becomes the sole spokesperson for others.
• Blame language becomes normal. Retrospectives focus on “who caused this?” rather than conditions, decisions, and safeguards.

The last two signals require care in distributed teams. A quieter engineer may be thinking, communicating in a second language, respecting organizational hierarchy, or dealing with an inaccessible meeting format. Do not interpret silence as agreement or lack of engagement. Instead, change the conditions: share questions in advance, collect written input, invite direct input without forcing it, and provide channels for concerns that do not depend on a single spokesperson.

Google’s re:Work scenario about a manager publicly “trouncing” an engineer’s idea illustrates an especially important pattern: a leader’s reaction can change what the entire team considers safe to say. One public humiliation may not explain every later silence, but repeated dismissive responses teach people that visibility is dangerous.

---

Signals of weak execution

Weak execution is a pattern in which the team does not reliably turn commitments into completed, quality outcomes. It is not equivalent to “the team worked slowly” or “a deadline was missed once.” Software delivery includes discovery, changing requirements, incidents, and dependencies; all can legitimately change a plan.

Instead, look for a repeated gap between what the team says it will accomplish and what it actually delivers.

Signal	What it looks like in an engineering team	What to investigate
Commitments repeatedly slip	Work rolls from sprint to sprint, or release dates move without a revised plan.	Was the work too large, blocked, unowned, interrupted, or misunderstood?
“Done” is unstable	A feature is declared complete, then returns because of defects, missing observability, security gaps, or unaddressed edge cases.	Are completion criteria explicit and shared?
Plans have activity but no outcomes	The board shows many tasks in progress, but no measurable milestone is reached.	Is work too fragmented? Is there excessive work in progress?
Risks are surprises	Capacity, security, vendor, or integration risks become visible only near release.	Were risks surfaced early but ignored, or did people feel unable to raise them?
Blockers persist without escalation	The same dependency or approval appears in several status updates.	Who owns the coordination action and escalation path?
Retrospectives produce no change	The team repeats the same problem but creates no owned, measurable improvement.	Is there honesty about the problem, or no follow-through after discussion?
Peer accountability is absent	People notice a missed agreement but wait for the manager to address it.	Is commitment clear enough, and does the team feel safe being direct?

Dependability includes both time and quality. A team that ships quickly but creates recurring production incidents is not executing reliably. Equally, a team may produce high-quality work but remain unpredictable because it does not expose uncertainty, manage dependencies, or revise plans when evidence changes.

Notice the overlap:

• Unclear ownership can cause weak execution because no one is empowered to resolve a blocker.
• Low trust can cause weak execution because risks remain hidden until late.
• Weak execution can then erode trust, particularly when missed commitments lead to public blame.

This is why a technical manager should avoid declaring one root cause too early.

---

Reading a team scenario: separate the symptoms

Consider this scenario.

A backend team is preparing a checkout-service change to prevent duplicate charges during retries. The work involves the Node.js service, a database schema change, an AWS queue configuration, and review from Security.

For three weekly planning meetings, Product asks who will make the final trade-off between a two-week release delay and reducing the initial scope. The engineering lead says it is Product’s decision; Product says Engineering must decide because it is “a technical risk.” Meanwhile, two engineers have begun different implementation approaches.

In stand-ups, the work is described as “almost done.” Privately, an engineer says the queue configuration may create a duplicate-processing risk, but does not raise it in the group because the last person who delayed a release was criticized for “overthinking.” At the retrospective, the team says the sprint went well, despite the release moving and an integration test failing twice.

Here is how to interpret the evidence.

Observation	Primary signal	Why it matters
Product and Engineering each assign the release trade-off to the other.	Unclear ownership	The decision has no clear approver or defined process.
Two engineers build competing approaches.	Unclear ownership	Execution began before a design decision and decision owner were explicit.
A material risk is shared privately but not in the meeting.	Low trust	The engineer expects negative consequences for raising inconvenient information.
“Almost done” persists while key work and tests remain unresolved.	Weak execution	Status reporting does not reflect observable completion criteria.
The retrospective reports success despite missed goals.	Low trust and weak execution	The team may lack safety to discuss reality and a mechanism to convert learning into improvement.

The scenario does not prove that the engineer who stayed silent lacks confidence, that Product is careless, or that the team is lazy. It reveals a team system with three credible diagnostic hypotheses.

A manager’s first move should be to make the observations discussable:

“We have a release decision that has been open for three weeks, two implementation paths in progress, and an unresolved processing-risk concern. I want to understand the decision ownership, the evidence behind our status, and what made that concern difficult to raise earlier.”

This wording does three things. It uses facts rather than accusations, connects the discussion to an outcome, and signals that surfacing risk is valued.

---

A lightweight diagnostic routine

When you encounter a troubled initiative, use this short routine before selecting a remedy.

1. Anchor on a specific outcome

Avoid diagnosing “the team” in the abstract. Name the concrete outcome, such as “release idempotent checkout retries without duplicate charges by the agreed date.” Vague outcomes produce vague ownership and vague status.

2. Collect observable evidence

Review recent meeting notes, work items, decision records, release criteria, blocked tasks, and changes to dates or scope. Look for patterns across several weeks or initiatives. A single incident may be random; a repeated pattern is more informative.

3. Map decision and execution ownership separately

For each active issue, ask:

• Who makes the final decision?
• Who performs the work?
• Who must be consulted before the decision?
• Who needs an update afterward?
• By when will a decision or escalation occur?

This makes it possible to identify whether a “delivery problem” is actually an unresolved decision-rights problem.

4. Test for safety with neutral questions

Use questions that invite information rather than defend a prior plan:

• “What information would have changed our plan, and when did we first know it?”
• “Which concern was hardest to raise, if any?”
• “For this decision, who believed they had authority to decide?”
• “What does complete mean for this item, and what remains uncertain?”
• “What made this blocker difficult to resolve or escalate?”

Listen for discrepancies between public and private accounts. If people repeatedly tell the manager one thing and peers another, treat that gap as a system signal.

5. Distinguish the immediate failure from its contributing conditions

A missed delivery can be the immediate failure. Contributing conditions might include an unowned Security review, unclear completion criteria, an estimate made before technical discovery, or fear of challenging a deadline. The distinction matters because replacing or admonishing one person will not fix a repeated condition in the system.

If you use a survey, follow Google’s approach: gather and discuss aggregated, anonymized patterns. Do not use psychological-safety questions to identify or pressure individual respondents. The goal is to enable an honest team conversation, not to grade personalities.

---

How to discuss this in a technical-manager interview

Interviewers may present an intentionally ambiguous scenario: deadlines slip, engineers disagree, and stakeholders complain about a lack of updates. A strong response shows that you can diagnose before prescribing.

A concise structure is:

“I would first separate the evidence into ownership, trust, and execution. I would check whether one person owns each material decision and dependency, because work may be stalled by unclear authority rather than technical difficulty. I would look for trust signals such as bad news arriving late, private dissent, or people avoiding questions, while being careful not to treat quietness alone as proof. Finally, I would compare commitments with observable completion criteria and identify recurring blockers. I would then bring the facts to the team in a non-blaming discussion, clarify ownership, and make it safe to surface risks early.”

That answer communicates managerial judgment: accountability without scapegoating, and empathy without avoiding performance standards.

---

Key takeaways

Effective teams need more than skilled engineers and a reasonable plan. They need visible ownership, enough trust to expose reality, and dependable follow-through.

• Treat team signals as evidence to investigate, not labels to attach to people.
• Look for unclear ownership in duplicated work, unowned decisions, stalled handoffs, and meetings that end without an owner or decision date.
• Look for low trust in artificial agreement, late bad news, suppressed questions, private dissent, blame, and unequal voice.
• Look for weak execution in repeated commitment misses, unstable definitions of done, persistent blockers, surprise risks, and retrospectives without follow-through.
• Diagnose the dimensions separately, then examine how they reinforce one another.
• Begin with observable facts and neutral questions; this creates the conditions for honest accountability.

Next, you will move into core people-management practice by preparing a structured one-to-one agenda with a direct report.