Hello, I am Guo Dongbai. Today's lesson is the fourth part of the architect's ability dimension. Let's continue to explore the ability transition of the architect's growth process. But today we will continue to talk about two transitions: the transition from cross-domain architect to chief architect (chief architect); the transition from chief architect to CTO.
We briefly mentioned before that if you can solve the problems faced by the CTO and the chief architect, you will definitely gain their trust and respect, thereby accelerating professional growth. So the core of studying today's lesson is to understand how a CTO or chief architect thinks and makes decisions, and how to help them.
Why put the two roles of chief architect and CTO together? In most businesses, these two roles are combined and performed by a single CTO. Therefore, in the following discussion, we will also analyze why this is the case. By studying this question, it can help you understand the connotation of these two roles more clearly, and help them from different angles.
The core competency of the chief architect: making correct technical decisions
In fact, we have mentioned before that the chief architect is also a cross-domain architect. Why should we separate the role of chief architect? From a cross-domain architect to a chief architect, what obstacles must be overcome? What special abilities should the chief architect have?
Let's first study the particularity of the chief architect as a cross-domain architect. In the function of corporate structure decision-making, cross-domain architects will form a superior-subordinate relationship. But the chief architect is different. He has no superior in the function of software architecture decision-making. In other words, the chief architect is responsible for the correctness of the entire company's software architecture.
You may have to challenge me. Isn't every cross-domain architect also responsible for the correctness of the software architecture in his own domain? Why is the chief architect special?
You are on the right track this time. The chief architect is also a cross-domain architect, so as we mentioned in the last lesson, in dealing with overall and partial conflicts, the chief architect is performing the role of a cross-domain architect and solving technical problems at the company level. Overall and partial conflicts in architecture.
But there is one big difference between the two roles. Please recall our definition of a cross-domain architect in the last lesson. His main role is to overcome local imperfections and find the global optimal solution.
But from the perspective of the company, is there a global optimal solution for software architecture? We mentioned in the discussion on external adaptability in Rule 5 of Module 1 that the correctness of software architecture is actually the external adaptability under the future-oriented technological uncertainty.
This correctness is distinct from paying off technical debt and removing locally suboptimal architectural flaws. There are clear goals for debt repayment and defect removal, but there is almost never a clear answer to future-proof architectural correctness for a business. As we mentioned before in Module 1 Maximizing Business Value, technological development, technical talent supply, and business competition all have great discontinuity and uncertainty.
For example, the original stable R&D personnel in the company may be poached completely by other companies because of a certain technical buzzword. Internet, mobile terminal, full-stack engineer, growth hacker, machine learning, cloud native, etc. Behind these big words in resumes are surging waves of resignations. The company's revenue is not always stable. The originally stable business may have completely collapsed because of the epidemic.
That is to say, to grow from a cross-domain architect to a chief architect, one must overcome the barrier of uncertainty.
In other words, whether the technical architecture is correct or not depends on many considerations. There are judgments on the future of technology, judgments on talent supply, and judgments on the internal and external environment of the company. There is no right or wrong here, only the estimation of long-term trends, risks and benefits, which is a process that needs to be decided.
Through the above analysis, the role definition of the chief architect is ready to come out: in the context of software architecture, the chief architect refers to the person who can have a clear and correct judgment on the future when faced with the uncertainty of technological development Software Architect.
By the way, this ability to continue to make correct judgments is called Are right a lot at Amazon. However, this ability is not specifically for architects, but one of the Amazon Leadership Principles, which is one of the leadership principles that everyone must have.
In fact, which company does not want such talents? I believe that when buying a lottery ticket, you definitely can't want anything, but this one!
The ability of the chief architect to make correct decisions is often called a technical sense. So how to overcome the obstacle of uncertainty to enhance the sense of technology?
Obstacles that need to be overcome to grow into a chief architect
I think the simple answer here is to keep looking for opportunities for high-stakes decisions. If there was only one career choice principle in my career, this is it.
In fact, to put it bluntly, it is to take the initiative to take risks. I think this is especially important for architects in large companies. Part-time or full-time architects who grew up in a large company environment often focus on solving practical problems and rarely have the opportunity to make decisions. In the case of major technical uncertainties, most of the time, his superiors weigh risks and benefits, and then make architectural decisions.
I have seen many excellent cross-domain architects in large companies, and I feel sorry for them curling up in large companies for a long time. They don't get the decision-making opportunities that match their thinking ability. As time goes by, not only the decision-making ability degenerates, but even the precious quality of courage gradually disappears.
The ability to make correct decisions does not appear out of thin air. Like other abilities, it needs to be polished repeatedly in the process of continuous trial and error. It requires both time and opportunity, and more importantly, the relatively friendly cultural environment we mentioned in Rule 6 of Module 1.
So the question now is how to improve the ability to make correct decisions in highly uncertain scenarios? In the final analysis, it is the improvement of thinking ability. We will have the entirety of Module 4 covered on this topic. Let's not expand here.
However, if you cannot leave a comfortable environment to take risks due to various considerations, I still want to give some specific suggestions to increase your chances of participating in similar decisions. In other words, how to help the chief architect make some decisions so that he can think of you every time he makes an important decision.
First of all, there is a necessary condition: you have a clear advantage in a specific field and can win at the company level. If you are a stable player in the company, you have a deep understanding of popular solutions in the industry. Then when the chief architect makes stability-related decisions, he will definitely call you.
When you help others make high-stakes decisions, here's what to do:
-
Understand the context of the entire decision.
-
Understand the constraints of decision making.
-
Provide as much evidence as possible in the field you are proficient in, and minimize the uncertainty of small decisions.
-
From your area of expertise, make recommendations for the final decision (that is, make a final decision).
-
Participate in as many decision-making discussions as possible, and learn about uncertainty and convergence methods in other fields.
-
Whether or not the final decision aligns with your recommendations, try to understand the logic behind the final decision as best you can.
-
In the following months or even years, continue to pay attention to the follow-up progress of the decision-making, and reflect on the missing and misjudged parts of the decision-making suggestions provided by yourself.
-
In the next few months or even years, pay attention to the subsequent changes in other fields and think about the correctness of the final decision. Note that it depends not only on the final effect, but also on the right or wrong of the decision-making logic and process. Even if the decision is right, how much of it is due to luck? How many components come from the correct interpretation of the current environment and future trends? If the judgment is wrong, how many of them are wrong assumptions and how many are wrong methods.
If you are in a relatively open and inclusive cultural environment, if you are really capable, you will definitely be noticed, then you will have the opportunity to increase your influence through the above methods.
What exactly does a CTO do?
I have been CTO for six years, and I have gained a lot of growth in this position. However, I have been adjusting my thinking on this issue and reviewing my own positioning and views.
Let me start with my current conclusion: a CTO is a CEO who makes the right decisions for the company from a technical perspective.
How to understand this sentence? As a CTO, your long-term goals and decision-making priorities are exactly the same as those of the CEO, except that you think about the company's survival and development from a technical perspective, not the business perspective considered by the CEO.
As a CTO, I often ask myself: What does the CEO want now? What do you want in the long run? What can I do to help him? From a technical perspective, what opportunities and risks do I see? Did he see it?
In the position of CTO, one should pay attention to the trend of the entire market, the growth of competitors, as well as the operating conditions of the entire company, financial statements, labor costs of the technical team, and so on.
Therefore, the CTO spends most of his time thinking about the same question as the CEO from a technical perspective: how to bring survival advantages to the company? It is the main way of thinking of a CTO to formulate a technology strategy by expanding the survival advantage of the enterprise. Creating a living space through technology is actually the biggest value-added of the CTO, and it is also the most important capital for him to exchange for more decision-making opportunities.
This perspective is very special. Except for the position of CTO, all technical functions, including the chief architect, take the growth of the enterprise's technical strength as the first priority. But the CTO is not, the long-term survival of the enterprise is the first priority of his decision-making.
Through the above analysis, we can naturally define the role of CTO: in the context of software architecture, CTO is an architect whose sole goal is to expand the survival advantage of the enterprise as the technical decision-making goal.
It is necessary for me to explain further, let's look at a simple case first. Suppose you are in a highly competitive industry, and your company has not yet accumulated enough capital and leading advantages. One day, the technical team was discussing whether to adopt a cloud-native architecture to replace the existing solution.
From the perspective of long-term technological development, cloud native will bring better computing scalability, a larger technology ecosystem, and a more advanced and faster iterative technology stack. Then the company should migrate offline machines to cloud native to accelerate the accumulation of cloud native technology stack. And it is necessary to plan and act immediately in order to cultivate talents and accumulate technological advantages as early as possible.
But from a CEO's point of view:
-
Migration will increase technical investment and reduce the speed of business iteration.
-
The return brought by cloud-native migration is a long-term and relatively slow release process. In the early stage of migration, due to the immature surrounding technology and large investment, the return on capital is relatively small.
-
The most important point is that migrating to cloud-native does not bring the current survival advantage to enterprises. However, the long-term survival advantage has nothing to do with cloud native.
Therefore, from the perspective of the CEO, cloud native is not the highest priority compared to other more practical and clear return technology investments.
This case illustrates one thing. As a CTO, you need to think about technical issues from the perspective of the CEO. Technological advancement is not the primary goal. We must start from a competitive perspective and make technological choices with the company's survival and long-term growth as the goal. From this perspective, investing in technological innovation, accelerating the construction of technical barriers, giving up a certain advanced technology and a certain team, or even looking for options other than technology to survive with a broken arm are all very reasonable choices.
This is my understanding of technology strategy.
The ability of CTO is actually what people often call business sense. Only when the business sense is good enough can we know how to make a technical strategy and put the most important technical investment in the most critical position. If you look back at our extra meals on technology strategy, you will find that all the technology strategies I do serve the company's business growth.
Now, back to the topic of this module, what hurdles do you need to overcome to succeed in the position of CTO?
Obstacles to overcome when growing into a CTO
In fact, our previous analysis has already mentioned that on the topic of software architecture, the uniqueness of the CTO perspective is that technology is not the first priority, nor is it the only option. This way of thinking in terms of business rather than technology is the hurdle you have to jump over.
You may ask me, you are a CTO, if technology is not the first option, then you must not be facing technical problems, right? I give an example of a major technical problem, but technology is not the first nor the only option and you will understand.
A CTO manages a multinational business. One day, a classmate of his team told him: "We received a notification from the legal department that a certain country issued a data compliance law. According to the compliance requirements, we need to build a data center in this country. The investment is 500 man-days, plus 450 Ten thousand dollars in construction costs, and other unknown maintenance costs. This project is very complex and needs to be started immediately.”
After hearing the report, the CTO did not approve any technical pre-research, but asked the government relations (GR) department to contact local regulatory agencies and law firms to find other options than not building a computer room. After various GR operations, the computer room does not need to be built. It not only saves various costs, but also avoids a substantial increase in system complexity.
This kind of thinking of finding solutions outside of technology is necessary for a CTO.
However, this kind of thinking is not what you and I were born with. I believe that you, like me, fell in love with computers from the first day you touched it. We believe that software is omnipotent, so we chose the career of programmers. We are attracted by it, fascinated by it, forget about eating and sleeping to learn new technologies or debug code, and finally grow into CTO.
But it's this fascination with technology that is now your biggest obstacle in the CTO role. In terms of technical decision-making, you must learn to give up the interests of the team, give up technology obsession, and even give up technical curiosity, and then you can make decisions that maximize the survival advantage for the company.
So how can we help the CTO think? In fact, the same as the method mentioned above, we must start from our own perspective and provide the CTO with the greatest input. At the same time, we must participate in decision-making to the greatest extent and improve our judgment.
But you may have to ask me again, are you suggesting that I give up technical thinking?
Wrong, wrong, never give up. I have been CTO for 6 years, and I still haven't given up technical thinking until now. What's going on here?
Chief architect and CTO, my dual personality
In most enterprises, the two roles of CTO and chief architect are combined into one, and the CTO is shouldered by one person. why?
First of all, it is very difficult to find a chief architect, and the company has very high requirements for the ability of this position. The chief architect's ability to judge the correctness of the software architecture is second to none in the entire company, including the CTO.
Secondly, it is difficult to cultivate talents for this position from within. Because the judgment ability of this role needs to be improved through many high-risk decision-making opportunities, it takes a lot of time, and it is also the most scarce for most small and medium-sized enterprises.
Then there is the issue of cost. The rank and salary of the chief architect are very high. From the perspective of the CEO, there are a lot of people to be recruited. Paying a high salary for this position is often not the first priority of many small and medium-sized enterprises.
Also, these two roles are reporting relationships, but the starting point of decision-making is completely different, so conflicts often arise. There are too many conflicts, and trust is gradually lost. If things go on like this, it is inevitable that they will part ways.
Finally, it is the demands of the chief architect's personal growth. Many chief architects expect to be CTO by themselves, make decisions and think in more dimensions, and will take the initiative to leave if given the opportunity.
It is difficult to recruit, difficult to train, and easy to leave, so in most companies, these two roles must be assumed by the CTO alone.
But these two roles are essential for an enterprise, let's take a look at the following picture:
In this picture, it is assumed that you are the CTO and the final decision maker. You have two split personalities, one is the chief architect personality and the other is the CTO personality, each holding different perspectives and decision-making priorities.
-
To deal with any problem, the personality of the CTO must be highly consistent with the CEO, with the survival of the enterprise as the first priority, and taking into account the perspectives of business competition, business, finance, and products.
-
As for the personality of the chief architect, the growth of technical strength must be the first priority.
These two personalities are in constant confrontation:
-
The personality of the chief architect should draw the perspective of the CTO, the decision maker, more into technical thinking, and put technological advancement and the interests of the technical team first;
-
And the CTO personality needs to pull the CTO, the decision maker, into business thinking, and put the long-term survival advantages of the company first.
This conflict is bound to exist in every day-to-day decision-making, constant confrontation. But the ultimate goal of the confrontation is only one, which is to make the optimal architectural decision for the long-term interests of the enterprise.
The value of the chief architect's personality lies in providing a different perspective for the CTO decision-maker, and helping him withstand the pressure from the CEO when it is reasonable to insist on correct decision-making. The value of a CTO's personality lies in resisting the inner obsession with technology, as well as the instinct to protect his team members, and to make optimal decisions from the perspective of the company's overall situation. When necessary, technological advancement, team interests, and structural rationality are all options that can be sacrificed.
Therefore, a necessary condition for being a good chief architect is to have the foundation of deep trust with the CTO and the ability to resolve daily conflicts.
It was very difficult to do this in a situation of frequent conflict and information asymmetry, so I ended up choosing myself to maintain two split personalities at the same time.
Of course, I can't maintain a high degree of attention in various fields for a long time, so I am constantly looking for and cultivating talents with the ability of chief architect and CTO, and supplement my shortcomings through their judgment.
Having said that, I would also like to mention one of the abilities that I am still improving, which is to find as many talents as possible who have both excellent business sense and technical sense and prioritize the interests of the enterprise under various pressures, and then invest as many talents as possible. Give him the opportunity to make decisions.
If you are a manager, I believe you will agree with this point: the ability to judge talents is the most important ability of any manager. Be able to believe, respect, and tolerate judgments that are inconsistent with yours, and help him improve when he makes a mistake in judgment, and give him a chance to make another decision. This is an amazing manager! It is also the direction of my long-term efforts.
But this is a management topic, not part of the growth of architects, so we won't expand here.
summary
Today we studied the differences in decision-making perspectives between the roles of Chief Architect and CTO. The technical sense of the chief architect is very important. He is responsible for the rationality of the entire company's software architecture and must make correct judgments for future technical uncertainties.
But the CTO is different, and the business sense of the CTO is more important. Technology is not the first priority of CTO decision-making, the long-term survival of the enterprise is. The existence of the chief architect will compensate the CTO's perspective, and draw decision-making more on the technological advancement and long-term rationality of the software architecture. Therefore, if you want to be a good chief architect, you must establish deep trust with the CTO. Great for resolving everyday conflicts.
At the current stage of career development, getting the attention of the CTO or chief architect is critical to the growth of your architect. Not only should we improve the quality and thinking power of our own decision-making suggestions, but we should also provide them with the highest quality input from our own perspective. At the same time, it is necessary to participate in the entire decision-making process to the greatest extent so as to improve one's own judgment. Of course, it is also an essential part to further improve judgment through continuous reflection.
thinking questions
So far, we have introduced all the capabilities of architects. I would like to ask you to think about it: how do you view these five capabilities? Do you agree with this division angle? Why? Any suggestions?