High-Efficiency Engineering Teams｜Pinkoi Tech Career Talk Insights

点击这里查看本文章简体中文版本。

點擊這裡查看本文章正體中文版本。

This post was translated with AI assistance — let me know if anything sounds off!

---

2021 Pinkoi Tech Career Talk — Secrets to a High-Efficiency Engineering Team

Pinkoi High-Efficiency Engineering Team Revealed Tech Talk Sharing

High-Efficiency Engineering Team Revealed

2021/09/08 19:00 @ Pinkoi x Yourator

My Medium： ZhgChgLi

About the Team

Pinkoi operates through multiple Squads:

• Buyer-Squad: Focused on Buyer-Side Features

• Seller-Squad: Focused on Designer-Side Features

• Exploring-Squad: Focused on Browsing and Exploration

• Ad-Squad: Focused on Platform Advertising

• Out-Of-Squad: Mainly provides support, infrastructure, or process optimization

Each Squad is composed of members from various functions, including PM, Product Designer, Data, Frontend, Backend, iOS, Android, and more; long-term, ongoing work goals are accomplished by the Squad.

Besides Squads, there are also some cross-team Run Projects, mostly with short to medium-term work goals. The Project Owner can be the initiator or any team member in any role. Once the task is completed, the project is closed.

At the end of the article, there is a section on how Pinkoi’s culture supports team members in solving problems. If you are not interested in the specific actions taken, you can go directly to the bottom of the page to read this section.

Relationship Between Group Size and Efficiency

The relationship between team size growth and work efficiency: I have experience in startups with teams of 10 people up to teams of 100 (haven’t yet experienced teams of 1,000). Just growing from 10 to 100, a tenfold increase, makes a significant difference in many aspects.

With fewer people, communication and task handling are very fast. You can discuss in person, and the response will come immediately; because the “human connection” is very strong, everyone can collaborate in sync.

But when there are many people, direct communication becomes difficult because more collaborators are involved. If everyone talks at once, the whole morning can be wasted. Also, since everyone collaborates with many others, tasks must be prioritized. Non-urgent matters cannot be addressed immediately, so asynchronous waiting is necessary while working on other things.

More roles can enable more detailed and professional division of labor, provide higher productivity or better quality, and faster output.

As mentioned at the beginning, conversely, there will be more collaboration with people, and collaboration means more communication time.

Small issues can be magnified. For example, if one person needs 10 minutes daily to submit reports, it’s acceptable; but if it involves 20 people, it adds over 3 extra hours daily. In this case, optimizing and automating report submission becomes valuable, saving 3 hours per day. Over 250 working days a year, that amounts to 750 hours wasted.

As the team grows, taking the App Team as an example, these roles will have closer collaboration.

Backend — API, Product Designer — UI goes without saying. Since Pinkoi is an international product, all functional text needs to be translated by the Localization Team. Also, because we have a Data Team handling data collection and analysis, besides developing features, we need to discuss event tracking points with the Data Team.

Customer Service is also a team that frequently interacts with us. Besides users sometimes reporting order issues directly through mall reviews, more often users leave a one-star rating indicating a problem. At this time, we need the customer service team to help investigate further by asking what the issue is and how we can assist.

With so many collaborations, it means many communication opportunities.

But remember, we are not avoiding or minimizing communication; excellent communication skills are also important for great engineers.

Our focus should be on important communication, such as brainstorming ideas, discussing requirements, and scheduling. Avoid wasting time on repeated confirmations or vague, unfocused discussions, including unnecessary back-and-forth questions.

Especially in the pandemic era, communication time is precious and should be spent on more valuable discussions.

“I thought you thought I thought you thought” — this sentence perfectly illustrates the consequences of unclear communication.

Let’s not talk about work. In daily life, misunderstandings often happen due to different perceptions. A relaxed and comfortable life relies on mutual understanding; however, this doesn’t apply to work. If both parties have different understandings and don’t discuss them deeply, it’s easy to realize at the output stage that things are completely different from what was expected.

Interface Communication

The idea introduced here is to communicate through a consensus interface, similar to the Dependency Inversion Principle in SOLID principles of object-oriented programming (it’s okay if you don’t understand this); the same concept can be applied in communication.

