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!
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%... >
I also don't really know any organization that goes all in on "all team members are interchangeable". I do know one organization that seems to go all in on "each team member has his own unique tasks, rights, and responsibilities", and that is disastrous (X writes SQL script, but is not allowed to know the name of the database or the server it is installed on, and isn't allowed to run the script; Y is allowed to run SQL scripts, but not modify them, not even to fill in the database name. Their manager compliments them because they refuse to get anything done/follow the rules to the letter)
I think it is examples like these that led to a swing to the other end of the spectrum that Scrum advocates. I also think the pendulum will swing back.
This has been a ubiquitous and openly stated goal from management in every job I've had. In one job that followed a consultant's implementation of Agile to the letter, it was actually part of new employee on-boarding to be turned into a full-stack developer no matter what your background was.
Our team worked on a large predictive analytics project, and you can imagine how hard it was to recruit machine learning engineers when the proposition was, "Gee, your amazing degree from Georgia Tech and your experience building a novel recommender system from scratch for a start-up are great and all, but don't you think it would be good for you to spend 6 months fixing Javascript bugs related to poor performance of some of our app's drop-down menus? BTW if you don't exude boisterous enthusiasm for that, it means you're toxic, poor attitude, not a team player, and HR will never let you through the interview process."
You should read our culture deck (especially the section about "context, not control", starting at slide 80): http://www.slideshare.net/reed2001/culture-1798664
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?
Love to hear more about this sometime.
"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.
Simple, we don't have subordinates (at least as far as I know). Netflix only hires Sr. devs and then empowers them.
The question you should be asking is when would you want to use Agile or Scrum. An answer of "All the time! It's the greatest thing ever" indicates either stupidity or limited experience. But an answer of "We never use that bullshit" also indicates either stupidity or limited experience. Good managers and good cultures deal in shades of grey, and are able to drill into the details of the situation to identify when a technique is appropriate.
What elements of the Agile Manifesto[1] do you disagree with, exactly?
...I mean seriously, "Agile process" is an oxymoron and terribad managers go around saying it without a hint of irony. Seriously?!?
Yeah, that's kinda my point. People throw the word "agile" around as though it has one precise meaning, when it clearly doesn't. And IMO, the kind of "Agile" that people are railing against is so far removed that it doesn't deserve any association whatsoever with the expression "agile". And then there's the thing where people act like "Scrum" == "Agile" when Scrum is just one of many processes that claim some degree of affiliation with the "agile" world-view.
All of that said, I get the vibe that some people either don't agree that there is a distinction, or don't care, and have a blanket "agile is bad" mindset. It's frustrating to me, as I've experienced a shop with a well run Scrum process (when I was at Lulu.com) and I know from experience that, done right, it's a pleasurable and effective way to work.
Yeah, that's kinda my point. People throw the word "agile" around as though
it has one precise meaning, when it clearly doesn't. And IMO, the kind of
"Agile" that people are railing against is so far removed that it doesn't
deserve any association whatsoever with the expression "agile".
Words are defined by usage, and every manager I've encountered has used "agile" to mean a system of project management in which work is broken up into things called "user stories", and is then bucketed into fixed-length "sprints", with planning sessions to actually put the work into the buckets. Now you may say that this is one mere implementation of agile, and you'd be right. But it is by far the most dominant implementation. It's like saying that GNU/Linux is one mere implementation of a GNU system. You're right. But realistically, no one you know will be familiar with any others. It's the same way with agile software development. Scrum is one mere implementation of agile. But it's the only one most developers and managers encounter, so it's understandable that they'll conflate the two.
You say,
>the kind of "Agile" that people are railing against is so far removed that it doesn't deserve any association whatsoever with the expression "agile"
but I say that the idealized notion of "agile" you're talking about simply does not exist in reality, and no company using Agile even comes remotely close to it. The fact that Agile is so easily subverted is an indication of how poor a tool it is, and in the end when everyone is misusing a certain tool (the way that everyone misuses Agile) you have to stop doing mental gymnastics to defend the tool and acknowledge the widespread failure is the tool's fault.
My experience suggests otherwise.
(the way that everyone misuses Agile)
But that's not the case.
I'm glad you found some of those one-in-a-million workplaces that "do agile right" -- but they are so rare that we can't go around basing our overall opinion about agile, or our expectations about the next marginal adoption of agile, upon these kinds of freak occurrences.
Counterpoint: Maybe you're just hearing from a "Vocal Minority". And maybe the people quietly doing agile and enjoying it, don't feel the need to go around trumpeting it to the world?
If someone as key to software productivity as Dave Thomas is saying this, it's clearly not just because of a vocal minority.
Your suggestion that we should check whether it's just a vocal minority is a good one. We should check that.
Unfortunately, it's extremely obvious that it's not the case, and the dysfunction / failure mode of Agile is extremely common, by far the majority of Agile implementations.
I've written much more about the in principle failure of Agile [0] so I'll leave it to that.