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.

I’ve been heads down, fingers coding, energetically building Buink for over a year with no time for writing. In truth, I’ve been barely keeping my head above water! We keep adding new clients and we keep delivering great solutions; all the while, I’m getting even more busy.

About a month ago, I decided it was time to hire employee #1 and I started the search. I’ve long had several contractors working for me, but it was time to bring someone in-house (although not really “in-house” because Buink is a remote-friendly company). During the search, I had Makency (my HR representative) research everything that comes with being an employer, like benefits, taxes, and all other costs. Her deliverable was an employee cost calculator that I could use to plug in an estimated salary and understand what I need to charge per hour for their time. My findings were interesting, to say the least.

I’ve written in the past about the benefits of using contractors over employees for web development but now I have some numbers to back it up. I’m confident that both employers and employees underestimate the true cost of an employee.

Both employers and employees underestimate the true cost of an employee.

Let’s take for instance an entry level software developer. Glassdoor.com estimates the average starting salary for this position would be $88,863 / year. Yes, I am even a little surprised by this number. If you do a quick back-of-the-napkin calculation on this salary (salary / 40 work hours / 52 weeks) you’ll find that this is $42.72 / hour; not a bad wage for coming right out of school and seemingly a bargain compared to a contractor rate.

But is that the true cost? No.

Do they really work 52 weeks? No, you’re still paying their hourly rate even when they’re out sick, on holiday, or living it up on the beach with Buink’s unlimited paid time off. At Buink (at the time of writing this), we offer unlimited paid time off, 9 holidays, and 2 weeks of sick leave. This leaves on average about 46 weeks of actual value to the employer.

Do you really get 40 hours of value from an employee every week? No! People are only really productive with portion of their time at work. Having painstakingly tracked all my work time for 5 years now, I’ve realized that even the best employees can only bill about 80% of the time they’re at work, so if you estimate a 40 hour work week, then you’re lucky if you get 32 hours of productivity.

So, the back-of-the-napkin calculation that many people unwisely use is wrong! The true cost of the entry level software developer is really $60.37 / hour or $125,567 using a more accurate back of the napkin formula: salary / 46 weeks / 32 hours.

Keep in mind, that isn’t including taxes, medical/dental/vision insurance, equipment costs, workers compensation, office space, retirement matching, and administrative costs. Not to mention bonuses (we don’t offer them at Buink because we’d rather just pay a fair salary then offer a phantom carrot).

When all is said and done, you barely break even on this entry level employee at $77.14 / hour or $160,442.

Unfortunately, this break even number doesn’t take into account the risk associated with hiring, the risk associated with the economy in general, and the ubiquitous need get a rate of return on your investment (in this case, their salary and benefits).

Adjusted for risk and return, my estimate is that this entry level developer is costing about $93 / hour or $193,440.

In light of this, I can’t help but chuckle a bit when I see the irrational bias to “bring people in-house” that permeates startups, tech companies, and businesses in general. There are good reasons to bring developers in-house, like gaining more control over their work schedule, enticing a particular person to stay long-term, or security concerns; but I’ve said it before and I’ll say it again, hiring contractors should still be part of your over all strategy.

I think this is why Buink is growing so quickly. We’re not only gaining the expertise to find and engage high quality developer resources wherever they may be (contractor/employee/remote/local), but our processes and practices allow us to even out compete in-house resources.