The first step is to identify which areas are unclear, require repeated confirmation, or need specific communication to be more focused and effective, or even which deliverables can eliminate the need for additional communication.

Once the problem is identified, the “interface” can be defined. An interface means a medium, which can be a questionnaire, process, checklist, tool, etc.

Use this “interface” as a bridge for communication. There can be multiple interfaces; use the one that fits the scenario. For the same scenario, prioritize this interface for initial communication. If further discussion is needed, use this interface to focus on the issue in depth.

Collaboration Between the App Team and External Partners

Here are four examples of interface communication using the App Team collaboration as an example:

The first case involves collaborating with the backend, where the above situation may occur before any interface consensus is reached.

Regarding how to use the API, simply providing the API response string to the App Team can lead to ambiguities. For example, with a date field, how do we know if it refers to the Register Date or Birthday? Also, since the scope is broad, many fields need clarification.

This communication is also repetitive; every time there is a new Endpoint, it needs to be confirmed again.

This is a classic example of ineffective communication.

The missing link between the App and Backend is a communication interface. There are many solutions, and it doesn’t have to be a tool; it could simply be a manually maintained document.

This section was shared at the 2020 Pinkoi Developer Night — by Toki

Pinkoi uses Python (FastAPI) to automatically generate documentation from API code. PHP can use Swagger (previous company practice); the advantage is that the overall structure and data format of the documentation can be automatically generated from the code, reducing maintenance costs and only requiring proper handling of field descriptions.

p.s. Currently, new Python 3 projects use FastAPI. Older parts will be updated gradually. For now, PostMan is used as the communication interface.

The second is collaboration with Product Designers, which is basically similar to working with Backend, but the focus shifts to confirming UI Specs and verifying Flows.

If color codes and fonts are scattered, our app will suffer greatly. Setting aside the fact that the requirements are like this, we don’t want situations where the same title has the same color but different color codes, or where the UI is inconsistent in the same position.

The most basic solution is to have the designer organize the UI component library, establish a Design System (Guideline), and properly label the UI during delivery.

We build corresponding Fonts and Colors in the Code Base according to the Design System (Guideline), and create Buttons and Views based on the component library.

When templating, consistently use these pre-built components, so we can quickly align by directly referring to the UI design drafts.

But this can easily get messy and requires dynamic adjustment; it should neither cover too many special cases nor stubbornly reject any expansion.

p.s. Collaboration between Pinkoi and Product Designers is mutual; Developers can also suggest better approaches and discuss them with Product Designers.

The third is the interface with Customer Service. Store reviews are very important for products, but it is a very manual and repetitive process of referral communication.

Because we need to manually check for new reviews from time to time, and if there are customer service issues, forward them to the support team for assistance, it is very repetitive and manual.

The best solution is to have store reviews automatically synced to our work platform. We can either pay for existing services or use the tools I developed: ZhgChgLi / ZReviewTender (new in 2022).

Deployment methods, tutorials, and technical details can be found at: ZReviewTender — Free Open-Source App Reviews Monitoring Bot

This bot is our communication interface. It automatically forwards reviews to the Slack Channel, allowing everyone to quickly receive the latest review updates and track, communicate, and discuss them there.

The last example involves dependency on the Localization Team; whether it’s new features or updating old translations, we need to wait for the Localization Team to finish their work before we can assist further.

The cost of developing this tool in-house is too high, so we directly use third-party services to help us eliminate dependencies.

All translations and keys are managed by third-party tools. We only need to set the keys in advance to work independently. Both sides just need to finish their tasks before the deadline without relying on each other. After the Localization Team completes the translation, the tool will automatically trigger a git pull to update the latest text files into the project.

p.s Pinkoi adopted this process early on, initially using Onesky. However, in recent years, there are many better tools available that you can consider using.

Collaboration Relationships Within the App Team

What was just mentioned is external; now let’s talk about internal.

When there are few people, or when a single developer maintains a project, you can do whatever you want. Your grasp and understanding of the project are very high, so there are usually no major issues. Of course, if you have good sense, even a one-person project can accomplish everything mentioned here.

However, as more teammates collaborate, all working under the same project, it would be disastrous if everyone works independently.

For example, calling an API here, doing this there, often reinventing the wheel and wasting time, or not caring at all and just rushing to launch, will greatly increase future maintenance and scalability costs.

