What's A Non-Programmer To Do? (How I keep myself busy.) (spencerfry.com)

154 points by spencerfry ↗ HN
I wrote a comment for Hacker News back in August in response to a guy's question about what a non-programmer should do in a startup. My response received 164 up votes and is the tenth most popular comment of all time. In this article I add some depth to most of my previous twenty bullet points.

Original comment thread: http://news.ycombinator.com/item?id=779378

33 comments

[ 3.6 ms ] story [ 73.5 ms ] thread
I wrote a comment for Hacker News back in August in response to a guy's question about what a non-programmer should do in a startup. My response received 164 up votes and is the tenth most popular comment of all time. In this article I add some depth to most of my previous twenty bullet points.

Here's the original thread: http://news.ycombinator.com/item?id=779378

Thanks!
Great mix of more general advice (like the previous set of bullet points), combined with specific context around your experience. It's a nice change of pace from the "your startup has to do this" blend of articles because it acknowledges your biases with the appropriate context.

Thanks for sharing!

  2. Doing all the business related tasks.
  3. Doing all the customer service.
  4. Handling all incoming e-mail.
  5. Doing all of the social networking stuff (facebook, twitter).
  8. Tracking all of our expenses, etc., into Excel and getting everything ready for accountant (see 7).
  13. Handling payroll. I do that.
  14. Dealing with the bank accounts. I deal directly with the small business rep at our bank.
  16. Handling all incoming advertising requests, setting up their campaigns, etc.
  17. Dealing directly with all our merchants (credit cards + PayPal). Dealing with the very few chargebacks we receive.
  18. Paying all of our bills (server expenses, software licenses, domains, advertising, etc.) and monitoring our cash flow.
  20. Anything that requires a phone call. Incoming or outgoing.
Frankly, this sounds like work for an administrative assistant more than an equal equity partner.

  1. Writing the copy for the website. Mainly keeping the support documents up-to-date.
  6. Doing all of our marketing. Handling Google AdWords, banner advertising, text advertising, etc.
  7. Dealing exclusively with our accountant
  9. Handling all legal work with our lawyer.
  11. We all come up with ideas for product development.
  10. Doing all of our networking. I'm the guy that goes to all of our relevant events.
  12. Blogging. I do all the blogging.
  15. Market research. I find out as much as I can about our competitors, what they do, etc. I also learn about our market as a whole.
  19. Pitching. I handle all of that.
There is no reason a technical founder wouldn't be able to do these things and continue to work on the product.
I'm a technical founder and 1) I certainly don't WANT to all of the above listed things and 2) I know I certainly wouldn't do these task as well as someone who specializes in them. A lot of these jobs are very important and should be done right. They shouldn't be done by a programmer who sees them as an inconvenience.

If the scope of business and the size of the startup justifies it a business minded founder can certainly be a good thing.

Hm, I think it's all a matter of cost/benefit. What value would hiring an administrative assistant bring compared to just having an equity founder with more of an incentive? At least the founder can abstract everything business related away, so all you need to do is code. And, to me, that's hard enough as it is.
More incentives and the communication barrier may be lower.
Plus I would never outsource copywriting. Good way to end up with a FAIL.
Thanks for your comment. I guess you should look into outsourcing / hiring / automating some of the more mundane tasks. Though for the second group of tasks you outlined, having a founder specialize in them, so that the other founders can focuse on the technical side, sounds like a good thing.

And it allows the business guy to grow. Eventually you will want to have a business guy anyway, so it's a sound approach to train him from day 0.

Spencer,

As a very technical, yet non programming, individual who is interested in start-ups and entrepreneurship, I really appreciate this list. As I work on my MBA and dream of one day starting my own company, I often wonder if I should relearn programming or focus on other skills. The more I think about it, the more I realize that my time would be better spent actually running a company and letting others program. Your list is a fantastic resource for the things I need to be thinking about and learning in order to be better prepared!

Thank you! I actually applied to business schools right before I started working on Carbonmade. I pulled my apps as Carbonmade began to grow. I think people lose sight at the fact that building a product -- design and code -- is just one piece of the puzzle. It's a very important part (arguably the most important), but the things I listed make up a sizable amount of work that must be done well. Companies cannot survive, or at least cannot grow to hundred million dollar companies, without excellent CEOs, sales people, marketing people, support staff, project managers, etc.
Yes. Though it might still pay off to set aside an hour a week to do some programming. Just so that you do not lose touch with your programmers. (I don't know, if you can find the time in a startup, but in a bigger company it may be worth it.)
I messed up your 164 with an upvote :)

