Obie Fernandez

Liveblogging: Lean Startup Machine Chicago

9:51pm Sunday

Well, we didn't win the grand prize, but I'm very proud of our team. We worked really hard and got a ton of useful advice and encouragement from the organizers, judges and mentors. Big thanks to Eric Ries and major props to Bernhard, Brandon, Eduardo, Trevor, Kyle, and Ben for putting on such a kickass learning event.

4:13pm Sunday

Whew! Presentation is over. I think we got our story across correctly. Now we sit tight and watch the rest of the competitors.

Companion Links for KickEatery.com Presentation

First MVP is our landing page, which is unchanged at KickEatery.com. After this morning's major pivot we linked that landing page to a followup form to help us gauge adoption at our initial commitment levels of $10 to $100.

Thanks to good participation from twitter followers and a small investment in Facebook ads, were were able to drive a healthy amount of traffic and conversions to our landing page. We even did some A/B testing around our tagline. Here is a screenshot of our Unbounce dashboard showing conversion stats of approximately 3%.

Throughout the weekend, we also created a Startup Canvas to help us achieve a shared understanding of our business concept.

3:27pm Sunday

Finally the presentations and judging kicks off. First up is RoutineMachine, which is a tool to help people be accountable over the course of a 30 day period. The presenter just told us he got the best reaction/responses to man on the street surveying by telling them they were part of an "Apprentice-style reality tv show. Seriously..." The room got a good chuckle out of that.

2:52pm Sunday

The heat is on. Second MVP prototype is deployed. We're waiting for the final "pencils down" from the organizers as Rob puts finishing touches on our slide deck, which now includes a breakdown of our hypotheses and assumptions, "pivot table" showing how our business model evolved over time, screenshots of our MVPs and a revenue model.

Excited about our potential, but I've zoned out of what the other teams are doing so I have no idea if we'll be in the running for the final $1000 prize.

12:08pm Sunday

Thank goodness that we "fell back" to DST last night. That extra hour of sleep was very needed.

The team is now over an hour into a heavy discussion about pivoting. We've split into a few different work streams to handle the presentation, number crunching and next version of our MVP. If we validate and adopt this pivot then KickEatery will have an actual product and profitable business model. Things are getting very interesting at this point.

9:00pm Saturday

