story
This may seem like a joke, but the answer says a lot about an organization. For example, last time I was at the Wikimedia Foundation offices, this sign was above the sink:
http://commons.wikimedia.org/wiki/File:These_dishes_may_requ...
Since you have to actually wash the cup after you drink from it, there were long queues before the kitchen sinks.
People started reducing the number of cups of coffee they drink :) and instead started dozing off (not joking)
People started congregating around the pantry or kitchen because if you wander off with your cup around the office, you still have to come back to kitchen to clean it up.
I used to wonder the whole 'go green' thing at the time because anyway the paper cups are going to be recycled :)
There is a dishwasher. It's five seconds to rinse your dish and put it away.
At the WMF, there is someone whose job it is to make sure the kitchens are clean and the dishwasher gets run, but that's only effective because most people exercise common sense.
I'm just not sure how that scales for tasks that require more time. If there is some task that requires 20 minutes, and the company is big enough, do the answers change or do they not? Maybe it is better to hire a dedicated person for the office to do that than to make everyone use 20 minutes of their time every day on such task?
http://www.youtube.com/watch?v=JGfXiIXTpE0
More seriously, I think that allegedly financial calculation often ends up covering up for laziness, arrogance, and hierarchies of social class. Make sure the code works? That's QA's job. Make sure it runs well? Oh, that's ops; file a ticket. Wash my own dishes? Hey, office manager, get on that. Oh, and and honey, make me some coffee while you're at it.
I know some companies work that way, but I'd never want to work at one.
Testing is a little different: most professional software engineers consider testing an intrinsic part of software engineering, and so would never say, "that's QA's job". (But even then, there are some especially hairy testing problems that would benefit from a specialist's touch.)
Anyway, I think you're conflating dysfunctional organizations with specialization. In your example, developers say "that's operations' job" because they are lazy and don't care about maintaining a sane production environment. In a functional organization, they'll say the same thing, but they'll mean, "that's operations' job because they will do a better job than me". It sounds the same, but it means something entirely different.
(The same goes for washing dishes. I could wash my own dishes, but I would use a lot of water. If we batch up all the dishes in a 3000-person company each day and wash them in an industrial dishwasher, it will take less aggregate time and use much less water and energy. So while washing your own dishes may be symbolic of teamwork, it's actually a dumb thing to do.)
Maybe there's some marginal value in saving highly paid employees from doing menial work, but there's also a cost in terms of culture when you treat people like they're better than anyone else.
I was selling work of and inexperienced tea maker or dishwasher or cleaner or delivery man to my employer at hourly rate of a skilled programmer. One of the best deals I've ever done albeit short one.
Basic hygiene/workspace maintenance is everyone's job. There are people who specialize, of course (the cleaning staff; if you have them, developers aren't scrubbing toilets and steam cleaning carpets, of course), but it takes literally 5 seconds to rinse a dish and put it in the dishwasher, the act of which improves the entire workspace and contributes to overall order in the environment. If you don't have a dishwasher, it might take upwards of 30 seconds to wash your plate, dry it, and put it away.
Developers are actually in a unique position where they can do their job while doing other things; much of a developer's job involves thinking through problems, and menial physical tasks are actually a pretty great way to get your brain engaged on the problems.
This is a practical salary versus return on work done calculation, not a human worth judgement.
It takes literally 10 seconds to wash (not just rinse, but entirely wash) a bowl and a spoon. Nothing has to stay in the sink - just wash things right when you're done using them.
This works if your coworkers are happy to leave you alone to think. I often pace the halls at work while I think, but the moment I step into the breakroom I get greeted with "Hi Michael how are you so nice to see you how was your weekend" which makes the exercise kind of pointless.
Not that I have anything necessarily against small talk, but the time spent in the breakroom is unproductive time.
So you may have saved some time dropping your stuff in the sink, but now you have another developer who's spending the identical amount of time cleaning up...but in addition he's pissed off as well. Sounds like a positive outcome to me.
Are we engineers or high schoolers these days?
If you can reliably find fresh coffee, morale is good. Low or now coffee, things are amiss.
The secret (iirc) was a wee bit of salt in the grounds, and regularly cleaning out the works with vinegar.
we have a number of 'bad apples', but they generally find themselves ostracized very quickly. as we have no downside income guarantees (we are organized as a group of independent contractors), people very quickly fall out of the organisation
i assume valve accomplish similar by minimizing payments to individuals who act in bad faith. as they are probably primarily financially motivated and valve is likely a great entry on a cv, i'm sure they don't stick around long
I don't think most people are quite as bad about this as financial traders, but I imagine no group's numbers add up to 100% exactly. What's the dynamic like at Valve, and how do you make sure people feel fairly treated?
Another way to look at it: a friend's marriage counselor said that if each member of the couple thinks they're doing 50% the work, that leaves another 50% of the work undone.
(from http://en.wikipedia.org/wiki/W._L._Gore_and_Associates)
Unlike the traditional management structure that Bill Gore had experienced at DuPont, he proposed a flat, lattice-like organizational structure where everyone shares the same title of “associate.” There are neither chains of command nor predetermined channels of communication. Leaders replace the idea of “bosses.” Associates choose to follow leaders rather than have bosses assigned to them. Associate contribution reviews are based on a peer-level rating system.
I always assumed this sort of org could only function with relatively small companies (e.g. Github, maybe even Valve) but Gore has 9000 employees - pretty impressive.
So no not 9000 people; 90 units of 100 people ( or something like that)
Edit: I would still love to hear how it actually is to work there in practice though.
2. What sort of system do you have to address problems with the unconditional hierarchy? For example, if an employee disagrees with Gabe, who wins and how is that handled?
UPDATE: addition to question #1
I don't know about you, but not doing anything is boring to me. Working is so often much more fun than doing nothing.
Real management isn't telling people what to do. It's helping people find the intersection between what they want to do and what customers need, and then supporting them.
That strikes me as especially easy at Valve, where the whole point is to create something that other people enjoy. If you can't find fun somewhere in the vast space of "create something fun," you're dead inside.
1. How do you handle jobs that suck, but must be done.
Like backups ... nobody really likes the job of 'backup guy'.
It's boring. Tedious. A backwater of a role with no meaningful career progression. Also - the software typically sucks, and is expensive. Also - the hardware typically sucks, and is super-expensive.
But someone must pay attention to backups because stuff happens and you might actually need to recover everything from tape to get the company online.
How does Valve get the tedious, boring, nit-picky, utterly necessary stuff done?
We experimented with out-sourcing a few years ago. It was a disaster: the out-sourcing company was 'fair-to-excellent' with standard products and services.
But we're a manufacturing company. The majority of our software is specific to our industry. Suddenly the vendor is dealing with dozens of apps they've never even heard of. And - whoops - some of the guys who dealt with that stuff are laid off.
The rest of us got calls from confused techs in Austin plaintively asking what in the heck was the UmptyFratz service and who can restart it?
Long way of saying that - I imagine - some of what Valve does is industry specific and hard to out-source.
Suppose you share a house with a half-dozen people. You are all good people, so whenever something seems messy to you, you clean it up. Problem solved, right?
In my experience, definitely not. Because the person who's best at perceiving mess tends to clean things up before other people notice anything. That person feels like they're doing more of the work. Because they are. And they feel unappreciated, because people generally don't notice the messy-to-clean transition.
I'm a recovering sysadmin; I burnt out because I grew so very tired of caring about things that people never noticed until they were broken. What they said then wasn't, "Gosh, I really appreciate how well the printer has worked these many months." They said, "God damn it! The printer's broken just when I need it the most!" I'd love to know how stabby Valve's sysadmins and IT people feel.
I've looked into some co-ops, including San Francisco's venerable (and very profitable) Rainbow Grocery. One of the biggest complaints is the amount and/or difficulty of meetings, but they see them as necessary to settle issues with sufficient buy-in from all stakeholders. How does Valve minimize that pain?
http://www.gamasutra.com/view/feature/3408/the_cabal_valves_...
I was mostly curious about project management. It seemed like everyone could be very fluid going from one project to another, or even proposing one on the spot and going on to execute it. There has to some sort of enforcement for this though. Are there expectations, do the self-selected leaders lay out milestones or goals, what happens when those aren't met?
Valve doesn't necessarily seem to have a reputation for having too many product delays vs. always shipping on time. They definitely seem to have constant flow of different products getting out the door though.
Hopefully someone answers, otherwise I might just hitchhike across the lake into Bellevue and see if I can meet with someone there. Very curious to learn what makes their system actually work well.
In hierarchical organizations, people often look to authority figures to decide between competing alternatives. How does Valve avoid or deal with deadlock, forking, cliques, cabals, butthurt sulking, and other common group dysfunctions?
(A cow-orker of mine went to Valve last year; he's incredibly, insufferably happy).
It's possible no Valve employee reads HN (unlikely), but at the very least someone might point us towards a Valve employee answer elsewhere.
http://en.wikipedia.org/wiki/ROWE
The business measures performance instead of hours. At Valve the performance appears to be measured as 'shipped'.
I'd also guess that Gabe is practicing his own version of servant leadership:
http://www.gorowe.com/2009/09/14/gap-goes-rowe/
FYI, this is just my opinion and doesn't represent the views of my employer.
The short version is that people who are good at things generally get that way because they have a strong ability to tell good work from bad. People who are bad at things can't tell the difference, so they a) have a hard time improving, and b) think their low-quality work is pretty swell.
Is your culture perhaps unusually frank? Alternatively, is it very supportive in a way that makes critique more comfortable? Might you have a formal (or informal?) mentorship program so that people get useful feedback?
Are there peer groups that meet around particular skill areas? E.g., do visual artists get together regularly to show recent work and discuss it?
lower skill -> higher confidence in ability (overestimation) higher skill -> lower confidence in ability (underestimation)
Anyhow, for those who want their full take, the original paper is here: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.64....
Moreover, this question could also be reduced to a question about their hiring in general.
If it will help everybody, please forget I mentioned Dunning-Kruger in specific. That's the inspiration for the question, not the heart of it.