It was a little depressing to read that list b/c I have to do all that stuff and code, and I'm doing it part time. Very jealous of the people working full time.

Haha! That's rough. I was computer science for the first two years of college back in 2002 and 2003. I had a few small projects that I worked on where I had to do both the programming and the other stuff as well. I found out early on that I was a lot better at the other tasks than I was at programming so I looked for co-founders that were talented programmers. You may want to figure out what you do best and then pair up with another person.
Before Spencer joined Carbonmade, I was right there with you. As the coding half of what was our two person design firm (Carbonmade was a side business at the time), I also handled the finances, server administration, and the onslaught of miscellaneous tasks that come up. It was getting to the point of being overwhelming, and things begin to be neglected. The least of which was our support account.

While today, it's amazing to have Spencer taking care of these things, delegating my workload in the beginning was a bit painful. We had stacks of paperwork to exchange and coordinate with our lawyers and accounting company. With OCD, was also difficult not to nit-pick ever single detail in the beginning. But as it began evident that he knew his shit (having ran several companies before joining us as an equal partner), these tendencies quickly subsided and our productivity skyrocketed.

Carbonmade is a triumvirate: one designer, one programmer, and one business guy. I think this is the Holy Grail for a three person startup. I think PG would agree with me?
For a three person web-startup. I guess you have different tasks and roles in an oil-exploration business. Though I guess having a business guy and a technical guy can't hurt.
Yes. Though I'd recommend another _first_ language. C is a fine second or third language.
What language would you (or others) recommend?

I'm just curious, as I'm doing Ruby (for the obvious RoR), but python also seems smart.

Or would recommend people start more basic, like with Scheme or something? Scheme was my true first language in school way back when, but I think others could benefit from a comment that dealt with some advise on recommendations about languages that I'm not qualified to give.

Python is a nice language because of the everything and the kitchen sink approach to the built-in libraries. It also has a clean look because of the significant whitespace. Ruby is another nice language. It seems to be a bit more esoteric as far as some of the more advanced language features but for the beginner the language lets you accomplish it in more than one way. C is a fine language too but you will spend your time working on memory protection instead of getting things accomplished fast. It is more useful on memory constrained systems.

Every language is useful in a different way and each have a domain or two in which they excel at.

The real takeaway is that the shift from knowing one language to another is fairly easy. The real trick is knowing the idioms of the particular language and how to use them.

http://www.pythonchallenge.com or http://rubyquiz.com/

C was my 1st and it worked out fine - curious to know which language you'd recommend.
Yes, C can work fine.

I learned C64 Basic, QuickBasic, C, Pascal, some Prolog and Lisp, Forth, Redcode (assembly), more Scheme, C++, and Python, Java. (And later Clean and Haskell.) I would not call this an optimal sequence. And it heavily overlapped. E.g. I only really got Scheme after playing around with Python a bit. And for some strange reason, I saw the light of higher order functional programming only when I began with Clean. In Scheme it felt too clumsy.

But what's `optimal' depends on what your goals are. If you happen to be in that part of the population that just can not not program, then you will eventually learn how to do it. Even if somebody locked you up in a dimly lit closed with just a reference manual. Just the amount of fun you will have, and projects you accomplish will vary. I learn programming languages for fun.

Python has a very nice library called PyGame that let's you produce some interactive graphics and sound (i.e. a game) quite fast. It's nicely documented. And in PLT Scheme images are first class objects, you can even embed them in your source code. I looked into Squeak, a smalltalk implementation, once, but it did not click for me.

If I had to start again on the same hardware, I'd spend less time with C64 Basic and tried to get Forth for the C64 or do some assembly there. On modern hardware I'd take Python as the first conventional language, and Haskell or Clean as the first real language. (I am not sure whether I should start with a conventional language.)

No. This guy is making it possible for the developers to code and design. If he started doing their work, they'd have to start doing some of his work.
Market Market Market...Sell Sell Sell. Even, if your product is not ready yet, start building relationship with your customers and other helpful people.
One thing I'm curious about - I don't see user research on the list, the closest ones to it are the customer support and maybe the market research as well. Does your designer cofounder run usability tests? Or do you all take the 37signals approach and rely more on a combination of your gut instincts and customer feedback?

Just to disclaim my bias: as a designer, I've slowly dropped the more esoteric UX/interaction tools like card sorting or mental models over the last 2-3 years as I've focused more on startups but usability testing is the one most resistant to being dropped and I still see it as pretty much the gold standard of design feedback.

Dave took the gut instincts approach for the current version because he built Carbonmade for himself originally rather than for anyone else. The new release that we're working on is a combination of gut instincts and user feedback. Your users don't always know what's best, so you can't base new features or approaches on user feedback alone.

