3 ms·

Thanks for the observations. Other people have made the same observation about the signs of the dysfunctional process table. When I wrote it, I was including s

Thanks for the observations. Other people have made the same observation about the signs of the dysfunctional process table. When I wrote it, I was including stakeholders and managers as part of "team". So the scenario you describe would be the business side of the team not managing the scope properly. I'll need to update the table to be clearer. I agree that people don't change quickly. In those cases, you need to adapt the process to guardrail them (e.g., add a check in the workflow) or put a different person in that role. If you don't, you're just going to get the same result again in the future. For your edit -- is that a bad thing? Presumably a architect should be able to explain their decisions. The major theme of the guide is that communication is a good thing, especially when the different people are likely working with different information and expertise.

throwaway2016a 10y ago
Thank you, great article. I enjoyed it and I wish all managers would read this. Fair point, the manager should be considered under the team umbrella. The stakeholder isn't always a manager, though. Sometimes it's a client. And one of the hardest things to do is say no to a client. I think all my criticism boils down to: guiding the discussion can be great, dictating the discussion is not. Some MBAs (any managers, really) have a hard time drawing that line. One of the toughest things when you're starting a company is to let go and trust your team. You don't have to solve every issue personally if you hire smart people and empower them, which I don't think this article quite gets across. I'm not saying there aren't times you have to personally step in, because there certainly are. One thing this does not touch on is prioritization. How do you decide what gets built and what doesn't? But there are countless article and books on that.

throwaway2016a 10y ago

Thank you, great article. I enjoyed it and I wish all managers would read this. Fair point, the manager should be considered under the team umbrella. The stakeholder isn't always a manager, though. Sometimes it's a client. And one of the hardest things to do is say no to a client. I think all my criticism boils down to: guiding the discussion can be great, dictating the discussion is not. Some MBAs (any managers, really) have a hard time drawing that line. One of the toughest things when you're starting a company is to let go and trust your team. You don't have to solve every issue personally if you hire smart people and empower them, which I don't think this article quite gets across. I'm not saying there aren't times you have to personally step in, because there certainly are. One thing this does not touch on is prioritization. How do you decide what gets built and what doesn't? But there are countless article and books on that.