One of the guiding principles at Buink is to be a code butler. Although our dress is a lot less formal, our attitude should be no less helpful.
The butler is there to serve, to make life easier. The butler is faithful; they’re sure to complete all requests without being asked twice. The butler avoids saying no and never has a bad attitude. They’re not yes men/women, but they’re helpfully humble and they’d only say no if it were illegal, unethical, or counter productive to the interests of their family.
If the butler is asked to do something that seems as if it is not in the best interest of the family, they make sure to voice their wisdom and help the family understand why it may be a bad decision. After making the family fully aware of the trade-offs, they cheerfully complete the request. They understand that they don’t always have the full picture.
These are qualities we try to embody at Buink. We’re wise and experienced. We’re happy to help and we’re ready to share our expertise so our clients know the trade-offs of what they’re asking. If you know me, you’ve heard the phrase, “happy to help.” Whenever I say it, I’m reminded of my true purpose as a servant coder.
The following are a few ways we strive to embody these butler attributes.
We Know What We Don’t Know
You’ve heard the phrase “the customer is always right” but what do you do when, in the famous words of Steve Jobs, “people don’t know what they want…”.
I’ve found that Jobs’ was correct, particularly when we’re talking about new technology. The reason clients don’t always know what they want is that there is a big difference between using technology and building technology.
You can quickly discover this truth for yourself by using a website builder to create a website from scratch. These builders allow you to give the site any look and feel that you want without knowing any code. If you have time, give it a try and you’ll quickly start thinking, “something is off, but I can’t quite put my finger on it.” I know the feeling, because that was exactly how I felt when I built my first site in 2006. I added images, links, and content, but it just didn’t have the professional feel of the sites and apps I know and love.
Through years of experience, developers learn the tricks of the trade, but this knowledge often tricks them into thinking they know what the client wants. Truth is, developers don’t know what the client wants EITHER!
Just two weeks ago I had an experience with a new developer where the client asked for a particular feature but the developer thought it was too expensive, so without circling back to the lead developer or the client for more information, they went off in left field writing code they thought was better. Needless to say, the code had to be trashed and their time had to be discounted. Rather then learn the business case for the change, this developer took matters into his own hands.
So, if no one knows what the client wants, where do we start?
We start with the business needs and goals. Luckily, the client knows their business better then anyone. So, it is the developer’s job to fully understand the business case and business goals; and then use their web development expertise to show the client solid solutions. Also note, it is not the job of the developer to decide if the business strategy is good, but more on that later.
The second part of the Jobs’ quote is probably more important than the first, he said people don’t know what they want “…until you show it to them.”
If developers take the time to learn the business, they can truly shine by creating descriptions, wireframes, designs, or web interfaces that satisfy the case or goals.
We Try to Ask Good Questions
From a very young age my dad taught me the value of great questions. Questions are the door to the human mind; with them we can dig into what clients say and find out what they really mean; in other words, what they really want (cha ching!).
“The wise man doesn’t give the right answers, he poses the right questions.” – Claude Levi-Strauss
We start with good questions because we need to fully understand the client and the business needs. Some examples of good questions are the overall goal of the desired web asset, the top three goals of a new feature, expectations for the final product, deadlines, and budget requirements.
There are bad questions, if you don’t believe me, take 3 minutes to watch “No Such Thing as a Stupid Question.” Bad questions are ones that can be answered by materials given to you already, answered by google within 10 seconds, or questions that are unrelated to the task at hand. Our time with a client is precious and we don’t want to take too much of their time or waste their time in any way.
We Love To Listen
Client feedback is gold no matter how they give it. If they give us praise, that is an opportunity to understand and pay attention to what they value. If they give us criticism, that is an even better opportunity because we can really get a feel for what they value.
We can dig in and understand what we can improve or how we can provide more value in the future. We need to listen intently and even take notes and review them from time to time. We can also look for thoughtful questions we can ask about the feedback.
You may be thinking, “Sure, but feedback hurts sometimes.” I’ll say this, if you learn to like it, you’ll benefit from it immensely. I used to lift weights quite frequently when I was younger. I remember when I started, I hated the feeling of being sore. It was torture! The day after a big leg work out I had a hard time even walking. So I started telling myself that the feeling of being sore was my body getting stronger and bigger, swole. 🙂 You might not believe it, but I love the feeling of being sore now.
The uncomfortable feeling of feedback is just the feeling of you becoming better at your craft. There is always something to learn from it. Code butlers look at feedback as a valuable opportunity to dig in, understand, and improve. I love the quote from Dr. Stephen R. Covey, bestselling author of “The 7 Habits of Highly Effective People”, he said, “seek first to understand, then to be understood.” This mantra is the easiest way to build trust and confidence with a client.
We’re Not The Super Hero
Think of the butler for a second, the movie is never about them; they’re there to support the super hero or the lead role. They want to make the hero shine. So do we!
Remember, we’re here to solve the client’s problems, not to give them more. We should never assume that a client has more time than we do or their time is less valuable then ours.
Let’s take a real world example; a client asks for a change to all product pages on a site but we find that this change will require some manual work in the admin (changing text, etc). We obviously don’t want to bill at a developer hourly rate to do data entry. We also don’t want to give our client more work.
This situation is a perfect opportunity to strike up a conversation (using good questions and great listening) about ways the client would like to address the problem. A bad question would be, “how do you want to solve this problem?” A good question would be, “here are three options, which one do you think is best?”
I want to emphasize that we should always try to give them three options and let them make the decision. One option is that we could have one of our people at a lower rate do the data entry. Another option would be that maybe the client has someone that could do it. Lastly, we could write a script to update the data all at once, or we could just have the developer do it manually. Each one of these options has trade-offs but we never want to assume that we know what the client wants.
We Align Our Incentives
Our desire to serve our clients is a big reason that we don’t charge by the project; we only do hourly work. We always want our incentives aligned exactly with our clients. We only charge for the value we provide, nothing more and nothing less.
We have many reasons to operate like this, but here are a couple that come to mind quickly: we never want to be tempted to cut corners or sweep things under the rug if a project goes over an arbitrary budget unsuccessfully predicted at the beginning of an agreement, we don’t want project deadlines to be jeopardized by a disagreement of scope or inability to agree on a scope, and we don’t want to make excess profits on one client in hopes that when we lose money on future projects it all evens out.
We also don’t set one blanket hourly rate for the whole company. Some developers provide less value then others; so, each developer has an hourly rate that reflects the value they can provide to a given project. Every hour they work, we get paid, every hour they work, the client gets code, and every hour they work, the project has a developer with no other incentive then to deliver high quality, high value work.
Conclusion
Hopefully, this article was helpful. Have you ever worked with a code butler? Or the opposite? I’d love to hear your thoughts in the comments below.
