Lately I’ve been mulling the attribute of flexibility. How much is too much, how much is too little, and how much is just right?
You’re working on a project, and the requirements change. This happens all the time. If it happens too often, should you call a “foul?”
There’s the question of how often is too often. What’s too often for you might be NBD for a colleague, or (more importantly) for the company.
One school of thought is that we should never call a foul. Software engineers (developers, product developers — pick your favorite term) have a customer. That customer is a client, product management, etc. Our job is to build what the customer wants to the best of our ability. We should be clear (at times, “crystal clear”) about the costs of changes in product requirements. Beyond that, if the customer wants a change then that’s fine!
Another line of reasoning says that developers are not whores working solely for a paycheck. There’s aspects of craftsmanship, artistry, and pride in building great things. If the company relies on those (in lieu of paying more for purely mercenary talent), it’s got to also accept that software engineers don’t like being jerked around. Developers, as employees, have a vested interested in the company’s success, and if something’s amiss in product management, they ought to tell the company (the CEO, the VP, the senior staff).
Should changes always be accepted cheerfully? I react to each scenario uniquely, but no matter what I do, I’m always wondering if I accommodated too much or too little.
Excellent point.
My perspective is that i get paid to think and thus i have a responsibility to express my reservations if my relatively experienced gut tells me that the project no longer seems to be moving forward.
This is a corollary problem to the ‘geniuses or idiots’ question that i asked you years ago at singingfish; are your leaders brilliantly steering your organization thru challenging times or are they madly lunging in different directions like a blind bull being randomly poked with sharp things because they are really scared and have no idea what to do next?
I have struggled to come up with a heuristic for this and have utterly failed.
However, I can offer that if you are not following the same basic outline you were following 90 days ago then it should be noted privately.
If this is the second time that you are not following the same outline you where 90 days ago then it’s time to surface that fact and explain why this looks like an unhealthy situation.
Because even if the second change is a really brilliant idea then that means that the first change wasn’t a brilliant idea (or you would have stuck with it, right?) and this kind of churn looks really mickey mouse to the troops.
I hit my limit when it turns into “couch moving”. If management asks me to build a big system, and then halfway before it’s done they ask me to rebuild it with different technologies or a new fundamental design, then a little flag pops up. If that happens over and over, and I have the sense they really don’t know what they want, then I feel like I’m moving a big, heavy couch against this wall — no wait, let’s try it over here.
Personally, the worst for me is when they can’t make up their minds enough for me to even get started. I can morph my software pretty easily midstream, but I find it really hard to just sit around with nothing even to morph.
I don’t have a clear response though. 😉 It’s more situational.