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.

 

1 Comment

Filed under Rants

One response to “Pushing Forward

  1. I really think this mentality comes from poorly written contracts. Where I work, we rely primarily on fixed cost and fixed timeline contracts. These contracts foster hostile environments between the client and vendor. The vendor benefits from whipping up garbage as quickly as possible, but screws the client. Vendors also want/need to “push back” clients to avoid additional costs, despite the possible benefits to the product/client. A proper contract that benefits both client and vendor yet places equal risk and responsibilities for both parties makes the most sense.

    In that regard, I’ve been pushing where I work for a “Money for nothing, changes for free” contract with new clients (also called the “Cancel after any phase” contract). Under this contract, both parties have incentive to make the best product possible for only as long as makes sense to provide the best bang for the buck. The clients get what they want for the best price and the vendor gets paid for everything they do regardless of variable scope. Everyone’s happy.

Leave a comment