MegaEase was founded in 2016 with a fairly specific technical mission: bring highly available, high-concurrency distributed technologies at the PaaS/SaaS layer to companies that care about technical autonomy and control. The point was to help them avoid being locked into closed-source systems or overly dependent on the cloud platforms of large vendors.
From the beginning, the company was built as a remote team. It started with 8 people and has grown to more than 20. In the early days, those 8 people were spread across 5 cities. Today the team is distributed across 8 cities in 2 countries. Even though shared office space is used now, the underlying culture is still remote-first.
That choice was not accidental. The appeal came from a certain kind of engineering company: small, distributed, independent, and deeply intentional about how work gets done. When the company was started, the goal was not simply to allow people to work from home. It was to build a team that could operate well without relying on physical co-location as a crutch.
And that model proved itself in practice. In 2017 and 2018, after the product became commercialized, the original remote engineering team supported major customer workloads, including a large New Year’s event associated with Dedao and Luo Yonghao, as well as several other clients. That period established two things at once: customers were willing to pay for the company’s products and services, and the business could generate meaningful revenue, with individual deals reaching the million-RMB range. At the time, some investors were skeptical that a company with no proper office and only 8 people across 5 cities could be real. But over the following year, the team helped banks, telecom operators, and internet companies upgrade and transform their architectures, making difficult distributed systems practices more accessible to enterprises.
So the basic conclusion is simple: remote work is not the problem people think it is.
Still, doubt about remote work is common, and not without reason. Managing people is hard under any setup, because people are complicated. Remote work just makes weak management easier to see. The real issues usually sit at the management level first, and only then at the tooling or workflow level.
Remote work exposes management problems rather than creating them
A lot of criticism aimed at remote teams is really criticism of poor management in general. The same foundational issues exist in office-based teams too. Remote work only makes them harder to hide.
If a company cannot solve the fundamentals of hiring, alignment, delegation, accountability, and execution, putting everyone in the same room will not fix it. In a remote environment, those flaws simply become more obvious.
Hire people who can carry their own weight
The most important management task is hiring. Nothing comes before it.
People often say that a remote team only works if you hire unusually strong people. That is true, but it is also true of every good company. Remote work merely forces you to take that standard seriously.
The kind of person a remote team needs usually has a few clear traits:
- someone who can operate independently and figure things out without waiting for constant instruction;
- someone with strong communication skills, who can turn ambiguity into clarity and persuade others effectively;
- someone capable of self-management and self-motivation, who does not need to be pushed at every step.
These are not remote-only qualities. Any company wants people like this. But remote teams cannot afford to pretend otherwise.
When you fail to hire such people, the organization starts compensating in inefficient ways. You add managers because some people cannot self-manage. You add testers because some people cannot consistently produce strong code. You add project managers because communication is weak. You pair weaker contributors with stronger ones as permanent coaches, and eventually the strongest people get overloaded.
At that point the real management question appears: is it better to spend time fixing bad hiring, or to spend time finding better people? Good managers choose the latter. That mindset is close to the hiring standard associated with Amazon: it is better to reject many candidates than to lower the bar.
Shared goals matter more when people are apart
Remote teams do not benefit from casual in-person correction. That means everyone has to work from the same picture.
People need a common understanding of what the team is trying to achieve, what it will not do, how trade-offs are made, and what standards define acceptable work. Without that shared mission, distributed teams slide into misunderstanding and unnecessary conflict very quickly.
But this is not unique to remote work either. A team sitting together without shared goals is still ineffective. The difference is that in a remote company the damage becomes visible sooner.
Because products and business conditions keep changing, leaders have to continuously restate, refine, and communicate those goals. Alignment is never a one-time announcement.
Small teams are not a limitation
Remote work naturally favors smaller teams because communication is expensive. That does not mean a company cannot scale. It means the company should scale by structuring itself properly.
The idea is familiar from classic software management and from Amazon’s two-pizza team principle: complex systems are better handled by small groups with clear ownership. Break a system into smaller components, let teams focus, and several good things happen at once:
- work can proceed in parallel;
- complex problems become easier to reason about;
- operations get simpler;
- scaling becomes easier.
There is also an important difference in how large and small teams think.
Big teams often drift toward labor-intensive behavior. The hidden question becomes: what work can be invented so all these people stay busy? Small teams ask different questions because they do not have enough people to waste. They think about priority, automation, leverage, and efficiency. What matters most? What can be simplified? What can be automated? Those are different management instincts, and they lead to different outcomes.
Remote teams tend to be closer to knowledge-dense, high-autonomy teams where people lead through expertise and initiative, not through headcount.
The practical side of making remote work actually work
High-level management principles are necessary, but not sufficient. Remote work also needs concrete operating habits.
Documentation comes first
The biggest practical problem in remote work is that discussion is less convenient than when a group can gather around a whiteboard. To compensate, important discussions should begin with a written document.
At MegaEase, that usually means GitHub issues, pull requests, or Google Docs. The initiator writes first, then discussion follows.
This is valuable for reasons beyond traceability. Writing forces deeper thinking. Once ideas have to be structured and written down, gaps in reasoning become visible. Documentation is not just a record of thought; it improves the quality of thought itself.
Simplify and automate relentlessly
Automation and simplification are central to software engineering, and even more important in remote teams.
That applies from unit testing, functional testing, and performance testing all the way to automated deployment with Kubernetes. The goal is for code to move into production automatically after commit, with gray release controls in place. The team uses a single-branch model similar to Amazon’s style: once code is merged into master, it is expected to go live.
Without good automation, remote collaboration gets slower and more fragile.
Give every important piece of work an owner
Ownership culture is essential.
This is not only about avoiding the classic “everybody thought somebody else would handle it” problem. It also addresses something more subtle: many competent, well-meaning people are too polite to step forward and direct others.
An owner model makes responsibility explicit. Every important task gets a named owner, and that owner has the authority to coordinate, request support, and drive the work forward. Greater authority also means greater responsibility.
Reviews should happen before implementation, not after confusion
Written reviews are a way to spread knowledge and test ideas early.
For important work, people are expected to write down the problem background, the objective, the available options, supporting references and data, and the pros and cons of each path before implementation begins. That makes later discussion much more effective.
A productive meeting does not just need a topic. It needs a serious proposal.
Commit to short-term goals
Each person is expected to define and commit to their own work goals. These plans are usually set on a short horizon—ideally one week, and generally no longer than two.
That rhythm helps maintain momentum and keeps accountability concrete.
Self-management works better than bureaucracy—if you trust adults
There is no approval machinery for leave, expenses, or travel. People arrange those things themselves and inform the team. The only exception is during critical periods when the whole team may need to stay fully engaged.
The core rule is simple: do not lie, and do not cheat. If someone does, the answer is straightforward.
This approach is based on a belief that most people are decent. It makes little sense to impose blanket pain on everyone because a small minority might abuse trust.
Casual interaction still matters
Working together physically creates emotional connection almost by default because people chat. Remote work strips that away unless a team deliberately restores it.
So private chats and informal conversation are encouraged. Team members are expected to get to know one another beyond immediate tasks, including their backgrounds and past experiences. They are also encouraged to visit one another in person when useful, with travel reimbursed by the company.
Keep learning lightweight and regular
The team runs a weekly knowledge-sharing session. It lasts only half an hour and focuses on one small topic rather than trying to cover too much. Some team members even use Google Forms to gather feedback on the sessions.
Reward contribution close to the result
Instead of assuming a standard year-end bonus model, the company favors immediate, local reward sharing.
When a piece of work directly generates revenue, 70% of the profit stays with the company and the remaining 30% is distributed among the team involved. This pushes everyone to think about how the company makes money, what customers are actually paying for, and why. That business awareness matters.
At the same time, if the company has a weak financial year but employees have still performed well, year-end bonuses can still be given. The underlying philosophy is clear: failure to make money is primarily the founder’s responsibility; success in making money belongs largely to the team.
Outsource support functions when possible
The team stays smaller and more cohesive by outsourcing as much support work as possible, including HR, administration, payroll finance, employee equity operations, testing roles, and custom development work.
That keeps the core team focused and makes remote operation easier.
Remote coding can be asynchronous
When a project starts from scratch, somebody—usually the owner—needs to lay out the framework and code structure first. Once that skeleton exists, others can fill in the pieces much more efficiently.
Even pair programming can happen asynchronously. In practice, that often means multiple people working through the same pull request. With GitHub as the protocol for collaboration, remote development becomes much more manageable.
The tools behind the workflow
The tool stack reflects the company’s operating philosophy.
For infrastructure, AWS is the main platform, partly because regular use of it gradually shapes engineers’ instincts.
For software collaboration, GitHub is the center of gravity. Development work happens there through pull requests, issues, projects, kanban boards, and the wiki.
For documentation and general collaboration, Google’s tools are used heavily, especially Google Groups, Google Drive, and Google Docs.
For communication:
- Zoom is used for voice meetings, especially because it supports larger groups and cloud recording.
- WeChat voice may be used for smaller conversations.
- Slack is the primary workspace for day-to-day work communication because it supports channels, threads, and better information flow.
- Telegram is used for informal chat.
Many of these are tools from outside China’s domestic internet ecosystem. The reason is practical rather than symbolic: the alternatives often work poorly for serious collaboration. There is also a cultural intention here. A team’s taste is shaped by the tools it uses. Good tools teach good habits.
The remote work agreement
To make expectations explicit, MegaEase uses a formal remote work agreement. It is not just a list of etiquette rules. It is a statement of how the team is supposed to think and operate.
The agreement includes several core principles:
Ownership and leadership
Everyone is expected to act like an owner and a leader. If you see a problem in the team or the project, do not wait quietly. Raise it, propose a solution, call the meeting if needed, and push for adjustment.
Initiative
People are expected to initiate work, claim responsibility, and find opportunities for improvement on their own. If there is no obvious path, create one.
Objectives first
Everyone should think not only like an engineer but also like a product manager and project manager. Work needs to connect back to the larger goal. Priorities should be judged from the user’s perspective and the product’s perspective, not just from the perspective of one isolated component.
High standards
Standards should be ambitious and non-negotiable, even if implementation strategy can be flexible. The team should not compromise on what “good” means.
Operating rules in practice
The agreement also defines everyday behaviors.
Be online when working
During working hours, people are expected to be reachable. If they will be offline, they should say so and indicate for how long. Slack is the main communication channel. For leave, non-urgent cases should be announced one day in advance in the team’s #random channel; urgent situations should also be communicated there as early as possible.
Important work should be documented
Real-time tools such as face-to-face conversation, calls, WeChat, and Slack are useful for fast feedback, but only documents can structure important information. For major features, processes, business logic, designs, issues, and ideas, written documentation is the default. GitHub wiki, projects, and issues, along with Google Docs, are the preferred media.
Design review before execution
For key work, ideas should be shared before implementation begins.
A strong design document should include:
- Background: the context, need, and problem being solved;
- Objectives: the purpose and significance of the work;
- Alternative Solutions: multiple options with pros and cons;
- Reference: support from authoritative sources;
- Data: evidence relevant to the proposal;
- Conclusion: the recommended direction.
Simplification and automation are permanent goals
Simplification is not the same as being crude. It reflects the ability to abstract, generalize, and improve reuse and extensibility. Automation demonstrates engineering capability and is necessary both for remote efficiency and for scaling. The team is expected to keep asking how current work can be simplified or automated.
Review and refactor constantly
Code and work processes both require reflection and restructuring. After milestones or when problems appear, the team should review what happened, preserve what works, and improve what does not. But any optimization measure should remain executable, not theoretical.
Short milestone commitments
Every project participant needs milestone plans, ideally no longer than two weeks and preferably within one. Those commitments should be real commitments.
Evidence over opinion
Discussions and analysis should rely on evidence, data, or authoritative references. Whether in design or disagreement, the best way to persuade others is to show proof. If debate stalls, stop arguing and go gather better support for each position.
Demo day matters
People should demonstrate their work live to the team. That encourages engineers to think from a product perspective. Demos do not need to be limited to product features; they can include algorithms, designs, or code.
Meetings should be effective
Meetings are for three things: proposals, problem discovery, and shared conclusions.
A meeting should not merely have a topic; it should ideally have a concrete proposal. The meeting itself is not where all problems are solved. It is where problems are identified and tracked. And every meeting should end with either a conclusion or a clearly owned follow-up issue.
For weekly or ad hoc team meetings, the organizer should collect agenda items in advance. Those may fall into categories such as:
- project items, which require progress plans in advance, with sub-items preferably limited to 1–2 person-weeks;
- design items, which require design documentation beforehand;
- problem items, which require both issue descriptions and proposed solutions beforehand;
- decision items, which require context plus analysis of pros and cons;
- information items, which require written explanation beforehand.
The organizer should begin collecting agenda items on Friday. Project owners need to prepare progress information, design and issue items need reviewable documents, and information or decision items can be written in Google Docs or team issues.
Escalate with a 1-2-3 rule
If you are stuck on a problem for an hour on your own, pull in another person for a small discussion. If two people make no progress within two hours, escalate to the team. If the team still has no direction after three hours, bring in outside help.
Progress updates should say something real
Status updates should be more meaningful than a simple check-in. When work reaches a meaningful point, updates should briefly cover 3PS: Plan, Priority, Problem, Summary—what the plan is, what matters most, what issues have appeared, and what the current work summary looks like.
Disagree first, commit after the decision
Different styles and viewpoints are inevitable in engineering work, so disagreement is welcome before a decision is made. Once the team reaches a decision, everyone is expected to support it and contribute to that direction.
For major disputes, the owner is responsible for driving the conversation toward a conclusion quickly. Important discussions should produce notes and updates in the relevant GitHub issue or pull request so that information stays visible to the whole team.
Standards should remain high. First comes industry standard, then the standard of leading global technology companies such as Google, Facebook, GitHub, and AWS, and only after that should local norms be considered. The rationale is practical: users may be difficult, but they are rarely in a position to reject a genuine industry-standard approach. And once something has been released and adopted, changing it becomes much harder, so decisions should be both cautious and decisive.
Remote work is a means, not the point
Remote work is not the end goal. What it really does is force management to confront reality.
It pushes a company to hire stronger, more self-driven people. It demands clarity about mission and standards. It favors compact, high-output teams. It requires more disciplined communication and more scientific collaboration practices. It exposes wasted motion, weak accountability, and organizational friction.
In that sense, the real value of remote work is not geographic freedom. It is that under remote conditions, the quality of your management model becomes impossible to hide.