2021 Pinkoi Tech Career Talk — Secrets of an Efficient Engineering Team
Tech Talk sharing on the secrets of Pinkoi's efficient engineering team
ℹ️ℹ️ℹ️ The following content is translated by OpenAI.
Click here to view the original Chinese version. | 點此查看本文中文版
2021 Pinkoi Tech Career Talk — Secrets of an Efficient Engineering Team
Tech Talk sharing on the secrets of Pinkoi’s efficient engineering team
Secrets of an Efficient Engineering Team
2021/09/08 19:00 @ Pinkoi x Yourator
My Medium: ZhgChgLi
About the Team
Pinkoi’s work structure consists of 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: Primarily for support, infrastructure, or process optimization
Each Squad is composed of team members from various functions, including PM, Product Designer, Data, Frontend, Backend, iOS, Android, etc.; long-term and ongoing work objectives are completed by the Squad.
In addition to Squads, there are also cross-team projects that typically have medium to short-term work objectives. These can be led by any team member, regardless of their role, who acts as the Project Owner, and the project is closed upon completion.
At the end of the article, there is a section on how Pinkoi’s culture supports teammates in problem-solving. If you are not interested in the actual content, feel free to skip to the bottom of the page to view this section.
The Relationship Between Team Size and Efficiency
The growth of team size and its relationship with work efficiency is evident; having experienced teams ranging from 10 to 100 people (though I haven’t yet faced a team of 1,000), the difference between 10 and 100 is significant in many aspects.
With fewer people, communication and task handling are quick; discussions can happen in person, and solutions can be provided immediately. The “connections between people” are strong, allowing for synchronized collaboration.
However, with more people, direct communication becomes challenging. As the number of collaborators increases, discussions can take up an entire morning, and with many people involved, tasks must be prioritized. Non-urgent matters cannot be addressed immediately, leading to asynchronous waiting while other tasks are tackled.
Adding more roles allows for more specialized work division, providing greater capacity or better quality and faster output.
But as mentioned earlier, this also means more collaboration, which in turn requires more communication time.
Small issues can be magnified; for instance, if one person spends 10 minutes daily updating reports, that’s manageable. But if this scales to 20 people, it could take over 3 hours daily to update reports. At this point, optimizing and automating the reporting process becomes invaluable, saving 3 hours a day, which translates to 750 hours wasted over 250 working days in a year.
As team size grows, the App Team, for example, has closer collaboration with the following roles.
Backend — API, Product Designer — UI; this is self-explanatory. Since Pinkoi is an international product, the Localization Team helps us translate functional text. Additionally, we have a Data Team that conducts data collection and analysis, so besides developing features, we also need to discuss event tracking points with the Data Team.
Customer Service frequently interacts with us as well. Users sometimes directly leave feedback on orders through the marketplace, and more often, they leave a one-star rating indicating an issue. In such cases, we need to ask the Customer Service team to conduct a deeper inquiry: What problem did you encounter? How can we assist you?
With so many collaborative relationships, this means numerous communication opportunities.
But remember, we are not trying to avoid or minimize communication; excellent engineers also need strong communication skills.
What we need to focus on is important communication, such as brainstorming, discussing requirements, and timelines; we should avoid wasting time on repetitive confirmations of issues or vague discussions. We should also prevent situations where you ask me, and I ask you about someone else’s situation.
Especially in the era of the pandemic, communication time is precious and should be dedicated to more valuable discussions.
“I thought you thought I thought” — this phrase perfectly illustrates the consequences of vague communication.
Not only in work but also in daily life, we often encounter misunderstandings due to differing perceptions. In daily life, we rely on mutual understanding; however, in work, if there are different perceptions without in-depth discussions, it is easy to discover discrepancies during the output phase.
Interface Communication
The idea introduced here is to communicate through a consensus interface, similar to the Dependency Inversion Principle in object-oriented programming under the SOLID principles (no need to understand this). The same concept can be applied to communication.
The first step is to identify areas that are vague, require repeated confirmations, or need specific communication to be more focused and effective. There may even be tasks that only require this delivery without additional communication.
Once the issues are identified, we can define the “interface.” An interface serves as a medium and can be a document, process, checklist, or tool, etc.
Using this “interface” as a bridge for communication, there can be multiple interfaces; use the appropriate interface for each scenario. When encountering the same scenario, prioritize using this interface for initial communication. If further discussion is needed, it can be based on this interface for focused problem-solving.
App Team and External Collaboration Relationships
Here are four examples of interface communication within the App Team’s collaboration:
The first is collaboration with Backend. Without any consensus on the interface, the situation may resemble the image above.
Regarding how to use the API, simply providing the API Response String to the App Team can lead to ambiguities. For example, how do we know if date refers to the Register Date or Birthday? There are many fields that need clarification.
This communication is also repetitive; every time a new Endpoint is introduced, it requires confirmation again.
This is a classic case of ineffective communication.
What the App and Backend lack is a communication interface. There are many solutions, and it doesn’t necessarily have to be a tool; it could simply be a manually maintained document.
{:target="_blank"}](/assets/11f6c8568154/1*q_MQ6y3RPKeO7q-zxSGqDg.png)
This was shared during the 2020 Pinkoi Developer Night — by Toki
Pinkoi uses Python (FastAPI) to automatically generate documentation from API Code. PHP can use Swagger (previously used by the company); the advantage is that the overall framework and data formats can be automatically generated from the code, reducing maintenance costs, and only the field descriptions need to be handled.
p.s. Currently, new Python 3 projects use FastAPI, while older ones will be gradually updated, and for now, PostMan is used as the communication interface.
The second example is collaboration with Product Designers, which is similar to Backend but focuses on confirming UI Specs and Flow.
If color codes and fonts are scattered, our App will suffer greatly. Setting aside the requirements, we want to avoid situations where the same Title has the same color but different codes or where UI elements in the same position are inconsistent.
The most basic solution is to ask the designers to organize the UI component library and establish a Design System (Guideline), ensuring proper labeling when presenting UI.
In our Code Base, we establish corresponding Fonts and Colors based on the Design System (Guideline) and create Buttons and Views according to the component library.
When templating, we uniformly use these established components, allowing us to quickly align with the UI design drafts.
However, this can easily become chaotic and needs to be dynamically adjusted; it cannot cover too many special cases, nor can it be rigid and unexpandable.
p.s. At Pinkoi, collaboration with Product Designers is mutual; Developers can also propose better practices for discussion with Product Designers.
The third example is the interface with Customer Service. Marketplace reviews are crucial for products, but they involve a lot of manual and repetitive communication.
We need to manually check new reviews from time to time, and if there are customer service issues, we forward them to Customer Service for assistance, which is quite repetitive and labor-intensive.
The best solution is to enable marketplace reviews to automatically sync to our work platform. We can either purchase existing services or use my developed ZhgChgLi / ZReviewTender (new in 2022).
For deployment methods, tutorials, and technical details, please refer to: ZReviewTender — Free Open Source App Reviews Monitoring Bot
This bot serves as our communication interface, automatically forwarding reviews to a Slack Channel, allowing everyone to quickly receive the latest review information and track discussions.
The final example is our dependency on the Localization Team. Whether it’s new features or modifying old translations, we need to wait for the Localization Team to complete their work before we can assist with the next steps.
Developing our own tools for this is too costly, so we directly use third-party services to help us eliminate dependency.
All translations and keys are managed by third-party tools. As long as we define the keys in advance, we can act independently; both parties only need to complete their work before the deadline for packaging, without relying on each other. Once the Localization Team completes the translations, the tool automatically triggers a git pull to update the latest text files in the project.
p.s. Pinkoi has had this process in place for a long time; initially, we used Onesky, but in recent years, more excellent tools have become available, which can be considered for adoption.
Internal Collaboration Relationships within the App Team
Having discussed external collaboration, let’s now focus on internal collaboration.
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 high, so there are usually no issues. Of course, if you have a good sense, you can achieve everything mentioned here even in a one-person project.
However, as the number of collaborators increases, and everyone works under the same project, if each person continues to work independently, it will lead to disaster.
For example, if one person implements an API in one way and another does it differently, it often results in reinventing the wheel, wasting time, or carelessly pushing things live without consideration, which significantly increases future maintenance and scalability costs.
Within the team, rather than calling it an interface, I think it’s more about consensus and resonance, fostering a stronger team spirit.
The most basic and often-discussed aspect is Coding Style, including naming conventions, placement, how to use Delegates, etc. We can use commonly accepted tools like realm / SwiftLint for constraints, and multi-language statements can be organized using freshOS / Localize (of course, if you are already using the previously mentioned third-party tool management, you can skip this).
The second aspect is the App architecture; whether it’s MVC/MVVM/VIPER/Clean Architecture, the core focus should be cleanliness and consistency; there’s no need to chase trends, just ensure uniformity.
The Pinkoi App Team uses Clean Architecture.
Previously at StreetVoice, we used pure MVC, but it was clean and consistent, making collaboration smooth.
Additionally, Unit Testing is crucial; with more people, it’s hard to avoid having the logic you’re working on inadvertently broken one day. Writing more tests provides an extra layer of assurance.
Lastly, documentation is essential, covering the team’s processes, specifications, or operation manuals, making it easy for teammates to quickly reference when they forget and for newcomers to get up to speed.
Beyond code-level interfaces, there are other interfaces that assist us in improving efficiency in collaboration.
The first is a Request for Comments phase before implementing requirements, where the developer explains how the requirement will be addressed, and others can provide feedback and thoughts.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
---
title: Enhancing Work Efficiency through Automation and Communication
---
In addition to preventing the reinvention of the wheel, we can also gather collective insights. For instance, how others might expand on existing work, or what future needs could be considered... and so on. Those involved may be confused, while observers have clarity.
The second point is to conduct thorough Code Reviews to ensure our interface consensus is being implemented correctly. This includes aspects like naming conventions, UI layout methods, delegate usage, and protocol/class declarations, among others. We also need to check if the architecture is being misused or hastily written, and if the development direction is indeed moving towards a fully Swift environment, rather than still sending Objective-C code... and so forth.
The primary focus should be on reviewing these aspects, with functionality being a secondary concern.
p.s. The purpose of an RFC is to enhance work efficiency, so it should not be overly lengthy, as that could severely hinder progress. Think of it as a simple discussion phase before starting work.
To summarize the consensus on interfaces within the team, I want to mention a mindset called the **Crash Theory**, which I believe serves as a good behavioral benchmark.
{:target="_blank"}](/assets/11f6c8568154/1*QJ8P_HjSvPdYrUmrqsQZXA.png)
Excerpt from [MBA Knowledge Base](https://wiki.mbalib.com/zh-tw/%E5%9D%A0%E6%9C%BA%E7%90%86%E8%AE%BA){:target="_blank"}
Applying this to the team, we should consider whether, if everyone suddenly disappeared, the existing code, processes, and systems would allow new members to quickly get up to speed.
Recapping the significance of interfaces, the interfaces within the team are meant to enhance mutual understanding, while collaboration outside the team aims to reduce ineffective communication. Using interfaces as communication tools should focus on discussing needs without interruption.
To reiterate, "interface communication" is not some special proprietary term or tool; it is simply a concept applicable to any collaborative work scenario. It can be as simple as a document or a process, and it should come first before any communication takes place.
Here, let's assume that each time we spend an extra 10 minutes communicating, with a team of 60 people, and this happens 10 times a month, we waste 1,200 hours a year on unnecessary communication.
### Improving Efficiency — Automating Repetitive Tasks
In this chapter, I want to share insights on how automating repetitive tasks can enhance work efficiency, using iOS as an example, though the same principles apply to Android.
I won't delve into technical implementation details, but rather discuss the feasibility of the principles.
Let's summarize the services we use, including but not limited to:
- Slack: Communication software
- Fastlane: iOS automation script tool
- Github: Git provider
- Github Action: CI/CD service from Github, which will be introduced later
- Firebase: Crashlytics, Event, App Distribution (to be introduced later), Remote Config...
- Google Apps Script: Plugin script for Google Apps, to be introduced later
- Bitrise: CI/CD server
- Onesky: Third-party localization tool mentioned earlier
- Testflight: iOS app internal testing platform
- Google Calendar: Google Calendar, which will be explained later
- Asana: Project management tool
#### Issues with Releasing Test Versions
The first repetitive issue arises when we want to allow teammates to test the app during the development phase. Traditionally, this involves directly borrowing a phone to build the app. If there are only 1-2 people, it's manageable, but with a team of 20-30 people needing to test, the entire day spent helping install the test version means no work gets done. Moreover, if there are updates, everything has to be redone.
Another method is to use TestFlight as a medium for releasing test versions, which I think is also good. However, there are two issues: first, TestFlight is equivalent to a production environment, not a debug one; second, when many teammates are testing different requirements simultaneously, TestFlight can become chaotic, and the builds can change frequently, though it's still feasible.
At Pinkoi, our solution is to separate the task of "installing the test version by the App Team" and use Slack Workflow as the input UI. Once the input is complete, it triggers Bitrise to run the Fastlane script to package and upload the test version IPA to Firebase App Distribution.
> _For reference on Slack Workflow applications, see this article: [Creating a Fully Automated WFH Employee Health Reporting System with Slack](../d61062833c1a/)_
Teammates who need to test can simply follow the steps on Firebase App Distribution to install the certificates and register their devices, allowing them to choose which test version to install or directly click the link in the email to install.
> _However, note that iOS Firebase App Distribution uses Development Devices, with a limit of only 100 devices that can be registered, based on devices rather than individuals._
> _So, there may need to be a trade-off with TestFlight (which allows external testing for 1,000 people)._
At least the initial Slack Workflow UI input is something to consider adopting.
> _For advanced implementations, a Slack Bot could be developed for a more complete and customized process and forms._
Recapping the effectiveness of automating the release of test versions, the most significant benefit is moving the entire process to the cloud, allowing the App Team to remain uninvolved and enabling a fully self-service experience.
#### Issues with Packaging Official Versions
The second common task for the App Team is packaging and submitting the official version of the app.
When the team is small, with only single-threaded development, updating app versions is not a major issue, allowing for both freedom and regularity.
However, with a larger team, where multiple threads of requirements are being developed and iterated, the situation can become chaotic as shown in the image above. Without proper "interface communication" as mentioned earlier, everyone may work independently, leading to the App Team being overwhelmed. The cost of app updates is higher than that of web updates, and the process is more complicated. Additionally, frequent and chaotic updates can disrupt users.
Finally, there is a management issue; without a fixed process and schedule, it becomes challenging to optimize each step.
The issues are as shown above.
The solution is to introduce a Release Train into the development process. The core concept is to separate version updates from project development.
We will fix the schedule and define what will be done at each stage:
- Fixed updates on Monday mornings
- Fixed code freeze on Wednesdays (no more merging feature PRs)
- Fixed QA starts on Thursdays
- Fixed packaging for official release on Fridays
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 fixed tasks will be done at what time.**
This is a survey of version update cycles shared by international peers, with most being every two weeks.
Using a weekly update and our multi-team example, it would look like the image above.
As the name suggests, the Release Train operates like a train station, with each version being a train.
**If you miss it, you have to wait for the next one.** Each squad and project can choose when to board.
This serves as a great communication interface; as long as everyone is on the same page and follows the rules, updates can proceed in an orderly manner.
**For more technical details on Release Train, refer to:**
- [Mobile release trains — Travelperk](https://speakerdeck.com/lgvalle/mobile-release-trains){:target="_blank"}
- [Agile Release Train](https://www.scaledagileframework.com/agile-release-train/){:target="_blank"}
- [Release Quality and Mobile Trains](https://developers.soundcloud.com/blog/quality-mobile-trains){:target="_blank"}
Once the processes and schedules are confirmed, we can optimize what needs to be done at each stage.
For instance, packaging the official version traditionally takes a lot of time and effort. The entire process from packaging, uploading, to submission can take about an hour, during which one has to constantly switch work states, making it difficult to focus on other tasks. Each packaging involves repeating this process, which wastes work efficiency.
Since we have already fixed the schedule, we can directly integrate Google Calendar, adding the tasks to be done on the planned dates. When the time comes, Google Apps Script will call Bitrise to execute the Fastlane script for packaging the official version and submitting it, completing all tasks.
Using Google Calendar integration also has the advantage that if unexpected situations arise requiring delays or advancements, the dates can be easily changed.
> _Currently, to automatically execute Google Apps Script at the time of a Google Calendar event, one must set up the service themselves. For a quick solution, IFTTT can be used as a bridge between Google Calendar and Bitrise/Google Apps Script. For more details, see [this article](https://gist.github.com/tanaikech/fbbfaa8f2a8a770424974aa16b9b6f3b){:target="_blank"}._
p.s.
1. The Pinkoi iOS Team currently uses the Gitflow workflow.
2. In principle, this consensus should be followed by all teams, so we do not want any requirements that break this rule (e.g., needing to go live on a special Wednesday). However, for projects involving external collaboration, flexibility must be maintained if absolutely necessary, as this consensus is internal to the team.
3. Hotfixes for serious issues can be updated at any time, regardless of the Release Train regulations.
I have also mentioned the application of Google Apps Scripts; for details, refer to: [Using Google Apps Script to Forward Gmail Messages to Slack](../d414bdbdb8c9/).
The last point is using Github Action to enhance collaboration efficiency (PR Review).
Github Action is Github's CI/CD service that can be directly linked to Github events, with triggers available for open issues, open PRs, merging PRs, and more.
Github Action can be used for any Git project hosted on Github. Public repositories have no restrictions, while private ones have a free quota of 2,000 minutes per month.
**Here are two features:**
- (Left) After a PR review is completed, it automatically adds a reviewer name label, allowing us to quickly summarize the PR review status.
- (Right) Every day at a fixed time, it organizes and sends messages to a Slack channel, reminding teammates of PRs awaiting review ([mimicking the functionality of Pull Reminders](https://pullreminders.com/){:target="_blank"}).
Github Action has many other automation possibilities that everyone can explore.
For example, issue bots commonly seen in open-source projects:
{:target="_blank"} / [fastlane](https://github.com/fastlane/fastlane){:target="_blank"}](/assets/11f6c8568154/1*64GaqzcldMHwU-HE4yt3_A.png)
[fastlane](https://github.com/fastlane){:target="_blank"} / [fastlane](https://github.com/fastlane/fastlane){:target="_blank"}
Or automatically closing PRs that haven't been merged for too long can also be accomplished using Github Action.
Recapping the effectiveness of automating the packaging of official versions, we again directly use existing tools for integration; in addition to **automation, we also incorporate fixed processes to double the improvement in work efficiency.**
Originally, aside from the manual packaging time, there was also the additional cost of communicating about the release time, which is now reduced to zero; as long as we ensure we **board** on schedule, we can focus all our time on "discussion" and "development."
Calculating the total impact of these two automations, we can save 216 work hours in a year.
With automation and the previously mentioned communication interfaces, let's see how much efficiency we can enhance overall.
In addition to the tasks we've just completed, we also need to evaluate the **cost of switching flow**. When we remain engaged in work for a period, we enter a "flow" state, where our thoughts and productivity peak, allowing for the most effective output. However, if we are interrupted by unnecessary matters (e.g., excessive communication, repetitive tasks), returning to that flow state requires additional time, which we can estimate at 30 minutes.
The cost of switching flow due to unnecessary interruptions should also be factored in; here, we estimate 30 minutes each time, occurring 10 times a month, resulting in an additional 3,600 hours wasted in a year for a team of 60.
Flow switching cost (3,600) + excess communication due to poor communication interfaces (1,200) + automation resolving repetitive tasks (216) = a total loss of 5,016 hours in a year.
The time wasted can be redirected towards more valuable tasks, so the actual productivity gain should be multiplied by 200%.
> **_Especially as the team size continues to grow, the impact on work efficiency also amplifies._**
> **_The sooner you optimize, the sooner you enjoy the benefits; delaying optimization comes with no discounts!!_**
Recapping the inner workings of a high-efficiency work team, we primarily focused on what actions to take.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
> **_No Code/Low Code First_** _Prioritize using existing tools for integration (like in this example). If there are no available tools, then evaluate the cost of investing in automation against the actual savings in revenue._
### Support for Culture
At Pinkoi, everyone can be a problem-solving leader.
For solving problems and making changes, it often requires a lot of teamwork to achieve better outcomes. This is where company culture plays a crucial role in providing support and encouragement; otherwise, pushing things forward alone can be very challenging.
> _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 mentioned earlier are often identified and proposed by teammates, and everyone works together to accomplish them._
Regarding how team culture supports driving change, the four stages of problem-solving can be linked to Pinkoi's Core Values.
**Step One: Grow Beyond Yesterday**
- Always strive for better. If you discover a problem, regardless of its size, remember that as the team grows, even small issues can have a magnified effect.
- Investigate and summarize the issues, avoiding premature optimization (some problems may just be temporary transitions).
**Next is Build Partnerships**
- Actively communicate and gather suggestions from all angles.
- Maintain empathy (as some problems may be the best solution for others, so weigh your options carefully).
**Step Three: Impact Beyond Your Role**
- Leverage your influence.
- Propose problem-solving plans.
- If it relates to repetitive tasks, prioritize using automation solutions.
- Remember to maintain flexibility and scalability to avoid over-engineering.
**Finally, Dare to Fail!**
- Be brave in your practice.
- Continuously track and dynamically adjust solutions.
- **After achieving success, remember to share the results with the team to facilitate cross-departmental resource integration** (as the same problem may exist in multiple departments).
**This concludes the sharing from Pinkoi's highly efficient engineering team. Thank you, everyone.**
Join Pinkoi now >>> [https://www\.pinkoi\.com/about/careers](https://www.pinkoi.com/about/careers){:target="_blank"}
If you have any questions or feedback, feel free to [contact me](https://www.zhgchg.li/contact){:target="_blank"}.
This article was first published on Medium ➡️ Click Here
Automatically converted and synchronized using ZMediumToMarkdown and Medium-to-jekyll-starter.
