Archive
“T”, “Hyphen”, And “I” People
In this:
the company talks about “T” people:
We value “T-shaped” people. That is, people who are both generalists (highly skilled at a broad set of valuable things—the top of the T) and also experts (among the best in their field within a narrow discipline—the vertical leg of the T). We often have to pass on people who are very strong generalists without expertise, or vice versa. An expert who is too narrow has difficulty collaborating. A generalist who doesn’t go deep enough in a single area ends up on the margins, not really contributing as an individual.
That’s too bad for the typical borg. These beasts actively recruit and develop horizontal “hypen” (mgrs, execs) people and vertical “I” (induhvidual contributors) people. Of course, the stewards of these dinosaurs get what they wish for. On top of that, anybody who tries to self-improve towards a “T” person is silently ignored. It would screw up the nice and tidy employee-in-a-box process of emasculation.
Come To Papa!
I recently listened to a fascinating podcast interview of Valve Inc‘s “economist-in-residence“, Yanis Varoufakis. According to Yanis, the company is still organizationally flat after 17 years of existence.
The thought early on at Valve was that the maximum limit to flatness would be around 50-60 people. Above that, in order to keep the wheels from falling off, some form of hierarchy would be required for concerted coordination. However, currently at 300+ employees, Valve has managed to blow through that artificial barrier and remain flat. Mind you, this is not a company solely made up of like-thinking engineers. There are also artists, animators, writers, and accountants running around like a herd of cats inefficiently doing the shit that brings in $1B in revenue each year.
According to Yanis, in order to maintain their egalitarian culture, Valve can’t afford to grow too quickly. That’s because they have to deprogram people who are hired in from hierarchical borgs as former bosses who expect others to work for them, and former workers who expect to be “directed” by a boss. If Valve didn’t do this, their culture would get eaten alive by the pervasive and mighty command-and-control mindset. The spontaneity, creativity, and togetherness that power their revenue machine would be lost forever.
Nevertheless, Valve is pragmatic with respect to hierarchy:
“Valve is not averse to all organizational structure—it crops up in many forms all the time, temporarily. But problems show up when hierarchy or codified divisions of labor either haven’t been created by the group’s members or when those structures persist for long periods of time. We believe those structures inevitably begin to serve their own needs rather than those of Valve’s customers. The hierarchy will begin to reinforce its own structure by hiring people who fit its shape, adding people to fill subordinate support roles. Its members are also incented to engage in rent-seeking behaviors that take advantage of the power structure rather than focusing on simply delivering value to customers.” – The Valve employee handbook
Whether Valve knows it or not, their success is due to their respect of some of Gall’s system laws:
- Systems develop goals of their own as soon as they come into existence – and intra-system goals come first.
- Loose systems last longer and work better. Efficient systems are dangerous to themselves and others.
Billiard Balls
The top-down organizational chart became the blueprint for the mechanistic organizational model, lining people up like billiard balls to ostensibly create a predictable chain of reactions. – Tom Coens & Mary Jenkins
A Big Fat Waste Of Time
Having recently finished the above two heretical books on the undiscussable joke that is “the Annual Performance Review“, I coincidentally stumbled upon this recent FastCompany.com article: “Why Year-End Reviews Are A Big Fat Waste Of Time”.
Alas, even though author Denis Wilson plants some decent advice for managers in the blarticle, it still reeks of a slight “tweak” to the notoriously bad, but eerily unopposed, APR practice.
After posting the link to the blarticle on Twitter, I had this interesting exchange with Adam Yuret:
Upon reflection on why such a horrendously demeaning practice like the APR still exists in the 21st century, BD00 has come to the conclusion that the guild of management collectively thinks:
- The APR actually “works” or,
- They know it doesn’t work but they have no motivation to attempt such a big and scary change to the org, or
- They know it doesn’t work but they have no motivation to explore alternatives for achieving what the APR is actually supposed to do.
So, How Do You Know?
In the software development industry, going too slow can result in nothing getting done in an “acceptable” amount of time and thus, impatient managers cancelling projects. On the other hand, going too fast can result in hackneyed designs, halted downstream progress due to lots of rework on an unmanageable code base, and thus, frustrated managers cancelling projects.
As the figure below shows, the irony is that going too slow can result in less sunk cost due to earlier cancellation than going too fast – which gives a false illusion of great progress till the fit hits the shan.
So, how do you “objectively” know if you’re going too fast or too slow? It’s simple: you freakin’ don’t. However, in a world increasingly dominated by “agile” indoctrination, faster seems to be always equated with better and the tortoise vs. hare parable is heresy.
I-Speak
I don’t know where I read it, but I remember someone giving great advice about using “I-Speak” to present your case on a sensitive issue. Don’t go blasting away and saying stuff like “everyone thinks the system is a freakin’ disaster“. Instead, say “I have a hard time using the system as it’s designed“.
In really uptight and unresponsive groups, preface your concern with “I can only speak for myself, but…“. But don’t forget, in zero tolerance bureaucracies, keep your “I” trap totally shut tight and keep toiling along in quiet desperation.
Underlying Assumptions
The underlying assumptions harbored by executive decision-makers drive an org’s processes/policies. And those processes/policies influence an org’s social and financial performance. As a rule, assumptions based on Theory X thinking lead to mediocre performance and those based on Theory Y lead to stellar performance. Most org processes/policies (e.g. the annual “objective” performance appraisal ritual) are Theory X based constrictions cloaked in Theory Y rhetoric – regardless of what is espoused.
Preventers, Not Managers
The worst companies directly contribute to the physical and emotional deterioration of their DICforces by unceasingly imposing ridiculous schedules and ratcheting up the (unspoken) pressure to work massive amounts of unpaid overtime for long stretches of time. Average companies do the same under the tired old mantra of “it’s a hostile business environment“, but they take good care of their DICsters after much damage is done. The best of the breed are highly self-aware systems that actively practice “crisis prevention” – not “crisis management“. They diligently monitor the “system’s” vital signs and know when things are getting too toxic for their people. Unlike the worst and the average, the best actually take effective action to relieve the stress on their people before the wreckage accumulates. They’ll sacrifice some almighty dollars by relaxing schedules, or giving some extra days off, or frequently providing small tokens of appreciation to counter the toxicity of the operational environment. They are preventers, not managers.
Wouldn’t it be kool if the role of “manager” was jettisoned in favor of “preventer“? If anything, it would at least drive home what those in charge of others should really be doing – preventing, not managing.
The Yearning For Autonomy
Since they generally increase operating costs, trigger “it’s not my job” myopia, and encourage us-vs-them friction, I’m not a fan of unions. Nevertheless, I found this article on TechCrunch.com amusingly interesting: “Want To Unionize Developers? Focus On Workplace Democracy”. This passage caught my eye and triggered a chuckle:
Developers want autonomy. They don’t want to be jerked around by stupid managers who impose unrealistic deadlines, make impossible promises to clients and just generally disrespect their employees. Historically developers have had two options for dealing with bad management: find a better job or found a startup. But worker self-management would offer a third options — give the developers control over their own work.
Alas, those managers that are stupid don’t know they’re stupid and those employees who are disrespected don’t know they’re disrespected. Between: 1) these two BD00 made-up facts; 2) management’s fear of loss of control and stature; 3) the declining reputation of unionization over the years – don’t expect the idea of software developer unions to take hold soon; if ever.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 