Effective Work Practices for Developers: Meeting Management, Communication, and PM Tips

The author, from a developer’s perspective, summarizes a collection of work‑efficiency techniques aimed at helping engineers handle meetings, communication, and product management more effectively.

How to Conduct Efficient Meetings

As the meeting initiator, prepare a complete technical document before the review, share it privately with upstream/downstream developers, and attach it to the calendar event. Avoid turning review meetings into open discussions. Limit meeting length based on effort size: under 5 person‑days, keep the technical review to 15 minutes; under 10 person‑days, about 30 minutes; larger reviews may take up to an hour.

Do not schedule meetings longer than one hour unless they are critical post‑mortems. If a meeting conflicts with your schedule, politely decline or propose an alternative and ensure a backup participant is informed.

Confirm Availability Before Inviting

Check whether core participants are available before sending an invitation. If many meetings are ad‑hoc, it indicates a lack of planning. For a demand with a 15‑day deadline, the product manager should send a review invitation at least two days in advance, and developers should do the same for technical reviews.

Read Meeting Documents in Advance

Every meeting should have a clear agenda and supporting documents. If the organizer does not provide them, request them yourself. Repeated meetings without documentation suggest the meeting may not be essential.

Backup Participation

When a meeting conflicts with your schedule, inform the host and arrange a backup colleague to attend, providing them with necessary background to avoid confusion.

Maintain Clear Boundaries

During technical reviews, developers should not ask product managers about technical details, and product managers should avoid delving into technical specifics such as schema design.

How Not to Be Criticized by Testers

Always explain the background of a technical solution before a review. Conduct thorough self‑testing (unit, integration, UI) and avoid relying on testers to perform basic checks. Do not make promises on release dates or risk assessments without involving testers.

How Not to Be Criticized by Other Developers

When collaborating across teams, always involve the product manager first, then coordinate with the appropriate developers. Clearly describe the business context and required assistance.

Simple PM Practices for Developers

Create a dedicated DingTalk group for the project, keep all relevant team members in the group, and update the group announcement with essential information such as domain responsibilities, review schedules, integration environment, test dates, and release dates.

子域<span>1</span>：对应开发、对应PD、对应测试</code><code>子域<span>2</span>：对应开发、对应PD、对应测试</code><code><br/></code><code>技术方案评审时间：xxxxx</code><code>联调时间：x<span>'x'</span>x</code><code>联调环境：dpath(xxxx)</code><code>提测时间：xxx</code><code>发布时间：xxxx</code><code><br/></code><code>PRD: 链接<span>1</span>、PRD: 链接<span>2</span></code><code>技术方案：链接<span>1</span>、链接<span>2</span>

Additional Advice

Participate in full‑link meetings if you are a technical interface person for a sub‑domain, and keep the information flow smooth without pulling unnecessary colleagues into every meeting.

When facing project risks or scope changes, involve the PMO for meeting‑room booking, conflict resolution, risk reporting, and resource coordination.

Overall, applying these habits can reduce wasted time, improve communication clarity, and help developers focus on delivering value.