I have written many articles, trying to answer the questions from the perspectives of “structural evolution”, “interview”, “meeting” and “career development”, but my knowledge and cognition are limited, and the output content is always a little one-sided. Last month, a friend recommended a book, and the whole reading experience gave me a new perspective on “architect”.

Once, I participated in the development of a software product as an architect. After more than a year of development, version 2.0 has been released and successfully implemented in some enterprise users. At the later stage of the project, due to the reasonable overall architecture design of the product and good expansibility of each functional module, the architect basically had nothing to do, and some other factors, the author decided to resign.

As the most senior professional and technical personnel of the project team, the architect is the senior development and test engineer of the project team. Engineers can see their future in architects, so architects need to be strict with themselves and set a good example.

1. Focus on people, not products

Always believe that a group of great people doing what they love will succeed. No matter how tortuous the process, no matter how improbable it may seem to outsiders.

Therefore, the best software project management is not to make plans, organize resources, track the progress of the project, encourage and punish the members, but to explore the excellent potential of each member of the project team, so that everyone can understand and love the final blueprint and vision of the software product. Everyone is trying to realize their own value, not to get paid to work.

Once this is done, each member of the project team will be self-driven, self-conscious and collaborative to find the optimal path to achieve their goals and persevere. There is no need for bad carrots and sticks. The best reward is the goal itself, and the greatest punishment is the failure to achieve the good goal.

That’s what leadership is all about: finding a common cause and creating a work environment in which everyone can bring out the best in themselves.

2. Discover the best in people

Some companies like to poach great people, rather than establish themselves as a place to train great people. As everyone knows, it is things that make people, not people who make things happen. It is better to do something that makes you and those involved good than to expect good people to do it for you.

It is far more meaningful to find the best in people than the best in people.

Share the blueprint

The architect and the project team work together to create a blueprint that the entire team can agree on and strive for.

The blueprint should be graphic: visualize what value a product can create for users, what market goals it can achieve, and what the product will eventually look like.

The blueprint should be simple: no matter internal or external communication, it should be clear in one sentence: what we are doing.

Blueprints should be written on the title page of a software architecture design document, in the signature line of an email, or in an announcement on an internal im group.

During the project, the architect should keep an eye on the vision, be alert to any design and decisions that deviate from the vision, correct any deviations, and discuss necessary changes and regain consensus.

“When I close my eyes, I see the future of China,” says a young revolutionary in the film bodyguards and Assassins. This tomorrow is the blueprint of the Revolution of 1911, for this better tomorrow he is willing to sacrifice his head, shed blood, die without regret. Entrepreneurs close their eyes to see the enterprise tomorrow; Developers of software products can close their eyes and see the moment when their software realizes value. This is the power of blueprints.

4. Participatory architecture

The architect is responsible for the architecture of the system, but it does not mean that the architect designs the architecture himself and that the project team strictly adheres to architectural decisions.

1. Don’t just own the architecture

Architects should not treat the architecture as their own private property and keep others from touching the architecture in order to maintain its purity and prestige. Let participants debate the architecture. The more they feel they are important contributors to the architecture, the more they are willing to take responsibility for the development process, and the more they are willing to work together to maintain the architecture and improve the software.

2. Have someone else maintain the framework and architecture documentation

Learn to compromise

Don’t try to justify yourself on a project. Remember, you’re here to build software, not be the boss. So don’t try to prove yourself. Don’t ever waste your time and hurt your feelings.

There is a story: a hunter went hunting in the mountains, but was caught by a black bear, the black bear said “if you give me XX I will let you go”, the hunter had no choice but to XX black bear. After returning home, he practiced his hunting skills and entered the mountain again. As a result, he was caught by a black bear and asked for XX again. The third time he came back, the bear saw him and laughed, “Are you hunting or to give me XX?” .

Every time I get lost in a project, I will think of this story and remind myself that I am here to make software and realize customer value, not to prove who is right or wrong, not to give XX bear.

Often, objections to architecture and technical solutions mean that architecture and technical solutions are looked at, tried to understand and accepted. The architect should not be too sensitive to opinions. What the architect should do is to share his design ideas openly, let others understand his ideas and strive to understand others’ ideas, and seek common ground while shelving differences.

Arguments about technical details should be verified immediately rather than continued, and when discussions get down to technical details it means that the issues are converging and the overall architectural design is converging.

6. Build others

We don’t live to work. We don’t design. We don’t program. We live to achieve ourselves, and to achieve ourselves we must first achieve others.

Everyone has his own goal to achieve, and work is a means to achieve his own achievement: through the challenge of work, discover his potential, redefine himself and the world.

The process of software development is the process of human intellectual activities. Software development is not only the process of making software, but also the process of developers to improve themselves and surpass themselves. So we work not just to make things, but to make people, and ultimately, ourselves.

Making a project not only creates value for customers and profits for the company, but also allows project members to grow. Make them feel that they have improved their knowledge, skills and business through the program. At the end of the project, it’s amazing to think, “This perfect product, this challenging development is all done by us.” And everyone feels vital to the project.

The architect, as the technical leader of the team, should not try to control anything during the project, proceed with a flexible plan and blueprint, and the team will take care of themselves. The more you impose prohibitions, the less disciplined the team is; The more coercive you are, the less autonomous your team is; The more you look outside for help, the less confidence everyone has.

Source: This is part 4 of Technical Architecture for Large Web sites


Recommended reading:

1. Evolution: In the past five years, we thought about and positioned the responsibilities of architects

2. Are meetings a technical activity for architects?

Life saved! In five years, we have also developed a technology center