It's also easy to jump on the "management sucks" bandwagon.
It's also easy to jump on the "management sucks" bandwagon.
Yeah, our turnover rate is 300% and people are crying in meetings, but please ensure your concerns are raised elegantly, with many euphemisms for conveying urgency, and above all, please ensure by raising your concerns you are not impacting the roadmap.
That kind of low-energy "platitudes driven" communication around issues is exactly what leads to insane dysfunctions like ones we see at Activision and every startup that failed before getting to build an MVP.
If you exaggerate and state things in as emotionally insulting way as possible, you are not saying things as they are. You are exaggerating and burdening everyone else with need to disentangle your emotions from actual content.
Global warming is real, the sky is blue, etc.
>This person sounds like an energy vampire.
The only thing worse than grumpy people are the posiopaths who keep spreading through organizations.
As one other commenter put it, the emperor has no clothes. And a lot of us are _really_ tired of pretending like he does.
There are many old adages for this: an eye for an eye makes the whole world blind, fire doesn't beat fire, etc. Just because someone else is bad doesn't mean being bad in response is good.
Difference is, nobody forces you read an article and what a random article says has negligible impact on your quality of life. You can choose to ignore it. Situation like this at work, while it is true that it is better if one minimises the level of being affected by them, are impossible to not affect one at all in some way.
Some people crave to be winners, crave to be on top, to be above others. They will raise hell and bring down the heavens on your head if they don't get what they want. They want status, they want control and they are constantly spending every waking moment of their lives on figuring out how to achieve it, and don't care about much. These people will destroy your organization if they don't get what they want.
These are a separate breed from engineers. You can look up their CVs and I guarantee even if they started out in technical roles they didn't spend more than a year there.
As for are they viable from a societal standpoint, I'm not sure. They are essential for the functioning a certain type of highly toxic organization, just like lawyers and prosecutors are essential for a functioning legal system. Office politics is a negative sum game, but not playing is worse than playing it.
It's going to take ambition, desire, hard headedness, reward etc to make anyone do such an undesirable thing. The higher and more risky it gets the more tough people probably need to be. It's also a lot easier to be selfish and tough than caring and tough so there's a larger supply of bastards to be in charge than empathetic and kind but still somehow tough people who can take the nasty decisions.
If they crash whose fault will it be? The answer is always the drivers' You cannot be held responsible for things that you have no direct control over.
In software, if the infra goes down, who will need to fix it? Developers. If a feature is particularly tricky and technically challenging, who is responsible for getting out of a rut? The answer is the developers.
Things like fixing a tricky bug in a million line lib I didn't write (IRL example).
Managers can use the carrot and the stick, bring in more resources, communicate the developers pains upwards, but most likely they cannot do anything directly that will bring about success.
To be clear if done properly, this can be helpful, but to say that they are under more stress and responsibility than ICs is just untrue, considering they literally cannot do anything to resolve the origin of said stress (see car analogy).
On the other hand, a tank with 5-8 functional roles does have the role of tank commander.
Ultimately the CTO is responsible to the board for why a problem damaged the business (even if it was all the mistake of a developer somehow). And the board to the shareholders for losing money.
In reality people, of course, try as hard as possible to evade blame or lay it elsewhere but in theory a developer who makes a big mistake should not have been in a position to do that damage solo and it's a fault in the system if they were able to - and in the people responsible for the system.
- How long will this take?
- I don't know. This is very complex and I'm not familiar with the code.
- You HAVE to know, we HAVE to plan for it.
- Okay, then 5 days.
- Hey 5 days has passed, why isn't this done yet?
- I underestimated the complexity of the task.
- Ah, so YOU estimated wrong, so it's YOUR fault!
Hard problems exist. They can only be solved by hard-work and expertise and even then solve times are unpredictable and draining to the individual and are thankless endeavors. Management tries to paper over that, but this is a fundamental invariant of life. The fact that management makes solving these problems feel like punishment, only makes people try to avoid these problems more.
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.
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.
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.
Congratulations - you've made it into their compliments list: https://ludic.mataroa.blog/compliments/
Ironically, he could make a great VP of "cut the horse shit"