2021 Pinkoi Tech Career Talk — High-Efficiency Engineering Team Unveiled

2021 Pinkoi Tech Career Talk — High-Efficiency Engineering Team Unveiled

Pinkoi High-Efficiency Engineering Team Unveiled Tech Talk Sharing

High-Efficiency Engineering Team Unveiled

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

My Medium： ZhgChgLi

About the Team

Pinkoi’s working method is composed of multiple Squads:

• Buyer-Squad: Focuses on buyer-side features
• Seller-Squad: Focuses on designer-side features
• Exploring-Squad: Focuses on browsing and exploration
• Ad-Squad: Focuses on platform advertising
• Out-Of-Squad: Mainly supports, Infra, or process optimization

Each Squad is composed of teammates from various functions, including PM, Product Designer, Data, Frontend, Backend, iOS, Android, etc. Long-term, continuous work goals are completed by the Squad.

In addition to Squads, there are also cross-team Run Projects, mostly with short to medium-term work goals. The initiator or any teammate can serve as the Project Owner, and the task is closed upon completion.

At the end of the article, there is how Pinkoi’s culture supports teammates in solving problems. If you are not interested in the actual content, you can skip to the bottom to view this section.

Relationship Between Team Size and Efficiency

The relationship between team size growth and work efficiency. Having experienced teams from 10 people startups to teams of hundreds (haven’t challenged thousands yet), but just jumping from 10 to 100, the 10-fold difference is very noticeable in many aspects.

With fewer people, communication and handling things are quick. You can discuss and get things done immediately because the “connection between people” is very strong, and everyone can collaborate synchronously.

However, with more people, direct communication becomes difficult because there are more collaborators. Spending the whole morning talking to everyone is not feasible. Also, everyone has many collaborators, so tasks are prioritized. Non-urgent matters cannot be addressed immediately, requiring asynchronous waiting and doing other tasks.

More roles joining can make work division more detailed and professional, providing more productivity, better quality, and faster output.

But as mentioned at the beginning, relatively, there will be more collaboration, which means more communication time.

Small issues can be magnified, for example, if one person spends 10 minutes daily on reporting, it’s acceptable. But if it becomes 20 people, it adds up to over 3 hours daily. Optimizing and automating reporting becomes valuable, saving 3 hours daily, which is 750 hours annually, assuming 250 working days.

As team size grows, taking the App Team as an example, there are closely collaborating roles.

Backend — API, Product Designer — UI, this is obvious. Pinkoi is an international product, so Localization Team helps translate functionality text. We also have a Data Team for data collection and analysis, so 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 directly providing feedback on order issues through the mall reviews, more often, users leave a one-star rating indicating they encountered a problem. At this time, we also need to ask the customer service team to help with in-depth inquiries: What is the problem? How can we help you?

With so many collaborative relationships, it means there are many communication opportunities.

But remember, we are not avoiding or trying to minimize communication. Excellent engineers also need good communication skills.

We need to focus on important communications, such as brainstorming, discussing requirements, and timelines. Do not waste time on repeated problem confirmations or vague communications. Avoid situations where you ask me, I ask you, and he asks me.

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

“I thought you thought what I thought” — This phrase perfectly illustrates the consequences of vague communication.

Not just at work, but in daily life, we often encounter misunderstandings due to different perceptions. In life, we rely on mutual understanding for ease and comfort; but at work, this is not acceptable. If different perceptions are not thoroughly discussed, it is easy to find out at the production stage that things are not as expected.

Interface Communication

The idea 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). The same concept can be applied to communication.

The first step is to identify what is vague, what needs repeated confirmation, or what communication is needed to be more focused and effective, or even what can be delivered without additional communication.

After identifying the problem, you can define an “interface.” An interface is a medium, which can be a document, process, checklist, or tool, etc.

Use this “interface” as a bridge for communication. There can be multiple interfaces, and different scenarios use different interfaces. For similar scenarios, use this interface for initial communication. If further communication is needed, you can have an in-depth and focused discussion based on this interface.

App Team and External Collaboration

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

The first example is collaboration with the Backend. Without any consensus interface, the situation in the above image may occur.

For how to use the API, if you simply give the API Response String to the App Team, there can be ambiguities. For example, date — how do we know if it is Register Date or Birthday? There are many fields that need confirmation.

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

This is a classic case of ineffective communication.

What the App and Backend teams lack is a communication interface. There are many solutions, and it doesn’t necessarily have to be a tool; it can just be a manually maintained document.

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

Pinkoi uses Python (FastAPI) to automatically generate documents from API Code. PHP can use Swagger (previous company practice). The advantage is that the main framework and data format of the document can be automatically generated from the code, reducing maintenance costs. You only need to handle the field descriptions.

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

