This is more applicable to service work than product work I think. I had a discussion last week that greatly changed the way I work. I learned the customer’s expectations.
One of the reasons’ people have problems in personal relationships is that they do not communication expectations to the other party. This builds up frustration with the other party when he/she/they fail to meet the unsaid expectations. This is unfair to the other party who is unknowingly making the person angry without knowing it.
On the flip-side, I’ve found I usually am better off asking what are the other person’s expectations up front to ensure we’re all the same page. In understanding how to best work with others, this is probably the single most important question to ask at any level.
The reason I bring it up here in this context of relating to work is that my style of work is adopted based on the client’s expectations. They want to see something to develop trust? I build something simple out quickly that works with no intention of updating the code base. They want to see continual progress and constantly change things? I build based on iterations. They want it perfect? I hunker down and test the heck out of it.
Those may seem obvious or relatively non-important, but I think they deserve to be re-iterated. In smaller teams there is more transparency, so even designers & developers on a team shielded by management are still privy to what the customer expects. On larger teams, or in ones where client communication is small to nil, without a clear communication of expectations, false impressions can not only sprout, but get entrenched into an attitude of development.
I’m not sure of the signs, but I know if you do recognize them, it is paramount to quickly clearly communicate, again if need be, the expectations. Why?
If you are a contractor and someone hires you for a small project to “see what you can do”, while the temptation may be to blow them away, I suggest you meet the expectations first, and if you have time, do the additions ONLY when you’ve met the original expectations. If you’re on time but didn’t get to add the extra things, feel free to share “what you wanted to add”. Better to build trust than to over promise and never deliver. I recognize that it may take less time to build the extra’s in initially, but I have failed time and time again when taking risks here, and I refuse to do so again… unless the risk is reasonably calculated, hehe!
If you are a developer under the impression you can “shoot the client an early build” when they signed off on mockups they expect to be perfect and working 100% as designed, you will fail, give the client a negative impression, and feel frustrated with your efforts being discounted since you aren’t getting the type of feedback you wanted.
If you are under the impression it needs to be 100% perfect and tested, and the client hasn’t seen anything for weeks or even months, you’ll be extremely frustrated and defensive when they return lackluster feedback and want changes. If the client is open to a more iterative style of development, or you get the impression they are untrusting or shifty in “what they really want”, it’s best to adjust your development style towards that type of development.
A former executive of General Electric encouraged companies to have a set of company rules, edicts, or ethics that the entire company, every employee, could use in their decision making process. Their wording, order, and amount all had significant impacts on the company. What the company stood for and how they go about accomplishing what they do is held in this list. The point, though, is that they are the “expectations” of how you do business in the company as an employee. This ethical guide leaves no room for questioning on how to approach problems from an ethical point of view, leaves little to no room for doubt on what is most important if written well, and serves as an overall guide for your company.
This empowering of clear focus is exactly what clearly articulated expectations do. They allow you to be successful, and remove all obstacles, leaving most of it up to your team’s collective skill set leaving your problem solving ability to be focused on algorithms and software bugs instead of customer bad feelings.
The reason for this post is I was recently in a situation where I assumed the client knew about the benefits to iterative development and agile development and was clearly mistaken. This lead me to develop in a fashion that focused on getting initial functionality down with bugs or not-so-finished functionality into a working build that I assumed I could get user feedback on early. This was a polar opposite of what the client was expecting, made my team, and me in particular, look bad, and was setting me up to fail. After a discussion of the client’s expectations and some context as to why they were like that, I realized my attitude was wrong, my style of development had to change, and I could now be successful my decision making process vs. always defaulting to wrong. The downside was this wasn’t early in the development cycle, so the damage in time spent had already been done. I also learned that you can’t always change these expectations either and just have to deal with it.
Bottom line:
- Don’t assume people recognize that even though you didn’t deliver on time, you were going to add all this cool extra stuff.
- Don’t assume every client knows what Agile or Iterative development is, nor cares.
Ask the other party what their expectations are, and confirm you can meet those expectations with the understanding you’ll do your best to exceed those expectations time allowing.
