I’ve always been very curious about the topic of “engineer team,”
I often ask my friends:
“How is this at your company?”
This article is my own thinking on this topic.

pic

Introduction

In the previous article 《Positive-Side Thinking》 I mentioned,
recent writings have leaned more toward “the Tao.”
Although this article’s title is “How to Build an Engineer Team,”
what it talks about is basically subjective thoughts,
or without considering title length,
a more appropriate title might be:
《We Still Don’t Know What Kind of Engineer Team Su Ziyue Was Fantasizing About in His Mind That Day》.

The main views involved may include the following:

I originally wanted to use single words to summarize the titles here (like my old expository writing),
but thinking about it, alarmism and crazy talk seem more Drama.
Then let’s tweak Zhang Mei’s 《Writing to Future You》 to lead into the main text:

Learn to appreciate the genuine,
see the genuine under layers of masks.

The standards of worldly smoothness are many,
but the outstanding are extremely few.
And often the outstanding is hidden under base wildness.

Self

Whether building a team,
or pursuing a career,
a person must always first be themselves,
ancient people called this “self-cultivation,”
foreigners also have a movie called《The Shawshank Redemption》(self-cultivator’s redemption) which is about this.

Positioning

Work like a game’s lead programmer

If you’re a leader in a tech team of about ten people,
what kind of positioning do you hope for yourself?
I’d hope I’m like a game’s lead programmer.
I’ve had this thought since college.
(The goal of this sentence is to clarify I’m not trying to ride Crab Tech’s hype)

What does a game’s lead programmer do?
Uh, actually I don’t know.
But Gu Yu on Zhihu in 《What makes a good lead programmer》 said it well:

The most common related qualities of a lead programmer include:
solid professional ability, good communication effectiveness, high management efficiency, skilled at goal breakdown.

The lead programmer also leveled up from being a small programmer,
he needs to solve helping all stakeholders reach consensus,
keeping noise as small as possible on the path of everyone pursuing goals with one heart.
As long as needed, the lead programmer can also be everyone’s safety net,
the team’s dumpster will first land on his head,
hard-to-tune Bugs will ultimately also land on his head.
With great power comes great responsibility, this is the same reasoning.

Doing it this way,
business can advance without hindrance,
tech has no worries.
The only thing that counts as a drawback,
is probably becoming a lead programmer requires not only effort,
but also constant vigilance to think more.

In the yellow wood there were two paths,
regretfully I can’t have them all.
I chose the one less traveled,
it changed my whole life.

Approach

Trust often creates beautiful realms

I’ve actually always paid attention to subculture circles.
(This topic is also one I’ve long wanted to write an article about)
If people and organizations are society’s cells and organs,
then subculture is like society’s pulse:
constantly changing, yet incomparably accurately reflecting society’s heart rate.

In today’s subcultures,
“hegemony” is mostly in negative contexts,
while “sang” (despondency) mostly bears positive emotional release.
With the deconstruction of language and culture,
more and more people maintain safe distance in interacting with others,
not easily trusting others, nor trying their utmost.

Sounds like the “prisoner’s dilemma,” right?
In the variant experiment of “repeated prisoner’s dilemma”,
the best strategy is very simple:
“Trust by default at the start, tit-for-tat afterward.”

Just like superhero movies portray,
if everyone in a team fights alone they’re easily picked off one by one.
The way to achieve final victory,
is everyone trusting each other, and using “Watch My Back”-style declarations to reach goals.

Starting with trusting others yourself,
often creates beautiful team trust.

Mindset

Always hold a beginner’s empty-cup mindset

The original reason for being designated “lead programmer,”
is often this fellow writes code fast and hard,
brothers all submit to him,
so the organization studies and decides,
he gets one more task of “leading everyone to charge.”

Engineer teams’ Tech Leaders are often the “brothers follow me and charge” type,
people from the frontline easily have the impulse “if I can do it I’ll do it.”
(In fact I often do too…)
But actually this isn’t scientific.

If all problems are solved by the lead programmer,
then the lead programmer’s level is the team’s ceiling.
If hard rules are written,
then the chess strength of a Go robot can only reach as high as the programmer who wrote it,
only practical combat and feedback can train the “machine-learning” AlphaGo.

Same for teams,
always hold a beginner’s empty-cup mindset,
as if you yourself are the most inadequate.
After all, if even you yourself are the most inadequate this way, how strong must the team be!

