Obie Fernandez

My RubyConf India 2010 Talk Highlights

Hashrocket sponsored the inaugural RubyConf India event primarily to support the nascent, yet growing community of Rubyists here, but also due to my personal love of Indian people and culture. I've been eager to get back to Bangalore for the last couple of years and this was the perfect excuse. I deliberated about what talk to deliver to this audience. At all costs I wanted it to be entertaining and provocative. In my opinion, too many Indian service companies are "doing it wrong" -- they stick to the stereotypical modus operandi of offshore providers, with waterfall processes and fixed bid. I wanted to impress on the audience that there is a better, more fun way to run your business. After opening comments by the organizers and Roy Singham, Chairman of ThoughtWorks, I delivered the second general audience talk.

I was charged up with the right kind of anxious energy and this being material that I know inside and out, it came straight from the heart. The talk was not entirely new, previous versions of it had similar material. However, I did go through and restructure the outline significantly as well as adding new material based on the last 12 months of operations at Hashrocket. Luckily I also added some elements that I knew would appeal to my audience -- slides based on the blockbuster Indian movie "3 Idiots". Little that I know how important the concept of "All Izz Well" would prove to be to myself!

On a scale of 1 to 10, I would rate myself a 9 on delivery. I was funny and engaging, making eye contact with the audience members and spending much time in storytelling mode. Unfortunately, I would have to deduct points for making the mistake of dropping the "F-bomb" too many times and as a result getting interrupted and vocally dressed-down by Tina Vinod halfway through! Somehow, although nervousness infected my voice and I started forgetting to breathe, I did pat my heart and tell myself audibly "all izz well, all izz well" and charged ahead with my talk -- the audience got a good laugh at that. Other challenges included the organizer mistakenly telling me I was out of time when I actually had at least 15 minutes left! Luckily my Keynote display presenter mode with its timer saved me. I did pick up the pace a bit, but finished in 48 minutes, just 3 minutes over my alloted time.

Reading List

In the section of the talk about Process and Practices, I mentioned that it is necessary to go "by the book" when starting out. Too many people criticize practices that they haven't properly implemented. You must learn to crawl (so-to-speak) before you can evolve your own practices. 

The list of books I recommended constitute a large part of the orthodoxy of progressive software development nowadays. I asked the audience, how many of you have read at least half of these books. Sadly, only a dozen or so hands (out of 400) shot up. I truly believe that you cannot be effective nowadays without studying these books and applying them to your day to day.

Agile Software Development, Principles, Patterns, and Practices

Agile Retrospectives: Making Good Teams Great

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

Design Patterns: Elements of Reusable Object-Oriented Software

Domain-Driven Design: Tackling Complexity in the Heart of Software

Extreme Programming Explained: Embrace Change (2nd Edition)

Refactoring: Improving the Design of Existing Code

Secrets of Consulting: A Guide to Giving and Getting Advice Successfully

Software Craftsmanship: The New Imperative

Test Driven Development: By Example

The Principles of Product Development Flow: Second Generation Lean Product Development

User Stories Applied: For Agile Software Development

Working Effectively with Legacy Code

 After you've mastered the fundamentals, then you can begin to evolve your process and practices to actually achieve the best results for your context. I must have said 20 times during my talk that "context is king."

 

One of my favorite and most controversial pieces of advice, at least based on the feedback and comments that it generated:

"I don't defend breathing... I don't defend Agile. It just is."

I believe unequivocally that the time to be evangelizing and advocating proven Agile techniques is over. It's been at least 10 years since Extreme Programming hit the scene. We know that TDD yields excellent results. We know that pair programming yields excellent results. We won. To continue being in defensive mode against stupidly obstinate management is a waste of time. It may take a long time from now, but eventually people that don't work in smart Agile ways will fail and go away. As for you, concentrate on being excellent, perfecting your craft and building a loyal and devoted group of clients that will provide you with strong references and testimonials.

If you want to put into practice my advice, refuse to work for clients for whom success is not 100% important. This will necessarily exclude most large enterprise clients, where politics and status quo are as important as results. Those types of clients will drag you down and make you compromise your values. Startups and entrepreneurs usually are 100% focused on successful results. These stakeholders will not be worried about your technology choices or whether you want to pair program and do test-first. They will let you do your job, and the way that you sell them on using you is with successful track record, demonstrated by copious amounts of testimonials from previous clients. I stressed the importance of photos and videos to capture the spirit of your success in a vivid and emotional way. We have the technology -- use it!

 

My advice to fire clients if they need to be fired was perhaps shocking. It shouldn't be. I've only had to fire a client a few times in the history of Hashrocket. That's considering a list of now almost 60 happy clients of all shapes and sizes. The key to not having to fire clients, is to not get the wrong clients to begin with. This is known as being able to "choose your clients." It's not as hard at it seems. Sure, when you're starting out it is somewhat difficult to put this advice into effect and you will make mistakes. That's when it's important to have the confidence to cut ties and look for greener pastures.