Within the team, rather than calling it an interface, it feels too distant; it should be called consensus or resonance to foster a stronger sense of team spirit.

The most basic and common topic is Coding Style, including naming conventions, placement, how to use Delegates, etc. You can enforce these using industry-standard tools like realm / SwiftLint. For multilingual strings, you can organize them with freshOS / Localize. (Of course, if you are already managing these uniformly with third-party tools mentioned earlier, you may skip this.)

The second is the app architecture. Whether it’s MVC, MVVM, VIPER, or Clean Architecture, the key is to keep it clean and consistent. There’s no need to chase trends; consistency is what matters.

Pinkoi App Team uses Clean Architecture.

Previously at StreetVoice, it was pure MVC but clean and consistent, making collaboration smooth.

There are also UnitTests. With many people involved, it’s hard to avoid accidentally breaking the logic you wrote; having more tests provides extra protection.

Finally, there is the documentation part, which covers the team’s workflows, specifications, or operation manuals. This helps teammates quickly reference when they forget something and allows new members to get up to speed quickly.

Besides the Code Level interface, there are other interfaces that help us improve collaboration efficiency.

The first step is a Request for Comments phase before implementing the requirement. The developer briefly explains how the requirement will be addressed, and others can provide feedback and ideas.

Besides preventing reinventing the wheel, it also encourages brainstorming. For example, others can consider how to expand or use it later, or what future needs might be taken into account… Sometimes those involved are confused, while outsiders see clearly.

Second, conduct thorough Code Reviews to ensure our interface standards are implemented, such as naming conventions, UI layout methods, delegate usage, protocol/class declarations, and so on.
Also, check if the architecture is misused or if code is hastily written due to time pressure. For example, if the development direction aims for full Swift adoption, verify that no Objective-C code is still being submitted.

The main focus is on reviewing these, followed by assistance with whether the functions work properly or not.

p.s. The purpose of an RFC is to improve work efficiency, so it should not be too lengthy or seriously delay progress; think of it as a simple pre-work discussion.

Summarizing the interface consensus within the team, the final mention of a crash theory mindset strikes me as a good behavioral benchmark.

Excerpted from MBA Library

Applied to a team, it means assuming everyone suddenly disappears—can the existing code, processes, and systems allow new people to quickly get up to speed?

Recap Interface Meaning: Interfaces within the team are used to build mutual understanding, while collaboration outside the team aims to reduce ineffective communication. Using interfaces for communication has no shortcuts; focus on discussing requirements.

To reiterate, “interface communication” is not a special term, tool, or engineering concept. It is simply a concept applicable to collaboration in any job scenario. It can be just a document or a process, and it must exist first before communication can take place.

Assuming each extra communication takes 10 minutes, with a team of 60 people and 10 occurrences per month, it wastes 1,200 hours a year on unnecessary communication.

Boost Efficiency — Automate Repetitive Tasks

Chapter 2: Sharing the Impact of Automating Repetitive Tasks on Improving Work Efficiency

I will use iOS as an example, but the same approach applies to Android.

Will not mention technical implementation details, only discuss feasibility in principle.

Organize the services we have used, including but not limited to:

• Slack: Communication Software

• Fastlane: iOS Automation Script Tool

• Github: Git Provider

• Github Action: Github’s CI/CD service, to be introduced later

• Firebase: Crashlytics, Event, App Distribution (to be introduced later), Remote Config…

• Google Apps Script: The add-on scripting for Google Apps, to be introduced later

• Bitrise: CI/CD Server

• Onesky: Previously mentioned as a third-party tool for Localization

• Testflight: iOS App Beta Testing Platform

• Google Calendar: Google Calendar, its usage will be introduced later

• Asana: Project Management Tool

Issues with Releasing the Beta Version

The first repetitive issue is when we want to let teammates test the app early during development. Traditionally, we just borrow a phone to build the app. If there are only 1-2 people, it’s not a big problem, but if the team has 20-30 testers, just installing the test versions can take the whole day. Plus, if there are updates, the entire process has to be repeated.

Another method is using TestFlight as a beta release platform, which I think is also good; but there are two issues. First, TestFlight is equivalent to a Production environment, not Debug. Second, when many teammates need to test different features simultaneously during development, TestFlight can get chaotic, and the packaged builds will be frequently changed. However, it is still feasible.

