Crowdsourcing blame
ONE THING I DON’T LIKE about working for large organizations is the moment when something goes amiss. This one requirement that wasn’t analyzed enough blows out in your face, or that bug you thought was fixed turns out to be alive and well, and all of a sudden, there are meetings, mass emails, other meetings, and yes, yet more meetings to come.
All orchestrated so that the person responsible is found. Why? If the problem is serious enough, there may be consequences, if not, the goal isn’t really finding the guilty party but making sure that everybody else is innocent. Then everybody laughs and the meetings are over, without any follow-up as to how to prevent future mistakes of the same kind.
Either you are serious about finding the culprit and teaching him a lesson, or you realize that software development is part craft and part magic and that mistakes just happen; either way, there is a point to be made. But this?
Small teams do both: they recognize individual contribution and the inevitable shortcomings of every member. Larger groups tend to focus more on member safety; there are business goals, sure, but the primary goal is keeping the status quo. After all, the company is big, so we might just as well do our 9to5 and go home.
It pays to know what your client’s culture is. When it’s an agile, lean operation, quality just might be your job #1. Other times, you as a software developer, project manager or analyst aren’t really an IT worker but a therapist. Just make everybody feel good about themselves: that’s often what our work is about.
comments
Additional comments powered by BackType

