DEV Community

Cover image for Survival in Software Team
Ourai L.
Ourai L.

Posted on • Originally published at ourai.pro

Survival in Software Team

This article is not about the survival strategies of software products, but rather the survival issues of software developers within a team—incidentally, this also falls under the category of "human factors", as discussed in the previous two articles.

Team Types

Whether or not related to the internet, in a company that relies on providing software and services for its livelihood, once it reaches a certain scale, it will differentiate into business teams and support teams—

The premise of division of labor is that the process is relatively complex, and due to insufficient standardization of operations or other reasons, it cannot be automated and cannot be replaced by machines. Therefore, it is necessary to break down the process into sub-links and find corresponding people to handle them.

Ourai Rethink Software Production

Business teams focus on "revenue generation", that is, adding value to the company's products to bring in more income or traffic; support teams are responsible for "cost control", which means improving efficiency so that the work of the business teams can be implemented faster, better, and with higher quality.

Work Value

When asked, "What valuable things have you done during a certain period?" how would you respond?

Many might confidently claim that they have brought in a certain amount of revenue and traffic for the business; others might enthusiastically list their contributions to making the business more efficient.

Just as you are elaborating on what you believe to be valuable work, the other person asks, "What is the value of what you have done?" Your first reaction is likely to be irritation, followed by confusion: "How could they not see the value in something so valuable?"

The questioner may not be malicious. It could be that your expression failed to convey the value you perceived, or perhaps they did understand your perspective but simply did not find it valuable.

The former is a matter of expression and comprehension, which is usually not a major issue—just rephrase it. The latter, however, is a matter of values, which can affect alignment, that is, the compatibility and integration with another person or group.

From the division of team types mentioned above, one might intuitively think that as long as the work aligns with the team's responsibilities and makes the team better, it is valuable. This might be true from the perspective of the "team" as a whole, but what about when we look deeper into the team's internal dynamics?

"Valuable or not" is a "judgment", and "judgment" is influenced by "human will". Anything influenced by "human will" is "subjective", whether it is the will of one or many people.

Therefore, whether an individual's or a team's work is valuable ultimately depends on the values of the direct supervisor—who determines whether the impact of the work is immediate or requires a gradual accumulation of effects, and whether it is recognized by the supervisor, colleagues, or the supported teams.

If the work only shows its (significant) power after a long period, you might have already been laid off or left the company because your direct supervisor initially deemed your work valueless.

Survival Dilemmas

The content above may seem "normal" or "nothing special" to some. However, the following points may reveal some more disheartening realities.

Those who regularly read my articles and know me are aware that my work experience includes time spent in both business and support teams, where I actively engaged in a lot of infrastructure-related work.

Moreover, having managed a small team, I can provide a more comprehensive perspective to address the issues from different angles—

Business Front-end

Career development and growth are concerns for everyone, especially for front-end engineers in business teams.

In a business team, the primary responsibility of a front-end engineer is to complete product requirements, ensure product quality, and meet the launch schedule. Want to encapsulate a UI component library, scaffolding, or development framework? Aren't there existing open-source projects and tools from the support teams? Is there a need to reinvent the wheel? Are the requirements finished? Can they make money for the team?

In a business team, what is the relationship between the business and the front-end? The front-end is just one of the implementation stages, and the front-end engineer is essentially a bricklayer, able to comment only on the feasibility and rationality of the implementation. Want to cut requirements or influence the direction of product development? Hahaha...

For front-end engineers in business teams, writing bug-free code is "expected"—it's their "core duty". If there are many bugs, not only will they be complained about by collaborators, but they will also be seen as incompetent by them and their superiors.

Want to do some infrastructure work to improve efficiency and reduce quality issues? Sure, but it must not affect the normal development of requirements. Moreover, doing such work is only considered personal growth because it doesn't directly contribute to the team's profitability. At best, it might be seen as having some ambition during performance evaluations!

It seems that the ceiling for front-end engineers in business teams is too low, and they can easily hit a development bottleneck.

Even if you can refactor the code for all projects in the team, will these efforts earn praise, admiration, and increased importance from your superiors and colleagues, leading to favorable performance reviews and promotions? If not, isn't this just self-indulgence, a form of self-motivation?

If you remain in such a system, you are essentially left with three options: transfer to a support team, become a front-end lead, or transition to a product role.

Support Front-end

The term "support team" sounds somewhat prestigious, giving the impression of technical superiority that business team members often envy—in terms of technology, there is some advantage, as they provide technical services, but it's not that exaggerated.

Here, "support team" refers to public technical departments that provide general development tools, or mid-platform departments that offer high-threshold services such as low-code platforms and data intelligence services, where resources are more concentrated.

After joining a support team, you might think you can finally focus on technical work without worrying about the ever-changing business needs!

Is it really like that? Is it really like that?? Is it really like that???

Not to mention that in some support teams, the situation for front-end engineers is actually similar to that in business teams. Consider who the clients of the support team are—the business teams!

If the technical work you do does not meet or poorly meets the needs of the business teams, where is the value and significance of that work? If issues arise during the对接process with the business teams, or if problems occur in their business after the对接, you might even receive complaints.

Thus, even if you are not in a business team, you are still affected by the ever-changing business needs, albeit to a lesser extent.

