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.
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.
On the left-hand side of the diagram below, we have a static system design structure where four “workers” and their manager have their hearts set on producing a world class product. On the right, we have an alternate system design where only one worker has his/her heart set on creating a world class product. The other team members are too busy posing, competing, and jockeying for positional stature in the mind of the manager for their next upward career move. It’s not shown on the diagram, but that manager is also jousting with his peers to advance his/her career.
In orgs where the policies/procedures/incentives/rewards promote individual performance over (and at the expense of) team performance, you’ll most likely find the design structure on the right in operation. Which archetype does your system design map onto?
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.
How many institutions are still being managed in accordance with the knowledge learned from 17th century physics? These days, its networks and relationships, not billiard balls and force.
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.
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.
Being anointed as a firefighter in an org that’s constantly battling blazes is one of the highest callings there is for any group member not occupying a coveted slot in the chief’s inner circle. Hell, since you didn’t start the fire and you’re gonna try your best to save the lot from a financial disaster, it’s a can’t-lose situation. If you fail, you’ll be patted on the back with a “nice try soldier; now we’re gonna go find the firestarter and kick his arse to kingdom come”. If you extinguish the blaze, at least you’ll lock in that 2% raise for this fiscal year. You might even get an accompanying $25 Dunkin Donuts gift card to keep your spare tire inflated with dozens of delectable, confectionary delights.
Given the above context, let’s start this heart-warming story off with you in the glorious role of firefighter Fran. You, my dear Fanny, oops, I mean Franny, have been assigned to put out a major blaze in one of your flagship legacy software products before it spreads to one of the nearby money silos and blows it sky high. Time, as always, is of the utmost importance. D’oh!
Since the burning pile of poop’s “agile” architecture and design documentation is a bunch of fluffy camouflage created solely to satisfy some process compliance checklist, you check out the code base and directly fire up vi (IDEs are for new age pussies!) for some serious sleuthing.
After glancing at the source tree‘s folder structure and concluding that it’s an incomprehensible, acronym-laden quagmire, you take the random plunge. With fingers a tremblin’ and fire hose a danglin’, you open up one of the 5000 source code files that’s postfixed with the word “Main“. You then start sequentially reading some hieroglyphics that’s supposed to be source code and you come to an abrupt halt when you see this:
And… that’s it! The story pauses here because BD00′s lizard brain is about to explode and it’s your turn to provide some “collaborative“, creative input.
So, what does our guaranteed-to-be-hero, fireman Fran, do next? Does the fire get doused? Does the pecuniary silo explode? Is the firestarter ever found? Does Fanny get the DD gift card? If so, how many crullers and donut holes does he scarf down?
Who knows, maybe you can become a self-proclaimed l’artiste like BD00 too, no?