Technical director
The technical Leader, also known in some companies as the technical manager, is commonly known as Tech Leader or TL for short. In Ram Charan’s book Echelon, it is mentioned that a person who spends at least 50 percent of his or her working role on administrative matters is considered a Manager. So the technical director (manager) is similar to the product manager, which is named after the manager but not the manager.
The “technical lead” is the role that one programmer on the development team assumes when he or she is responsible for the entire development team that created the system together. He is usually responsible for both the final delivery of the software system and the implementation of the system as a programmer. 60 to 70 percent of a technical lead’s time may be spent on development task breakdown, development practices, code review, and risk identification, while the remaining 30 to 40 percent of his time is spent planning, collaborating, communicating, and managing the various activities needed to ensure the system is delivered on time. Unlike a team manager, the majority of the management of a technical lead is directed at specific r&d tasks and technical issues.
For example, it is common for a development team to encounter differences in technical solutions and implementation details. If the programmers are unable to agree on different technical ideas independently and amicably, then the technical lead needs to step in to understand the conflict caused by the two different ideas. Get to the bottom of the problem, analyze the pros and cons of each solution, and even suggest a third, better technical solution if necessary to help the development team reach a consensus.
Technical leaders, on the other hand, are generally not focused on a specific feature implementation, even in their day-to-day implementation. After assessing, breaking down, and assigning specific development tasks, the technical lead should be responsible for designing the structure and specifications of the overall code, introducing new tools to improve the productivity of the entire team when necessary, promoting code templates, and summarizing best practices. He needs to constantly pay attention to the gap between the team’s ability to complete a development task and the level of actual requirements, so that the team can not only meet the timely delivery of software systems, but also grow.
In reality, it’s easy for the best programmers on a development team to be assigned the role of technical lead, but it’s easy for the best programmers to get bogged down in the details of implementing features, content with perfect implementation, elegant and concise code. In fact, such a good programmer into the role of technical director, it is easy to try to control the design and code implementation, they find it hard to accept the code is not in accordance with the way they want to write, this is their work habits, as good programmers have been in the long term themselves easily become the bottleneck of the development team, The rest of the team didn’t get enough exercise and growth.
So the technical lead actually takes a broader view of the system and thinks in a more strategic and long-term way than any other programmer on the team. They even have more than all the other programmers team excellent development skills, for all the realization of the development task has the most powerful self-confidence, also need to shift to another “with the help of others to make the implementation of” the ability and confidence, because the technical director is a wider responsibility, the role of effective encoding time will inevitably leads to focus a lot less than in the past, This is one of the biggest challenges that good programmers face when they become technical leaders.
Finally, we summarize the responsibility requirements of the technical supervisor:
Technical responsibility
Code specification development and promotion
Productivity tool development and promotion
Best practices summary and promotion
Workload assessment
Task breakdown and assignment
Code reviews
Risk identification
R&d Task Management
Improvement of technical capability
Key code implementation
Organization responsibilities
Coordination communication
A job interview
coaching
Checking summary
The architect
After reading about the technical lead’s responsibilities and competencies, you might be a little confused, but it seems that many of the items are also for architects. Yes, you feel that’s right, technical director of the role and the role of the architect will produce some duties overlap, in fact I think in the team when the relatively small size (the size of the more than 10), the architect and technical director duties overlap almost completely, even some technical director will agent team manager role.
Like technical lead, architect is a well-known title in the industry, but it’s not a job title in most companies. Many companies struggle with how to define the role of the architect and what the architect does. I heard from Ali that P7 belongs to the position of architect, but recently I read another article written by Ali that “in the past few years, there were full-time” architect “positions, but now it has returned to” engineer “, “technical expert”, “researcher” and other purely technical positions. . It can be seen that the definition of architect in first-tier Internet companies is also very vague.
In an article titled “The Essence of Architecture in the Eyes of the Chief Architect… Referring to an architect competency model, I have written that this competency model is appropriate for the role of architect based on my own experience and experience.
But because the definition of the role of architect is so vague in the industry and in companies, many good programmers who have gained a certain level of experience and have been promoted to a certain technical level within the company are called architects. But the reality is that most good programmers who have just started out as architects have a capability model that is mostly in the blue area of the figure above, with no systematic knowledge or training of the other areas.
Having looked at the architect’s capability model, let’s try to analyze the corresponding responsibilities. Up the software system complexity and scale, the team also corresponding change, so an architect’s job position at this time began and technical director, if the technical director is like standing on the roof to see the entire system, so the architect at the moment is the need to hang a balloon (imagine animation “up” scenario), fly to the sky to see the whole system.
In addition to the technical responsibilities of the technical director, the architect also needs to stand at a higher level to do the abstraction and encapsulation of software systems. If the technical director of abstraction and encapsulation level is more consideration of language function, design patterns, code structure, etc. This kind of transaction, then the architect is high standing in the whole software system, considering the interaction relationship between the different subsystems, the rationality of the technology, requirements for completeness, the evolution of future possibility, technical system development and organization, product, commercial appeal to match.
This is a global perspective with a higher latitude than that of the technical director. On the other hand, there are still many technical decisions and technical disputes that the technical director may feel uncertain and require the intervention and coordination of the architect. The reason architects are called upon to make decisions on technical issues and solutions is often due to programmers’ trust in the architect’s expertise and influence in the technical domain, and building this expertise and influence is the source of the actual building of the architect’s non-authoritative leadership.
What is “non-authoritative leadership”? Non-authority refers to relative authority. The authoritative leadership of the manager comes from the position and authority officially appointed by the company, while the responsibilities of the architect are not clearly defined in most companies, let alone the word of authority. Therefore, there is no authoritative leadership in fact. Therefore, in order for architects to play a greater role and value, they need to build their own non-authoritative leadership, which requires long-term accumulation of professional strength and influence. As for how to accumulate and play a good role, I am still exploring this point, and have not formed a systematic cognitive system.
On the other hand, the architect’s organization responsibilities in addition to technical director for the architect also carries on the technology team and non-technical (for example: the product design team), the interfaces between the boundary of the specific product, draw the outline of technical blueprint, coordinate different skills of technical team, to complete the final delivered software system. The role of the architect is like an API in a service-oriented architecture, defining collaboration specifications, interaction protocols, and ways, but not focusing on implementation.
On larger scale systems, architects seem to need to engage in more cross-domain knowledge, or they may not be able to make the most appropriate technical decisions. But people are limited, and you can’t learn everything, so there will be vertical architects in certain areas. For example: data architect, network architect, business architect, security architect. Therefore, an architect with a background in one domain has only a rudimentary understanding of other domains, and when it comes to making architectural decisions involving other domains, it needs to have in-depth communication with vertical architects in other domains to help make decisions.
Finally, let’s summarize the responsibilities of an architect:
Technical responsibility
Inherit responsibilities of technical supervisor
High – latitude system design, abstraction, and encapsulation
Product technology blueprint and key technology decision
Organization responsibilities
Inherit responsibilities of technical supervisor
Interface collaboration across technical and non-technical teams
Development of trade-offs
From the beginning, I mentioned that the technical lead and architect are two branches of the natural growth path of a programmer, and that a programmer who stays in the “good programmer” competency model domain is not going to perform well in the technical lead and architect roles. So as programmers grow up, they need to consider whether they really want to become technical directors and architects. The transition from technical director to architect is relatively more continuity, but technical director will also have another path, is to transition into a pure management position, to become a true manager.
Once you choose to become an architect, you are basically stepping out of the realm of being a good programmer and need to quickly complement the other competencies outlined in the competency model above. This will make programmers who have just started this path very uncomfortable, because more responsibilities, will inevitably reduce the time in the implementation of coding, gradually suspect that their coding ability will deteriorate, and also keep up with the latest technology stack, all kinds of cool new tools. There was a time when I felt this bewilderment and fear, but now I am relieved.
Willing, willing, no give up, no get. Being an architect gives you a more three-dimensional matrix of knowledge and skills, which is what you get. Acquired a surface, at some point must face the end of being surpassed. If, after years of being an architect, you are still the most skilled coder on the team, you are a failed architect who has completely failed in the role of coach and mentor. There are articles about architects that say:
An architect must be responsible for coding the core and hardest parts of the entire system. If a team needs an architect, he must be the best coder on the team and be responsible for at least 40% of the core development work.
The above statement is bullshit, and such architects are the biggest bottleneck for the team. An architect who does more than 40% of the core development work on a larger software system or team is basically a senior programmer with other responsibilities that I doubt he has the time or ability to consider. He will realize that this approach is not sustainable, and that it takes away from other developers the ability to innovate and the joy of solving problems. An experienced architect is better able to express certain guiding principles and know when to step in and when to let go.
Whether or not an architect should code, and how much coding he should do, is not determined by any definition or phrase. But determined by the architects themselves, because the architect for the final delivery of the software system and process of risk identification, if architects think some key part, in no one else can write to him in front of the delivery date enough reliable code recognition, he put it identified as a risk, decided to do, so he went to implement, Otherwise, delegate to a team member he thinks is reliable enough, which is the aforementioned ability and confidence to “make it happen.”
As the programmers on the team grow up to be senior or experienced programmers, there are fewer and fewer opportunities for the architect to actually write code. Capabilities in this area will inevitably deteriorate, so decisions in this area of the technology stack will increasingly be left to senior programmers on the front line. But we worry about the time, the environment, and the day when we need to go back to the technology stack, when the technology stack has changed dramatically, the architect will be able to adapt well. I don’t think it takes much time to learn a stack again. Months, six months, or a year may get you back to the programming state that feels good on the new stack.
.
Sometimes it’s nice to be a programmer quietly.