Yang Fan approaches remote work from the organizer’s side. He liked the idea long before he started a company, yet his team returned to offices, struggled with a product that failed to retain users, and lost most of its members before it established a lasting remote culture. The practices he describes grew out of those setbacks rather than from a complete policy designed at the outset.
The recording was published on March 8, 2023; the event date has not been confirmed. Team size, product capabilities, roles and working arrangements below refer to the time of the talk.
An engineer becomes an organizer, while the product remains the test
Yang had developed software and led a team in Tencent’s QQ organization. He recalls exploring a web-based desktop-client approach years before Electron became widespread. The internal project could not proceed because it would have required too much change to QQ. After starting a company, he continued writing code but spent more time on product and operations. He prefers to describe his role here as an organizer rather than simply a boss: the question is how people can build something together.
His company, CodeFun, aimed to turn UI designs into frontend source code. The tool needed to infer structures such as repeating lists, grids and flexible layouts, and handle work such as data binding and network requests. Yang’s ambition was to save developers from repeatedly reading design annotations and adjusting margins and padding. That promise, however, concealed hard product questions: whether a design’s structure could be understood, whether generated code was usable, and whether it fitted a real project. A working demonstration alone would not make people continue to use it.
The first remote arrangement gave way to an office
Yang dates the preparation for the business to 2017 and its funded start to 2018. With only two founders, remote collaboration happened naturally. They called each other, shared code through a paid private GitHub repository, and sometimes met in a friend’s office. At that scale, they needed little formal management.
Hiring changed the conditions. Yang says the budget and hiring market at the time made it difficult to find enough people who could immediately work independently in the setup they wanted. They opened an office in Shenzhen. An initially flexible routine gradually became office attendance. He acknowledges that progress anxiety and limited management experience also led him to impose a demanding overtime arrangement. The later remote model was not a straight success story; the team had already tried and abandoned one version of it.
Two offices became an accidental rehearsal
After an earlier product received disappointing feedback in 2019, the team shifted direction. A former classmate in Chongqing joined. Yang initially imagined Shenzhen handling core research and development while a Chongqing operation took on delivery work. The business did not develop that way, so the Chongqing team also joined shared engineering and testing.
They had to make two rooms function as one meeting. Each office needed a camera, screen sharing and sound that would work without echo. The conferencing products they tried often assumed that each participant joined individually with a headset, whereas they needed groups in two rooms to hold one stand-up. Expensive enterprise systems were out of reach. Buying and adjusting basic equipment consumed considerable effort, but it also taught the team to hold cross-city meetings, find colleagues remotely and share work online.
When the pandemic forced everyone home in 2020, they had already practiced collaboration across Shenzhen and Chongqing. Moving the meeting from a room to individual computers was easier than learning cross-city work from scratch. Still, the transition exposed another problem. Some colleagues kept irregular hours; others stayed blocked for a whole day by questions that might have taken minutes to resolve in an office. Yang came to see that someone who works well beside colleagues will not automatically follow the same rhythm at home. A remote difficulty could reflect the environment, a missing support habit or an unclear process, not simply poor attitude.
Yang enjoyed his own experience of working away from the office, including a period in Thailand. But his personal satisfaction did not prove that the team could deliver effectively. He had to separate an attractive lifestyle from the work of coordinating people and improving the product.
A product setback reduced the team to six
The first CodeFun beta attracted users but did not keep them. Yang’s diagnosis was direct: the product was not good enough. Design inputs varied, layout analysis remained difficult, and the output had not reached the standard users needed. The team paused the test to concentrate on development.
The consequences reached beyond the product roadmap. When engineering attention shifted toward algorithms, a designer was assigned AI data-labeling work. Some new graduates could not see a convincing future despite the technical challenge of their jobs. Eventually a core algorithm colleague also left. Yang recalls that a team of more than ten people fell to six, spread across Shenzhen, another Guangdong city and Chongqing. Even the remaining Shenzhen members did not meet every day.
This is when the team, by his account, began to build an entirely remote culture. He does not blame the losses on remote work alone. The slow product, mismatched roles and uncertainty of a startup all contributed. Asking everyone simply to keep believing in the project could not substitute for a product that worked.
A stable core set the pattern for slower growth
The six remaining members knew one another’s strengths. They took code review seriously, delivered agreed work and could raise problems without waiting for constant reminders. From late 2020 through the product’s formal launch in July 2021, this small team developed a common cadence.
The first people hired after launch included an experienced operations lead in Beijing. She needed to understand the product and goals, but not step-by-step supervision. She then helped bring in an operations assistant. Yang describes adding one person, working together for months, and only then adding another. The point was not that every company should grow slowly. In their circumstances, a stable group could pass on its habits to each new member; doubling headcount overnight might have diluted the very practices that made remote work possible.
Those habits were concrete. How do people discuss a requirement? How is work scheduled? Does someone say promptly when a task is blocked? Who checks the result? If a manager can only see that progress has slowed, they may suspect someone is not working, even though the actual cause could be a technical obstacle or a misunderstood requirement. Trust had to be supported by communication, standards and reliable delivery.
The team also agreed on core hours and a morning stand-up. Yang says ordinary messages he sent after work did not require an immediate reply. He had learned that regularly borrowing two more evening hours would push the next morning later and eventually reproduce the long hours they wanted to avoid. The exact hours were the team’s arrangement at that time; the broader lesson is that flexibility should not quietly become permanent availability.
Build the team as a system that can be revised
Yang compares team building with product development. An organizer decides what skills, scale and costs the work requires, designs ways to cooperate, observes failures, and revises the system. This does not mean treating people as interchangeable components. It means taking the working environment seriously enough to keep improving it.
He distinguishes a team designed for distributed work from a large office organization suddenly sent home. The latter may have depended on walking to someone’s desk, training a newcomer in person or settling a priority by an informal conversation. Once the location changes, those hidden routines break. Buying collaboration software is only one part of replacing them. Meetings, documentation, training and feedback must address the actual gaps.
Remote hiring also enlarges the pool of possible colleagues. Yang describes people working in several Chinese cities and attempts to find suitable people elsewhere. Geography is less restrictive, but language, cost, skills and expectations still matter. He emphasizes checking whether a candidate can do the work and cooperate well. His account of particular hiring encounters is one person’s experience, not a reason to judge a group of candidates by identity.
More hiring reach means more deliberate training
Distributed teams cannot assume a newcomer will ask every question at the right moment. Basic Git pull and push commands are only the beginning; Yang’s team also cared about rebasing, combining commits and writing useful commit messages. These are easy to demonstrate a few times beside a colleague, but a remote new hire may hesitate to interrupt someone repeatedly.
Nor is Git the entire onboarding problem. Engineers had to understand a chain extending from design-tool plugins through frontend and API services to algorithm, compilation and internal quality tools. Product staff needed to learn how to write and analyze requirements and compare competing approaches. Training each new person for a full week would be costly; leaving them alone with tasks would turn flexibility into isolation. Yang says the team was still working on that balance.
Different learning speeds, experience levels and unexpected bugs also affect scheduling. A plan that counts only the time to implement a feature but not the time to learn the system or help another person will misrepresent the amount of work. That makes training and project management parts of the same problem.
Keep relationships alive beyond task assignment
Yang connects remote workers’ loneliness with an organizer’s responsibility to create opportunities for contact. At the time, the whole small company joined the morning meeting, including engineering, operations, HR and AI-labeling roles. A participant would call on another person who had not yet spoken. That small rule gave people a reason to listen across functions, not merely open the microphone for their own update. Yang also acknowledges the cost: a meeting of around twenty people could take half an hour.
At the end of a two-week iteration, the team showed its work and talked about how people felt. A four-quadrant exercise combined whether work felt challenging or easy with whether the person felt happy or unhappy. The important part was whether someone could say that an assignment was unreasonable, a problem was difficult or something outside work was affecting them. If everyone mechanically reported that things were fine, the exercise had little value. Yang says some colleagues still spoke rarely and that preserving trust as the team grew remained unresolved.
Define what “done” means, then seek feedback
Remote teammates may interpret an apparently clear instruction differently. “We must launch tonight” leaves open which bugs must be fixed, how much testing is required and what can be deferred. Yang describes using an objective-and-key-results way of discussing a specific requirement: what outcome counts as a successful launch, and which results must be visible? He does not mean simply filling in a periodic OKR form.
Some innovative tasks cannot be fully quantified at the beginning. His team therefore tried to generate shared understanding through feedback. One practice was to “sell” a feature inside the company: after building it, an engineer would ask someone who had not worked on it to spend five minutes trying it. The tester might be an engineer, someone in operations or a colleague in HR. Their confusion could reveal what the implementation team had overlooked.
Individual development branches could also be deployed through the team’s CI/CD setup, producing a working test environment and a link to share before a formal release. Feedback from colleagues and willing users, together with meaningful usage data, could then inform the next decision. Yang objects to a developer treating a requirement card as finished and assigning responsibility for a poor outcome entirely to whoever requested it. That habit turns a remote team into a series of disconnected handoffs.
The team experimented with other ways to break a fixed assignment pattern: temporary groups with a small activity budget to complete a larger task, longer-term research challenges, and volunteers serving as owners of a piece of work. Yang gives these as examples of mechanisms they tried, not as measured formulas guaranteed to improve every team.
Choosing remote work is choosing where to invest effort
Yang cautions against idealizing remote work as freedom from work. He appreciates avoiding a commute and having a more comfortable daily rhythm, but meetings, responsibility and growth remain. A team still needs overlapping hours to discuss time-sensitive questions. Working from home does not mean every hour can be asynchronous.
He argues that taking several jobs only to sell more hours may raise short-term income without improving the value of the work one can do in an hour. He prefers long-term investment in skills and judgment, while acknowledging that immediate financial needs can lead someone to make a different choice. He once imagined that an overseas remote role would itself solve his career concerns; experience made him more interested in the substance of the work and the contribution he could make.
His advice for selecting a job is to investigate it as carefully as a significant investment: understand the team, product direction, room for development and what the position will let you learn. The company’s pay, benefits and remote arrangements described in the recording were historical recruiting claims, not promises about current openings.
Q&A: Learning and tools
How did you learn, and which books do you recommend? Yang points to sustained work, attention and fundamentals rather than a single book. He recalls earlier anxiety about career prospects despite having written code for many years. Starting a company forced him to learn beyond engineering, including product and operations; he was still learning sales at the time of the talk. As his foundations grew, he could understand a new framework or read source code faster. His own learning speed is not a benchmark for someone else. He advises learning the technical basics and choosing projects for long-term growth instead of chasing a fashionable label or a higher short-term salary without understanding the work.
Which tools supported the team? Its setup evolved from room-based conferencing equipment to individual computers, online meetings and Feishu as a principal collaboration suite. In one example, testers put ten or twenty issues in a shared document. Developers replied there with what had been changed, what could not be changed and who needed to know. Written updates handled many routine bugs; a call was useful when text was insufficient. Meetings were scheduled through a calendar where possible.
Yang also urges product and design colleagues to expose a direction early. Spending a whole day finishing a large proposal before showing it to anyone can produce more rework than checking an uncertain decision after an hour. The tools help only if people are willing to use them for timely, low-friction feedback.
Q&A: Code review as part of delivery
Asked about quality and security, Yang concentrates mainly on code review. Developers used GitHub pull requests and a team channel to find reviewers. Review was not an optional step squeezed in just before release; schedules had to include both the time to have one’s own work reviewed and the time spent reviewing colleagues’ work. When a proposal was hard to explain in comments, people could share a screen and talk it through.
As graduates gained experience, they began reviewing newer teammates’ code. Yang says his own changes were also returned for revision: a founder’s permissions did not justify skipping the team’s rules. Even commit descriptions and whether several commits should be combined could be questioned. A core group that practices review consistently helps others learn the standard. The talk does not describe a complete security-control program, so code review alone should not be read as evidence of one.
Q&A: What mattered in hiring
Yang values reliability, willingness to learn and curiosity. He asks what a candidate has recently chosen to explore, including interests outside technology. To illustrate what curiosity can contribute, he tells a story from the time of the recording: after the team discussed ChatGPT, a colleague voluntarily connected it to a Feishu bot and later experimented with an internal debugging tool. Yang does not present use of a particular fashionable product as a hiring requirement. The point is whether someone explores a useful idea and shares the result.
Technical exercises were drawn from actual work. A frontend candidate might need to construct a directory tree from a table of files; an algorithm candidate might discuss how two rectangles overlap. Yang says the team needed solid technical ability, but he did not want an exam unrelated to the job. Recruiting links and contact instructions at the end of the historical recording may no longer be current.