The second example is collaboration with the Product Designer. The principle is similar to the Backend, but the problem is confirming UI Spec and Flow.

If color codes and fonts are scattered, our App will also suffer. Apart from the inherent requirements, we don’t want situations where the same Title has different color codes or inconsistent UI in the same position.

Solution The most basic step is to have the designer organize the UI component library and establish a Design System (Guideline), and mark it well when releasing the UI.

In the Code Base, we establish corresponding Fonts and Colors based on the Design System (Guideline) and create Buttons and Views based on the component library.

When templating, we uniformly use these pre-established components, making it easy to quickly align by directly looking at the UI design draft.

But this can easily get messy and requires dynamic adjustments; it shouldn’t cover too many special cases, nor should it be rigid and unexpandable.

p.s. At Pinkoi, collaboration with Product Designers is mutual. Developers can also propose better methods and discuss them with Product Designers.

The third interface is with Customer Service. Reviews in the marketplace are very important for products, but it is a very manual and repetitive task to communicate and refer issues.

Because you have to manually check new reviews from time to time, and if there are customer service issues, forward them to customer service for assistance, which is very repetitive and manual.

The best solution is to automatically sync marketplace reviews to our work platform. You can spend $ to buy existing services or use the ZhgChgLi / ZReviewTender (new in 2022) that I developed.

For deployment methods, tutorials, and technical details, refer to: ZReviewTender — Free and Open Source App Reviews Monitoring Bot

This bot is our communication interface. It will automatically forward reviews to the Slack Channel, allowing everyone to quickly receive the latest review information and track, communicate, and discuss on it.

The last example is the dependency on the Localization Team. Whether it’s a new feature or modifying an old translation, we need to wait for the Localization Team to complete their work before we can assist with subsequent processing.

The cost of developing this tool ourselves 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. As long as we set the keys in advance, we can work independently, and both sides only need to complete their work before the deadline. There’s no need to depend 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 has had this process since the early days, and at that time, Onesky was chosen. However, in recent years, there are more excellent tools available, and you can consider adopting others.

Internal Collaboration within the App Team

We just talked about external collaboration, now let’s talk about internal collaboration.

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

But as more teammates collaborate, and everyone works under the same project, if everyone does their own thing, it will be a disaster.

For example, calling APIs differently here and there, frequently reinventing the wheel and wasting time, or not caring and just doing things haphazardly will greatly increase the cost of future maintenance and scalability.

Within the team, instead of calling it an interface, I think it’s too formal; it should be called consensus and resonance to have a stronger sense of team awareness.

The most basic and often talked about is Coding Style, naming conventions, placement, how to use Delegates, etc. You can use industry-standard tools like realm / SwiftLint for constraints. For multilingual sentences, you can use freshOS / Localize for organization (of course, if you are already using the third-party tool mentioned earlier for unified management, you don’t need this).

The second is the App architecture. Whether it’s MVC/MVVM/VIPER/Clean Architecture, the core focus is on cleanliness and consistency; it doesn’t have to be trendy, just consistent.

The Pinkoi App Team uses Clean Architecture.

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

There’s also Unit Testing. With a large team, it’s hard to avoid the logic you are working on from being accidentally broken someday; writing more tests provides more assurance.

Lastly, there’s documentation. This includes the team’s workflow, specifications, or operation manuals, making it easy for teammates to quickly refer to when they forget something and for newcomers to get up to speed quickly.

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

First, there’s a Request for Comments stage before implementing a requirement. The person responsible for development briefly explains how the requirement will be implemented, and others can provide feedback and ideas.

This not only prevents reinventing the wheel but also allows for brainstorming. For example, how others might extend it in the future, or what future requirements might be considered… etc. Sometimes, an outsider’s perspective is clearer.

Second, there’s Code Review to ensure our interface consensus is implemented, such as naming conventions, UI layout methods, delegate usage, protocol/class declarations… etc. It also checks if the architecture is misused or hastily written, and if the development direction is towards Swift, whether there is still Objective-C code being submitted… etc.

The main focus is on reviewing these aspects, and secondly on whether the functionality works correctly… and so on.

p.s. The purpose of RFC is to improve work efficiency, so it shouldn’t be too lengthy or seriously delay the work progress; think of it as a simple pre-work discussion phase.

Summarizing the function of interface consensus within the team, I want to mention a Crash Theory mindset, which I think is a good behavioral benchmark.

Excerpt from MBA Library

Applying this to the team means assuming that everyone suddenly disappears today. Can the existing code, processes, and systems allow new people to quickly get up to speed?

