Change Engineering Culture Through Trust and Small Wins

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 company may ship quickly with no tests, no current policy document, and specifications passed from one developer to another. Bugs take a long time to understand because nobody knows whether the remembered rule is still current. Do not answer with an immediate company-wide reform. For at least the first three months, keep your ears open, do the work well, and earn trust from developers and non-developers.

Gather around one piece of real work

After understanding the team, propose a recurring hour every two or three weeks to discuss the actual service. The name is unimportant. Bring an unclear policy, a recent incident, or a flow the team does not understand. The purpose is not to study an outside theory; it is to make the team’s code and business knowledge visible.

Tests enter through the same work. Do not demand coverage for the whole legacy system. Pair on a recent bug or write the regression case that would protect the next change. When a test later catches a similar problem before release, teammates experience its value rather than hearing a lecture about it.

Let one team’s result create the next invitation

Begin with the team you can influence. Neighboring developers noticed a public channel where people were solving real work, asked to observe, and wanted to try the format in their own teams. The changed atmosphere and visible work on real problems made the practice noticeable without a company mandate. Product and planning colleagues may eventually notice requests finishing faster or operating issues declining; the source illustrates this with a change that might take one month instead of two. Explain the connection when such a result appears. Invite them when policy knowledge is needed, because documenting a rule or writing a test can reveal that even product and engineering held different versions of the specification.

Some structures will not permit the sequence

The result may take a month or a year, so the effort needs patience. It also needs willing colleagues. If long-tenured people use hidden knowledge as power and an entrenched group blocks every attempt to improve, bottom-up effort may not be enough. In that case, leave rather than pretend persistence can overcome the structure.

Where people want improvement but do not know how, the sequence is workable: observe, deliver, earn trust, create one useful team practice, show what changed, and let others pull it outward.