Choose Strong
For Tim.
The next Monday after Agile training, I joined L and three others
including an Indian, a Thai, and a native (born in US), at lunch. The
subject came up naturally and it turned out that I missed or simply
forgot one important lesson. To the question "How do we work with
colleagues across time zones under Agile", Bob replied with a vehement
"Don't!" and spent the next half hour bashing the Follow-The-Sun idea.
Sitting in the front, our CTO, who championed out-sourcing to India,
must have been kicking himself for inviting the fellow.
The Indian guy then told us about how Chennai managers pushed their
teams hard and engineers there preferred White to Indian bosses. I
understood from firsthand experience. Tough bugs were pushed their way
and the poor guys often had to attend meetings passing 12:00am their
time, especially before a release.
My co-workers at lunch saw eye-to-eye with me on our code-review
practice. Once a piece of code is ready, at least two engineers,
theoretically, have to eyeball it. Any can give a "+1" vote to accept
the work but only a few can give a "+2" necessary to merge in the code
base. The idea was to give more experienced programmers the final say.
This double-checking sounded thoughtful and rigorous but it turned out
that +2-voting served more to divide people than to ensure quality.
It created a group more equal than others and some +2 folks
tried to assert their positions in the pecking order by wielding their
votes. As one submitted her work, she had to approach a +2 guy as if
asking for a favor. The latter had the option to treat her high-handedly
if that pleased him.
I have since learnt not to ask for reviews. After submitting code, I
would act as if nothing happened. When the manager or team lead got
around to ask about the task assigned to me because some dog higher on
the corporate ladder was kicking their butts, I would tell them the code
was ready. It would be their job to get the votes and that would have
nothing to do with me anymore.
In reality, nobody tried hard to vet others' code. Under this power
structure, reviewing was a mere ritual with no liability attached. +2s
were readily granted to members of the mini-tribe and selectively
withheld from those rejecting the order. No one would've guessed but the
practice had created distinct bands of engineers, discouraged innovation
and destroyed morale.
The root of the problem seems to be our tribal origins. The Indians grow
up in the caste system and know all about power-struggle and fear for
survival but next to nothing about treating people as equals. And some
have brought the rules of that land to the US. Threat is a major weapon
in some managers' arsenal which is very effective on people of similar
backgrounds.
Chinese immigrants face similar challenges. Many come for the famed
American (material) Dream but refuse to learn how to navigate the land
of the free. As practiced in the old tribal society, we can never bring
ourselves to treat each other as humans with similar needs and equal
rights. Our deep-rooted strict hierachical views limit the appeal of our
stories no matter how much we achieve or sacrifice.
> > high-handedly: 高抬貴手?
No. It means "Using power or authority without proper consideration for the feelings or rights of others."
There sure IS such a thing as corporate culture and there are sub-cultures. As IT-workers, we often see tribal cultures because so many of us are from tribal societies.