Team

Last year I rarely finished a whole anime series,
called 《Middle Management Record: Tonegawa》,
the genre being the rare workplace comedy.
This anime sideways and at-angles revealed several crooked characters:
when meeting mountains build paths, meeting rivers build bridges. (fog

Atmosphere

The three “gongs” of “four generations, three gongs” refer to fairness, justice, and openness

Let me interrupt and explain to prevent anyone from taking my fabricated sentence above seriously.
“Four generations, three gongs” refers to Yuan Shao being born of a famous family, of noble status,
his four generations of ancestors above were all “san gong”: Grand Marshal, Grand Educator, Grand Constructor (in short, very impressive)

Building a team, besides doing yourself well,
determining the team’s atmosphere is a very important matter.
Long-term, the team’s atmosphere will determine the efficiency and effectiveness of getting things done,
will affect new people’s integration, docking with other teams;
short-term, you’ll play the lead programmer role in such a team.
So the team’s atmosphere must be what you think is correct.

Fairness, justice, openness are what I think is correct.

Fairness means equal opportunity.
Everyone has the same opportunity, the same space to complete their goals.
Justice means rights and responsibilities balanced.
Because everyone has different strengths, the tasks borne and expected outputs are also different.
Openness means information transparency.
Everyone can obtain timely, accurate information, no consensus will be affected by internal information transmission, further affecting the advancement of things.

Actually engineers have very low requirements on this point,
when distributing the dumpster, clearly explain what it is, why,
how to do it leave to us to decide,
ultimately engineers will choose suitable tech and division-of-labor solutions to complete it.

Sounds like,
this reasoning also applies to
“how girlfriends should boss boyfriends to do work.”

Process

Use tools to practice automation

This reed-like human not only thinks,
but also uses tools.
Engineers all the more,
just like in 《Engineer Culture》:
one item of engineer culture is solving problems with tools.

Set aside team tools for now,
the excellent engineers I’ve seen all have one unified characteristic:
skilled at using tools, even inventing tools themselves.

“Programmers are all lazy,
but some laziness is once-and-for-all.
He’ll write a code script that automatically makes coffee,
then every day no longer needs to press that damned button by hand.”

Engineer teams equally need tools to automate various processes.
From the most basic automated code checks,
to automated continuous integration, automated monitoring,
even automated task distribution, automated communication.
Each automation here can save corresponding manpower,
or from the financial angle: “improve people-efficiency.”

In my ideal engineer team,
there’s also this group of engineers,
whose task is making good-to-use tools for other engineers.
Maybe there’ll be 2-3 fewer programmers on the frontline business,
but the whole team’s total productivity can be greatly improved.

Rights and Responsibilities

My dad is Liu Bei: delegation

This line is from the “Three Kingdoms Kill” game’s “Liu Chan” line,
conveying a sense of ordinariness from being born to a normal family.

Like discussed in the earlier four-generations-three-gongs,
justice means rights-responsibility balance,
this point is also a very important link in engineers’ cognition.
Whether it’s Youzan’s annual meeting declarations or Logic Thinking’s open letter,
I think they’re all helpless moves on the rights-responsibility issue:
because they couldn’t become a team with balanced rights and responsibilities,
that’s why they have to promote this reasoning.

Justice (rights and responsibilities) in four-generations-three-gongs is worth singling out,
because in my cognition, justice is harder to execute than fairness,
but sometimes more correct.
Let me give an example.

Like a team has to evaluate performance once each quarter,
then the organization mandates,
every team’s performance has to be ranked,
there’s always one person who must eat 0 points.

What’s the (seemingly) fair way? Take turns.
Everyone harmoniously takes turns eating 0,
this time I eat the egg, next time your house.
What’s the just way? By performance.
Under the statistical data closest to facts,
the worst eats 0 points.
What if it’s always the worst?
Then keep eating 0 points.
Of course, if the whole team’s business collapsed, all eat 0, or disband.

Under just conditions, delegating to every person is a way to do things well.
The tech stack I chose, I do the later refactoring too.
The infrastructure I built, if not good-to-use I fix.
The process I wrote, stably held high concurrency over Chinese New Year, without even triggering on-call, I’m awesome.
Freedom triggers autonomy, autonomy brings pride.

Once chatting with a good friend at Pinduoduo,
he said the thing he loved most about the startup feel was:
“After going over requirements with the product manager,
I said three days to finish.
Then snap, in a day tested and launched,
I felt I’m just too awesome.”

Culture

If you’ve noticed,
many organizations or teams not only have culture,
but also concrete symbols of culture.
Team culture is the team’s soul,
the team’s soul is determined by the team’s leader.

Elite

20% of programmers write 80% of the code.

—— 《The 80/20 Rule of Programmers》

Although programmers like to compare themselves to “code farmers,” “code laborers,”
the job title is also called “engineer,”
what’s learned in college is also called “software engineering.”

But actually coding shares the same characteristic as all mental labor:
the output difference between people is exponential.

The poet Li Bai’s poems are sung more than ten thousand low-tier poets combined;
philosopher Marx’s thoughts influenced the entire historical process;
linguist Liu Bannong’s creation of the character “她” (she) spawned love letters across thousands of li;
give a top programmer a needle, they can carve a full 4GB CD (meme).

Without cross-comparison,
even one person’s output can differ vastly.
A programmer works 8 hours a day,
maybe in his most focused 2 hours he finishes a whole day’s features,
the other time he’s just writing new bugs into it,
then trying hard to find and fix them.

So a culture pursuing ultimate productivity,
will definitely put elevating elite engineers’ output,
raising engineers’ effective work proportion in an important position.

For example Google’s “notorious” 20% rule,
the official version is each engineer only allocates 80% time on work,
the remaining 20% on side projects they’re interested in.
But actually this instead sparked engineers’ enthusiasm,
making some put 120% time on business.
In the end most 20% projects may not produce effects,
but the few 20% projects and the cultural enthusiasm contagion they brought have very great value.

Striving

Think about problems from the positive side.

After finishing the topic of elite,
it’s easy to think of the pyramid model,
and then there’s a question:
“Then if a small portion of engineers do most of the output,
what about the rest of the engineers? Layoffs?”

This question is interesting.

My thought is when a team is being built,
it goes through a constant-standard talent filtering mechanism.
Under this background, from an individual angle,
me as a person with low output proportion in the team,
I’m also very desperate…
Like our company has a frontend,
he not only does business fast and fierce,
he also has many ideas on tech issues,
can pull out a demo in a snap.
Guess what I, who can only look up at him, would think?

That’s right, I’d hope to also work hard to become this excellent.

Good culture not only catalyzes top talent’s output,
but also lets potential, hardworking excellent talent evolve into top talent.
After ten years twenty years some founding members carry the company’s operation,
those who’ve left also scatter to different companies,
all doing core things like lead programmers.
What’s called gather as a flame, scatter as full-sky stars.

Relying on processes, evaluations, regulations to improve the team’s statistical productivity,
isn’t a way to solve problems from the positive side.
Building a striving culture,
will let everyone know flowing east definitely flows into the sea,
this is the way to fundamentally solve problems.
From the team’s angle,
everyone’s overall productivity is higher,
things are easier to do;
from the individual’s angle,
personal fate is combined with the company’s process,
returns are very promising.

Vision

Find balance between farming and rushing units

Strategy choice in strategy games,
often dynamically swings between two directions:

  • Farming. Your economy and tech will be better, more advantageous for long-term development, but easy to get rushed down short-term.
  • Rushing units. Your combat strength is stronger, short-term combat will definitely win, but long-term very weak.

What engineer teams do essentially is these two aspects:

  • Optimize tech infrastructure.
    All your statistical indicators are good, can also support large traffic.
    But occupied too much business development time, you don’t have large traffic.
  • Implement business requirements.
    Your business requirements get done fast, user feedback quick, they’re very happy.
    But tech debt is growing, even you haven’t done security protection, you’ll crash on first DDOS.

These two things have you in me, me in you, are dynamically balanced.
Either not doing infrastructure, or “all is lowly only infrastructure is high,”
neither is a good situation,
engineer team culture needs to avoid going to either extreme.

The ideal distance is the “just right” of being in love,
business requirements won’t squeeze out tech infrastructure because of timeline,
tech infrastructure also won’t abandon business requirements for wanting to practice dragon-slaying skills.
Both sides modestly polite, both saying “you go first” and yielding their own position…

No, wake up, this situation won’t happen.
Unless career development stalls (company’s about to die),
in the situation of rapid career progression,
business requirements always endlessly emerge,
this is when the balance point turns into “improvise based on situation” in strategy game guides.
In the end, the team will form a self-adjusting culture,
to achieve high-quality high-efficiency business requirements,
and prepare sufficiently solid infrastructure in advance :)

