I've now bought a few of these Mental Notes decks for the Hashrocket offices. Each card (52 in all) has an insight drawn from psychology that can help you with brainstorming and problem solving. They arrive in an attractive faux leather box and the whole package seems like a great little Christmas gift. I'm not making any money from this referral -- I just think they're great.
Mental Notes (about $50 incl. shipping to US destinations)
Get the first 7 cards as a PDF download
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:
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.
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...
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.