Launched! Checkout kickeatery.com (In case you didn't figure it out yet, our name is inspired by kickstarter.com)

Looking back, I'm pretty impressed that we did some fairly extensive customer research and achieved our MVP in less than 12 hours. Total cash outlay: approximately $60 for Facebook advertising and registration of the kickeatery.com domain with Namecheap.

Wait, MVP? Really? Well, I guess the point is that for now the minimum viable product is a website to validate the concept and make sure that the investment that we would put into creating a feature-filled application would be worth it. These lean startup guys are definitely on to something.

Since the team has now dwindled down to just three members, we're looking at how to wrap up the day. We're gradually filling up our Startup Canvas as well as brainstorming how we can prove the concept prior to an actual website implementation. I'm thinking that a successful fundraising effort would probably garner news coverage and serve as good PR fodder for publicity and showcasing on the kickeatery homepage in the future. My Jacksonville Beach peeps can look forward to a "Bring Indian Food to the Beach" campaign in the near future. :)

7:41pm Saturday

After a quick break for dinner and socializing, the landing page is almost done. It was easy thanks to Unbounce. We're still tweaking a more detailed survey that we plan to send to the folks that gave us follow up information on the previous survey, but that should be done soon. We're also working on a Startup Canvas to draw out information that we'll need for our presentation tomorrow.

5:19pm Saturday

Relocated to Hashrocket Chicago for a change of pace and better chance of getting Rob's laptop online. (I also wanted to pick up some yummy raw food at French Market before they closed.)

Now we're talking about followup to the survey results, which indicate enough interest in the core hypothesis.

A quick look at the list of deliverables for tomorrow indicates that we need to boil the information we've collected so far:

• Make a clear statement of business assumptions (i.e. problem, business model, etc.).
• Validate or refute assumptions based upon user or customer feedback.
• Create a clear MVP (or MVP spec) that sheds light on assumptions via real data.

We're thinking our MVP (Minimum Viable Product) might simply consist of an ad campaign and a landing page to collect information about our champions.

3:30pm Saturday

After a tough iteration, we finally agreed on a survey for restaurant owners. We needed to validate the questions in some way, so I called up my friend Guy, who owns a local Thai restaurant in Jacksonville. We got some interesting insights from the conversation, especially around the importance of competitors within a 5 mile radius.

Now we're trying to figure out if the data collected means we need to "pivot" from our original concept.

1:35pm Saturday, Nov 6

Bernhard Kappe is mentoring our team and telling us to not put the cart before the horse. We need to determine that people have the problem we've identified before we propose the solution that we're discussing. Where is the pain?

The group believes the pain is there for the consumer. For the restauranteur, we don't know and we need to find out.

1:11pm Saturday, Nov 6

I'm currently participating in Lean Startup Machine, a weekend-long startup competition that conforms to Lean Startup principles, a method of using customer feedback to rapidly iterate your product to reach product/market fit.

Eric Ries kicked off Friday evening's event followed by networking and pitches. Kevin Taylor of Obtiva advised us to leave Agile practices for when fea Brant Cooper and Patrick Vlaskovits, authors of The Entrepreneur's Guide to Customer Development also gave brief presentations and are functioning as team mentors for the duration. Participants selected ideas and formed teams to work on their project over the weekend. On Sunday, teams will pitch their business and Minimum Viable Product to a panel of well-known entrepreneurs for cash and mentoring.

I pitched my idea and enough people liked it that I am now leading a startup team. The root of the concept is the lack of cuisine diversity within particular neighborhoods and suburbs. My gut (haha) says that there is pent-up demand that would make itself manifest if given the right vehicle. The backstory is that for at least a few years I've been ranting about the pathetic fact that there is no Indian food near Jacksonville Beach. We have to drive at least 20-30 minutes to the Baymeadows area of South Jacksonville, where there are at least half-a-dozen Indian restaurants.

Our hypothesis is currently split in two parts:

 

1. Customers with pent-up demand will pledge seed money to attract a particular type of restaurant to their neighborhood.
2. Restaurant entrepreneurs will be inspired by a successful campaign to open a restaurant that fulfills customer demand.

 

It's been a lot of fun so far. My teammates and I are currently trying to validate the first hypothesis and the assumptions behind it using a quick 4-question survey.

Competitive Research Series: Part I

Early this year, I commissioned a competitive research project with the goal of producing real insight into how other web design and development shops out there do business. The results were interesting, to say the least, but due to time constraints I haven't been able to do much with them. I'll be sharing highlights of the data with you over the coming months, starting with this introductory blog post.

First, an explanation of how the data was gathered. First we helped our researcher, a potential entrepreneur with a good idea, to flesh out his web startup concept (involving social media and e-commerce). We crafted the scope of the project to correspond to the type of complex web application work that Hashrocket has designed and built on budgets ranging from 100 to 500 thousand dollars. The project details were crafted well, probably beyond what was necessary in order to do the study.

Over the course of a month, our entrepreneur painstakingly contacted a total of 103 web design and development companies, primarily via email. 54 of those companies followed up to some degree or another, ultimately leading to in-depth conversations with 42 of them. That leads to one of the first eye-opening revelations of this study: Almost half of the companies we contacted didn't follow up properly or at all. In fact, about 6% of our initial contact emails bounced! Has that much of the industry gone out of business this year? Or is email that unreliable a contact method?

It is difficult to discern whether the firms that ignored initial contact did so because they were careless or simply too busy. Perhaps the work didn't interest them? One well-known firm had an auto-reply message to the effect that they were too busy to respond to anything other than urgent requests, adding that their lead time for starting new projects was at least 3 weeks or more. Ballsy.

I will not be identifying any of the companies researched, although I will say that many well-known shops were on the list, including one behemoth that ended up being excluded from much of the results by merit of being such an outlier (ahem). The list of companies to contact was first drafted by naming the shops we know off the top of our heads, then enhanced with shops found via Google searches and a variety of online resources including:

    ⁃    FirmList.com

    ⁃    RailsDevelopment.com

    ⁃    Sortfolio.com

Our entrepreneur purposely tried to contact providers with a variety of technology specializations (not just Rails shops) and did not express a preference for a particular technology, instead asking the shop to give their preference. As you can see in the graph below, we were able to include a healthy number of PHP and .NET shops.

Somewhat surprisingly, but perhaps due to our small sample size, none of the shops expressed a preference for Python. We also were not able to talk to that many Java shops. Perhaps Java really is losing steam as a mainstream web technology?

The size of the companies studied varied quite a bit. In a future entry in the series I plan to analyze a bit more carefully the smaller end of the spectrum, but for now I'll simply give you a graph showing the distribution by headcount.

We also got data on the years in business of the companies contacted and what kinds of people they employ.

 

By itself, the years in business distribution seems somewhat even and perhaps doesn't say much, but I hope to break down some of the other data in relation to maturity of an organization and hopefully yield some interesting results.

On the other hand, the employee type breakdown did surprise me. The vast majority of the firms we spoke with claimed to employ only full-time employees (FTE) rather than a mix of FTEs and contractors. Even less used only contractors, with a significant fraction of the mix being shops with a main market presence and offshore development resources. 

 

When we asked companies about the average years of experience of their developers, most said "it varies," which we took to mean that junior developers would be involved. Fifteen percent gave us a number between 1 and 3 years, which doesn't inspire much confidence! 

 

Over half of the companies we spoke with were willing to share annual revenue figures, with the rest declining to answer for confidentiality reasons or simply not knowing.

 

We're guessing that many of the numbers we were cited were make-believe, because the variety of revenue figures was very surprising, especially when analyzed in conjunction with head count to derive per person revenue numbers. Could the spread in profit margins really be that wide?

 

 

The next entry in the series will delve into hourly rate data, which I'm sure you don't want to miss.

 

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.