Taking Over a Team? Learn Its Unwritten Rules Before Changing Them

You inherit a team with a clear organization chart and a folder of documented processes. By the end of the first week, you discover that urgent work goes through a different person, approvals happen in a chat thread, and the official meeting rarely settles the important questions. The team has a second operating system made of habits and shared expectations.

Before changing those routines, learn what each one accomplishes. Some may preserve useful knowledge; others may create delays or unfair burdens. Understanding the difference gives you a firmer basis for your first decisions.

Follow one real piece of work

Choose a recent task that represents the team’s normal activity. Ask someone to walk you through it from the initial request to the finished result. Use actual steps rather than the ideal sequence in a process document.

Who noticed the request? Who decided its priority? Where did the work wait? Who checked it, and what happened when something was unclear? A practical example often reveals dependencies that disappear in a broad discussion about communication.

In a hypothetical design team, the documented process might assign approval to a project lead. The real work may also wait for an experienced colleague who remembers previous customer preferences. Removing that informal check without understanding it could remove useful context along with the delay.

Ask consistent questions across the team

Speak with people individually as well as in groups. Use several of the same questions so you can compare experiences without assuming that the first confident account represents everyone. Make room for newer employees and people whose work happens away from the main office.

• What helps you do good work here that I might not notice?
• Where does an ordinary task become harder than it needs to be?
• Which decisions can you make without checking with someone?
• What should I understand before changing this process?

Listen for examples, then summarize what you think you heard and invite correction. Avoid treating the conversation as an opportunity to announce your preferred solution. People may stop explaining the current problem once they believe the answer has already been chosen.

Separate an observation from its explanation

Keep three categories in your notes: what you directly observed, what someone reported, and what you currently infer. “The request waited two days” is different from “the approver does not care.” The first can be checked; the second assumes a motive.

Compare accounts with available work records and with the people involved. Perhaps the approver was waiting for missing information. Perhaps the deadline was never communicated. Perhaps the process does rely too heavily on one person. Each explanation suggests a different response.

Handle sensitive comments carefully. Do not promise absolute confidentiality if your role may require you to act on a serious concern. Explain how you intend to use the information, and avoid repeating personal criticism when a process issue can be discussed without naming the speaker.

Learn which habits solve a real problem

An informal routine often exists for a reason, even if that reason is no longer obvious. A private handoff may have developed because a shared system was unreliable. A repeated meeting may once have coordinated two departments that now work independently.

Ask what would break if the habit stopped tomorrow. Then ask whether that need could be met more clearly or fairly. This prevents two opposite mistakes: keeping every routine out of respect for history, or removing one simply because it differs from your previous workplace.

Understanding a practice is not the same as accepting it indefinitely. Urgent safety issues, harassment, or other serious concerns need action through the appropriate channels. Listening should improve your response, not become a reason to postpone necessary intervention.

Choose one improvement with a visible purpose

For a routine process problem, select a limited change the team can evaluate. For example, if requests arrive through several channels and priorities keep conflicting, agree on one intake point and a named person to resolve competing deadlines.

Explain the problem, the proposed change, and what will count as improvement. Fewer lost requests or less time waiting for a decision are more concrete than “better collaboration.” Record a simple baseline where possible, and choose a review date that fits the team’s work cycle.

Tell people which parts of the arrangement are experimental. A reversible trial allows useful feedback without requiring everyone to defend the old process or endorse the new one permanently.

Close the loop on what you learned

Share a short account of what you heard, what you verified, and what you plan to address. Include what is working well and should be preserved. If a requested change is outside your authority, say who needs to be involved and what you can do next.

Your first weeks need not produce a sweeping reorganization. A clear explanation of one well-chosen improvement can show the team how you intend to manage: understand the work, make a decision, test its effect, and take responsibility for the result.