I think we'll get more heavily into some A/B testing, but really only on select pages. For example, I want to set up A/B testing for our new sign up page. Right now you can't upgrade immediately when first signing up. You instead need to sign up for a regular Meh account and then upgrade to Whoo! later. I want to test allowing people to upgrade immediately when they first sign up and see how that goes.

"because he built Carbonmade for himself originally rather than for anyone else"

That works pretty well for a v1, Tim O'Reilly had the colorful phrase "fishing with strawberries" to explain why it works so well:

http://www.oreillynet.com/pub/a/oreilly/tim/articles/straw.h...

I'm down with user feedback and a/b tests, I guess I was asking specifically about usability testing though since I don't see it talked about much around here. It's categorically different from the other stuff and yields much more qualitative insights (why did they just do that?) versus the more quantitative results (which page layout has a higher conversion rate?). Plus it's actually a hell of a lot of fun to do! If done right.

Wow! Brilliant article. Love it.

"On one level, the difference between the two points of view is simply the difference between selling one on one to a very targetted prospect and selling to a mass market, where you are casting a wide net, and some set of potential customers will match your own "strawberry" profile."

Yeah, I think one thing to add to that list is testing. I'm not a programmer, but I have often been able to root out bugs that really affect customer usability (and often can save our programmers time by finding the specific variables that contribute to the bug...which can make fixing them faster).

Product testing is really everyone's jobs (in software it's much easier to manage your app if it's something you engage every day).

Great list though!

I'm actually the guy that started the thread, and I really appreciated your well-thought-out response. Since putting that up, things have picked up tenfold for me, I had been doing a lot of the things you mentioned, but our customer base was small, and all the little stuff really hadn't reached a level where it was challenging to organize. Boy did it change, and I'm really happy for it. These days I'm finding myself getting buried in an ever-deepening list of must-do items. It's sometime stressful, but then I think about having too little work and smile, so it all works out. A couple of specific comments about your post:

1) You said that the business guy should keep his eye on the macro focus. I find myself doing this to a point of fault. One of my cofounders works in the same room as I do and one day he just had to say: "Look, I can't work with you talking about the future all the time, we need to keep our heads down and develop at this exact moment." I'm curious: do you guys have physically separate work spaces or are you just better able to control your forward looking urge than I am?

2) Customer service: I've taken over most of this, and it's been great. I love interacting with customers (even if I get some requests about a hundred times), and as we grow, I'm ecstatic to report it's eating up larger and larger chunks of my day. Eventually I'll have to figure out a way to continue producing new content (I double as the designer, but I traded that workload with our third guy for the book keeping), but for now it's great. I was curious, we have a one day policy so that people always get a response in a day, oftentimes it's much faster, but sometimes we'll be focused on designing a new feature together, it slips. People have told us they don't mind getting a response one or two days after, do you think it's worth investing high energy in making sure it's super fast?

3) We've been having troubles with our user's guide and we're thinking about pulling it altogether in favor of a more dynamic feature-specific overlay system. We're keeping the FAQ though. Do your customers appreciate a user's guide because it's a collected resource, or do you think it would work as an enhanced tooltip system? This is just personal style, but I was curious.

Again, I really appreciated your comment back when I posted, and this blog post is great. Thanks for helping me out.

I'm stoked that I was able to help you. That makes writing this article completely worthwhile.

1. Dave (designer) works in our NYC across office right across from me (http://www.carbonmade.com/blog/2009/09/24/150000-portfolios-...). Jason (programmer) works back in Chicago and is moving to NYC in May or sooner. What I find works best is to plan for the future, but not to necessarily bring it up with the other folks until it's time. I actually find myself saying "let's focus on the present" a lot more than I find myself sharing my thoughts for the future. Sharing those thoughts are best left for when you've completed a new version or a major segment of your product. Keep everyone focused on the task at hand and bring out your plans for the future only at the appropriate times.

2. Someone mentioned in a response to one of my posts (and I'm paraphrasing) that "a response to a support ticket takes the same time today as it does tomorrow, so you might as well answer it today." I think that's very true. You shouldn't let it derail you if you're deep in concentration, but if you see it and you can take a minute to respond, why not respond then and there? By responding it won't weigh on you for the rest of the day and affect your other work.

3. What troubles have you been having? I think the decision of having a user guide or not should be based on whether your product needs one or not. Luckily, ours is simple enough that a few FAQs do all the work for us.

Let me know if you have any other questions here or via email [at] spencerfry [dot] com. I'm also open to having lunch/coffee/beer with you if you're in NYC at any time.