To the eyes of management he was a champ, the king of "shipping".
So management also was bad at their jobs. They probably didn't get canned, though they deserved it as much as the King of Shipping.
But, congratulations, you know the "What's Bad About Working Here". Maybe there's a way to train management what their implicit job responsibilities are. I've never seen it happen in the wild, but maybe it's possible.
That's the problem, management is bad at their jobs. Management is so bad in the U.S. that everybody imagines they can hire their way out of situations rather than manage their way out of them.
For instance, when you tell people that you went to a Burger King and it took them 30 minutes to serve you a cup of coffee, the conventional answer is "it's hard to find good help these days."
That's a loser attitude on the part of management. Management hires employees, fires employees, trains employees, supervises employees, etc. If management does not take responsibility for your experience as a customer it is definitely the fault of management that you have a bad experience.
The problem has many facets but one of them is that few people are cut out to manage other people and our illusions about "meritocracy" contribute to an American culture that creates excellent foot soldiers but mediocre to terrible officers.
This is the reason why I find "tipping" food servers for "good service" so perverse. the quality of the service you get is almost always a function of how well the place is managed.
Was your hard working server set up for failure by someone making 4 times her wage? A good manager can take a terrible team and make them a great team.
I usually tip well and complain to management when I get bad service for this reason. Unless business is slow and the server is obviously goofing off in the back or something.
This is my experience. It's a codependent relationship between management who is unable to determine the feasibility of what it's asking for (or, just as often, what it is asking for) on the one hand, and an eager-to-please yes-man of an engineer on the other.
Management loves how fast things are delivered, and boyscout loves the pats on the head. The rest of us hate the countdown until the house of cards comes tumbling down.
I saw a great tweet some time ago that defined a 10xer as an engineer who accumulates technical debt so fast, it takes 10 engineers to fix their mess. That about sums it up, doesn't it?
I love that tweet. Although it happens on the management side too. Manager comes in runs a team into ground(that the previous manager spent years building), pushes all kinds of work on other teams as well, takes credit for all of it and keeps getting promoted.
Management trusted the developer knew what he was doing, and didn't micromanage. I would go as far as say that management should be setting requirements in terms of security, maintainability, documentation etc, but I guess in this case (because apparently it was just one dev), they gave the developer full freedom. Misplaced trust, in this case. In a lot of cases though, I'd rather management ask me what should be done, instead of them telling me (or telling me something I'd disagree with).
You trust teams, not individuals. The smallest possible team (1) to give some responsibility to is three people for this reason. Someone can quit or take a leave of absence and you still have technical accountability, code reviews, meaningful discussions, etc.
The fact that management made a mistake here is understandable. Management needs room to make mistakes, too. The fact that the developer was blamed and fired but the management wasn't held to a similar standard of accountability is the problem.
The code is the product. The management owns the code just as much as that developer did. So does everyone up the chain and anyone in parallel organizations (the business experts, the people that make the budgets, the QA department, etc.).
It's likely, at least implicitly, that the org structure sees some people owning 'the product' and other people owning 'the revenue' and other people owning 'the budget' and the developers owning 'the code'. As if we can separate those things.
If you work for a car manufacturer, everyone needs to know about cars, care about cars, drive cars, learn about cars, and expect good cars to be produced for a nice profit. I think shops that sell software, whether shrinkwrapped or through services, need to have the same attitude about software. If you are in the business of software, you are in the business of code, even if you can't write any yourself.
1) Team loosely defined here. It could be three people from different parts of the company, as long as they all understand the aspects of the system well enough to have a meaningful discussions about it.
Yes, but it seems that they didn't extend the same trust to the rest of the team. There surely would have been other people on the team who could have told them that the product was not headed in a good direction if they had just been asked how they felt it was going.
Comments
So management also was bad at their jobs. They probably didn't get canned, though they deserved it as much as the King of Shipping.
But, congratulations, you know the "What's Bad About Working Here". Maybe there's a way to train management what their implicit job responsibilities are. I've never seen it happen in the wild, but maybe it's possible.
That's the problem, management is bad at their jobs. Management is so bad in the U.S. that everybody imagines they can hire their way out of situations rather than manage their way out of them.
For instance, when you tell people that you went to a Burger King and it took them 30 minutes to serve you a cup of coffee, the conventional answer is "it's hard to find good help these days."
That's a loser attitude on the part of management. Management hires employees, fires employees, trains employees, supervises employees, etc. If management does not take responsibility for your experience as a customer it is definitely the fault of management that you have a bad experience.
The problem has many facets but one of them is that few people are cut out to manage other people and our illusions about "meritocracy" contribute to an American culture that creates excellent foot soldiers but mediocre to terrible officers.
This is the reason why I find "tipping" food servers for "good service" so perverse. the quality of the service you get is almost always a function of how well the place is managed.
Was your hard working server set up for failure by someone making 4 times her wage? A good manager can take a terrible team and make them a great team.
I usually tip well and complain to management when I get bad service for this reason. Unless business is slow and the server is obviously goofing off in the back or something.
Management is very bad across the board in the US. Very short-sighted and hierarchal culture.
Great leadership is humility and service to those being led. In America the ego worship and adoration for the Type A nutjob stands in the way.
This is my experience. It's a codependent relationship between management who is unable to determine the feasibility of what it's asking for (or, just as often, what it is asking for) on the one hand, and an eager-to-please yes-man of an engineer on the other.
Management loves how fast things are delivered, and boyscout loves the pats on the head. The rest of us hate the countdown until the house of cards comes tumbling down.
I saw a great tweet some time ago that defined a 10xer as an engineer who accumulates technical debt so fast, it takes 10 engineers to fix their mess. That about sums it up, doesn't it?
I love that tweet. Although it happens on the management side too. Manager comes in runs a team into ground(that the previous manager spent years building), pushes all kinds of work on other teams as well, takes credit for all of it and keeps getting promoted.
Let's be honest. management probably pushed the guy to ship NOW
Pass on the blame, keep the credit. That's the way to the top in many companies unfortunately.
https://en.wikipedia.org/wiki/Plausible_deniability
Management trusted the developer knew what he was doing, and didn't micromanage. I would go as far as say that management should be setting requirements in terms of security, maintainability, documentation etc, but I guess in this case (because apparently it was just one dev), they gave the developer full freedom. Misplaced trust, in this case. In a lot of cases though, I'd rather management ask me what should be done, instead of them telling me (or telling me something I'd disagree with).
You trust teams, not individuals. The smallest possible team (1) to give some responsibility to is three people for this reason. Someone can quit or take a leave of absence and you still have technical accountability, code reviews, meaningful discussions, etc.
The fact that management made a mistake here is understandable. Management needs room to make mistakes, too. The fact that the developer was blamed and fired but the management wasn't held to a similar standard of accountability is the problem.
The code is the product. The management owns the code just as much as that developer did. So does everyone up the chain and anyone in parallel organizations (the business experts, the people that make the budgets, the QA department, etc.).
It's likely, at least implicitly, that the org structure sees some people owning 'the product' and other people owning 'the revenue' and other people owning 'the budget' and the developers owning 'the code'. As if we can separate those things.
If you work for a car manufacturer, everyone needs to know about cars, care about cars, drive cars, learn about cars, and expect good cars to be produced for a nice profit. I think shops that sell software, whether shrinkwrapped or through services, need to have the same attitude about software. If you are in the business of software, you are in the business of code, even if you can't write any yourself.
1) Team loosely defined here. It could be three people from different parts of the company, as long as they all understand the aspects of the system well enough to have a meaningful discussions about it.
Yes, but it seems that they didn't extend the same trust to the rest of the team. There surely would have been other people on the team who could have told them that the product was not headed in a good direction if they had just been asked how they felt it was going.