The feeling of living in a dream is a bit real.

Other

Overall,
the individual, team, culture above are my understanding of engineer teams from different angles.
But actually understanding of “the Tao” is often complex,
especially evaluating team building all relies on posterior perception.

But overall, I really like our current team :)
And we’ve forcibly reached consensus:
do the right thing, no matter how hard the thing is.

The following are some possibly related,
but I don’t know how to abstract them,
just listed at the end as the tail of some essay.

Vague vs Concrete

Recently a line has gotten a second spring because of the New Oriental annual meeting parody song:

Those who write PPTs aren’t as good as those who present them, those who present aren’t as good as those who listen.

Mia got promoted to Manager last year,
also sighs to me from time to time,
she feels in current work,
the vague portion suddenly increased a lot,
feels she has to work harder.

This is very scientific.

People fighting alone actually don’t need much thinking,
just relying on intuition to act is fine.
But the squad captain,
needs reasons whether dignified or heart-to-heart to convince squad members.
Companies at Alibaba’s level even more need company culture, values to maintain organizational unity.

And as the embodied representative of organizational culture,
will get the feeling of “the higher up, the more vague.”
Possibly when you become the leader of an entire company,
you must ensure your cognition is reusable, can be promoted,
thus you have to be even more vague, even more,
ultimately becoming the company’s mascot,
then the company achieves great success!

