The Opening: The Vicious Cycle of “More People, Slower Progress”
Have you ever experienced this scenario? In the early stages of a project, a small team of three to five people is incredibly agile. As the business expands and the team size doubles, the delivery speed, instead of increasing, actually declines. Meetings become more frequent, disputes last longer, and a simple requirement seems to have to navigate a dense fog from proposal to launch.
This is the “efficiency trap” that many technical teams are falling into. When system complexity crosses a certain threshold, “throwing more people at the problem” not only fails to solve it but becomes a shackle that drags down efficiency due to skyrocketing communication costs and dependencies.
How do we break this cycle? My answer is: Stop patching the “people” problem; start demanding efficiency from the “architecture.” Good architecture is a force multiplier for a team’s productivity. It can fundamentally untangle chaos and unleash the team’s true potential.
The Root of the Problem: Silent Architectural Decay
The decline in team efficiency is often not a sudden collapse but a gradual “architectural decay,” like a frog being slowly boiled. Its symptoms manifest in every corner of daily work:
- Repetitive “Wheels”: Login, permissions, notifications… these common features are reinvented time and again, like ghosts, in different projects and modules. Each “wheel” has subtle differences, collectively forming a “museum of wheels” that is difficult to maintain.
- Fragmented “Experiences”: Module A uses Vue, Module B uses React; this page’s button is on the left, that page’s button is on the right. This inconsistency not only confuses users but also causes a developer’s cognitive load to skyrocket when switching between different tech stacks and standards.
- A Fragile “House of Cards”: Modules are intertwined and highly coupled. Modifying an inconspicuous function can trigger an unexpected “butterfly effect,” making the scope of regression testing hopelessly large. Every deployment feels like a gamble.
The essence of these problems is the long-term absence and passive evolution of architecture. We have been acting like a borrower who only cares about the present, constantly overdrawing credit and accumulating a massive amount of technical debt. When the “interest” becomes too high to repay, the entire team’s output efficiency is completely crippled.
The Core of Architecture: Walking a Tightrope Between “Fast” and “Stable”
An excellent architecture is never about showing off skills; it’s about achieving two seemingly contradictory goals:
- Externally: Supporting Business Agility. The market changes in an instant. The architecture must be like a flexible Lego set that can be quickly assembled, disassembled, and extended, allowing the business team’s ideas to be validated and delivered at the fastest possible speed.
- Internally: Enhancing Development Efficiency. The architecture must be like a clear city map with distinct roads and zones, allowing any developer to quickly locate what they need and get started easily, ensuring the long-term health and sustainable iteration of code assets.
Therefore, the core job of a technical manager is to find the optimal balance between these two goals. We must satisfy the business’s desire for “speed” while safeguarding technology’s commitment to “stability,” guiding the architecture to evolve healthily in a dynamic equilibrium.
My Three-Step Practice: From Chaos to Order, Then to High Efficiency
Step 1: Unify and Converge — Establishing Order, Reducing Internal Friction
This is the first step in correcting the chaos, aiming to draw a baseline for the current messy state.
- Unify the Tech Stack: Clearly define the team’s primary language, front-end framework (even UI framework), database choices, etc. This greatly reduces decision fatigue and promotes knowledge consolidation and sharing.
- Establish Standards: From high-level standards like coding style, API design guidelines, and Git workflow, to low-level ones like naming conventions and log formats, we must establish a “common team language.” Standards are not constraints; they are lubricants that eliminate communication ambiguity and improve collaboration efficiency.
- Perfect the Toolchain: Provide an “out-of-the-box” development environment and automated CI/CD pipelines. Delegate repetitive, tedious tasks to tools, allowing developers to focus their precious energy on creative business logic.
Result: After this step, unnecessary “tech stack debates” within the team disappeared, code style became consistent, and the onboarding speed for new members significantly increased. We laid a solid foundation for future efficiency improvements.
Step 2: Abstract and Consolidate — Creating Leverage, Reusing Value
This is the core step in creating an “efficiency lever,” aiming to transform repetitive labor into reusable assets.
- Identify Commonalities, Initiate Abstraction: We strictly follow the “rule of three.” When a feature, a pattern, or a solution is implemented repeatedly three times within the team, it must be nominated as a candidate for a formal abstraction and consolidation process.
- Layered Abstraction, Building an “Arsenal”:
- UI Layer: Encapsulate common interactive modules into a high-quality front-end component library.
- Service Layer: Consolidate cross-business capabilities like User Center, Permissions Center, and Order Center into highly cohesive business modules.
- Infrastructure Layer: Package underlying technical capabilities unrelated to business, such as distributed locks, message queues, and monitoring/tracking, into standardized base libraries.
Result: We no longer start from “mixing mud and laying bricks” every time. Instead, we can directly use high-quality “prefabricated components” and “standard modules.” Developing new features transformed from “inventing” to “assembling,” leading to a qualitative leap in both efficiency and quality.
Step 3: Empower and Cycle — Igniting the Engine for Self-Evolution
This is the key to unlocking the team’s productivity, aiming to make the entire system “alive” and form a self-reinforcing positive cycle.
- Empower Developers, Lower the Barrier to Entry: Even the best “wheel” is just a decoration if no one knows how to use it. We invest effort in writing clear documentation, recording tutorial videos, organizing tech talks, and establishing dedicated Q&A channels to ensure every developer can easily and correctly use these consolidated assets.
- Establish Positive Incentives, Encourage Co-creation and Sharing: We incorporate contributions to public component libraries into engineers’ performance reviews and promotion evaluations. We publicly recognize “star contributors” who make outstanding contributions, fostering an “all for one, and one for all” engineering culture within the team.
Finally, Igniting the Team’s “Efficiency Flywheel”
- Developers use common components and services, leading to a significant increase in the speed and quality of new feature development.
- The time saved allows them to have more energy to think about business innovation and technical optimization.
- More thought and optimization will give rise to more and better common components and solutions.
- A more powerful “arsenal” further equips all developers, making development even more efficient.
Once this flywheel starts spinning, the team’s efficiency improvement is no longer linear but enters an exponential growth trajectory.
Conclusion: The Evolving Role of the Technical Manager
In modern software engineering, the value of a technical manager is no longer that of a “foreman” holding a stopwatch and supervising work hours, but that of a “gardener” who meticulously designs the garden and cultivates the soil.
Our core responsibility is to build a “system” where talented engineers can thrive, and to use architecture, our most powerful tool, to give wings to the team’s creativity.
Good architecture is the amplifier of team efficiency. And we are the ones responsible for building and tuning this amplifier.
Postscript
The real catalyst for writing this article was Claude’s Agent Skills feature.
For a long time, I have envisioned a self-iterating, fully closed-loop AI product and research team. However, the reality is that while current AI can handle most coding tasks, it still falls short in the realm of technical management, which requires complex trade-offs and decisions.
The emergence of Agent Skills offers a new approach to this problem. It’s no longer about making AI understand the “art” of management out of thin air. Instead, it allows us to deconstruct and encapsulate complex management processes, decision models, and best practices into standardized “skill packages” that AI can call upon as needed. This is, in essence, transforming abstract management experience into executable engineering entities.
Although this technology is still in its infancy, it has shown me a clear path to the future.
Therefore, I took up my pen to write this article, to sort through and consolidate my years of management experience. I hope it serves not only as a summary of past experiences but also as a blueprint, contributing initial designs and thoughts for the future “encapsulation” of sophisticated management methodologies into AI-usable Skills.