You are a programmer who has worked for many years. Your position in the company is "software engineer", a front-line code writer. But in your daily work, you don't have much time to write code. It seems that most of the time is spent in meetings, non-stop meetings. You hope to have time to stop and write code, but it seems that there is more work for you to do, such as:
Explain business knowledge to newly graduated campus recruits to help them better solve problems at work;
Communicate and align with other cooperative teams to help team members sort out work content and solve problems;
Carefully read the technical solution documents of team members and give them various opinions and suggestions to prevent problems after the project goes online;
Like a customer service representative, actively answer questions for customers and troubleshoot the causes of problems;
Help others "clean up" and think of solutions to ensure that there will be no abnormalities in the project;
...
I call these jobs "glue" jobs. In principle, they are not the job of a software engineer. They keep you so busy that you have no time to write code or study, but after a week of work, when you write a weekly summary, it seems that you have done nothing. Think carefully, are you doing these things more or less in your team? If you are not doing them, who is doing these things in your team?
Of course, if no one does these things and focuses on writing their own code, the team's projects may be in a mess, and some projects may be delayed again and again. Every senior staff member in the team should know that these trivial tasks are crucial to the development of the team. They also know that these tasks are not very helpful for their "promotion and salary increase" in most cases. If you can manage these matters in an orderly manner and ensure that each task is completed efficiently, you can cultivate strong technical leadership through these "glue" tasks. However, if it is not handled well, it may affect your career and even lead to your final departure from the industry.
Should you do "glue" work and how to do it? Let's take a look at a short story first:
1. Zhang San's growth path
Today is Zhang San's first day at work, with excitement and trepidation. He has graduated for several years and has accumulated rich project experience in software development. However, this is one of the top companies after all. He is not very confident in his technical ability, but he likes this job very much and believes that he can do well with his ability.
After years of "accumulation", the department's projects have a large number of system design documents, but there are a lot of jargons in them, which makes the documents difficult to understand and often confusing to read. The same is true for the code. The compatibility logic accumulated over the years has made the code changes appear extremely complicated. His first requirement took a long time to be successfully launched. This is actually a very normal phenomenon. Although colleagues in the department are very friendly, they are all busy with their own things and have no time to care about him. They did not give him any help or comfort him. As a result, Zhang San felt that his ability was not very good, he worked too slowly, and needed too much help. He began to fear that he would not be able to pass the probation period normally.
Not long after, he completed a job and received extremely good reviews from customers: customers need to obtain user usage data reports. Logically, the system should provide corresponding functions to facilitate customers to query by themselves, but the team's workload did not list this work as a future function to be implemented. Zhang San spent several days to sort out the data needed by the customer and provide it to the customer, which made the customer very satisfied. In addition, he recorded the methods and steps for obtaining data in the team's documents and shared them with his colleagues, which greatly improved the efficiency of team members when dealing with such problems, facilitated the work of colleagues, and the customer was also satisfied.
Zhang San carried out his daily work step by step until one day, a thorny problem arose in the department project, but no good solution was found at the time. After internal discussion, the team came up with a preliminary solution. At the same time, Zhang San consulted colleagues from the next team about the relevant content and found that they had different solutions. So Zhang San organized a meeting and invited the system designer of his team and colleagues from the next team. He raised many key issues in the meeting, and after full discussion, the two teams decided to work together to create a better product. After the meeting, Zhang San sorted out the minutes of the meeting and sent them to all participants to ensure that everyone had a consistent understanding of the consensus reached. After development, the customer's problem was finally solved well and the company's revenue was increased.
Time passed slowly, and Zhang San gradually became a senior member of the team. As new members continued to join, he recalled his difficult experience when he first joined the company, so he organized his colleagues to write some new onboarding documents and established a "newcomer landing plan" to provide mentors for new members to help them integrate into the team faster.
With a deeper understanding of the business, Zhang San found that there was a serious lack of unit tests in the code base. To this end, he convened some experienced old employees, continued to promote improvements, and formulated coding standards and code integration processes. Now, all codes have more complete tests, higher readability and stronger reliability.
As more and more problems were solved, Zhang San's status in the team gradually improved, and department heads began to understand the situation of the team through him. One day, the project that the "excellent programmer" in the team was responsible for was delayed and might not be delivered to the customer on time, so the boss asked Zhang San to investigate the situation. Zhang San spent a lot of time to understand the ins and outs of the matter and found that the "excellent programmer"'s project needed to obtain information from the services of another team, but after three weeks of discussion, no consensus was reached. So Zhang San took the "excellent programmer" to communicate face-to-face with the people from another team and quickly solved the problem. In the end, the "excellent programmer" completed all the functions and the project was delivered on time. Zhang San made a huge contribution to the normal progress of the project, but all the credit went to the "excellent programmer".
Two years passed like this. Zhang San kept swearing to himself that he must find time to write more code, but there were always more important things every day, and his schedule was full:
Team members have begun to regard him as an informal leader. He knows everything in the team, can find problems in system design, and propose effective solutions. He often needs to communicate one-on-one with team members and guide all new members. The only free time is one or two hours between meetings, but it is almost impossible to focus on writing code in this short time. However, he is not worried about his development because everyone tells him that his work is excellent and he can always get the best performance. After more than two years of growth, he feels that he has reached a new height.
However, in the company's promotion process, those who write good code are often promoted, such as the "system designer" and "excellent programmer" mentioned above, but Zhang San is not promoted.
Although Zhang San helped customers, developed coding standards, and assisted colleagues in reviewing system design documents, and although we all know that not all technical work requires writing code in person, the boss will still tell you:
Your project is not online yet.
You haven't written much code.
You don't have enough influence yet.
You have strong communication skills.
Your soft skills are excellent, but we don't think you are a qualified engineer.
Do you want to consider being a project manager?
2. Promotion dilemma: the collision of ability and system
Is the promotion mechanism in the story really fair to Zhang San? Zhang San undertakes the most influential work at the key nodes of each project. Without him, many projects may not be delivered on time. He is the "glue" that closely connects the entire team and all projects. In the past two years, he has grown rapidly in technical leadership and performed very well: not only has a deep understanding of the problems in the project, but also has a very good understanding of the needs of team members, introduced standards, optimized designs, and greatly improved efficiency. Although the improvement in coding ability is relatively limited.
How should we view this situation? Can he be promoted to a senior engineer?
Do you feel that you should be promoted based on your ability, but you should not be promoted based on the system? This kind of conflict is normal! The answers to this question are varied. Some people think that the answer is obvious and there is no need to ask this question (although their answers are not consistent).
But one thing is certain: his boss is partly responsible for this matter, and they did not communicate well about the content of the work. Zhang San received very high performance evaluations every year. He firmly believed that he was on the road to promotion to senior engineer. Moreover, he did take on and solve the work and problems expected of senior or even senior engineers. His leadership ability is undoubtedly excellent. However, the company did not think that this work was enough for him to be promoted, at least not at the good level. Although they did not say it explicitly, what they really valued was code or other quantifiable technical achievements. And the boss never told him that the work he did was not enough to support the promotion. The boss may just be relieved that someone is willing to take on these "glue" work, because these jobs really need someone to do them.
"Glue" work is often the key to the success of a project. Usually these jobs are done by project managers, but what happens in a team without a project manager? In some teams, the boss will take the initiative to take on this part of the work. In more teams, these tasks are often undertaken by those who are willing to do it, or by those who are assumed to be willing to take on such work.
3. Focus on the core and avoid career wandering
The above does not mean that all your work must directly contribute to promotion. For personal growth, it is indeed beneficial to develop soft skills and expand your horizons. At work, everyone should share some of the "dirty work" fairly. However, most of your work should focus on core KPIs. If someone deviates from the core work for a long time, it will actually have a negative impact on their career development. And if you, as their boss, let this happen, you are actually allowing them to inadvertently hurt their career.
In daily work, the content of work is often like "one man's honey, another man's poison". Work that is not good for your promotion may be very beneficial to the promotion of others. For example, an engineer organizing a team building event is unlikely to be considered as a basis for promotion no matter how well it is done. But if this person is an HRBP? Then this work may be their core responsibility.
For those tasks that are truly detrimental to anyone’s promotion, they should be distributed fairly. They need to be tracked like any other task on the team and they need to be distributed in a planned way. If they are just picked up by random people, they are not distributed fairly. Take a moment to think about who on your team is doing these detrimental tasks?
Okay, now let’s go back to John. He is being advised to move to a position where he can turn these tasks into promotional tasks. We see this a lot: the message is often “you are doing detrimental tasks, so change your position”. It’s rare to see someone emphasize “then adjust your work content” or “change the way you present your work results”.
Let’s talk about the issue of transfer. I read a lot of articles about whether or not to choose a certain job. Most of them are written by people who are already doing the job and discuss whether you are suitable for the job, as if you are good at something, it means you have to do it. They will say:
Are you good at handling feedback? Do you like coaching others? Do you like dealing with people? Then you should be a project manager.
Can you think from the customer's perspective? Then you should be a product manager.
But this stereotyped way of thinking is like those signs at amusement parks: "You must be this tall to ride the roller coaster." But just because I'm tall enough, does that mean I have to ride the roller coaster? I have good social skills, so I have to be a project manager? But that's not what I want to do!
In my opinion, if you write code, you will gradually become better at programming; if you manage people, you will become better at management. So the key is what do you want to improve yourself in? What skills do you want to acquire? It's not about what skills you already have, but what skills you hope to have in the future. After all, most of our abilities are learned on the job.
I have seen many people never seriously consider the job they really want because they feel that they don't have all the skills for that job. Many computer science college students told me that they didn't apply for any programming-related jobs because they didn't feel that their programming skills were strong enough. They ended up choosing a job they didn't want because they were afraid to try the position they really wanted or because others told them that they would perform better in another position.
I recommend making conscious choices. Choose a job that will make you feel successful, happy, proud, and teach you the skills you need. Do a job that excites you. You will learn and become better at it. Most of the time, we don't do our jobs perfectly on the first day, and most of the skills are learned on the job. However, when you try to move to non-engineering jobs, you need to make sure you have a solid technical background, because once the word "project manager" appears in your work experience, many people will be biased and immediately assume that you are not good at technology. I have seen many people accept such offers, only to find themselves assigned to non-technical management or project management positions and gradually move away from software development. And when they want to return to their original developer positions, they find that they can no longer be hired at their previous level, even if they have not been away from development for a long time. It's like their skills have disappeared. They have to return at a lower level than when they left because people no longer believe they are capable of doing their original job.
Here I suggest that you don't tell people that they are "not technical enough", but be specific about what you want them to know. For example:
You need to understand and participate in technical discussions in design meetings;
Our senior engineers are system designers, and you need to take courses in distributed systems.
Otherwise, you are basically just saying: "You don't look like an engineer. Can you act more like one?"
4. Contribution and growth, how to choose
Two years ago, Zhang San joined the company as a mid-level engineer. Since then, he has been helping the team fill gaps and helping the team and the organization succeed. However, in the promotion field, he was told that he had no technical achievements.
I am not sure what the right career choice is for him, but he hopes to be promoted. Assuming that he decides to continue on the path of an engineer and become a senior engineer, in fact, most of his work content is already the responsibilities of a senior engineer. However, he frequently hears the evaluation of "not enough technology". If you are a "glue", what should you do? If you are managing a "glue", what should you do? As a person who has been through it, I have four suggestions:
1. Communication
Zhang San should have a long-overdue career conversation with his boss as soon as possible. He should ask straightforward questions such as:
Will I be promoted in the next round?
What work do I need to do to be promoted?
Do these jobs meet the standards of a senior engineer?
His boss also needs to answer questions honestly and directly based on his understanding of the career development path. They need to agree on goals, develop a clear plan, and check in on progress regularly to make sure they are still on the right track.
2. Title
Find a way to get a suitable job title. If he and his boss both want him to continue to do a lot of "glue" work, can you consider giving him a title that can enhance his technical credibility? For example, let him take a position such as technical leader. Usually, people expect the leader to do a lot of "glue" work, and such a title can better reflect his contribution. Maybe some of you will think when reading this, titles don't matter. Maybe you don't need them, but my friends, this doesn't mean that everyone doesn't need them. There are all kinds of stereotypes in this world. If you are a white or Asian male, others will assume that you are good at programming by default. Even if you just graduated yesterday with a law degree, people still assume that you can program. A suitable job title can save us a lot of time and energy, and we don't have to spend time proving our qualifications. It also gives us more freedom to do "glue" work without worrying that others will think we are "not technical enough". Please remember that titles are very important.
3. Packaging
At work, Zhang San makes the project come true through his hard work and technical judgment. But he still needs to package the results and express them so that everyone in the team knows his influence. If you, as a manager, see similar situations, you should also publicly express your appreciation and praise your colleagues' leadership.
At the same time, you also need to organize your work materials, such as program design documents, meeting minutes, and key issues for solving problems, and use these materials as promotion statement materials. However, even with these materials, you may still not be promoted smoothly.
4. Stop doing "glue" work
In order to get promoted better, I would suggest that you put aside those things that are more important to the company and department, work strictly according to the requirements of the job ladder, and do more easily quantifiable work, some "technical" work that everyone recognizes:
Write a bunch of code;
Write some design documents that anyone can write;
Optimize the performance of the system and optimize the database.
Even if these tasks may be done by someone more suitable in the team, or you are slower than others because of your lack of skills, you still need to do them.
Coding is very time-consuming and requires high concentration, and it usually takes a large block of time to really get involved. Therefore, before the promotion is passed, do not participate in the interview, do not participate in the organization of team building, and stop all things related to team building. The most important thing is: do not save things that are about to be shelved.
Only when your schedule becomes like this can you have a large period of blank time to focus on writing code, writing design documents, and so on. When you complete these tasks one by one, it will form a virtuous circle and continuously improve your coding skills and your ability to write design documents.
This process is learning. Most of our learning happens at work. Every time you encounter a problem at work and you search for an answer on Stack Overflow, you will learn something, and this process is repeated. But for those things that are not often repeated, you must actively learn to truly master them.
5. Continuous learning and continuous improvement
For those who like to do "glue" work, I also recommend that you continue to improve your technical skills. If you keep doing "glue" work, you will eventually become better at "glue", and your technical skills may stagnate, which will affect your future career development. Learning core technical skills is almost impossible to regret.
In our industry, few people really discuss the importance of learning. We all have the technical knowledge in our brains that we learned in some way, but we often ignore the huge amount of time we invested in the learning process.
If you are a senior developer, I recommend that you share what you learned and how you learned with the junior employees on your team. Some of us are lucky enough to have free time to learn, while others have almost no time to learn due to various work matters. Here, I want to emphasize that you need to realize that it is okay - and normal - to learn during working hours; for managers, it is also a very valuable investment to train mid-level employees to senior employees. Never waste any opportunity to let people learn.
At work, if you always do something for someone, it seems to be protecting them on the surface, but in fact you are depriving them of the opportunity to learn. If there are some tasks that you are already very familiar with how to do, then you should try to assign these tasks to those who can benefit from it. Let them block time in their schedule to learn and support them in the learning process. This will not only help them grow, but also cultivate more capabilities for the team.
My awesome colleague Polina has some great advice on how she handles people trying to push her into the “PM” job:
Coworker/boss: “You should do this because you’re great at communication.”
She responds: “Yeah, I’d be great if I put in the time, no matter what. You should see how I do system design.”
So, while she focuses on designing systems, the communication needs to be handled by other colleagues. By doing this, she creates a learning opportunity for other colleagues to improve their communication skills as well. If you’re a manager, I recommend helping those on your team who aren’t great at “glue” to do that work.
Remember the “excellent programmer” and “system designer” in the story? They were able to do their jobs because John helped the “excellent programmer” communicate and helped the “system designer” figure out how the system he built integrated with other systems the company was building. I don’t think these two are truly senior engineers. And if someone continues to do the “glue” work for them, they’ll never learn how to become truly senior engineers.
Our skills are not fixed, you can be good at many things, and you can choose to do anything. Say no to tasks that ask you to do more than your fair share and that don’t allow you to move up, and put your energy into what you really want to do.
