Original link: https://ourai.ws/posts/survival-in-software-team/
This article is not about the survival strategy of software products, but about the survival of software developers in the team – logically speaking, this is also a “human factor” problem as mentioned in the previous two articles.
Team type
Regardless of whether it is related to the Internet or not, in a company that relies on providing software and services, as long as it has a certain scale, it will differentiate into a business-oriented team and a support-oriented team——
The premise of the division of labor is that the process links are relatively complex, and due to insufficient standardization of operations or other reasons, it cannot be automated, and machines cannot be used to replace labor.
Ole, ” Rethinking Software Development: Software Production “
The business-oriented team focuses on “open source”, that is, “revenue generation”, and contributes to the company’s products to bring more revenue or traffic; the support-oriented team is responsible for “throttling”, that is, “efficiency improvement”, allowing the business-oriented team to do things Can land faster, better, and with more quality.
work value
How do you respond when asked, “What valuable things have you done in a certain period of time?”
I believe that many people will “confidently” say how much revenue and traffic they have brought to the business; there are also many people “excited” to list how much they have contributed to making the business better.
When you are talking to someone about something that you think is very valuable, the other person asks: “What is the value of doing this?” , and wondered: “There is no value in such a valuable thing?”
The person asking is not necessarily malicious. It may be that your statement did not allow him to get the value point you think, or it may be that although he gets the value point you think, he thinks it is worthless.
The former is a problem of expressiveness and understanding, which is generally not a big problem, and can be explained in another way; while the latter is a problem of values, which will affect the lineup, that is, the degree of matching and integration with another person or group.
Judging from the above division of team types, it is intuition that what you do is valuable as long as it conforms to the team’s responsibilities and can make the team better. This may be true from the “team” as a whole, but what about going deep into the team?
“Worth or not” is “evaluation”, and “evaluation” is affected by “people’s will”. As long as it is influenced by “people’s will”, it is “subjective”, no matter whether this “people’s will” is for one or two people or many individuals of.
Therefore, the value of what an individual or team does is ultimately determined by the values of their immediate superiors—whether the effect of what they do is immediate or needs to be changed from quantitative to qualitative, and whether the immediate superiors themselves and other colleagues or supported teams recognize them .
If it takes a long time for what you do to show (huge) power, then you may have been fired or gone because your immediate superiors decided that what you did was worthless.
survival predicament
The above may seem like “normal” and “it’s nothing”, so let’s start with some facts that I find frustrating.
People who always read my articles and know me know that my work experience is that I have worked in both business-oriented teams and support-oriented teams. No matter what type of team I am in, I have actively done a lot of infrastructure construction. aspects of work.
And I have also managed a small team, I can use different perspectives to explain as comprehensively as possible –
business front end
The issue of career development and growth revolves around everyone, especially for R&D personnel, but especially for front-end engineers in business-oriented teams.
In the business team, the main responsibility of front-end engineers is to complete product requirements, ensure product quality and launch time. Want to encapsulate UI component library, scaffolding, development framework? Isn’t there a ready-made open source project and a project with a supportive team? Is there a need to repeat the wheel? Is the requirement done? Can the team make money?
In a business-oriented team, does business have any relationship with the front end? The front-end is only one of the implementation links, and the front-end engineer is just a brick-brick. Basically, he can only intervene in the feasibility and rationality of the implementation. Do you want to cut demand or control the development direction of the product? hehehe…
The front-end engineer of the business team, writing the code without bugs is “should”, this is “their job”. If there are too many bugs, not only will they be complained by the cooperating people, but they will also be considered incompetent by them and their superiors.
Want to do some infrastructure work to improve efficiency and reduce quality issues? Yes, but it cannot affect the development of normal requirements. Also, doing those things can only be regarded as your personal improvement, because it doesn’t make the team make more money, it’s not bad if you don’t count as “not doing a proper job”.
In this way, the ceiling of front-end engineers in business-oriented teams is too low, and it is easy to encounter development bottlenecks.
Even if you can refactor all the project code in the team, after all the refactoring? Do these refactorings make your superiors and other colleagues praise you, appreciate you, value you more, improve your important status, and make the evaluation results conducive to promotion and salary increase? If not, is this self-exalted and self-motivated?
If you still stay in such a system, there are basically three paths in front of you: to switch to a support team; to be the front-end leader; to switch to product direction.
Supported front end
The “supportive team” sounds a bit tall, giving people the appearance of technical smashing, and making the people of the business team fascinated – relatively speaking, it has some advantages in technology. After all, it depends on providing technical services to eat, but also Not so exaggerated.
Here, “supporting teams” refer to public technical departments that provide general development tools, or middle-office departments that provide low-code platforms, data intelligence services, etc., with high thresholds and related resources.
After joining the support team, I thought that I could finally concentrate on my favorite technology-related things without thinking about the unpredictable business!
Is it really? Is it really? ? Is it really? ? ?
Not to mention that the situation of front-end engineers in some support teams is actually the same as that of business teams, think about who is the business side of support teams? It’s a business team!
If the technical work done cannot meet or meet the needs of the bad business team, what is the value and significance of the work done? If there is a problem in the process of docking with the business team, or if there is a problem in their business after the docking, they may be complained.
Therefore, even if you are not in a business-oriented team, you will be affected by the unpredictable business, even if it will be relatively small.
Even if you can focus more on technology than business teams, the ceiling is higher, and bottlenecks will be encountered later, but what can you do?
Tool Library? UI component library? scaffold? Development Framework? Cross-end solution? Configure the platform? monitoring platform? Low-code platform? anything else?
Doing these things for the first time will feel very fresh and rewarding, but if you are motivated, if you have done it once in a business team, or when you switch to a support team in another company to do similar things, it is very likely that You will find that there is nothing new, and the ideas and practices are very similar.
So, for you, is there any value in doing these things again? What’s the value?
When you do those things step by step according to the plan and instructions of the team leader, you are just a brick mover just like in a business team, there is no bright spot, and you are still a highly replaceable screw, there is no difference.
For R&D personnel, the biggest difference between front-end engineers in support teams and business teams is that their direct business is technology. They understand their own business better than those in business teams, and are more likely to the left and right direction of development.
If you want to change direction and reflect your own value, you have to figure out what the value of the team is, dig out the root cause of the problem, come up with better ideas and feasible solutions that can solve the real problem, and convince the team leader and others. and business side.
The responsibility of the support team is the “efficiency improvement” that everyone talks about, and it is also the “instinct” of most software engineers.
However, what many people may not expect is that in some cases the proud “improvement” has become a “butcher’s knife” that deprives others of their jobs, and themselves become an “accomplice”. What’s even more funny is that he may be one of those who have been deprived of his job and “suicide” in disguise…
The logic behind this is that “efficiency improvement” increases production capacity. If the overall revenue of the organization does not increase accordingly, that is, those business-oriented teams are not strong enough, there will be excess labor, which will increase the organization’s operating costs; in order to survive, the organization will Find ways to reduce expenses, thereby reducing staff in various forms.
front-end manager
Some people will naively think that being in charge of the front end will allow you to sit back and relax… I don’t deny that this is the case, but it’s more likely –
Not only continue to do front-line development work, that is, to fulfill the responsibilities of front-end engineers in ordinary business teams, but also to do team management and project management related work.
It’s better to say things in your own department. When you encounter cross-departmental collaboration, the division of responsibilities and coordination of resources will be quite troublesome.
Due to the adjustment of organizational structure and personnel changes, the phenomenon of playing football has occurred from time to time. If you want to find a personal consultation question, you have to go around in a circle. It may take a lot of time to ask, and of course there is a possibility of not getting the answer.
When you or your subordinates encounter the other party’s uncooperativeness, you have to communicate with the other party’s leader or find your superior to communicate with the other party’s leader’s superior. This kind of thing happens even in the same department.
As the front-end leader of a business-oriented team, according to people’s inertial thinking, you have to understand the business better than other front-end engineers, right? But the question is, how to understand the business?
To really understand business, you must first be interested in that field, right? If you are not interested, how can you really understand the business? People who don’t like math make me worship with high scores in math test?
Do those who say they understand business really understand business? ? ? Can you identify problems in the current product architecture and business model and propose improvements? ? ?
As the front-end leader of a business-oriented team, according to people’s inertial thinking, do you have to know more about management than other front-end engineers? But the question is, how to manage it well?
What is “management”? Is it waving the sword of power in his hand to force him into submission? Or use various techniques and means to draw a big cake to tempt and trick them?
People who think and act like this don’t understand “management”, let alone human nature. The real “management” is to create a comfortable environment, to stimulate the initiative of others to work, to achieve their own and then to achieve the team——
The ideal management should be able to arouse the enthusiasm of the subordinates, arouse the sense of mission and achievement of standing together through thick and thin, and make them feel that work is not only a means of maintaining survival and living, but also a way of self-realization, and ultimately achieve self-driving, self-organizing, The effect of self-management; the most ideal organizational form is a decentralized or weakly centralized organization based on a common vision.
Ole, ” Rethinking Software Development: The Human Factor (Part 2) “
First figure out what “management” really is, and then think about how to express the profound connotation of that word well – this is actually a sociological issue.
But to be honest, in this kind of middle role, the rank and the money are likely to be similar to other people’s, and it is easy to do things that are not pleasing to the top and the bottom. Not only is the blame reprimanded by the superiors, but also the subordinates say that they are putting on airs and are not human, and they are wronged. Can only swallow tears.
make product direction
When it comes to switching to a product direction, it means that you are very interested in the team’s business area, although you don’t necessarily know it well. If you don’t know, you can learn, but if you’re not interested, you can’t.
Product direction is not necessarily to be a product manager, business line leaders, architects, etc. also need to understand the business well, these are more suitable for front-end engineers to transform.
In fact, the obstacles on this road are still quite large. Needless to say, “vision” or “consensus” may be the biggest obstacle to replenishing a large amount of missing knowledge and improving cognitive ability and thinking style.
When you have a strong point of view on the positioning, function and form of the product, although the business field and the team are the same, the positioning and goals may be different.
What should I do then? Convince the team leader? Unlikely. Submissive obedience? One is that you will feel unwilling and aggrieved, and the other is that you return to the original question – what is the value of what you do?
Summarize
Many articles talk about the career development and growth of front-end engineers from a positive and positive direction, just like human society always tends to promote good and positive things, so that people can attract people named “easy” and “happy”. The pacifier, thus forgetting the dangers around him.
This article attempts to discuss the problems, dilemmas and contradictions that front-end engineers may face in their career development and growth from a negative and negative direction, trying to awaken everyone’s sense of crisis.
I did not give a “survival strategy” like the title of the article, but pointed out the “survival problem” and hoped that everyone will find a “survival strategy” that suits them.
This article is reprinted from: https://ourai.ws/posts/survival-in-software-team/
This site is for inclusion only, and the copyright belongs to the original author.