API7.ai is an open-source software company that delivers the most performance, security, and scalable platform for APIs and microservices. The story happened because of the open-source software Apache APISIX. Read more about my story with the Apache Software Foundation.
In early 2020, Ming Wen invited me to join the company and start a business together, and I was attracted by the keywords “Startup, open-source, and Remote.”
At that time, I worked as a web engineer in another company in Shenzhen. I politely declined Ming’s invitation twice because:
- The current team leader Xin gave me an offer as a Web engineer in early 2019 and waited for me for nearly half a year after graduation from university.
- Xin taught me many skills in Web skills.
- I wanted to do something long-term.
Later, I talked with Yuansheng Wang again, and I finally decided to join the entrepreneurial journey because of my inner desire to Do open-source projects remotely full-time.
Everything needs to start from zero. There is no collaborative process, team rules, or more resources, and there are only members to communicate with each other from time to time through the API7.ai WeChat Group. (We don’t even have a Slack workspace at the beginning)
In the months that followed, we had new members who joined the group occasionally, and by the end of 2020, we had about ten members.
In addition, our members travel from different countries to our Zhuhai office every month for a reunion (one week), where we had lunch and dinner together and chat with each other to promote our relationship.
At the same time, we will occasionally hold Apache APISIX Meetup in Shenzhen, Shanghai, Beijing, and other cities to bring the community together for sharing and discuss.
Also, Apache APISIX completes Incubation from the Apache Software Foundation in 2020, becoming top-level project.
All of the above looked good, but the team did not mesh well internally: remote collaboration was the primary source of inefficiency.
Most members had no remote experience in their previous work. It was exciting for them initially, but they felt lonely and depressed after the period, especially when communicating in asynchronous and mixed work and life. All these side effects lead to very low efficiency of team collaboration. I have been working remotely for a long time since 2018, which is a natural thing for me, but may be a disaster for others: both them and the team leader were “suffering.”
I don’t have a more direct solution other than enriching yourself through reading, games, and communication, but if you wish to talk to someone, I will give you some inspiration by showing up.
Here are some of the things worth sharing over the past two years.
Responsible for your Codes
Engineers must provide related and reasonable E2E test cases, whether frontend or backend projects, which means everyone should be responsible for each Pull Request. Here’re some benefits:
- Although it took several months to run this model well, it improved delivery stability and manually reduced human testing time.
- It increases engineers' technical skills and reduces company hiring costs.
For more information about the E2E test, please read this post Using Cypress to Deliver Consistent Products.
At the end of 2020, the team size is around ten people, but there are hundreds of interview invitations. We want the candidates to match and work with the team for a long time, not just get a job.
For example, after filtering through 100+ resumes/candidates, we currently have only 5 Web Engineers on the team (3 full-time and two internships). They are not Web specialists, but they fit my idea of a good match for the company: ready to push themselves, able to take responsibility, and malleable enough.
Also, as the early members of the company, we had to fulfill our responsibility as “mentors” and guide them to work together as a team.
Because I was the first to join the team, and I had more contact with Ming Wen and Yusheng Wang before joining the team, I didn’t have too many uncomfortable or formal places in the communication process (even if I did, I would solve it after thinking it over for a while), so I was too direct in giving feedback when needed: sometimes I would send emails, sometimes I would send IM messages, and sometimes I would directly point out the problems I thought needed to be solved in the public channel, which would inevitably lead to discussions and arguments, but we would talk clearly about the issues every time.
In addition, I initiated an Ask CEO/CTO Anything meeting in April this year. I collected about 40 questions from within the team in advance (about personal growth, salary adjustment, poor collaboration, etc.). Then, Ming Wen and Yuansheng Wang came from Zhuhai to the Shenzhen office to answer them in person. The nearly 2-hour AMA meeting powerfully brought the members closer to the founder and enhanced the team cohesion and strength. Please also read our Handbook.
The following are some screenshots.
As a remote team, we should use “documentation” wisely. For example:
- We should collect topics before the meeting. No topics, no meeting.
- We should have meeting minutes to organize our thoughts and sort out the to-do items after the fast-paced meeting and facilitate the new members to understand the evolution of things through the document in the future.
The following screenshots show the Global Team’s Meeting Minutes, and it’s convenient for other team members to understand and participate in it.
The Product flow is lacking from Day 1, and we take for granted that “this is the way it is, isn’t it?” Unfortunately, this will lead to the product not being able to iterate. Therefore, we needed to use documentation to clarify requirements and define technical proposals before feature development, documenting the product iteration, thinking and discussion.
I am delighted that the team has smoothed out the process of “Requirement Collecting → Requirement Evaluation → Requirement Splitting → Product Solution → Technical Solution → Project Scheduling → Feature Development → Feature Testing → Release and Launch → Product feedback” by working on the product for several months.
Later on, we followed the productization standard in the Cloud project, making both the delivery speed and quality more and more controllable.
Most of the engineers in our team are from the server-side background, and we didn’t do well in design and product user experience since Day 1, which is also my shortcoming.
To provide a better user experience and branding, we worked with the Dine team to design the Cloud UI and new logo to show Efficient, Secure and Connected. We want to serve most API requests globally, reliably, securely and fast.
I will keep encouraging myself and my friends to keep sharing content (ideas, thoughts) with the outside world to achieve my accumulation and help more people unintentionally.
There are many members with sharing spirit in the team. Besides attending events and conferences, they share various thoughts and ideas in the open-source community and the team 💡!
In January, I started to build the Global Team after deciding on the general direction of the year with Ming Wen: I interviewed dozens of candidates from different countries and finally invited six Advocates, Tech Writers, and Growth leaders from Europe, India, and China.
I had my first all-hands meeting with the team after the New Year’s call on the first day of the year. Then, at the end of April, I compared what we had done in the past quarter to the initial goals, and overall we were not off track but needed to be more focused.
There are also many stories from the Global Team that I will document and share in separate articles.
Looking back on the past two years, the startup journey for me is a process of practice. Do long-term things with long-term people.
The company has been three years, dear members, thanks to you! In the future, let’s continue to work together to create brilliant!