Guidelines for Frontline Technical Managers: Process, Standards, and Code Review

Overview

The previous article "A Person Gets Promoted Not Only Because of Ability, but Trust" discussed what kind of engineers get promoted and their intentions after becoming frontline managers. This article explains what a frontline technical manager actually manages.

A complete project release typically passes through the following major nodes:

Project Initiation → Requirement Review → Visual Design Review → Technical Review → Project Kick‑off → Development → Integration Test → Testing → Release.

By controlling the quality of each process node, the overall project quality is guaranteed. Therefore, a frontline manager’s job is to ensure the quality of every node.

Establish Standards

Technical Review Standards

Before a technical review, the reviewer must be familiar with the product documentation, business flowcharts, and interaction prototypes provided by the product team, repeatedly confirm details with the product owner, and only then design the technical solution.

The technical solution should be designed from the overall to the local level, covering:

Overall: system architecture diagram, business flowchart, sequence diagram, core class diagram.

Local: feature changes, database field changes, business‑process changes, upstream/downstream interface agreements.

When the technical solution is fixed, the following items are determined:

Technology selection (frontend/backend frameworks, logging middleware, message middleware, database, etc.).

Technical architecture (how components cooperate and are deployed).

Anticipated technical difficulties and their solutions.

Potential performance bottlenecks and mitigation measures.

Upstream/downstream system interaction points and interface delivery / integration timelines.

Functional module division and task allocation.

Required output documents include a development schedule (e.g., Estimated Development Schedule.xlsx ) that lists system, module, function, function description, developers, work hours (h), and estimated completion time. Functional tasks also cover providing interface documents, integration, self‑testing, and documentation updates. The granularity of work items should not exceed 2h to keep tasks simple and approachable.

Project documentation should be updated to include project overview, product documentation, business flow, system architecture, interface documentation, data fields, external dependencies, and other relevant information.

Code Style Standards

Although code style does not affect program execution, a good style improves readability and makes others feel the code is as if they wrote it themselves. Follow language‑specific style guides, such as PHP PSR standards.

Code Development Standards

Integrate a unified visual logging platform.

Integrate a unified configuration center.

Integrate a unified exception monitoring platform.

Integrate a unified message middleware platform.

Exception handling guidelines: direct return, throw exception, retry, circuit‑break, degrade.

Unified API specification: HTTP/RPC interfaces with standardized Code , Msg , Data fields.

Branch development rules: naming conventions, hot‑fix procedures, release procedures, etc.

Other conventions can be added as needed.

Code Management Standards

Common version‑control tools: Git , SVN . Basic agreements include:

Do not commit personal IDE configuration files.

Do not commit code that fails to compile.

Commit early and often; always pull before committing.

Write clear commit messages using the format <type>(scope): <subject> , e.g., fix(homepage): fix JS popup bug . Types include: fix – bug fix feat – new feature test – test code style – code format or comment changes docs – documentation changes refactor – refactoring

scope indicates the affected module, library, or method.

subject is a concise description (preferably under 60 characters) and may include related Jira IDs.

CodeReview Standards

CodeReview should examine:

Normative checks – compliance with coding style and development standards, correct variable definitions, accurate comments.

Robustness checks – avoid infinite loops, unhandled exceptions, resource leaks, runtime errors such as out‑of‑bounds or division by zero.

Reusability checks – duplicate methods, opportunities for generic classes or components.

Security checks – prevent SQL injection, XSS, SSRF, CSRF, privilege escalation, unsafe file uploads, etc.

Performance checks – identify synchronous code that should be async, missing caching, frequent DB connections, need for connection pools.

Execution steps:

Preparation : Define CodeReview standards, assign reviewers and participants.

Implementation : Communicate review scope and standards to all participants, conduct thorough item‑by‑item review, record issues, provide solutions, and discuss design and business logic with authors.

Post‑tracking : Assess difficulty and impact of each issue, set a fix deadline, and verify the fix after implementation.

Summary

The above describes a portion of the responsibilities of a frontline technical manager; it is only a small part of overall management.

In many companies, business code is the primary focus because it generates revenue, but as the organization grows, establishing these standards becomes essential to avoid problems.

If a team is very small, it may prioritize rapid business development over formal processes.

Feedback and suggestions are welcome.