[t43562]

I heartily agree that the problems are hard and unpredictable things don't get made predictable by a method.

I think, however, if you're in a company with bastards who don't care they will find out how to screw agile just as they screwed the scheme before that. In the waterfall projects the example you gave is just the same.

In your example "I don't know, it's very complex" should lead to a spike where you have a chance to find out more. Then you'd give a high complexity estimate and everyone would try to think of ways to chip off a bit of the problem at a time.

You're also trying to get your whole team to think about what can be done rather than each developer facing horrible problems alone. But if you're managed by arseholes then even the most positive ideas tend to get turned into nightmares.

[torginus]

I'd really like to get on the same page as you, let me ask you are you a manager? Are you technical? Do you work on technically challenging topics (which I define by needing people with rare specialist skillsets)?

Because if you do you know you can't do certain kinds of stuff. You can't bring in another guy who's a cryptography expert while also having your particular domain knowledge. You can't communicate effectively upwards that you have a teethy issue.

Management is a leaky abstraction. The idea is that a manager is the person for a team who upper management can treat as a proxy for the team itself.

As for how things should work, the difference between that and how things actually work is the existence of carrot-and-stick feedback mechanisms to enforce a desired reality.

In absence of that you get a regression to the mean. Management which shifts blame. Disgruntled engineers who shirk responsibility. Stupid idealist youngsters who maybe go above and beyond once or twice, then after being burned either join the disgruntled majority or quit the company.

[t43562]

I became a tech lead and a line manager not too long ago. It's very difficult to keep your technical edge and also deal with the the meetings, the debates about what to do next quarter, the personal issues and yet be able to zoom back down to how the hell I'm supposed to add my bit of code into this design in a sensible way that will work...what the hell is going on with this incomprehensible bug...etc.

TLDR: the use of BLAME is not that helpful. We're all human and fallible. We don't want to get to the point of blame in the first place anyhow. We want to solve problems before they go badly wrong and blame is really just about what we try to do to make things better in future. Like, if you say "this person is the one who screwed up - they're just an idiot" that lets everyone else off the hook and lets the company not change itself at all. So I don't think that mode of searching for a scape goat is very useful. What's useful is that when there are several people and none is sure who should take on some problem then you need to clarify who is most responsible and should follow up and keep chipping away at it till it's solved.

I wrote a lot of other boring crap and deleted it to spare you the pain of reading it. Yes I'm technical but it's impossible to be technical in all areas. I do write code and I'm always struggling to keep up with the other developers on the team. I have specialist skills but they're only of limited relevance to this company and this team and skills become less and less relevant. It's very hard to deal with problems in a domain that you're not familiar with but you end up being forced to deal with things that you're not equipped for because nobody else really is and you're responsible.