Work System

Working 9am to 9pm, six days a week, is it really good?

The direct way to ask: Do you accept 996?

Although I can use many arguments to embellish,
actually my core thought is one line:
I cannot accept forced 996,
but I am a person who will voluntarily 996 work.
Specific thoughts I won’t elaborate too much on (now it’s 4am, I’m a bit sleepy)

I think the enterprise choosing 996 work system is actually like humans liking to drink alcohol,
a natural result of sufficiently competitive market environment.
The currently existing problem is the whole work system has malicious competition,
causing possibility of damaging social labor atmosphere.
Can add things like “additional work medical insurance requirements” and “old-age employee work-hour compensation” for system optimization.

Overtime is fine, normalized is not.
Voluntary is fine, forced is not.
Healthy is fine, dying is not.

Recruitment

The sentence quoted in the outline is a Hungarian web article from 7-8 years ago,
when I read it I thought it was fun,
the first time viewing employees from an enterprise/capital perspective.

Recruitment is a very headache-inducing problem.

Especially mentioned in the article above,
my cognition set up a Flag for myself:
“I only want to hire excellent people.”

When I wrote 《HR Hates Tech People Like Us》 two years ago,
our hiring standard summed up in one sentence was
“hoping candidates fit the role (worked on Python internet backend development),
and also hoping candidates are excellent (have potential to be lead programmer in projects)”

At the time the recruitment season HR went through every Python resume in Shanghai,
we gave only 2% final offer rate,
so HR hammered our dog heads,
and warned us: “Shanghai’s Python candidate pool is busted, you guys think about what to do.”

So (besides introducing Java tech stack) we thought about the “fit + excellent” standard,
removed the “fit” requirement,
only wanting to hire “excellent (have potential to be lead programmer in projects)” talent.

This plan worked very effectively,
the teammates we newly added last year are all very reliable.
This also validated the earlier thinking about engineer team culture,
scientific.

Performance

Programmer is a hot industry today,
hot industry salary is equally a hot topic.
(Just like worker compensation during the Industrial Revolution)

As a curious baby,
I’ve also talked about details of this topic many times in 《A Meaningful Bullshitting Session》,
《Training Three Months, Monthly Income Over 10k?》,
《Company Culture, Salary and Stock Options, Dev Experience》.

From a higher cognitive angle,
I confirmed and firmed up my view since graduation:

As long as you maintain yearly progress,
a person’s life will be exponentially rising.
Your current achievement,
is just a star among the stars in your achievement ten years from now.

Just like Dantès gave Maximilien at the end “wait and hope.”
My friend, as an engineer I want to give you two words,
they’re full of inner philosophy of “recursion,” “compound interest,” and even “universe expansion”:
think, persist.

(Full article end)