Although you can focus more on technology compared to being in a business team, with a slightly higher ceiling and a later bottleneck, what can you really do?

A toolkit? A UI component library? Scaffolding? A development framework? Cross-end solutions? Configuration platforms? Monitoring platforms? Low-code platforms? What else?

These things may feel fresh and rewarding the first time you work on them, but if you have already done them in a business team or if you switch to another company's support team to work on similar projects, you might find there is nothing new— the ideas and approaches are mostly the same.

So, is there still value in doing these things for you? What value is there?

When you follow the team leader's plan and instructions to do these things step by step, you are just like a bricklayer in a business team, with no highlights, still a highly replaceable cog in the machine, no different.

For front-end engineers in support teams, the biggest difference from those in business teams is that their direct business is technology. They understand their business better and are more likely to influence its direction.

To make an impact and demonstrate your value, you need to understand the team's value, identify the root causes of problems, propose better solutions that address the real issues, and persuade the team leader, colleagues, and business clients.

The responsibility of support teams is the much-talked-about "efficiency improvement", which is also the "instinct" of most software engineers.

However, what many people may not realize is that the pride of "efficiency improvement" can sometimes become a "sword" that takes away others' jobs, making you an "accomplice". More ironically, you might be one of those whose jobs are taken away, effectively committing "career suicide".

The logic behind this is that increased efficiency leads to higher productivity. If the organization's overall revenue does not grow accordingly, that is, if the business teams are not strong enough, there will be a surplus of labor, increasing the organization's operating costs. To survive, the organization will try to cut costs, often through layoffs.

Front-end Lead

Some might naively think that becoming a front-end lead means a worry-free life... I won't deny that this can happen, but more likely—

You will continue to do front-line development work, that is, fulfill the responsibilities of a front-end engineer in a typical business team, while also handling team management and project management tasks.

Dealing with your own department's affairs is one thing, but when it comes to cross-departmental collaboration, the division of responsibilities and resource coordination can be quite troublesome.

Due to organizational restructuring and personnel changes, the phenomenon of buck-passing occurs frequently. Finding someone to consult can be
a long and winding road, and sometimes you may not get an answer at all.

When you or your subordinates encounter uncooperative counterparts, you have to communicate with their leader or ask your superior to talk to their superior's superior. This kind of situation can happen even within the same department.

As a front-end lead in a business team, according to common thinking, you should understand the business better than other front-end engineers, right? But the question is, how do you truly understand the business?

To really understand the business, you must first be interested in that field, right? How can you truly understand something you are not interested in? I am in awe of those who dislike math but still get high scores.

Do those who claim to understand the business really understand it?? Can they identify problems in the current product architecture and business model and propose improvement plans??

As a front-end lead in a business team, according to common thinking, you should be better at management than other front-end engineers, right? But the question is, how do you manage well?

What is "management"? Is it waving the power you hold to force compliance? Or using various tricks and means to paint a big picture to lure and manipulate them?

Those who hold such thoughts and act accordingly do not understand "management", let alone human nature. True "management" is about creating a comfortable environment to inspire others' proactivity, helping them achieve themselves and, in turn, the team—

The ideal management should be able to inspire the enthusiasm of subordinates, evoke a sense of mission and achievement, and make them feel that work is not just a means of survival and livelihood, but also a way of self-fulfillment, ultimately achieving self-motivation, self-organization, and self-management; the ideal organizational form is a decentralized or weakly centralized organization based on a common vision.

Ourai Human Factors in Software Production Part 2

First, understand what "management" really is, and then think about how to best express the profound meaning of that term—it is actually a sociological issue.

To be honest, this middle role, with a similar job level and salary to others, is likely to end up pleasing neither the superiors nor the subordinates—taking the blame from the higher-ups while being criticized by the subordinates for being arrogant and unapproachable, swallowing the委屈in tears.

Transition to Product Roles

When considering a transition to product roles, it implies a strong interest in the team's business domain, although you may not fully understand it yet. If you are not interested, there is little hope of truly understanding it, no matter how much you study.

Transitioning to product roles does not necessarily mean becoming a product manager. Business line leaders, architects, and other roles that require a deep understanding of the business are also suitable for front-end engineers to transition into.

However, the path is not without obstacles. It is not only necessary to acquire a lot of missing knowledge and improve cognitive abilities and ways of thinking, but the "vision" or "consensus" may become the biggest barrier.

When you have strong opinions on the positioning, functions, and form of the product, even though the business domain and team are the same, your positioning and goals may differ.

What should you do then? Convince the team leader? Not likely. Give in? Not only will you feel frustrated and upset, but you will also return to the original question—where is the value of what you are doing?

Summary

Many articles discuss the career development and growth of front-end engineers from a positive and optimistic perspective. Like human society, which tends to promote good and positive things, it makes people suck on the "pacifier" of "comfort" and "happiness", thus forgetting the dangers around them.

This article attempts to explore the potential issues, dilemmas, and contradictions that front-end engineers may face in their career development and growth from a negative and pessimistic direction, in an effort to raise awareness of the potential crises.

I have not provided "survival strategies" as the title might suggest, but rather pointed out "survival issues", hoping that everyone will find their own "survival strategies" that suit them.

Top comments (0)