Join the Team Before You Try to Change It

Source and AI note: This article is based on Gemini’s Devpractice on YouTube. It was generated and edited with the gpt-5.6-sol model.

A new engineer can create trouble in two opposite ways. A junior may stay silent for days because asking feels embarrassing. An experienced hire may start correcting the team’s architecture before understanding why it exists. Both leave teammates with the same problem: they cannot see what the newcomer is doing, and they have no reason yet to trust the newcomer’s judgment.

Adapting well is less about displaying everything you know than reducing that uncertainty. Ask with context, make progress visible, learn the local system, and deliver work in a form the team can review. Change becomes possible after that foundation exists.

Ask after looking, and ask before disappearing

A good question begins with a small amount of investigation. Read the available documentation, search the team’s material, and inspect the nearby code. If the answer is still unclear, ask promptly. This shows that you have made an effort without wasting hours rediscovering knowledge the team already has.

The dangerous pattern is silent struggle. Imagine receiving a task that appears small and then giving no update while several days pass. The person who assigned it does not know whether the task was misunderstood, the system is blocking progress, or help is needed. Silence turns an ordinary obstacle into a coordination problem.

Share the intermediate state before someone has to chase you:

• what you have completed;
• where you are spending time;
• what you tried or read;
• the specific decision or information you need.

This is not a request for constant supervision. It is active ownership. Work is shared in a company, so the engineer closest to a problem should surface it while teammates can still help cheaply.

Learn the team’s reasons before judging its results

Experience creates a different risk. A familiar structure from another workplace can look obviously better than the system in front of you. But the current code may reflect constraints, incidents, staffing, or product decisions you have not learned yet. Comparing everything with “how we did it elsewhere” dismisses both that context and the people who carried it.

Begin by reading broadly. Review the team’s documents and recent discussions. Pull the projects, inspect dependencies, code style, modules, and layers, and ask whether written or unwritten conventions exist. When teammates explain the history, listen for the constraints behind the choices instead of preparing an immediate rebuttal.

Respect does not mean declaring every current decision correct. It means understanding the system well enough to distinguish a genuine problem from an unfamiliar convention. Even when a design is flawed, the people maintaining it need to participate in changing it. Arriving with a private architecture and implementing it without discussion merely creates another system the team did not choose.

Seek review early with a small piece of work

An early, reviewable change is one of the fastest ways to learn how a team actually works. Follow the existing style, keep the scope small, and request feedback as soon as the work is useful to inspect. If the task permits, this can happen within the first few days rather than after a large independent build.

The review teaches more than a guide can. It exposes naming habits, testing expectations, communication style, and assumptions that nobody thought to document. It also gives teammates evidence that you listen, finish work, and respond to feedback.

Avoid using that first change as a stage for a preferred architecture. A newcomer who talks constantly about patterns but cannot finish the assigned work makes expertise hard to trust. Delivering within the team’s current constraints is not surrender; it is how you learn which constraints are real.

Make change a team decision backed by a case

After working together and building trust, start with a concrete problem. A bug, an incident, or a recurring maintenance cost gives the discussion shared evidence. Instead of proposing a complete architecture replacement, suggest the smallest useful boundary: perhaps separate two layers in the area that caused trouble, while leaving a harder internal structure alone for now.

Ask teammates what they think and listen to the trade-offs they see. One person may know why the current design exists; another may identify a safer sequence. The resulting compromise can be less elegant than a private ideal and still be far more likely to survive.

Joining the team first is not passive conformity. It is the work required to make influence legitimate. Timely questions protect delivery, visible progress enables help, early review aligns expectations, and respect uncovers context. Once teammates know that you understand their system and will carry work to completion, improvement becomes something the team can do together rather than something imposed by its newest member.