6 ms·
This reminds me of a Steve Jobs quote "it doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.
by gtrubetskoy 11y ago
This reminds me of a Steve Jobs quote "it doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do." Any company that doesn't have this as part of its culture will feel very depressing to creative people.
- RKoutnik 11y agoThat's a fantastic quote, wish I had known about it before publishing this! (I might just add it in post-facto anyway).
- deleted 11y ago[deleted]
- p4wnc6 11y agoEven Apple doesn't do it that way. Like many things Steve Jobs said, it contradicts what he did. The things we say about ourselves espouse ideals and far-mode thinking to enrich our status and legacy. But the brass tacks of what we actually do is still boring, controlling, manipulative, micromanagerial, and petty. I've never encountered any company, nor heard of one, that enacts the advice of that Jobs quote. In fact, I've recently been taking a deep dive into some organizational management literature to try to better understand where these absolutely ass backwards ideas of "cross functional" and "full stack" teams came from, and why they are so bundled together with open-plan offices. I found an interesting paper [0] that seems to serve as somewhat of a basis paper in this area, and which makes bald and unsupported claims about the superiority of what are called "process complete teams" (this, as far as my research has yielded so far, seems to be the prototerm that led to "full stack" and "cross functional"). The entire idea of this management philosophy is that you exactly should hire smart people then tell them what to do. The advice is basically to take generically smart people and then re-train them to have a generalist skill set as it relates to your business, so that every person can do every task, from talking to the customer to filling out the right paperwork to actually writing the code (whether it is front end, back end, whatever) and walking through all of the steps from start to finish. The paper advocates having a small number of job titles in an organization, each of which has many employees with that title, and to create teams and positions with enormous overlap in terms of their skill set and responsibility set. The paper makes all sorts of weakly supported (or entirely unsupported) claims that organizing by specialization (what they call "functional" units) is bad, and spends time talking about how to "break" specialist employees form their mindset that their specialization matters and instill into them a cross-functional "sense of responsibility" for the entire possible pipeline of work. This is where the ties to open-plan seating arrangements come from. It is argued that open-plan, community seating creates a communal sense of responsibility for the entire pipeline of work, whereas even changing to an organizational structure that is "cross functional" or "full stack" is not enough whenever employees are allowed to have privacy while doing their work -- their privacy, so it is argued, and private work habits prevent you from successfully "breaking" their mindset that they are a specialist focusing on their special subset of tasks. Eerily similar to both military indoctrination and prison inmate indoctrination... It's very easy to see how this mid 1990s organization literature has created the bizarre dysfunction of modern "cross-functional" teams and "full stack" developers, leading to Agile/Scrum bullshit, pan-everything job ads with a million bullet points, the treatment of specialized workers as undifferentiated cogs, and the flagrant hostility on the part of the modern HR apparatus towards employees whose sense of pride in their personal specialty (something they had to protect in order to have a resume that would have gotten them hired in the first place) leads them to protect themselves by demanding an employer provide relevant work resulting in HR labeling them as "not a team player" or some other buzzword meant to "break" them (isn't it insane that a professional management article is using language like "breaking" an employee, like this is boot camp or something??). Anyway, while I love indulging in some good far-mode thinking about the peachy world where companies actually hired specialists and did the real work of managing them (instead of the lazy "throw it all in a cross-functional bucket" non-management they do now), it's just not the world we live in. [0] "Breaking the Functional Mind-Set in Process Organizations" Ann Majchrzak and Qianwei Wang. Harvard Business Review, Sep/Oct Issue 1996. < http://business.unr.edu/faculty/Kuechler/788/breaking%20the%20functional%20mindset.pdf http://business.unr.edu/faculty/Kuechler/788/breaking%20the%... >
- RKoutnik 11y ago> I've never encountered any company, nor heard of one, that enacts the advice of that Jobs quote. You should read our culture deck (especially the section about "context, not control", starting at slide 80): http://www.slideshare.net/reed2001/culture-1798664 http://www.slideshare.net/reed2001/culture-1798664
- p4wnc6 11y agoI've read the Netflix document many times. To be fair, I don't have any special knowledge about working at Netflix to suggest that Netflix doesn't actually empower specialists. I am curious if Netflix avoids Agile/Scrum or offers real private working conditions though, and if not, why not? Answers focused on "collaboration" would count as evidence that, contrary to the slide deck, you aren't actually "hiring smart people and getting out of their way."
- RKoutnik 11y agoGenerally we have cubes (as far as working space goes). It's up to the teams if they want Agile/Scrum (most don't, a few find it useful, folks are encouraged to experiment). Collaboration, in contrast to many other valley companies, isn't a big priority. Since we only hire senior (Finder) devs, each is capable of taking on one or more projects almost solo. So where you'd have an ~8 person team at Google, Netflix has a single developer. There are pros & cons to this approach, I might talk about them in a future article. The practical upshot is that everyone does what they think is best for their particular project (others are encouraged to provide feedback but the ultimate decision is left up to the project owner [who is not a manager]). Does that help?
- douche 11y agoSounds like nirvana
- p4wnc6 11y agoIf you can guarantee that non-Agile teams never have deliverables required for Agile teams (and it sounds like such a guarantee is something you strive for), then this seems reasonable. But it seems very fragile if you can't guarantee that condition. "Do what you feel is best" is the right attitude, so at least it suggests you treat employees as grown-ups. But I would worry how that "do what you feel is best" property could possibly trickle down to subordinates within Agile teams.
- dclowd9901 11y agoWho's the "us" in this quote? We have project managers who are ostensibly experts at determining the needs of the customers, but whereas they want to solve the problem of findability in our app with a glorified tagging system, I want to solve it by making our search good. Who's the smart person and who's listening?
- bpchaps 11y agoI've been working in ops for quite some and only within the past two years got to work with PMs. Some of them are absolute pleasures to work with, but.. get more than two PMs on a call and just sit back and watch the chaos of Getting Nothing Done in full force. It's pretty amazing until the dread kicks in that those same bickering folk are making a huge portion of the decision making around the world. Bless the souls who can deal with that and do a good job at the same time.. My most notable experience with PMs was when a PM gave another PM a six month project to me and only introduced himself about a month before it was over. Normally, this wouldn't be that bad at a big company, but the dude was maybe 100 feet away and could've stopped by at any time. Ugh, I say!