Recap the significance of interfaces. Internal team interfaces are used to increase mutual consensus, while external collaboration interfaces reduce ineffective communication. Use interfaces as communication tools, focusing on requirement discussions.

Reiterate that “interface communication” is not a special term or tool, nor an engineering concept. It’s just an idea applicable to any job scenario collaboration. It can simply be a document or process, and it should be established before communication.

Assuming each additional communication takes 10 minutes, with a team of 60 people, occurring 10 times a month, that’s 1,200 hours wasted on unnecessary communication in a year.

Improving Efficiency — Automating Repetitive Tasks

The second chapter aims to share the effects of automating repetitive tasks on improving work efficiency, using iOS as an example, but the same applies to Android.

It won’t cover technical implementation details, only the feasibility in principle.

Here’s a summary of the services we use, 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: Google Apps’ plugin script program, to be introduced later
• Bitrise: CI/CD server
• Onesky: Third-party tool for localization mentioned earlier
• Testflight: iOS app beta testing platform
• Google Calendar: Google Calendar, to be introduced later on its usage
• Asana: Project management tool

Issues with Releasing Beta Versions

The first recurring issue to mention is when our app is in the development stage and we want to give other teammates an early test. Traditionally, we would directly borrow a phone to build; if there are only 1-2 people, it’s not a big deal, but if the team has 20-30 people to test, just helping with the installation of the beta version would take up the whole day, and if there are updates, the whole process has to be repeated.

Another method is to use TestFlight as a medium for releasing beta versions, which I think is also good; but there are two issues. The first is that TestFlight is equivalent to a production environment, not debug; the second is that when there are many simultaneous development needs and colleagues need to test different requirements, TestFlight can become chaotic, and the build versions will change frequently, but it’s not impossible.

Pinkoi’s solution is to first separate the task of “installing the beta version by the App Team” and use Slack Workflow as the input UI to achieve this. After inputting, it triggers Bitrise to run the Fastlane script to package and upload the beta version ipa to Firebase App Distribution.

For more on Slack Workflow applications, refer to this article: Slack Builds a Fully Automated WFH Employee Health Status Reporting System

Firebase App Distribution

Teammates who need to test just need to follow the steps of Firebase App Distribution to install the certificate and register the device, then they can choose to install the desired beta version or directly click the link in the email to install.

Note that iOS Firebase App Distribution occupies Development Device slots, with a limit of 100 devices, counting devices not people.

So you might need to balance this with TestFlight (by people, external testing for 1,000 people).

At least the Slack Workflow UI Input in the front is worth considering.

For more advanced needs, you can develop a Slack Bot for a more complete and customized process and forms.

Recap of the effectiveness of automating beta version releases: the most noticeable benefit is moving the entire process to the cloud, making it fully self-service without the App Team’s intervention.

Issues with Packaging the Official Version

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

When the team is small and there is only single-line development, updating the app version is not a big issue; it can be done freely and regularly.

But when the team grows and there are multiple lines of development and iteration, you encounter situations like the one shown above. Without proper “interface communication” as mentioned earlier, everyone will work on their own, leading to the App Team being overwhelmed. The cost of updating an app is higher than a webpage, and the process is cumbersome. On the other hand, frequent and chaotic updates also disrupt users.

Finally, there is the management issue. Without a fixed process and schedule, it is difficult to optimize what needs to be done at each step.

The problem is as shown above.

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

We fix the schedule and set what will be done at each stage:

• Update the new version every Monday morning
• Code Freeze every Wednesday (no more merging of Feature PRs)
• Start QA every Thursday
• Package the official version every Friday

The actual schedule (how long QA takes) and release cycle (weekly, bi-weekly, monthly) can be adjusted according to each company’s situation. The core is to determine what to do at what fixed time.

This is a survey on release cycles posted by a foreign Twitter user, with most being bi-weekly.

Using weekly updates & our multi-team setup as an example, it would look 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 have to wait for the next one. Each Squad team and project can choose their boarding time.

This is a great communication interface. As long as everyone agrees and follows the rules, updates can be rolled out smoothly.

For more technical details on Release Train, refer to:

• Mobile release trains — Travelperk
• Agile Release Train
• Release Quality and Mobile Trains

Once the process and schedule are determined, we can optimize what needs to be done at each stage.

For example, packaging the official version manually is time-consuming and labor-intensive. The entire process from packaging, uploading, to review takes about 1 hour, during which it’s hard to do other tasks due to constant context switching. Repeating this process every time wastes work efficiency.