Pinkoi’s solution is to first separate the task of “having the App Team install the test version.” They use Slack WorkFlow as the input UI to achieve this. Once the input is completed, it triggers Bitrise to run a Fastlane script that packages and uploads the test ipa to Firebase App Distribution.

For Slack Workflow applications, refer to this article: Slack builds a fully automated WFH employee health status reporting system

Firebase App Distribution

Testers just need to follow the Firebase App Distribution steps to install the certificate and register their devices. Then, they can select the desired beta version to install on the platform or simply click the link in the email to install it directly.

Note that iOS Firebase App Distribution uses Development Devices, with a limit of only 100 devices registered, counted by device not by user.

So it may be necessary to balance this with the TestFlight solution (by person, external testing with 1,000 users).

But at least the previous Slack WorkFlow UI Input can be considered for use.

For advanced use, you can develop a Slack Bot to have a more complete and customized workflow and forms available.

Recap the release of the beta automation results: the most noticeable improvement is moving the entire process to the cloud, allowing the App Team to be hands-off and fully self-service.

Issues with Packaging the Official Version

The second is also a common task for the App Team: packaging and submitting the official version of the app for review.

When the team was small, development was single-threaded. App version updates were not a big issue and could be done freely or regularly.

However, with a large team and multiple development and iteration demands running simultaneously, the situation shown in the above image occurs. Without proper “interface communication” as mentioned earlier, everyone works independently. This causes the App Team to be overwhelmed since app updates are more costly and complex than web updates. Additionally, frequent and chaotic updates disrupt the user experience.

Finally, management issues arise. Without fixed processes and dates, it is difficult to optimize what needs to be done at each step.

請提供您需要翻譯的 Markdown 文章段落內容，我將依照您的要求進行翻譯。

The solution is to introduce a Release Train into the development process. The core concept is to separate version updates from project development.

We have fixed the schedule and determined what will be done at each stage:

• Update the new version every Monday morning

• Code freeze on Wednesday (No more merging feature PRs)

• QA starts on Thursday

• Official packaging every Friday

Actual timelines (QA duration), release cycles (weekly, biweekly, monthly) can be adjusted according to each company’s situation. The core is to determine what to do at fixed times.

This is a survey from foreign Twitter users about update cycles, mostly every two weeks.

Taking weekly updates & our multiple teams as examples, it would be like the image above.

Release Train, as the name suggests, is like a train station, where each version is a train.

If you miss it, you’ll have to wait for the next one. Each Squad team and project can choose their own boarding time.

This is a great communication interface. As long as everyone agrees and follows the rules, version updates can proceed smoothly and orderly.

For more technical details about Release Train, please refer to:

• Mobile release trains — Travelperk

• Agile Release Train

• Release Quality and Mobile Trains

Once the process and schedule are finalized, we can optimize the tasks for each stage.

For example, packaging a release version manually is time-consuming and labor-intensive. The entire process of packaging, uploading, and submitting for review takes about an hour. During this time, you must constantly switch tasks, making it hard to do other work. Repeating this process for every package wastes a lot of productivity.

Since our schedule is fixed, we directly integrate Google Calendar here, adding the planned tasks to the calendar. When the time comes, Google Apps Script will call Bitrise to run Fastlane, packaging the official version and submitting the review script to complete all tasks.

Another advantage of integrating with Google Calendar is that if unexpected situations arise requiring a delay or an earlier time, you can simply go in and change the date directly.

To automatically run a Google Apps Script when a Google Calendar event starts, you currently need to use your own on service. For a quick solution, you can use IFTTT as a bridge between Google Calendar and Bitrise/Google Apps Script. The method can be found in this article.

p.s.

1. Currently, the Pinkoi iOS Team uses the Gitflow workflow.
2. In principle, this consensus must be followed by all teams, so requests that break this rule are not desired (e.g., special Wednesday releases). However, for projects involving external collaboration, flexibility should be maintained since this consensus is internal to the team.
3. HotFixes for critical issues can be updated at any time and are not subject to the Release Train rules.

Here, Google App Scripts applications are additionally mentioned. For details, please refer to: 運用 Google Apps Script 轉發 Gmail 信件到 Slack .

The last one is using Github Action to improve collaboration efficiency (PR Review).

