Like many small technology companies, Snooty Monkey makes the mortgage and the payroll through work for clients while carving off time to build products. It’s not ideal, but it beats the alternatives: working a corporate job for years to save up a financial runway, or ceding autonomy to outside investors, who of course get a say in how their money is spent.
Once you have built a successful services business in a niche that matches your passions and interests (in the case of Snooty Monkey, building brand new products for entrepreneurs), you can start to ask yourself: this is profitable; this is fun; why not just do this forever?
Even if your long term goal is to have a services business (or be a freelancer) and build products for other people, you should never stop building your own products. There are important professional obligations that client work brings. Being free at times from those obligations is critical for long term success.
#1 Learn radically new stuff
When working for a client, you have an obligation to manage technical risk and to properly represent your experience and skills. Both of these work to prevent you from learning radically new stuff “on the clock”.
Managing technical risk involves choosing a sound technology that’s suited for the task at hand, that’s robust and relatively bug free, and where you have a reasonable assurance that they’ll be future development to fix bugs, fix security issues and adapt to new operating systems and language versions. You also are obliged to choose technologies that are readily picked up by someone else should you get hit by a bus. If you are the only Logtalk programmer in a 4 state radius from your client, it’s probably not a great idea to build your client’s project in Logtalk without their informed buy in.
Representing your experience and skills is all about communication and honesty. If you literally wrote the book on a given technology, say so. If you are waiting for your copy of the book to arrive from Amazon, and will know more next week once you get to chapter 2, say so! When hiring freelancers or project teams, clients are usually paying for more than your raw intelligence. Part of your rate derives from your skills and experience with a technology. If you don’t have said skills and experience, many clients won’t be interested in you learning them on the job, and others may expect a break in your usual rate until you come up to speed. This is a reasonable position for your client to take if your usual rate properly reflects the skills and experience you bring to the table.
That’s not to say a given client might excuse you from all these obligations and give you free reign to learn a risky new technology that you have no experience with on the job. But that’s a double rainbow client. Don’t expect to have them.
None of this precludes trying new things and continual improvement. You also do your clients a disservice by never learning, adapting and improving. Each project should be better than the last. Always been a Test::Unit user but want to use RSpec for the next project? Want to switch from your tried and true restful-authentication to the new hotness, authlogic? These evolutionary improvements are not what I’m cautioning against in client work. It’s the big disruptive changes that make you suck for a long time until you “get it” and that you have a good chance of deciding are a mistake and abandoning.
So how do you make those big leaps forward that require a huge step back first? Do them on your own time of course. And rather than building the blog sample from the book or some other toy project, you might as well try building a useful product. You’re going to invest the time in the new technology anyway, if it turns out to be great stuff, it’d be great if you got a fantastic new product out of it along the way.
In that vein, Snooty Monkey kicked off the development of a new product last week; the idea for it has been kicking around since Summer. Some weeks we’ll spend no time on it, some weeks we’ll be able to carve out a few hours or a whole day. Our “rule” (admittedly arbitrary) is, everything has to be new. The main purpose of the project is learning and having fun. The secondary goal is creating the product (if it was the primary goal, we’d use the tried and true technology stack).
Out: MySQL In: CouchDB
Out: Ruby In: Erlang (the 1 tiny exception to the rule, it’s new for all but 1 of us)
Out: Rails In: Nitrogen
Out: XHTML In: HTML5
Out: JavaScript In: CoffeeScript
Out: AJAX interval polling In: Comet and Web Sockets
Out: CSS In: LESS
Reader’s imaginary Socratic dialog section:
Q: Is this choice of technology driven by the needs of the project or is it a bit gratuitous? A: Uhh… the tail is wagging the dog.
Q: Will you be able to build the new product as fast as you would if you used a tech. stack in your comfort zone? A: No.
Q: Will you be able build a successful product with it? A: Dunno.
Q: Will you learn a lot? A: Hell yeah!
Q from a Geek: Is it going to work well to combine CoffeeScript with all the JavaScript generated by Nitrogen. A: Dunno, waiting for that CoffeeScript book to get here from Amazon. We’ll find out. But I think you missed the point. Go back to the top and re-read the post.
#2 Reconnect with your inner customer
The other great reason to not stop building your products is empathy. Being a “customer” of your own services stokes the flames of empathy. It’s important to walk in your customers shoes, to put yourself in the position to care about the same things they care about. Are you sitting your customer down for the three legged stool talk (“Sorry Jack, scope, time or resources; only 2 can be fixed…”) yet again? When was the last time you sat yourself down for the same talk?
Treat yourself like you treat your customers. Don’t give yourself special breaks and exceptions you wouldn’t give them. Make a budget (in time, not dollars) and try to stick to it as they have to. How easy do you make sticking to the budget? Are there things you are doing, such as lots of tangential work on the project that’s not core, or a lack of timely visibility and tracking that make it hard to stick to it? Or are you so fixated on the budget that you sacrifice the other goals of the project?
Most important to rebuilding the empathy with your clients is to scratch your own itch with the product. Build something that you are madly passionate about, and that you are the customer for. It’s easy to slip into a calloused, distanced, assembly-line mode of working when building product after product for customers. You need to rekindle the spark that comes when you are building something that you are truly obsessed with. By reminding yourself what it’s like to care so much about the outcome, you’ll be better able to empathize with your clients.
startups-i-like liked this
jelleprins reblogged this from snootymonkey
snootymonkey posted this