"Never allow your clients to corrupt your values or integrity."

The worst thing that can possibly happen, more than having money difficulties, is to corrupt yourself by compromising on your values and integrity due to pressure from a bad client. I'm not saying to be inflexible! I'm saying that there are core values that will allow you to reach for excellence and achieve it. You won't know what those values are when you're starting out, but you can be informed by studying the successful results of others and internalizing that knowledge. Then when you're on a roll and doing great work for your clients, you will realize what those core values are. From that moment on, no matter how big the pressure is, you should not compromise. The more confident you are about your way of working, the easier it will be for you to sell your services and acquire quality clients. The last thing you ever want to do is to appear desperate -- at that point great clients will go away running and bad clients, those that will take the worst advantage of you will become very friendly! Never allow your clients to compromise you. Stick to your values and focus on success.

When I'm evaluating software developers to hire, I don't give much credence to resumes, cover letters, referrals or work history. The only things I care about are work ethic and cultural fit. And there's only one way to determine whether a candidate satisfies my criteria for success -- actually see them in action over the course of a week or more. Since we always pair program, it is trivial to do short contract gigs with qualified candidates and bring them in putting them on multiple real projects. Seeing them working on real code in real situations is very instructional. Again, context is king. Over the course of time, we've created a very desirable work environment at Hashrocket, which means that there is a strong demand for people to come work with us. That means I can diverge easily from traditional hiring models.

Conclusion

Indian business culture, at least the stereotypes that are propagated to the west, doesn't strike me as particularly fun. But if you're doing great work for your clients and sticking to your core values, then you're going to have a lot of success and be able to enjoy it by building a very fun work environment. My final series of slides was a photo set of various fun activities that Hashrocket folks engage in on a regular basis, from participating in user groups, to music and sporting events, games, having parties, drinking and dancing and doing crazy stunts like all jumping into a swimming pool at the same time.

I truly believe that if you're not having fun at work, you're doing it wrong. A happy, healthy environment is one that leads to the best results. However, you can't impose fun on a group by fiat, just like you can't create culture. It has to emerge from hiring happy, progressive folks that want to do the best work possible while sticking to strong core values. This is the final message of my talk and I hope that the audience found it inspiring and worth passing on...

 

What does Quality mean to you?

 

The tag map above is an artifact of a discussion about quality that we had internally at Hashrocket last Friday. The question was: "How do we measure Quality on our projects?"

Many of us felt that money (budget) or rather, adherence to the client's budget was the best way to judge quality. I took that to indicate awareness and constant refinement of the quality/speed ratio.

Interestingly, lifestyle (pace) ranked highly, which I think is a reflection of our core values. A comfortable, stress-free environment and sustainable pace is an essential factor in production of quality software. However, I don't know if you can use lifestyle indicators as a quality measurement.

Customer satisfaction ranked highly as well, but perhaps not as high as the others because customers are not always clued in to the real level of quality in their application? Hopefully some of my rocketeers will chime in with their opinions about that.

The answer with the most votes by far was craftmanship, which itself needs further discussion to define well and understand. As a group, we brainstormed ways to measure craftsmanship and ended up with the following ideas, not weighted:

 

How do you define quality and craftsmanship? Tell me in the comments.

By the way...

I absolutely have to tell you about a great consultant that we retained at Hashrocket to spend a couple days with us discussing quality and helping our management team to figure out growth plans for 2010. His name is Steven M. Smith and I met him at the AYE Conference in Phoenix last month. Besides being a great management consultant, Steve specializes in experiential workshops. You should definitely consider hiring Steve to help you with your software development company or department.

