Archive
Schmuckers?
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?
Spoken But Unwritten
Because they may be called to account for their hypocritical behavior, you may find people in authority saying things like these, but you most likely won’t find them written into the Employee Handbook:
“Providing the freedom to fail is an important trait of the company— we couldn’t expect so much of individuals if we also penalized people for errors. Even expensive mistakes, or ones which result in a very public failure, are genuinely looked at as opportunities to learn. We can always repair the mistake or make up for it.”
“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.”
“…for the most part working overtime for extended periods indicates a fundamental failure in planning or communication. If this happens at Valve, it’s a sign that something needs to be reevaluated and corrected. If you’re looking around wondering why people aren’t in “crunch mode,” the answer’s pretty simple. The thing we work hardest at is hiring good people, so we want them to stick around and have a good balance between work and family and the rest of the important stuff in life.”
“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.
“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
Under Or Over?
In general, humans suck at estimating. In specific, (without historical data,) software engineers suck at estimating both the size and effort to build a product – a double whammy. Thus, the bard is wrong. The real thought worth pondering is:
To underestimate or overestimate, that is the question.
In “Software Estimation: Demystifying the Black Art“, Steve McConnell boldly answers the question with this graph:
As you can see, the fiscal penalty for underestimation rockets out of control much quicker than the penalty for overestimation. In summary, once a project gets into “late” status, project teams engage in numerous activities that they don’t need to engage in if they overestimated the effort: more status meetings with execs, apologies, triaging of requirements, fixing bugs from quick-dirty workarounds implemented under schedule duress, postponing demos, pulling out of trade shows, more casual overtime, etc.
So, now that the under/over question has been settled, what question should follow? How about this scintillating selection:
Why do so many orgs shoot themselves in the foot by perpetuating a culture where underestimation is the norm and disappointing schedule/cost performance reigns supreme?
Of course, BD00 has an answer for it (cuz he’s got an answer for everything):
Via the x-ray power of POSIWID, it’s simply what hierarchical command and control social orgs do; and you can’t ask such an org to be what it ain’t.
The Accumulation Of Rules
According to that dumbass BD00, in any given level in an institutional hierarsy, the number of internal org rules a member of that level is required to follow is a function of the number of levels above. Each level makes some rules for the levels below. Relatively speaking, the dudes in the head shed have to follow zero rules and they concoct the “high level” rules for the levels below them.
As one travels down a dysfunctional hierarsy, the number of rules to be obeyed is cumulative. By the time you’re down in the bilge room, the number of written and (especially) unwritten rules to follow is essentially infinite. The irony is that while the unfettered infallibles at the top keep piling on the handcuffs, they’re also simultaneously professing their love for empowerment, taking-initiative, dedication, trust, loyalty, yada-yada-yada.
T’is what it is, just another paycheck-for-repression tradeoff. You can’t have your cake and eat it too, so suck it up soldier!
It’s The Relationships, Stupid
If you read Sam Culbert’s book rant against the taken-for-granted and unassailable “annual performance review” process, you’d think he is an anti-hierarchy revolutionary deserving to be crushed. But the dude is not:
Hierarchical structure, in the form of an organization chart, serves many constructive purposes. By showing the chain of command, it allows everyone to see who is responsible for what, how organization units are being deployed, and, most importantly, who should be accountable for bottom-line results. In contrast, I can’t think of a single constructive purpose served by hierarchical relationships— that is, those in which the boss gets to dominate all conversations.
Culbert, Samuel A. (2010-04-01). Get Rid of the Performance Review!: How Companies Can Stop Intimidating, Start Managing–and Focus on What Really Matters (Business Plus) (pp. 128-129). Hachette Book Group. Kindle Edition. – Sam Culbert
In a man-made conceptual hierarchical breakdown of a tree’s “parts“, the relationships between the parts have nothing to do whatsoever with their “position” in the hierarchy. A tree’s components miraculously work together in synchronous harmony to manifest and share its beauty as a whole with all of nature – including us (perhaps undeserving) humans. Leaves aren’t pitted against leaves for the purpose of gaining more hierarchical status in the “minds” of the other tree parts. The trunk doesn’t perceive itself as “more important and deserving” than the “lowly” branches. The roots don’t talk about the topmost branches in a derogatory manner, nor vice versa.
Related articles
- He Said, He Thought, He Said, He Thought (bulldozer00.com)
Industry Best Practice
When we got the idea for this book, we expected to surely find dozens of other books with the same theme… To our surprise, however, we found no other books devoted to abolishing (the annual performance) appraisal and exploring fresh approaches to the functions of appraisal. – Coens/Jenkins (Abolishing Performance Appraisals)
Since the thought of replacing the sacred “annual performance review” is so shockingly unthinkable, any proposed alternative doesn’t have a snowball’s chance in hell of being embraced. The undiscussability of this “industry best practice” is so palpable, that not many souls even make an attempt to concoct any alternatives, let alone expose them for scrutiny. Alas, such is the power of entrenched 20th century management thinking to keep the status quo on corpo-social issues that really matter, in-situ.
Related articles
- Behind One’s Back (bulldozer00.com)
- He Said, He Thought, He Said, He Thought (bulldozer00.com)
Scrum And Non-Scrum Interfaces
According to the short and sweet Schwaber/Sutherland Scrum Guide, a Scrum team is comprised of three, and only three, simple roles: the Product Owner, the Scrum Master, and the Developers. One way of “interfacing” a flat and collaborative Scrum team to the rest of a traditional hierarchical organization is shown below. The fewer and thinner the connections, the less impedance mismatch and the greater the chances of efficient success.
Regarding an ensemble of Scrum Developers, the guide states:
Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.
I think (but am not sure) that the unambiguous “no exceptions” clause is intended to facilitate consensus-based decision-making and preclude traditional “titled” roles from making all of the important decisions.
So, what if your conservative org is willing to give Scrum an honest, spirited, try but it requires the traditional role of “lead(s)” on teams? If so, then from a pedantic point of view, the model below violates the “no exceptions” rule, no? But does it really matter? Should Scrum be rigidly followed to the letter of the law? If so, doesn”t that demand go against the grain of the agile philosophy? When does Scrum become “Scrum-but“, and who decides?
Related articles
- The Scrum Sprint Planning Meeting (bulldozer00.com)
- Bring Back The Old (bulldozer00.com)
- Ultimately And Unsurprisingly (bulldozer00.com)
- From Complexity To Simplicity (bulldozer00.com)
- Why I’m done with Scrum (lostechies.com)
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 