An exploration of the organizational structure of modern front-end R&D teams

preface

Companies of different sizes have their own independent front-end research and development departments, whether large front-end or small business teams, small to a few people to hundreds of people. In the past, the organizational structure of the front-end R&D team was a natural development based on the situation. There are many names and different forms of teams, but they basically consist of two parts

• Research and development of business
• Technology research and development

With the increasing complexity of modern software, the richness of front-end technology and user experience, enterprises have increasingly higher requirements for data. This dual structure is increasingly unable to meet the development needs of front-end R&D teams. To some extent, natural contradictions and antagonism are formed between business R&D and technology R&D.

So I’m going to start by saying how do we try to resolve this problem and this contradiction right now

The body of the

The core contradiction is interests

We know that most front end teams have an organizational structure that is divided into business development and technology development, and there may be some subdivisions within each company, but I think it’s pretty much the same.

• Business research and development is mainly to meet business needs and achieve product functions
• Technology r&d, often referred to as technology infrastructure, helps business R&D improve efficiency

This division principle is not a big problem in the early days, but is a natural development of the front end development team. Because the software reuse principle and basic consistent, when we are in the business development can be found in the abstract and share code, we will naturally draw out, and then the model or independent management and maintenance tools, in order to ensure the maintenance of resources, so there will be a technology research and development team, the technology research and development team over time.

More and more infrastructure was abstracted and defined, and the development of open source technology became the infrastructure of today. But there are contradictions.

Let’s start by rethinking infrastructure, or technology infrastructure

Advanced deployment of technical infrastructure

As long as the technical team of an enterprise wants to carry out gay construction, it must make planning. I believe that students who have similar experience should know that all the infrastructure planning is ahead of time. That is not to meet the needs of the moment, but to some extent develop infrastructure that exceeds the needs of the moment.

For example, a component library may be needed by the business at the moment, but the infrastructure may have a more complete planning for the definition, development, and design of the component library.

For services, scaffolding is nothing more than YARN dev → Yang build. However, for infrastructure, you need to deploy in advance for future CI/CD online r&d to ensure smooth interconnection.

In fact, this is similar to China’s infrastructure model. Infrastructure does not come first when there is demand, but infrastructure will bring demand. So infrastructure is focused on the long term, and as much as possible on the needs of the future, not the present.

But business is not. Business development needs, according to market changes adjust to has high flexibility and variability, or you can tie the business and capital, what is the capital, capital is the pursuit of short-term interests, most of the capital is irrational, speculative, although we all hope that our products, our business can have long-term planning, There is long-term value, but the reality is that most companies are chasing short-term profits. This creates a naturally short-sighted situation in business r&d.

One chasing the long term, the other chasing the short term, resulting in a typical binary thinking. In the case of infrastructure, long-term benefits require some short-term benefits to be sacrificed, while in the case of business r&d, short-term benefits cannot be sacrificed.

Unfortunately, for most infrastructure implementation team, lack the necessary transition ability, tend to understand the technology but don’t know how to set the transition, the long-term interests of the cash cycle control, when the long-term interests of the cash cycle becomes very long, business research and development of short-term interests will sacrifice more than business can withstand threshold. Eventually the conflict broke out.

Infrastructure is hard to push, the business does not buy, and then the business itself to build wheels, leading to the entire technology system increasingly divided, and ultimately loss-lose.

The landing strategy of technology infrastructure

While there are a lot of proven underlying technologies in the front-end open source ecosystem, actually applying them to your own team is still a complex process. In most cases, it will need to be improved or even reimplemented.

In addition, the replacement cycle of front-end technology is too fast, leading to the fact that some basic technologies will become new historical debts in the future. Therefore, the overall upgrade and migration design should be done well in the landing process.

This requires the implementation strategy of the entire infrastructure to follow the principle of adjusting measures to local conditions, step by step, pilot in a small scope and promotion in a large scope.

But as far as I know, the current front end R&D team is mostly forced to demolish gay buildings

Forced demolition is against the law

Since China’s reform and development, local governments have relied on land finance to build gay buildings. As a result, a large number of ghost cities and ghost roads have been created. These hidden debts have become a stubborn policy problem. In those days you open have much cool, this year governance rises have much headache

It is the same with technology infrastructure. If it is not done, there will be long-term benefits. If it is not done with component libraries, it will be right. Nothing is absolute. Not paying attention to landing strategies will eventually come back to haunt you.

Abandon dual thinking and create a ternary structure

Dual thinking is either-or, you lose and I win. First of all, we need to realize that the opposition between infrastructure and business RESEARCH and development is naturally irreconcilable. We cannot expect to solve it through conventional means, nor can we expect to achieve the promotion of infrastructure at the expense of business research and development. This is too risky for the leader of the front-end development team to take on.

For this I envisage adding a new structure

• Business architecture

First of all, unlike business RESEARCH and development, business architecture does not belong to the business team, but still belongs to an independent organization, with independent resource guarantee and independent decision-making rights. Different from infrastructure, business architecture focuses on both the technical side and the business side.

Positioning and responsibilities of the business architecture

In terms of business architecture, there are two main responsibilities

• Analyze, abstract, and locate business problems based on the core principle of unifying technical standards, seeking a combination of existing technical tools/products to provide systematic, non-single point solutions.

• Build a business architecture governance toolkit with the infrastructure. Combine and improve the technical tools/products of the infrastructure to export to business R&D.

Core competencies of the business Architect

• Abstract, can be small business problems into technical problems abstract
• Systems, not single points, but systems to solve business problems
• Technology, ability to develop and improve technical products/tools independently

Core job requirements of the business Architect

Win-win cooperation

Avoid dual thinking, not only to let the business in the development of infrastructure support benefits, can gradually upgrade, smooth transition. And get infrastructure output moving in the right direction. This is a test of the overall quality of a business architect. It can be said that the business architect is the true driving core and link of the future front-end development team. For large front-end r&d teams, qualified business architects can ensure smooth development and iteration of the entire technology system. Optimize the input and output of resources.

Core principles of the Business Architect

Uniform technical standard

Without violating this core principle, the business architect can flexibly adjust and specify the governance solution of the business architecture in line with the business, and smooth the transition between short and long term benefits through technical means. Provide a transitional solution for the business and ensure that the business can develop under the same technical standards before the infrastructure is completed.

The latter

Of course energy is conserved in this world, and to some extent, business wins, technology wins, business architecture wins, so who loses? The contention of a hundred schools of thought in the Spring and Autumn Period and the Warring States Period created various stages for numerous thinkers to realize their own value, but since the Qin Dynasty abolished the losers and held Confucianism as its own, this opportunity channel was closed. In fact, with the advancement of technical standardization, the space for business RESEARCH and development will become smaller and smaller. In the past, business R&D was able to compete with infrastructure because of the bundled benefits of the business. To some extent, there was room for building wheels, but once the transition from binary to triple structure, the addition of business architects left most mediocre business R&D without room for development. It can be said that 10 business r&d can produce one business architect, what about the other 9? As a dry battery, of course…