(MSA Series #4) Warranties

BUY THE ANNOTATED MSA+SOW DOCUMENT TEMPLATE BUNDLE!

The documents discussed in this blog posts are now available from me for only $99. Click here to learn more.

 

This is the fourth entry in a long-running series of blog posts about the Hashrocket Master Services Agreement (MSA). Parts one, two and three are also available. When the series is finished, you might be able to piece together a valid MSA document from the examples presented here. However, keep in mind that I am not a lawyer, and that the context of your business may be different than mine. Also, remember that laws vary wildly from country to country and what is presented here might be useless outside of the USA.

Section 5, Warranties

This section of the MSA establishes what warranty, if any, you are guaranteeing on the work performed under the scope of your contract with your client.

The first clause is a bit of legalese stating that each party is authorized to enter the agreement:

5.1 Warranty of Authority; No Conflict
Each party warrants that it is authorized to enter into this Agreement and to perform its obligations hereunder, and that its performance hereunder shall not conflict with, limit or be contrary to any other agreement. 

The second clause of section 5 establishes a warranty on the nature of the work provided, that it will be performed in a professional manner and by qualified personnel.

5.2.1 Professional Manner Hashrocket warrants that all services will be performed in a professional manner using qualified professional personnel. 

Of course, the words professional and qualified are subjective, which means they could be the basis of dispute later on, if problems were to arise. I've been involved in arbitration hearings as an expert witness, testifying on whether work performed lived up to generally-accepted best practices and industry standards. Some of the big factors that affect whether I consider a Rails project to be professional have to do with the quality of testing on the project, and adherence to the Rails conventions and best-practices.
This paragraph edited on 9/23, because the original wording made it sound like I was casting judgment based on my book The Rails Way.

The following paragraphs are of terrific importance in terms of protecting the vendor from unreasonable liability, which is why they are printed in prominent all-caps:

THE WARRANTIES SET FORTH IN THIS AGREEMENT ARE EXCLUSIVE AND ARE IN LIEU OF ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. EXCEPT WHEN OTHERWISE STATED IN WRITING THE MATERIALS PRODUCED UNDER THE TERMS OF THIS AGREEMENT ARE PROVIDED TO CLIENT "AS IS," THAT IS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE AND/OR SERVICES PROVIDED UNDER THIS AGREEMENT RESTS SOLELY WITH THE CLIENT.  SHOULD THE SOFTWARE OR PROGRAM PROVE DEFECTIVE, CLIENT SOLELY ASSUMES THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION, INCLUDING WITHOUT LIMITATION ANY "DEBUGGING."

Significant in this paragraph is the stipulation that work is provided as is, that is, the client cannot force you to continue working on the project if you don't want to do so, or for free. The fact that you are not providing a warranty decidedly does not mean that you are planning to give your client junk. In fact, unless you have a great reputation and client testimonials to back it up, you're probably going to have trouble getting clients to agree to this clause.

There's more to this clause, specifically the stipulation that the client is solely responsible for the "risk as to the quality and performance of the software." The only effective (and moral) way that I know to put that risk on your client is to establish small feedback loops via a well thought-out acceptance process. At Hashrocket, we use the features of Pivotal Tracker to facilitate constant, ongoing acceptance of story functionality and tracking of defects. Delivery of new features and bugfixes happens on a daily basis and so does client acceptance.

The following graph, generated by Pivotal Tracker as part of its Project Points Breakdown report, visually shows progress of a project along the stages of our workflow. The overall height of the bars gives an indication of scope. As the black bars (unstarted work) shrinks, you can see the project headed towards completion.

The vertical axis denotes the number of story points in the project. Note how narrow the bands of green (Delivered) are during the progress of this project. The graph tracks the state of stories on a daily basis. Green bars represent functionality that has been delivered to the staging server for the client to test, but not accepted yet. Occasionally the circumstances cause the client to fall behind for a day or two, but gentle pressure and assistance brings them back in line.

I won't try to explain the legalese of the second all-caps paragraph, simply because I don't necessarily understand it fully myself. This text is in there under the strong advise of our lawyer.

EXCEPT AS OTHERWISE STATED ABOVE, NEITHER PARTY MAKES ANY WARRANTIES OF ANY KIND OR NATURE, WHETHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES RELATED TO INFORMATION OR BUSINESS ADVICE PROVIDED, WARRANTIES RELATED TO OUTCOMES BASED ON INFORMATION OR ADVICE PROVIDED, WARRANTIES OF MERCHANTABILITY OR MERCANTILE QUALITY, WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE OR USE, WARRANTIES OR CONDITIONS ARISING BY STATUTE OR OTHERWISE IN LAW, OR WARRANTIES OF ANY PRODUCTS OR SERVICES PROVIDED BY THIRD PARTY VENDORS.

What I will say is that the wording of this paragraph, and indeed all of the all-caps paragraphs are of supreme importance. There is established case-law about these kinds of warranties, and mucking with the wording is a good way to have the entire clause invalidated.

Finally, the supremely-important liability disclaimer, which helps ensure an angry client doesn't put you out of business.

THE PARTIES AGREE THAT NEITHER PARTY’S LIABILITY FOR DAMAGES FROM ANY CAUSE OF ACTION WHATSOEVER, REGARDLESS OF THE FORM OF ACTION, WILL EXCEED THE FEES PAID OR TO BE PAID BY CLIENT PURSUANT TO AN APPLICABLE STATEMENT OF WORK UNDER THIS AGREEMENT. IN NO EVENT SHALL EITHER PARTY BE LIABLE FOR LOST PROFITS OR ANY INDIRECT, INCIDENTAL, CONSEQUENTIAL OR SPECIAL DAMAGES OF ANY NATURE WHATSOEVER, INCLUDING, WITHOUT LIMITATION, DAMAGES ARISING FROM LOSS OF USE OF ANY SOFTWARE OR HARDWARE, COSTS OF PROCUREMENT OF SUBSTITUTE PRODUCTS OR SERVICES, LOST DATA, LOST PROFITS OR REVENUE, OR FOR ANY CLAIM OR DEMAND BY ANY THIRD PERSON, ARISING OUT OF OR RELATED TO THE AGREEMENT OR THE PERFORMANCE OR BREACH THEREOF, EVEN IF ADVISED OF THIS POSSIBILITY.

If things go completely wrong and lawsuits are filed, you agree beforehand that the maximum liability incurred will not exceed the amount of money that has changed hands. In other words, if you completely fuck up the project, no matter how hurt the client is the most he can do is to get his money back. Absent this stipulation, you could face lawsuit claims in the millions of dollars to account for all sorts of opportunity costs and damages asserted by the client. Luckily this language is fairly common in service contracts.

5.2.2 No Infringement The parties represent and warrant that their disclosure and delivery of any information, documents, software and other materials, and use thereof, as contemplated by this Agreement, will not knowingly infringe or violate any proprietary right of any third party, including, without limitation, any copyright, known patent or trade secret right.

This clause is entirely for the protection of your client. It binds you to a promise not to deliver intellectual property to them that belongs to someone else. In practice this prevents you from taking code that you've written for Client A and selling it again to Client B, without the express knowledge and permission of Client A. Since it's common for software consultancies to produce non-domain-specific code with potential for profitable reuse across clients, a different clause in the MSA establishes a method of differentiating intellectual property produced under billable time, and how the rights to such vary.

5.3 Noninterference with Business
During the term of this Agreement and for all periods thereafter, Hashrocket agrees not to directly or indirectly compete or interfere with Client’s Business in any manner.  Additionally, and without limiting the foregoing, during the term of this Agreement and for a period of two years thereafter, Hashrocket agrees not to, directly or indirectly solicit or induce or attempt to persuade any employee, independent contractor, vendor, supplier, outsourced third-party, director or other participant of Client to terminate an employment, contractual or other relationship with Client, or to enter into a relationship with Hashrocket or into any business organization in which Hashrocket may be directly or indirectly involved.  The term “enter into a relationship” shall include, but not be limited to, acting as a paid or unpaid director, officer, agent, employee of, or consultant to, or acting or participating as owner, partner, manager, member, or shareholder.  During and for a period of two years immediately following termination of this Agreement, Hashrocket further agrees not to (a) directly or indirectly contact any person or entity disclosed by Client for the purpose of taking advantage of a business opportunity, (b) otherwise circumvent a relationship with the Client  or establish a relationship with a party with whom Client already has a relationship or foreseeable relationship with whom Hashrocket has never had a relationship, or (c) seek to establish any rights, including but not limited to intellectual property rights, anywhere in the world in conflict with Client’s pre-existing, herein established, or hereafter established intellectual or other property or proprietary rights.

Interestingly, as I was reading this clause for inclusion in the article, it struck me that its limitations are not mutual. (I'll be fixing that soon.)

All this final paragraph of the section does is to limit you as the vendor from screwing your client in various ways, such as poaching their business model or employees, behavior that would harm your reputation and future business anyway. It's smart to make your clients feel comfortable that you won't engage in nasty behavior as described above. You should keep aware of this clause, particularly as it applies to hiring people that work (or used to work) with your clients.

The next article in the series will cover Fees, Invoices and Payments.

IP and Non-Competes for Employees

Got the following email the other day, concerning intellectual property issues and non-compete agreements:

I was wondering how Hashrocket handles intellectual property and non-competes with its employees.  Is it something that your developers are required to sign as a new employee?

I ask because I got into a deep discussion with my boss about this.  The employee agreement he came up with basically says that he owns any software / web related intellectual property that I work on (on and OFF the clock).  The non-compete section says that I can't start my own business or work for another firm in the same or surrounding states.

I have an issue with him owning the intellectual property for work I do off the clock.  It makes me less motivated to learn and be innovative when I'm tinkering around on my own. I have my pet projects that I don't want him to have any part in.  His argument is that he doesn't want his employees using company resources (software and laptops) to start their own business... which gets into the non-compete.

The answer is an emphatic "NO!" I do not require non-compete agreements to be signed by new hires at Hashrocket. Neither do I try to claim ownership of work that they do off the clock (open or closed source), a practice I learned from and admired at my former employer, ThoughtWorks.

Work done on the clock is a different story. We have the notion of chartered projects, internal initiatives which you are paid to work on for at most 5 hours per week or when paying client work is not available. If I'm paying someone to work on something then Hashrocket owns it, end of story. Actually, there could be some gray areas there, like bringing interesting outside projects in-house in order to make more progress on them, but in that case reasonableness is key.

Anyway, a non-compete agreement (or non-compete clause in a larger contract) restricts employees from engaging in similar work after leaving your firm. I didn't like them as an employee and I don't like them as an employer either, because I think they're fundamentally unfair. If as the owner of the firm I'm insecure about my people leaving and competing with me, then I'm doing it wrong. Keeping my people from being innovative on and off the job is exactly the opposite of what I need to be doing.

The rationale that your boss used with you, that he "doesn't want his employees using company resources (software and laptops) to start their own business", is IMO such a cynical asshole thing to say to anyone. I've heard it before, and it always pisses me off. The thought process doesn't come up at Hashrocket because I require my people to buy and maintain their own computers. Professional craftsmen have their own tools, yada, yada... that's the subject for a different blog post.

And paid software? Really? What do we actually use for Rails development that costs money? Texmate? (Use vim to solve that problem.) I guess Adobe products are a notable exception there, but I still can't bring myself to look at the situation with such shortsightedness as to try and prevent someone from using tools that I purchased for them to further their career. I just realized why that is -- I see my mission as their "boss" to help further their career! (The rewards from treating your employees this way are immeasurable.)

Incidentally, non-compete agreements are not enforceable in California, but elsewhere in the USA they are legally binding, so you should be very careful signing anything with a non-compete clause.

My suggestion to people presented with non-compete clauses in their offer letters or as part of agreements signed post-hiring, is to strike the offending clause from the contract and initial the change. Do that or refuse to sign the agreement altogether. Yes, it takes chutzpah to do what I'm suggesting, but c'mon now... you shouldn't kick off your new job by bending over and taking the corporate shafting from day one. Given the time and expense needed to find qualified hires nowadays, after some initial fussiness from HR or the hiring manager, the whole matter will be forgotten. If they try to force you to sign under threat of termination then you really should be evaluating whether you wanted the job in the first place. Seriously.

I do believe in a particular type of informal non-compete agreement, which I make verbally with all my people. I ask my people to refrain from "moonlighting" (doing side work) of the same type that they do during the day at Hashrocket. As an employer, you should do that too, but only if you pay competitively!

I can't forcefully prevent my people from moonlighting, but I discourage it strongly for one simple reason: burnout risk. Rocketeers work very hard every single day of every single week, putting in 35-40 hours per week doing intense pair-programming. I want them to go home and relax, so that they're fresh the next morning. Think that's an unreasonable request? Don't come work for me.

On a final note, I think it's a good idea, as a company that sponsors open-source projects and encourages open-source work on the clock, to have signed contributor agreements from all employees. I haven't done this at Hashrocket but I'm going to look into it soon.

What Matters

Picked up this little nugget from Jeff on the Spolsky podcast: "what matters is what you deliver to the customer, and how happy the customer is with what you've delivered. There's many, many ways to get there."

That sentiment strikes me as very common and I know that several people used a variant of it to protest the entire concept of a maturity model. It also strikes me as overly simplistic and damaging to its adherents. The customer's happiness is temporal! What actually matters is the customer's happiness before, during and after a project. Delivery itself is not everything nor by itself the most important aspect of a project.

Once you start identifying practices that make your customer happy during the entire lifetime of a project, I think there's significantly less ways to "get there".

Top Ten Attributes of Good Clients

The following attributes are arranged in countdown-style, to denote relative importance to me. I'm the first to admit that it's a subjective and incomplete list. Also, to go beyond "good" and be considered a "great" client, they would have to possess almost all of these attributes and more. No single attribute can redeem an otherwise "bad" client by itself, and many of the attributes on this list are of similar importance.

10.  Friendliness (and camaraderie)

Nobody really wants to work with dry and/or unhappy people or people that don't care that they are part of a team. Friendliness and camaraderie goes a long way towards smoothing over the bumps in the relationship that will unavoidably crop up. The question "Would I want to have a beer with this person?" that we sometimes use as a basis to judge job candidates applies equally well to potential clients. Always acting as a team engenders a more successful and satisfying project for both parties.

9.  Gives you positive publicity in public

Our great client, David Cohn (of spot.us) comes to mind. We did great work for him and in return he has promoted Hashrocket with an infectious enthusiasm that is more than I could have ever dreamed of asking from him. The positive feedback loop of goodwill and results is priceless -- my developers at Hashrocket are actually competing to get the chance to work with David on upcoming phases.

8.  Pushes you to learn and evolve in private

The positive flip-side of enthusiastic promotion in public comes from clients that push you privately to  evolve your internal processes and raise your output. I'm talking about clients that treat you more as a partner than as a vendor, and take corresponding measures to help you improve. Those clients play a non-trivial part in the growth and success of your business via their questions, advice and support.

7.  Realistic expectations

One of the most important skills that a good consultant possesses is the ability to properly set expectations. However, the client needs to be receptive to expectation-setting and be open-minded about evolving their own plans as the relationship evolves and the project takes on a life of its own. I never take this attribute for granted; too many times I've been burned by clients that refuse to acknowledge the realities of software development and the impact of scope creep on schedules.

6.  Involvement

A great client doesn't want to simply hand off responsibility for the project to you. They want you to be their partner and they are communicative and optimistic about your involvement. Involved stakeholders aren't afraid to make decisions. They stay engaged and communicative during the entire project. They don't make you wait hours or days for responses to questions, and they are enthusiastic participants in your acceptance process, allowing you to finish the project without being overly demanding.

5. Open-mindedness

You might have some success with a close-minded client that has money and lets you drive a project mostly by yourself, but in my experience the client has to be highly intelligent and open-minded to understand and apply Agile concepts to their business and allow you to do the same when you're working with them.

4.  Respect

Do you want to deal with a client that second-guesses your advice and decisions? Of course not. This is one reason why it's so critically important to truly be an expert of the domain in which you consult clients. You can't ding a client on this attribute if you are making legitimate errors in your advice and decisions. However, if you know what you're doing and have the track record to prove it then make sure you get the respect you deserve.

3. Has a viable business model

Great clients that are established companies are not in the process of going out of business or struggling through corporate crises that distract them from the success of your project. Great startup clients have a business plan that you believe in, or at worst, you can see some viability in. You might be tempted to work with clients that do not have viable businesses, but it's a risky proposition. Eventually the same problems that are dooming their business will make them aggravating to work with or cause them to default on their financial commitments to you.

2.  Diligence

Great clients takes the time to read and understand the contract they signed with you. They take the time to learn and appreciate your development process. They don't act in ways that subvert your development process. They respond to your communications in a timely fashion. They provide thorough and detailed answers to your product-related questions.

1.  Pays on time

Simply put, great clients always pay what they owe you and they pay on time.

---

Consultants, what are some of the top attributes that you associate with great clients? Share your thoughts in the comments...

Think you have what it takes to be a great Hashrocket client? Contact us at info@hashrocket.com

(MSA Series #3) Work Provisions

This is the third entry in a long-running series of blog posts about the Hashrocket Master Services Agreement (MSA). Parts one and two are also available.

BUY THE ANNOTATED MSA+SOW DOCUMENT TEMPLATE BUNDLE!

The documents discussed in this blog posts are now available from me for only $99. Click here to learn more.

 

Section 4, Work Provisions

This section of the MSA establishes rules concerning the nature of the relationship between you and your client. In particular, you want to make sure that you are not entangled with them in a way that negatively impacts your own business or your ability to service other clients.

The first sub-section, entitled "Independent Contractor" is pretty straightforward in specifying that you are not an employee of your client, nor do you have the right to act as an agent for each other.

4.1  Independent Contractor
For all purposes hereof and in the performance of its obligations under this Agreement, Hashrocket is and shall remain an independent contractor and nothing in this Agreement or in a Statement of Work shall be deemed or construed to create an employer/employee, joint venture or partnership relationship between Hashrocket and Client.  Nothing herein shall be deemed or construed to create an employment relationship between Client and any employee, agent or independent contractor of Hashrocket.  Neither party shall have any authority to insure any obligations on behalf of the other party or to make any promise, representation or contract of any nature on behalf of the other party.

The definition of the term "independent contractor" is important. Clients do not have to withhold or pay any taxes on payments to independent contractors. More importantly, independent contractors ultimately have the right to perform the work in the manner that they see fit. Consider the way that the IRS defines independent contractor: "The general rule is that an individual is an independent contractor if you, the person for whom the services are performed, have the right to control or direct only the result of the work and not the means and methods of accomplishing the result."

The means and the method of accomplishing results for us involves Agile software development techniques and everything else setting us apart from competitors and companies that provide staff augmentation. Preserving our right to work as we see fit is very important to our value proposition.

Note: An independent contractor clause is definitely something you want in your contract regardless of whether you use an MSA or not. I started using this clause in my contracts when I left ThoughtWorks to work as an independent consultant.

The next section deals with the identity of the people that we assign to the client. It also makes assertions to the effect that our personnel are all suitably qualified and experienced to do the work. Use of the word "suitably" might be unnecessarily subjective, but since Hashrocket doesn't hire entry-level resources, so it's not a big deal for us.

4.2  Hashrocket’s Personnel
Unless otherwise stated in the applicable Statement of Work, Hashrocket shall have sole discretion over the identity of its personnel used to provide the Services, provided that Hashrocket shall ensure that the personnel are in all cases suitably qualified and experienced.  Where specific personnel are specified in an applicable Statement of Work, Hashrocket shall use reasonable efforts to provide the Services through those personnel, provided that Hashrocket shall be entitled to replace such personnel with personnel of equivalent qualification and experience on no more than 15 days notice to Client.  Without limiting the foregoing, Client acknowledges that it is Hashrocket’s standard policy not to allocate the same personnel to any one client or project for periods exceeding six (6) months.

Most of the time we do name a particular person in our statement of work contracts, as the lead for that project. Other resources rotate in and out of the project as needed. The lead provides continuity and functions as a liason to the client, the un-named others provide labor and support while giving us flexibility to staff other projects, as needed.

It's also worth noting that I included language in this section which indicates our intention to limit the amount of time that one of our people is forced to be on a particular client, to six months maximum. "Endless" assignments are counter-productive to morale and productivity. (A lesson I learned at other consulting organizations.) Everyone has limits related to boredom and desire for change, so might as well deal with that reality upfront.

The following section ensures that the relationship between Hashrocket and its client is non-exclusive. We can use our people to do similar things for other clients, and they have the right to use other consultants.

4.3  Non-Exclusivity
Client recognizes that Hashrocket’s personnel providing services to Client under this Agreement may perform similar services from time to time for other persons, and this Agreement shall not prevent Hashrocket from using such personnel for the performance of such similar services for such other persons. Hashrocket recognizes that Client may engage other consultants to perform similar services from time to time, and this Agreement shall not prevent Client from using such consultants.

You could argue that this section is needlessly mutual, that you don't need to explicitly give permission to your client to use other consultants. That's true, but I can't think of a situation where you would be able to prevent them from using other consultants anyway. In general, "mutual-ness" clauses seem to soften the adversarial impact of contract terms, so you should use that tactic wisely and to your advantage whenever possible.

(MSA Series #2) Cooperation and Reliance

BUY THE ANNOTATED MSA+SOW DOCUMENT TEMPLATE BUNDLE!

The documents discussed in this blog posts are now available from me for only $99. Click here to learn more.

David Cohn, our Client's Representative on the Spot.Us project

The following two sections of our Master Services Agreement establishes who (as in, a specific person) is responsible for managing the relationship on behalf of your client. This is a critically-important bit of information to establish on a contractual basis when more than one stakeholder is involved in decision-making. Once the work has begun, make sure that important decisions are communicated back and forth through this person.

2. Cooperation
Client shall assist Hashrocket in the performance of its obligations under this Agreement and shall undertake the responsibilities specified in this Section 2 at its own expense. Client shall make available to Hashrocket a designated representative: [name of representative] (“Client’s Representative”), who shall be authorized to make binding decisions for Client regarding the obligations which are the subject of this Agreement, and shall perform or have performed other duties and requirements of Client as set forth in this Agreement or in an applicable Statement of Work.

3. Reliance
Client understands that Hashrocket shall rely upon Client’s Representative as having the authority specified in Section 2 herein and that all official communications from Hashrocket to Client shall be addressed to Client’s Representative.

The Client's Representative should be a party to all important decisions and project communications. If they are not directly the person involved in a decision or communicating it to you, make sure they are at least CC'd (assuming email). These clauses are your protection from accusations of having acted in a reckless or otherwise unauthorized manner.

Make sure to make an amendment to the agreement if the identity of the Client's Representative changes during the term of the agreement. At no point in time do you want it to become vague or unclear who it is that should be giving you definitive directions.

Master Services Agreement (Part 1)

UPDATE: BUY THE ANNOTATED MSA+SOW DOCUMENT TEMPLATE BUNDLE!

The documents discussed in this blog posts are now available from me for only $99. Click here to learn more.

In the months since delivering my Hustle talk at RubyFringe at least a few dozen people have emailed me asking for a copy of Hashrocket's Master Services Agreement (MSA). I consider it a competitive advantage to use a strong MSA and I'm not inclined to just give that document to anyone. However, based on the obvious interest level, I think it's worthwhile to discuss what goes into an MSA so that you can craft one for yourself with the help of your own legal counsel.

This is the first post in a probably-long series where I will go section by section into what I believe constitutes a strong MSA that protects the vital interests of both parties to a software consulting relationship.The intended audience of this series is people running their own Rails consultancies or working as independent contractors, although of course you could generalize the principles given in the series to software consultancy in general.

Why am I doing this? I strongly believe that it's good for the community to base their contracts on terms that are favorable to both parties while protecting consultants from abuse. I've found that the majority of clients act in good faith at all times, but ocassionally you will run into problems that send you scrambling for legal advice. The proper time to worry about whether your interests are protected are prior to entering into a contract, not when you run into trouble.

Just to be clear, I stress the following: I am not a lawyer and strongly advise you to engage your own legal counsel in a dialogue about the use of an MSA and how it specifically applies to your business, especially in countries other than the USA.

The Purpose of a Master Services Agreement

An MSA document lays the contractual groundwork for a consulting relationship that is expected to last for more than one engagement. You don't go ahead and do work based solely on an MSA; it requires addendum documents in the form of "Statement of Work" (SOW) exhibits that define the scope and term of a particular engagement. I prefer so-called "Time and Materials" (T&M) engagements, and with a good MSA you can usually fit your SOW onto one page. (Fixed-bid or scope-based SOWs will generally need to be quite a bit longer than one page, since they must detail the scope on which agreement is based. I'll go into the topic of SOWs in detail later in the series.)

As I mentioned in my Hustle talk, once you have a signed MSA in hand, you have created a client relationship where before there was none. And once you're in a client relationship, in my opinion you are in a much friendlier and more cooperative situation for negotiating contractual work. Later, the benefits of an MSA really start to shine brightly as you gain the client's trust and negotiate follow-on work, since they allow you to keep your SOWs small and easy to understand for all parties.

That said, let's proceed with how an MSA document is structured. I'll leave references to Hashrocket in place, but fields that should be filled for each client are identified like [this].

Preamble

The MSA document should be drafted on company letterhead, so the first item on the first page is your company logo, followed by the title MASTER SERVICES AGREEMENT.

The first paragraph identifies the document and a few key terms, as follows:

This Master Services Agreement (“Agreement”) dated [date of the agreement] is made between Hashrocket, Inc., a Florida corporation with its principal place of business at 60 Ocean Boulevard, Suite 11, Atlantic Beach FL, 32233 (“Hashrocket”) and [Client Company Name] a [State] [company type, i.e. LLC], having offices at [Address] (“Client”).

Simple enough so far. The next few paragraphs go under a heading of RECITALS:

RECITALS

WHEREAS, Hashrocket is in the business of computer software consulting and development services.

WHEREAS, Client desires to engage Hashrocket to provide software consulting and development services, and Hashrocket agrees to perform such services, on the terms and conditions set forth herein.

WHEREAS, Hashrocket and Client agree that this Agreement shall apply to all such future services.

Again, simple stuff, although we start getting into some legalese with this "whereas" stuff. The terminology "Computer software consulting and development services" is probably something that you should think about customizing to communicate exactly what you see your firm as providing.

Finally, you finish off with a paragraph under the heading of AGREEMENT, where the legalese starts to get a bit heavier:

AGREEMENT

THEREFORE, in consideration of the mutual covenants contained herein and other good and valuable consideration, the receipt and sufficiency of which is hereby acknowledged, the parties agree as follows:

Section 1: Services

As I said before, the MSA doesn't specify the work to be performed, that's what SOW documents are for. Therefore, Section 1 lays out the rules for describing the services in SOW documents. Since the identity of your client is established in the beginning of the preamble, it is sufficient to refer to them as Client in the rest of the document.

Hashrocket agrees to perform services for Client as described in one or more Statements of Work, the form of which is attached hereto as Exhibit A (the “Services”). Any conflict or inconsistency between the provisions of this Agreement and any executed Statement of Work shall be resolved by giving precedence to the executed Statement of Work under which the Services are to be performed and then to this Agreement.

Note that precedence is given to the SOW over the MSA. The reason is that the MSA is considered the more general document. Although you'll put information in it about things like invoicing and payment schedules, there are usually items in the SOW that are more specific or outright changes from the general rules of the MSA.

---

That's it for now. If you're not already subscribed to my blog, now might be a good time to do so. I will publish the remainder of the series over the course of the next couple of months.

Upcoming RubyFringe Talk: Do the Hustle

Sales is an art that very few technical people have mastered. Very few. It takes patience, confidence, empathy and whole slew of other skills mixed together -- a brew that is seriously difficult for many geeks to figure out.

In my RubyFringe talk, I will leverage my experience successfully selling consulting services for both Thoughtworks and Hashrocket to answer some of the following questions:

• How do I figure out how to price my services?
• How do I figure out the kind of work I want to sell?
• How do I write contracts and statements of work?
• What about proposals?
• And RFPs? (Requests for Proposal)
• How do I close the deal?

The word "hustle" can mean "to sell aggressively" and has a mostly negative connotation, but the main reason I used it in the title was for catchiness. (And, I guess, also cause I like the disco song of the same name.)

I hear there's only a few registration spots left.