Regarding your comment, the most major issue is with that term "lean." In many cases, this means some usage of Agile/Scrum nonsense, which if true completely throws out any credibility that the position is focused on productivity in the least bit. Sometimes instead of Agile, "lean" is used for six-sigma like micromanagerial process, which suffer all the same criticisms as Agile.
Even in the best case, a team that self-identifies as "lean" is failing to make use of specialization of labor. Many of these teams hire people into roles titled "full-stack" or "generalist" and they say stupid shit like, "because our team is lean, you will have to wear many hats." (I am actually so sick of hearing the phrase "wear many hats" that it causes me to instantly reject a job out of hand at this point).
"Full stack" is arguably the single worst trend in all of software. It goes completely against the major benefits of software development: specialization and separation of concerns. Many organizations that use full-stack practices also believe that they don't need to provide meaningful job descriptions. They want to leave job descriptions vague ("many hats!!") and argue that candidates have to be adaptable if they want to cut it in this crazy dynamic world of ours.
This is all total bullshit. There might be a small period of time in a start-up life cycle when it pays to have many generalists and leave everyone's work assignments vague. But most start-ups, and certainly most established companies, have no business operating in "lean" mode. You need to empower employees to know the limits of their job descriptions, so that they won't be treated as catch-all, pan-everything work receptables who are capped solely by the literal limits of their physical exhaustion (at which point you whip together another pan-everything job ad to hire yet another generalist to handle the undifferentiated work overflow).
This fails to respect the worker's speciality (which is something the worker absolutely had to protect to advance in their career). It also means the company is not extracting the full value from the worker that they could by doing the challenging job of actually managing them and setting up the workflows so that work requiring that specialist skill is routed to the right worker. If the company embraces a "full-stack" "we're lean so everyone wears many hats" attitude, it's an overt admission that the company couldn't give two shits about what you're actually capable of doing for them, and instead only cares that you do what they happen to tell you to do right now, even if it's hilariously underutilizing you or is hilariously inappropriate for someone with your particular skills, or is using in a way that fails to address critical business needs you've identified.
Basically, I see "lean" and I immediately think, "managers believe they can throw a bunch of so-called full-stack developers on a Scrum team and then flip on autopilot." The managers are going to get mad if that machine learning expert they assigned to clean up the legacy Rails codebase ever breathes a word of dissatisfaction over not being fully utilized or utilized in their speciality.
"lean" is by far the buzzword that is most negative from your comment, but I also see the phrase "move the ball forward" and I immediately picture those trite motivational posters with eagles and someone passing a baton in a relay race and I just roll my eyes. We're not in middle school. We go to work to do work. We can speak about the work we do in grown up terms. Not "moving the ball forward." To me, this communicates a very top-down attitude about what progress means. There are some high-level, likely paternalistic or even misogynistic, ideals about company progress and what a good little worker must do to be productive. No thank you! Even if this language is not indicative of the worst kinds of problems, it still is extremely infantilizing.
"A single unproductive developer ..." oh boy, don't even get me started. Right away this sounds like someone with a way over-inflated opinion of the work their team does. "Our work is so very important that we can't abide even a single person who isn't amazingly productive." Yeah, OK. For one, you just said your team is lean, so whose fault is it that you don't have adequate redundancy built into your technical resources (your tech staff). If someone said their distributed database "couldn't tolerate even a single node failure" you'd ask them why they don't create more nodes and add redundancy to have a safety factor.
Why would a team agree to be lean if they are also worried that a single bad link in the chain will cause a problem. Either there's some kind of extreme budget constraint, or else this is someone who just read a Malcolm Gladwell-like pop book about "lean" and "Agile" and decided that's the shiny new management thing they just had to have.
Lastly, I'm not sure why "release date of a feature" was the example you chose to go with. This could be innocuous, but more often than not when I see people who think in terms of release dates and features, it's a huge red flag. Most teams need to actively constrain the set of features they agree to support, tell customers and internal business stakeholders "no" way, way more often, and address overall technical debt and architectural quality concerns far more than shipping features. If I was in an early interview stage and someone is already asking me how I make sure I always cram out all the features on time, that's a huge red flag of a dysfunctional process driven more by short-term business managers seeking bonuses that are tied to on-paper accomplishments (e.g. we shipped X,Y and Z) than the engineering reality (X, Y, and Z were technically delivered 'on time' but they suck and now everyone's asking for W which we can't even do because of how fragile the implementation of X, Y, and Z was to get it out the door on time").
Let me qualify all of this by saying that yes, absolutely, 100% this sort of detailed dysfunction can be inferred from very small amounts of buzzwordy HR text and job ads. I've seen it time and time again, and even been part of the teams responsible for drafting job ads and seeing first hand the thinking processes of HR as they inject all of this awful stuff into it.
There is even a major qualitative social science study about exactly how this kind of vague, symbolic HR-approved linguistic atmosphere is heavily, heavily related to the skewed ethical views held by executives and managers. I strongly urge you to read it if you have not already:
< http://www.amazon.com/Moral-Mazes-World-Corporate-Managers/d... >
I'm not saying that this definitely applies to you (I don't know you). I'm saying that my experiences tells me that the odds are that the team you are representing to "move the ball forward" with a "lean" team that cannot bear "a single unproductive developer" is a very dysfunctional one, and that many of these buzzwords actually imply the opposite of the image they are invoked to create.
DannyBee - have you read Moral Mazes by Robert Jackall (http://www.amazon.com/Moral-Mazes-World-Corporate-Managers/d...)? It was one of Aaron Swartz's favorite books.
It's an excellent, and fair to all sides, dissection of morality in corporate management. It explains how and why managers rehearse to explain actions their company's have taken.
In this particular comment of yours, you say lots of true things. However, you are not acting in a straightforward "hacker" way, as befits this site, telling the truth how it is.
Google can continue to behave in this way as a company, but it will alas find it harder and harder to hire good geeks.
[1] https://www.amazon.com/dp/0199729883
[2] https://www.lesswrong.com/posts/zpA2Tnp2k38qSmr8J/how-to-ide...