HiCTO Founder, Former Dianping CTO Shihai Gong: How to Build a High-Performance Engineering Team
A Practical Handbook for Building High-Performance Engineering Teams at Startups
Successful internet entrepreneurship depends on an efficient R&D system, and the key to that system is people.
As startups grow, they constantly face pain points: technologies that need to be rebuilt from scratch, frequent technical risks, clunky development processes, and low efficiency. On the talent side, they often struggle to attract senior technical hires and retain top performers. At an online interactive salon series called Building Internal Strength: Entrepreneurship Leadership Battlefield, co-hosted by Gaorong Ventures and Tsinghua University's PBC School of Finance Global Entrepreneurship Leadership Program (click "Read More" at the end for details), Shihai Gong — founder of HiCTO and former CTO of Dianping — drew on years of frontline technical management experience to prescribe solutions for these challenges in building technical systems and teams.
Gong joined Dianping as CTO in 2005. Over more than a decade, he helped build out its complete technical system, expanding the R&D team from just a few people to a lean force of 600. Here's a one-page summary of his insights:
How to Choose the Best Technical Solution Based on Product Planning
Business First, Ship Fastest
Product planning typically spans long cycles. How do you get technical R&D to collaborate more efficiently? The core principle is "business first" — ensure the core product can launch as quickly as possible. This requires staging the business plan, specifically defining the MVP for each phase with minimal requirements. The smaller the MVP, the more core the problem it captures, the faster it ships, and the quicker it delivers value and iterates.
Balancing Fast Launches with Long-Term Technical Requirements
As product planning evolves, the technical approach must balance shipping quickly with meeting future technical demands. How?
1) Keep technical solutions elegant and simple, while clearly understanding the future evolution path.
The solution should support the current MVP while clearly defining the direction for evolution as traffic grows and business complexity increases.
Two important reminders here. First, avoid both over-engineering and crude, simplistic design. Some people want to design for where the business might be in one or two years, anticipating system complexity and building for it now. This is unrealistic — it makes systems complex and slow to launch, and the market landscape in two years may look nothing like what you imagined. But crude simplicity is equally dangerous. If the design is too simple, you may find after just a version or two that it can't handle the load, forcing a large-scale rebuild that significantly impacts the company.
Second, don't look too far ahead when designing technical solutions, but don't be too short-term either. Based on past experience, except for very fundamental underlying systems, looking ahead about six months is generally appropriate for application-level technical solutions.
2) Continuously abstract business logic at the global level, componentizing abstracted business logic.
Through product iteration, as traffic, business, and data grow, continuously abstract business logic from a global perspective — turning abstracted business logic into components. For example, two similar businesses can be abstracted to make the system cleaner.
How Business and Technology Can Collaborate Efficiently
The Core of Efficient Business-Technology Collaboration: A Qualified Product Manager
The product manager is the lead. If the lead points in the wrong direction, the damage is severe — even throwing all engineers at the problem wastes time and money.
I've seen startup product managers who aren't truly qualified. They act more like translators or megaphones, converting business requirements into technical language without truly understanding the logic behind them. This often leads to system dysfunction down the road. A good product manager must be a business expert — even more knowledgeable than business staff — able to methodically and logically push the product forward layer by layer, enabling efficient business-R&D collaboration.
A Collaborative Culture Between Product Managers and Engineers
Beyond excellent product managers, good collaboration between product and engineering is critical. How to cultivate this culture? Some experiences to share:
1) Encourage both mutual respect and mutual challenge.
Different fields have different expertise. Engineering should respect product thinking, and product should respect technical judgment, making decisions together to better execute. But mutual challenge should also be encouraged. For example, engineers can challenge product design and logic from a user perspective; product can challenge development workload and timelines based on actual complexity.
2) Take product requirement review meetings seriously to improve requirement quality.
In my interactions with startups in recent years, I've found many don't do product requirement reviews well — they often become product presentations. I strongly recommend taking this seriously to improve requirement quality. First, engineering can challenge product logic in these meetings, helping product think more clearly. Second, you can jointly uncover hidden requirements; without thorough discussion, various bugs often emerge later.
3) Include key metrics for product improvement in product design.
To some extent, product and engineering are one team. After launch, how do you evaluate, whether to improve, and how? Let the data speak. I recommend including key product improvement metrics in the design, giving everyone a shared ruler for evaluation, making it easier to reach consensus on optimization and collaborate on solutions.
4) Encourage personal friendships between product managers and engineers.
At Dianping, we allocated team-building budgets specifically to encourage engineering and product teams to grab meals or coffee together outside the office, fostering personal friendships that benefit team collaboration.
5) Establish mutual interview mechanisms in the hiring process.
Another effective practice: build mutual interview mechanisms into hiring. When recruiting a product manager, we'd have the engineering manager or director from their future business line interview them. The goal was less about assessment and more about laying a strong foundation for future collaboration.
Building an Efficient R&D Team
The Three-in-One Capability of Technical Team Leaders
To build an efficient R&D team, strong technical team leaders are critical. How to evaluate their capability model? Three dimensions:
1) "Things" — the ability to get things done well.
This shows in several aspects. First, completing projects on time with realistic timeline estimates — neither overestimating nor underestimating, giving the team better rhythm. Sometimes a requirement is estimated to take a long time but finishes quickly, which disrupts the team's rhythm and creates problems.
Second, high project quality — no stupid or serious bugs, with appropriate design and architecture that doesn't hold business back.
Third, good technical team leaders must be business-oriented, not technology-for-technology's-sake. Some engineers aren't business-oriented; they just want technically challenging projects, which can hinder business development.
Getting things done well earns a team leader about 60 points.
2) "People" — leading the team well.
Several dimensions here. First, build team cohesion — not a loose group where people point fingers at each other. A cohesive team covers for each other and works toward shared goals.
Second, enable team growth. For many startups, R&D teams are very expensive. Giving a leader a 10-person team means entrusting them with several million RMB in annual investment. How they make that investment "appreciate" is critical — growing the team's capabilities. This involves many things: how to assign tasks, career coaching, guiding different capability types toward technical or management tracks, fostering a sharing culture, etc.
Beyond the above, if team members feel a sense of achievement in their work — not seeing themselves as "code monkeys" but as contributing to business — their enthusiasm and effectiveness improve.
Getting things done and leading people well earns a leader about 70-80 points.
3) "Systems."
A truly excellent leader, I believe, has another key dimension: leading the team to continuously improve the R&D system. This includes optimizing underlying architecture to prepare for future changes and higher performance requirements; turning commonly used business functions into building-block components for rapid system assembly when trying new businesses; improving mechanisms and processes including test environments, continuous integration, and fast or gray-scale launches; and building general tools to improve efficiency for internal and external teams.
So I suggest startups look for and evaluate team leaders along these dimensions. Even if they don't meet them now, you can develop them along these dimensions to steadily improve the entire team.
Guard the Hiring Gate, Continuously Upgrade Team Quality
Many startups grow fast, and team size expands accordingly. A critical challenge is guarding the hiring gate and continuously upgrading team quality, laying a solid foundation for increasing efficiency.
Two suggestions here. First, when the technical team reaches about 100 people, launching campus recruiting becomes important. From Dianping's experience, truly excellent new graduates quickly become R&D backbone — building this reserve force is critical.
Second, strictly gate new hires so team quality only rises. At Dianping, we required technical directors to assess their team's median quality before hiring, then mandate that new hires exceed that median, driving continuous improvement.
Strengthening Principles and Mechanisms for Building Efficient R&D Teams
Building an efficient R&D system also depends heavily on underlying principles. Here are several key principles from Dianping's team:
1) Agile development.
More teams practice agile now, but Dianping adopted it relatively early. Define MVPs, let R&D advance rhythmically, iterate quickly — this principle runs through the entire process from requirements to technology, testing, and launch.
2) Product thinking.
From an R&D perspective, there are two mindsets: project thinking and product thinking. Project thinking means constantly moving to the next project without much attention to launched products. Product thinking means continuously tracking key product metrics, thinking about improvements. For example, a payment R&D team would continuously track module performance, optimizing promptly if latency exceeds thresholds.
3) Encourage generalist culture.
Typically technical teams divide into frontend and backend engineers — backend handles logic, frontend handles JS pages and CSS. Generalists mean encouraging backend engineers to do some frontend, and frontend engineers to understand backend code. In practice, this lets small changes be made directly, saving significant cross-team coordination time.
4) Value tool culture.
Many excellent Chinese engineers don't like building tools, finding them unchallenging or unrewarding. But I believe if a tool delivers significant value, especially at larger team sizes, it can benefit many engineers. At Facebook, many excellent engineers willingly built tools.
5) Cultivate a culture where developers own quality.
Many companies mainly blame testers when products have issues. But many problems stem from the code itself. If you rely entirely on testers for quality, team efficiency won't improve. True efficiency comes from developers owning quality, making development and testing collaborative, drastically reducing test-fix cycles.
When teams are lean, you mainly drive individual capability and close collaboration. As teams scale, shared principles, culture, and underlying consistency become more important.
Culturally Creating an Environment Where Top Talent Thrives
An excellent team also needs top talent to want to stay long-term, not have the best people leave. Some key points:
Equal, Collaborative, Honest, and Transparent Culture
Engineers generally value equality and directness — less political maneuvering. They want companies that are equal, collaborative, honest, and transparent. When company culture aligns with what engineers can accept, excellent engineers are more likely to stay.
Technical Achievement
When technical teams make good progress, they should receive recognition from parallel business departments and superiors, boosting their sense of achievement.
Winning in Battle
As long as business keeps improving and you keep winning, with the company advancing rapidly, excellent talent is willing to fight alongside you.
Technical Involvement in Product Definition, Not Being Code Monkeys
In some companies, product definition is entirely the product team's job, followed by a product briefing where the technical team just writes code. Without clarity on product value and positioning, engineers self-identify as "code monkeys." We need to eliminate this mindset, letting technical staff appropriately participate in product definition — including taking requirement reviews seriously, encouraging technical staff to surface more hidden requirements; early on, letting some technical leaders participate in product definition helps subsequent R&D work.
Technical Staff Feeling Valued
Through compensation, company awards, and other means, technical teams need to feel recognized and valued. Some companies are operations and product-driven, but technical teams still need to feel valued.
Work Challenge: Technical Depth, Full-Stack Development, Encouraging Technical Accumulation
If an engineer's technical skills don't improve at a company, they'll worry about declining market value, which is a significant risk for long-term stability. We need to value technical challenge in work.
If an engineer's business isn't particularly complex or high-traffic, how to increase challenge? Some approaches: expanding technical depth, encouraging full-stack development, encouraging technical accumulation, etc.
Flexible Hours, Rhythmic Intensity, Celebration Culture
R&D work needs some flexible hours. I also recommend a rhythm of intensity. In agile development, the first sprint might require 120% effort — very efficient overtime is needed to complete it, and this high pressure develops engineers' capabilities. The second phase might schedule 80% workload, letting people relax. Tension-relaxation-tension-relaxation can improve team capability and efficiency.
When R&D work achieves breakthroughs or solves major problems, these highlight moments deserve celebratory rituals.
Relaxed, Non-Suppressive Environment, Desks, Chairs, Computers
Create a relaxed, non-suppressive environment for engineers. Provide good work equipment and computers — the ROI on this investment is extremely high.
Quickly Eliminate Unsuitable Team Members
Finally, quickly eliminate unsuitable people when found. Engineers prefer working with excellent people. In hiring, A players generally hire A players, B players generally hire C players, C players generally hire F or E players.
So quickly eliminate unsuitable team members, with the core need being to eliminate negative energy and poor attitudes. Some veteran employees may be weaker in capability but familiar with the business, serving as company "stabilizers" — companies should provide matching work environments and positions for them.
At the salon, CEOs and CTOs from Gaorong Ventures portfolio companies and the Tsinghua PBC Global Entrepreneurship Leadership Program also exchanged with Gong on practical technical team issues. Below is the Q&A.
For senior technical talent, what truly attracts them, and what elements can genuinely attract them in startups' talent competition?
For senior technical talent — including technical experts and excellent technical managers — when leaving major companies to join startups, they generally focus on several elements:
First, whether they're genuinely interested in what the startup is doing. Beyond technical challenge, they care about the value behind the technology. Even if the venture ultimately fails, their market value shouldn't decrease.
Second, practical considerations: compensation shouldn't be too far below major companies, and they'll consider whether there's opportunity for financial freedom or help with future entrepreneurship.
If both above are met, the third element is cultural — whether they can sense the team is excellent enough through their interactions.
As startups develop, how to build a mature hiring process that continuously attracts mid-level, senior, and high-level engineers?
Two suggestions. First, find a domain expert who can attract a cohort of high-potential excellent talent. At Dianping, for example, we recruited an excellent person from eBay for our algorithms team. After he joined, working with campus recruiting to select top students, we quickly built a very strong team.
Second, as startup teams grow, emphasizing internal referrals is a good strategy. Referral quality tends to be relatively high, and costs much less than headhunters.
How to effectively motivate technical R&D teams to make them more combat-ready?
Engineer motivation must never be single-dimensional, as this often leads to distorted behavior. For example, evaluating only by workload without focusing on real value output, and single-dimensional motivation often creates perceptions of unfairness.
Instead, motivation should unfold across multiple dimensions. First, performance reviews — generally twice yearly, with flexibility to adjust based on overall strategic direction. For example, if business orientation is needed, engineer evaluations can include some business dimension.
Second, career levels — like Alibaba, Tencent, and Meituan's level systems. Timely level assessments for employees, with accompanying raises and equity adjustments upon promotion.
Other motivation dimensions: company-level project awards, newcomer awards, most improved awards, best sharing awards, even small "big impact with small money" incentives — conveying a diverse, fair motivation culture to the team.
For startup technical teams from 0 to 100 people, 200 to 600 people... what are the key levers at different stages?
When I joined Dianping there were only 4 engineers, eventually expanding to 600. Generally, 50 people is an inflection point. Below 50, one person can keep track of everyone, knowing both the people and business well.
Beyond 50 or 100, you don't have energy to understand everyone's situation or interview them all. You need to establish mechanisms for managing through people — systematic meeting mechanisms, career coaching systems, etc.
When teams exceed 200, the company likely has several directors leading major business lines, requiring more cultural investment. At larger scales, principles, concepts, and culture become even more important. For example, different leaders each managing dozens or hundreds of people inevitably develop parochialism — management must compress space for parochialism, getting everyone to think more globally.
