The 12 Disciplines of a Software Architect

Come, check your company, whether the following phenomena exist:

• There are individuals whose technical level is not as good as yours, but they are your leaders
• There are individuals whose technical level is not as good as yours, but they are project managers
• There are individuals whose skill level is not as good as yours, but their salary is higher than yours
• There are individuals whose technical level is not as good as yours, but they are valued more than you
• There are individuals whose technical level is not as good as yours, but they have more bonuses than you
• There are individuals whose technical level is not as good as yours, but they are more popular than you

If you encounter any of the above situations, you will definitely have the following reaction: No matter how good the technology is, it is useless, and it cannot determine the height of the workplace.

You may even blame others: I, Kao, are a bunch of ignorant guys. Sooner or later, you will know the consequences of doing this.

Either way, the truth is, you hit a ceiling:

You can't break this ceiling with technology in a short time - if you could, you would have broken through the walls and entered the new world long ago.

So, what is the cause of this ceiling?

>> Lack of soft skills

The book we're recommending today offers another perspective on how to break down the so-called "tech ceiling." This book is - "12 disciplines of software architects":

In this book, the author says:

Most of the time the so-called "glass ceiling of technology" is really just a lack of soft skills. These skills can be learned, and the lack of knowledge can be made up for in the effort to decide to change.

He also drew a diagram to describe the phenomenon:

>> 12 Soft Skills

Since the so-called ceiling is only due to the lack of soft skills, what does soft skills include? The author divides them into three parts:

• relationship skills
• personal skills
• business skills

Relationship Skills: Elegant demeanor, communication, negotiation, leadership, politics.

Personal skills: transparency, passion, context switching.

Business skills: business knowledge, innovation, pragmatism, cognition.

A total of 12 skills, which is also the origin of the title.

There is a hierarchical relationship between technical skills and the above 12 soft skills: technical skills are basic, then relational skills, then personal skills, and finally business skills. The following capability pyramid model illustrates this relationship:

The training direction of developers in the workplace is from the bottom of the pyramid to the top. The closer your practice is to the top, the higher your position, the higher your salary, and the higher your importance.

Therefore, when you have certain technical skills (this is the foundation), you must pay attention to the cultivation of soft skills. Pencil-style honesty cannot go far in the workplace.

>> How to practice

Usually, we think that soft skills are difficult to describe in words, and their training methods are difficult to systematize. But because the author of this book is also from a technical background and can look at the cultivation of soft skills from a technical perspective, it still gives a great guide and method.

Let's take Chapter 2—"Communication"—as an example.

Note that the communication skills here apply to all technologists, not just architects.

The author believes that the communication of architects is based on communication principles first, communication strategies second, and effective communication with executives on top of that.

Here are 5 principles of communication:

1. listen before talk
2. Concentrate on
3. Positive thinking
4. apologize early
5. Don't incur anger over flaws

Each principle is expanded and detailed in the book. Principle 5, for example, is especially useful when you have a review meeting.

Recalling the technical review and project review meetings you have participated in, is there often a situation like "Zhang San pointed out that Li Si's plan or approach is insufficient, and then everyone is red-faced"?

To avoid this situation, the author gives some effective methods:

• Make sure that the focus is on the review item, and the review is not directed at the person or unit that produced or created the review item. In other words, reviews should be about things, methods, not people.
• Avoid personal comments like "you" and "your".
• Try to express what the reason you are asking for the change is to achieve: Determine if the change is related to market strategy, based on general architectural principles, or is it a corporate or departmental goal?
• Reviews should focus on improving the way the project is reviewed, not just because a certain code-aware principle isn't followed, but why the modification works. People reviewing projects need to know not only how to make things better, but also why this improvement is useful.
• Look for opportunities to speak out about the positive aspects of the work that has been done. Most people are very tempted to justify when they are pointed out the flaws exposed, and the good aspects of finding a job can soften that dynamic. All attendees should understand that the goal is to produce excellent work results and that everyone is expected to hold to the same standards - this is a collective effort.
• Make sure everyone at the meeting is involved. Attending meetings as an outsider is a waste of the company's time.
• Mimic the behavior you're looking for. Come up with the behavior when your work is reviewed and the result is "good, keep doing it". The goal is to create great work and continuously improve it. In other words, it's not about you, it's about trying to be right and good.
• Elegance: If the roles were reversed, as a reviewee, how would you like others to give you feedback?

After introducing the communication principles, the author next talks about 7 major communication strategies:

1. Say more "yes" and less "no".
2. Build trust in the sales process
3. Say no to special occasions
4. Resist the urge to defend yourself
5. Listen to suggestions to improve collaboration
6. Understand the communication needs of others and yourself
7. quick-witted

The strategy part is more detailed than the principle, allowing the reader to act according to the map.

For example, in the section "Understanding the Communication Needs of Others and Yourself", the author tells you in detail how to use other people's words, sentences and body language to figure out the needs, ideas and attitudes of the attendees. So he asked us to keep these things in mind during the meeting:

• Are you smiling?
• Are you sitting upright?
• Do you nod your head in agreement?
• Are your eyes on the person who is speaking?
• Is your voice or tone of voice cadenced?
• Do you dress like others when you go to meetings?
• Are you really listening and understanding what other people are saying?
• do you take notes?
• Do you advocate confrontation?

This is how the 12 Disciplines of a Software Architect presents each discipline, it tells you the principles, strategies, methods, dos and don'ts, lists of questions you can find what works for you, if you put it into action , you can gradually improve your soft skills and break through the ceiling.