Boost Your Productivity: Proven Meeting and Collaboration Hacks for Developers

Preface

If your job does not require writing PRDs, technical specifications, or test cases, you can skip this article; otherwise, the following tips may save you valuable time.

Background

Many new engineers report that non‑coding tasks such as communication and coordination consume the majority of their work time, often exceeding 70% of effort, while actual coding and self‑testing take only one or two days.

Out of concern for fellow engineers, I share a collection of practical work‑style tips.

How to Run Efficient Meetings

As the Meeting Initiator

Prepare meeting documents in advance. For technical design reviews, have a complete document ready before the meeting and discuss agreements with upstream/downstream developers privately. Attach the document to the calendar event to avoid post‑meeting “action items” caused by information gaps.

All review‑type meetings should not turn into open discussions.

Control Invitation Duration

Any meeting longer than one hour should be declined by default unless it is a critical incident review. For technical or product design reviews, a small team representative can attend instead of the whole team.

Based on experience, a review for a requirement under 5 person‑days can be limited to 15 minutes; under 10 person‑days, about 30 minutes.

One‑hour technical reviews are suitable for multi‑domain or full‑stack design sessions. Simple sync meetings (e.g., interface agreements) should not exceed 10 minutes.

If a 10‑minute meeting cannot convey the issue clearly, meet the person directly for pair‑programming style discussion.

Confirm Others' Availability

Before sending an invitation, check whether key participants are available. If a meeting conflicts with their schedule, politely decline or propose a new time and arrange a backup attendee.

Provide the backup with sufficient background to avoid confusion.

Read Meeting Documents in Advance

Every meeting should have a clear agenda and supporting documents. If the organizer does not provide them, request the documents before attending.

If a colleague repeatedly schedules meetings without any documentation, consider skipping those meetings.

Be a Backup for Colleagues

For cross‑team or early‑stage projects, a single representative from each domain (development, product, testing) can attend meetings to reduce overhead.

Notify Time Conflicts Early

If a meeting conflicts with your schedule, decline or mark it as tentative and inform the organizer promptly.

If you have no backup, communicate that either the meeting will be rescheduled or you will miss it, making the importance clear.

Maintain Boundaries

During technical design reviews, developers should not ask product managers about technical details, and product managers should avoid delving into low‑level technical specifics.

How Not to Be Scolded by Testers

Explain Background Before Technical Review

Even if everyone has reviewed the PRD, repeat the scope and requirements during the technical design review to ensure shared understanding.

Self‑Testing Is Mandatory

Perform unit, integration, and UI tests yourself. Do not rely on testers to create test data or trigger flows for you.

Never Make Promises Without Test Involvement

When discussing release dates or risk assessments, do not give estimates without consulting the testing team.

How Not to Be Scolded by Other Developers

Contact Product First

For cross‑domain work, always involve the product manager before reaching out to another development team.

Explain Context Clearly

Provide a concise background and the reason for the request so the other team can understand the business need.

How to Do PM (for Developers)

Create a Working Group

Set up a dedicated DingTalk group for the project instead of using ad‑hoc meeting groups.

Ensure all relevant engineers, product managers, and testers are added.

Keep the group announcement up‑to‑date with meeting schedules and key information.

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

Schedule Meetings Early

Book technical design reviews, test hand‑overs, and release plan reviews at least two days in advance.

Familiarize Yourself with the Technical Solution

Even if you are not writing the code, understand the key technical details and any interface changes that affect your domain.

Summarize the Technical Solution

Maintain a single document that aggregates all relevant specifications, optionally including a high‑level diagram to illustrate dependencies.

Participate in Full‑Chain Meetings

When you are the technical owner of a sub‑domain, attend project‑wide sync meetings to stay informed and avoid last‑minute surprises.

Leverage PMO Support

Use the PMO to book meeting rooms, mediate conflicts, report risks, and coordinate resources across teams.