Obie Fernandez

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.

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

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)

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.