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
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.