Ooh, ooh. Look at the picture that I snapped whilst on vacation. Expectedly, the sign “protected” the first parking spot next to the restaurant entrance. I’d speculate that it’s a great place to work, wouldn’t you?
Much has been written about the differences between, and similarities across, management and leadership. But unsurprisingly, most managers equate the word “manager” with the word “leader” by default. After all, they’ve been appointed by other “leaders“. Thus, by (their) definition, managers are leaders.
On the other hand, most raw employees equate the word “manager” with “manager” by default. Err, on second thought, since (as usual) he has no supporting “data“, this BD00 post is prolly full of BS00:
Our old arrogant, egotistical nature (continuously) seeks out sustaining agreement with itself and its distorted opinions. – William Samuel
The title of this post sounds like the stodgy name of some inhumane, BS, corpo process under which “supervisors” evaluate their children, I mean, induhvidual contributors. But wait! It’s the Valve way.
You don’t know who Valve is? Valve is a company that creates massive, multi-player, online games. According to “economist-in-residence“, Yanis Varoufakis, Valve rakes in $1B in revenue even though they have a measly 300 employees. Also, according to Yanis (and their employee handbook), they are totally flat chested. There’s not a single boob, oops, I mean “boss“, in the entire community. D’oh!
The employee handbook spells out the details of the “Stacked Ranking” process, but in summary, peers rate each other once a year according to these four, equally-weighted metrics:
Skill Level/Technical Ability
Notice that there’s no long list of patriarchical, corpo-BS ditties like these in the four simple Valve metrics:
- Takes initiative and is a self-starter
- Knows how to acquire resources when needed
- Manages time well
- Knows how to prioritize tasks
- Yada, yada, yada
As you might guess, the stack rankings are used for salary adjustment:
…stack ranking is done in order to gain insight into who’s providing the most value at the company and to thereby adjust each person’s compensation to be commensurate with his or her actual value. Valve pays people very well compared to industry norms. Our profitability per employee is higher than that of Google or Amazon or Microsoft, and we believe strongly that the right thing to do in that case is to put a maximum amount of money back into each employee’s pocket. Valve does not win if you’re paid less than the value you create. Over time, compensation gets adjusted to fit an employee’s internal peer-driven valuation. - The Valve Employee Handbook
Whenever I serendipitously discover jewels in the rough like Valve, SAS Institute, HCL Technologies, Semco, Zappos.com, etc, I always ask myself why they’re rare exceptions to the herd of standard, cookie-cutter corpricracies that dominate the business world. The best answer I can conjure up is this Ackoff-ism:
The only thing harder than starting something new is stopping something old. – Russ Ackoff
But it’s prolly something more pragmatic than that. Since corpo profits seem to keep rising, there is no burning need to change anything, let alone blow up the org and re-design it from scratch to be both socially and financially successful. That would be like asking the king to willingly give up the keys to his kingdom.
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.
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.
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
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.
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.