Episode 3: Leading Without Becoming a Manager: Raising Standards Without Becoming the Code Police

Episode 2 covered the difference between mentoring someone without micromanaging and removing overdependencies.

Many experienced engineers fall into this same pattern. Nothing ships without their approval. Every code review depends on them catching mistakes. It feels responsible at first.

Eventually, it becomes a bottleneck.

If code quality exists only because one person enforces it, then quality is not part of the team's culture. It is that person's workload. As covered in Episode 1, technical influence built on credibility scales in ways that authority simply does not. Becoming the gatekeeper trades one for the other.

• Leaving thoughtful review comments that explain the reasoning, not just the correction
  
• Adding tests without being asked
• Documenting decisions that future teammates will need to understand

People notice consistent behavior over time. The standards an engineer practices often become the standards others begin to follow.

One reason code reviews become frustrating is that every discussion feels personal. Without agreed conventions, every review risks becoming a debate about individual preferences rather than engineering decisions.

Strong teams reduce that noise by:

• Agreeing on coding conventions and documenting them
• Capturing architectural decisions where the team can reference them
• Automating formatting and linting to remove subjective debates
  

Shared standards do not eliminate judgment. They reserve it for the decisions that actually matter.

Most engineers hear about what went wrong. Far fewer hear about what went right.

When a teammate writes a thoughtful test, mention it. When someone simplifies a complex solution or catches a subtle bug during review, call it out directly. The behaviors a team celebrates tend to spread.

Culture is built by reinforcing what works, not only by correcting what does not.