Github Action is Github’s CI/CD service, which can be directly linked to Github events. Trigger timings include opening an issue, opening a PR, merging a PR, and more.

Github Actions can be used with any Git project hosted on Github. There are no restrictions for public repositories, and private repositories have a free monthly quota of 2,000 minutes.

Here are two features:

• (Left) After PR Review is completed, the reviewer name Label will be automatically added, allowing us to quickly summarize the PR review status.

• (On the right) is a tool that organizes and sends messages to a Slack Channel at fixed times daily, reminding teammates which PRs are waiting for review (modeled after Pull Reminders’ features).

Github Actions offer many automation possibilities; everyone can use their imagination.

Like the issue bots often seen in open source projects:

fastlane / fastlane

Automatically closing PRs that have not been merged for a long time can also be done using GitHub Actions.

Recap the results of automating the official version packaging, still using existing tools for integration; besides automation, a fixed process was added to double work efficiency.

Originally, besides the manual packaging time, there was additional communication time for deployment, which is now reduced to zero; as long as you ensure to board within the schedule, all the time can be focused on “discussion” and “development.”

In total, these two automations save 216 work hours per year.

With automation combined with the previously mentioned communication interface, let’s see how much efficiency can be improved by doing these tasks.

Besides the projects we just completed, we also need to evaluate the cost of flow switching. After working continuously for a period, we enter a “flow” state where our thoughts and productivity peak, enabling the most effective output. However, if interrupted by unnecessary matters (e.g., redundant communication, repetitive tasks), it takes time to return to flow again. Here, we use 30 minutes as an example.

The cost of switching flow due to unnecessary interruptions should also be considered. Here, we estimate 30 minutes per interruption, occurring 10 times a month. For 60 people, this results in 3,600 wasted hours per year.

Flow switching cost (3,600) + extra communication due to poor interface (1,200) + repetitive tasks solved by automation (216) = over 5,016 hours lost in a year.

The time originally wasted on work can be saved and invested in other more valuable tasks, so the actual productivity gain should be multiplied by another 200%.

Especially as the team size continues to grow, the impact on work efficiency also increases.

Optimize early, enjoy early; optimize late, no discount!!

Recap of the insider details of a high-efficiency work team: what we mainly did.

No Code/Low Code First Prioritize existing tool integration (as shown in this example). Only evaluate automation costs and actual savings if no existing tools are available.

Support for Culture

On Pinkoi, Everyone Can Be a Problem-Solving Leader

For solving problems and making changes, the vast majority require the collective effort of many teams to improve. This greatly depends on the support and encouragement of company culture; otherwise, driving progress alone can be very difficult.

At Pinkoi, anyone can be a problem-solving leader. You don’t have to be a Lead or PM to solve problems. Many communication interfaces, tools, or automation projects introduced earlier were discovered by teammates who proposed solutions, and everyone worked together to complete them.

Regarding how team culture supports driving change, the four stages of problem-solving can all be linked to Pinkoi’s Core Values.

Step 1 Grow Beyond Yesterday

• Good but strive for better. If any issues are found, no matter how small, as mentioned earlier, with the team’s growth, even small problems can have amplified effects.

• Investigate and summarize issues to avoid premature optimization (some problems may be only temporary).

Next is Build Partnerships

• Actively communicate on all fronts to gather suggestions

• Maintain empathy (since some solutions might be the best option for the other party, so careful consideration is needed)

Step 3: Impact Beyond Your Role

• Leverage Your Influence

• Propose a Problem-Solving Plan

• If related to repetitive tasks, prioritize using automation solutions

• Remember to maintain flexibility and scalability, and avoid over-engineering.

Finally, Dare to Fail!

• Be Brave to Take Action

• Continuous Monitoring and Dynamic Solution Adjustment

• After achieving success, remember to share the results with the team to promote cross-departmental resource integration (because the same issue may exist in multiple departments simultaneously)

The above is a sharing from the Pinkoi high-efficiency engineering team. Thank you all.

Join Pinkoi now »> https://www.pinkoi.com/about/careers

If you have any questions or feedback, feel free to contact me.

---

This post was originally published on Medium (View original post), and automatically converted and synced by ZMediumToMarkdown.

Improve this page on Github.

Follow Me on Medium 1K+ Followers