Since we have a fixed schedule, we directly integrate Google Calendar, adding the tasks to be done to the calendar. When the time comes, Google Apps Script will call Bitrise to execute the Fastlane script to package the official version and submit it for review, completing all tasks.

Using Google Calendar integration has another advantage. If there are unexpected situations requiring a delay or advance, you can directly change the date.

To automatically execute Google Apps Script at the event time in Google Calendar, you currently need to run your own service. For a quick solution, you can use IFTTT as a bridge between Google Calendar and Bitrise/Google Apps Script. Refer to this article for more details.

p.s.

1. Currently, the Pinkoi iOS Team uses the Gitflow workflow.
2. In principle, this consensus should be followed by all teams, so we do not want any requests that break this rule (e.g., special updates on Wednesdays). However, for projects involving external collaboration, flexibility is necessary if unavoidable, as this consensus is internal to the team.
3. HotFix for severe issues can be updated at any time and is not subject to the Release Train rules.

Here, we also mention the application of Google App Scripts. For more details, refer to: Using Google Apps Script to Forward Gmail to 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 bound to Github events. It can be triggered by events such as open issue, open PR, merge PR, etc.

Github Action can be used for any Git project hosted on Github. Public Repos have no restrictions, and Private Repos have 2,000 free minutes per month.

Here are two features:

• (Left) After PR Review, it automatically labels the reviewer’s name, allowing us to quickly summarize the PR review status.
• (Right) It organizes and sends messages to the Slack Channel at a fixed time every day, reminding teammates of PRs waiting for review (similar to Pull Reminders).

There are many other automation tasks that Github Action can perform. Feel free to use your imagination.

It’s like the issue bot often seen in open-source projects:

fastlane / fastlane

Or automatically closing PRs that have not been merged for a long time can be done using GitHub Action.

Recap the effectiveness of automated packaging for the official version, directly using existing tools for integration; besides automation, adding fixed processes to double work efficiency.

Originally, besides the manual packaging time, there was also the cost of additional communication for the release time, which is now reduced to zero; as long as you ensure to get on board within the schedule, you can focus all your time on “discussion” and “development”.

Calculating the effectiveness brought by these two automations, it can save 216 work hours a year.

With automation and the communication interface mentioned earlier, let’s see how much efficiency can be improved by doing these things.

Besides the items just done, we also need to evaluate the cost of context switching more. When we continue to work for a period of time, we will enter the “flow” state, where thoughts and productivity reach their peak, providing the most effective output; but if interrupted by trivial matters (e.g., excessive communication, repetitive work), it will take some time to get back into the flow. Here, we take 30 minutes as an example.

The cost of context switching due to trivial matters should also be included in the calculation. Here, we estimate 30 minutes each time, occurring 10 times a month, wasting 3,600 hours a year for 60 people.

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

The originally wasted work time, when saved, can be invested in other more valuable things, so the actual productivity should be multiplied by 200%.

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

Optimize early, enjoy early; late optimization has no discount!!

Recap the inside story of a highly efficient work team, what we mainly did.

No Code/Low Code First Prioritize using existing tools for integration (as in this example). If there are no existing tools available, then evaluate the cost of automation and the actual savings.

About Cultural Support

At Pinkoi, everyone can be a problem-solving leader

For problem-solving and making changes; most of the time, it requires a lot of team effort to make things better, which needs the support and encouragement of company culture. Otherwise, it would be very difficult to push forward alone.

At Pinkoi, everyone can be a problem-solving leader. You don’t have to be a Lead or PM to solve problems. Many of the communication interfaces, tools, or automation projects introduced earlier were discovered by teammates, who proposed solutions and 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 can be better. If problems are found, no matter how small, as mentioned earlier, with the growth of the team size, small problems can also have a magnifying effect.
• Investigate and summarize problems, avoiding premature optimization (some problems may just be temporary transitions).

Next is Build Partnerships

• Actively communicate and gather suggestions from all aspects
• Maintain empathy (because some problems might be the best solution for the other party, so balance is needed)

Third Step: Impact Beyond Your Role

• Exert your influence
• Propose problem-solving plans
• Prioritize automation solutions if it involves repetitive work
• Remember to maintain flexibility and scalability, avoid over-engineering

Finally, Dare to Fail!

• Courageously implement
• Continuously track and dynamically adjust solutions
• After achieving success, remember to share the results with the team to facilitate cross-departmental resource integration (because the same problem might exist in multiple departments)

The above is the sharing of Pinkoi’s high-efficiency engineering team secrets, thank you all.

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

For any questions or comments, feel free to contact me.

===

本文中文版本

===

This article was first published in Traditional Chinese on Medium ➡️ View Here