Thursday, August 25, 2011

Pushing Forward

There's a phrase that bothers me quite a bit when I hear it. Lately, I've heard it a lot. I hope that as I continue on in software development, that I can somehow manage to erase this phrase from my use. The phrase I'm referring to is "push back".  I've heard this used numerous times when client requests come in - "we can't do this... we need to push back" , "how did this requirement slip in? Someone's not pushing back on the client" , etc. etc.

When did the relationship between the developer and the client move to the battle field? Take a look at free dictionary's definition of push back. When did the client become the enemy?

I know that we have to protect the business and have to ward off scope creep. I understand these things well. But we also have to protect our environment and our relationships. This is where using phrases like 'push back" do more harm than good.

At the inception of  a project, things tend to be positive. The developer(s) begin(s) to learn about a clients needs and drafts solutions for the client. More often than not, both parties are pretty positive. The client has found a partner to build their dreams! The developer(s) have found problems that need to be solved and are anxious to provide a solution!

Development is an evolutionary process though. We as developers can never fully see into the mind of the client and often only understand small compartmentalized pieces of a much larger puzzle. The client might not fully understand what the developer(s) can provide, and might not fully understand how what they can provide maps to their problem.

-Enter Frustration-

The situation I describe above can lead to (at varying degrees) conflict between the developer(s) and client. The client gets frustrated with the developer(s) for not being able to fully see what is evolving in their mind. The developer(s) get frustrated because as the project evolves, the client desires change that may not have been anticipated.

-Enter a Critical Point-

How we handle the above can make or break a project. There are pros and cons with heading in any direction at critical decision points. Sometimes the client might not know these pros and cons. It is our job as developers to work with the client, guiding where we can, being guided when we don't understand, both openly and honestly.

This does not, and should not mean "pushing back". This should instead be an opportunity for us as a team and as a partnership to PUSH FORWARD.

Pushing back implies that at these critical decision points, we are in conflict. It implies that the client is attempting to guide us in a direction that we must aggressively provide resistance against. It is a negative term that (in my opinion) only leads to negativity seeping into a project.

WE ARE NOT IN CONFLICT WITH A CLIENT. We have a relationship with clients. That relationship should stay positive. We must work with our clients to keep that relationship positive. When we find ourselves at a discussion point with the client , WE MUST GUIDE EACH OTHER. WE MUST PUSH FORWARD into a direction that we both feel comfortable with.

Honesty with each other should guide this. We must be up front with what we know, and what we don't know. We must address these unknowns and identify reasonable action if, while pushing forward, we find ourselves treading on rocky ground.

I know this might seem like silly semantics. Push forward, push back, does it really matter?

I think it does. Relationships stay strong through positive re-enforcement. What we say and how we say it matters.

With that in mind, I'm going to make an honest effort to never use the phrase "push back" in the context of a developer / client relationship ever again. I'd like to replace it with something I see as more positive - pushing forward.

No comments:

Post a Comment