When You Stand
So your organization isn’t responding to reason. What started out as a team that would attempt to exemplify the way your organization wanted to do product development has become a micro-managed monstrosity, full of stakeholders, and absent of accountability. You’ve decided that in the face of this blame-storm you keep hearing referred to as a “team effort” (which you’re starting to believe!), you have to take a stand. Here’s what you’re in for:
First, things are going to get unpleasant. Most people dislike conflict, but everyone dislikes hearing they’re part of the problem. If you think people are displeased with your team’s performance now, just wait until they’re on the business end of an after-action review and their role isn’t in the “Things Done Well” quadrant. Second, you’re going to be scrutinized — and I mean under a microscope — and I don’t mean like in the way a botanist admires nature through the examination of a leaf; more like in the way a biochemical engineer watches bacterial cells, always on the lookout for indicators of any exploitable weaknesses. This one is particularly difficult to deal with the first time, as you’ll have to face the harsh reality that you might just be the only person in the equation who’s actually focused on improving the project, rather than advancing your own career by damaging someone else’s.
Finally — and there’s really no getting around this — you may lose. You may lose huge. You may ultimately be thought of as a cautionary tale for crossing Product, or Architecture, or Management-or-QA-or-whoever. For this reason, taking this kind of a stand should really only be done as a last resort — pretty much when things couldn’t reasonably get worse, and when you’re ready to leave if you must. Are you ready? Are you sure? Ok. Fight.