If you're over a barrel, you'll say "yes" to anything. Not wanting to tackle hard social situations, or even be honest, IT shops will just imagine themselves over a barrel when even hard questions are asked. They try to code their way out of awkward situations.
The business group wants a bunch of new features, but the business group also denied them any room or resources to do engineering overhead with and half the development team left. In this situation, should the development team:
1. Claim too much of a brain drain to be able to do anything other than self-educate their remaining members for a year while the situation is only critical, and before it becomes catastrophic, with eventual hope of having human hours remianing to help new hires.
2. Take a hard stance on the position of those who recently left: that engineering has needs too and cannot spew out features endlessly without reinvestment in infrastructure and architecture, and otherwise using the situation as bargaining leverage to get what the engineers know they need to be able to do what's asked of them.
3. Abandon all testing, refactoring, and other engineering, architecture, and infrastructure projects, and just try even harder to keep bolting on code to have more and more features to demonstrate so they don't look weak.
So often, management is to blame for the decisions that discount technical considerations and fixate on social ones, but in this case, the programmers tend to back them up. I've worked for startup code shops that tried to appease unhappy clients by writing more code for less money, only managing to damage themselves further until they were cripple. The strongest companies I've worked for ahd the happiest clients and were the ones who knew how to say "no". They didn't even feel they had to have a bullet proof explanation. In fact, they'd use anything -- never anything snarky because it didn't have to be. They'd say, we're working on other things and we won't be able to get to that for a while. Or, that wasn't in the original design and now our programmers are committed to other things. Or, the original plan won't work because of complications we ran into. So the client might take their money and walk -- you're not firing the engines to Warp 9, threatening to destroy the entire crew on a quest to make someone happy who has no incentive to be happy as long as you're busting their ass catering to their whims. Such is it in IT, too. If you can't say no, or you've got yourself convinced that you can't, you'll never do right by anyone again. All of your promises will turn into lies. Your attempts to reconsile will all backfire. You'll squander your credability and your good intentions won't compensate. You'll look like an amature... a sniveling fool, rather than a professional who knows what is and isn't possible. At the very best, you'll look like a poor manager of your resources who has no idea what your capabilities actually are. And that's not doing your job, managing technical people.
The best IT situation I was in, at Mayo, my manager took saying no to an art form. When we said yes, it was after carefully scoping out not only the technical but political landscape, with this question foremost: will us coming in and do this work really solve such a huge need that a lot of people will have an easier days work and tell everyone about the wondeful thing we did for them. A few short projects in, and we were gods. No one dared pressure us; everyone wanted to be our friends; we weren't in a rush to expand our group; what we said carried weight above the idle jockeying of business idiots.
-scott
