

Ask YC: The business process sweet spot - wheels

In the last 6 years I've worked for two different companies, Company A with 40,000 employees, Company B with 150.<p>At company A, we had a process for everything.  The joke was that to have the trash taken out you had to fill out a support ticket, wait a week, contact an escalation manager, negotiate a new priority and then if it was determined to be mission critical, you'd get your bin emptied in two weeks.  Processes often got in the way of just getting stuff done.  Often by the time you'd gotten an ok for a new project (even if you only needed two weeks to do it), it was 9 months later and you'd forgotten why you wanted to do it in the first place.<p>At company B, processes have evolved organically, and usually poorly.  Time tracking is based around emailing around Excel spreadsheets and having an intern copy and paste them all into a bigger Excel spreadsheet so that an accountant can crunch the numbers.  Projects and budgets are planned the same way.  There are at least three different ticket systems, none of which are connected back to planning unless someone extracts the stuff ... and you guessed it, pastes it into a spreadsheet.  Document management is just dropping stuff one of the dozens of SMB shares on the filer.  We use AIM for communicating internally.<p>When looking at founding a company, it seems important to find the middle ground.<p>I'd like to provide some infrastructure -- we've already got a Jabber server, version control, and a wiki for basic document / idea organization.  These, plus some simple groupware seem to be a given.  I've debated playing around with open source CRM (SugarCRM) and ERP (Compiere or OpenBravo maybe).  On one hand, I'm worried about going overboard, and slowing us down with overly rigid tools that don't really get all two of us anywhere.  On the other hand, we're not planning on going full on until this summer and it seems like this is a good time to knock out mundane details.  If things really heat up, it seems like it'd be really easy to drift into Company B-like patterns, because there wasn't the infrastructure or impetus to do things better, what with distractions like the company surviving and all.<p>What have been your experiences with seeing processes grow up from two man shops?  Does it even make sense to be worrying about this stuff right now?  If you don't mind, I'd be interested in your company size and age in responses.
======
suboptimal
I'd go with 1) what works for you, 2) at that time, 3) with an eye toward
future expansion. What #3 means is if you go with a simple solution per #1,
make sure you can migrate your data.

For example, I've seen many companies grow from using Excel to Access to SQL
Server. This path seems quite natural, and despite the issues associated with
Access databases designed by non-DBAs (ahem), the process generally works
(with the assistance of those of us who get paid to help).

Company B's problem is they don't realize they've outgrown their system, and
need to evolve to the next step. However, I think their solution
(spreadsheets) should work perfectly fine for your two-man shop.

I duplicate this lifecycle in my own personal projects. I might start off
tracking fitness in vim, and decide I want sums so I migrate to Calc, etc. I
recommend using simple tools, well.

Do you think if you try to adopt a larger package before you're ready you
might end up spending most of your time playing with the system instead of
working (like a writer who procrastinates writing)?

~~~
wheels
I think it's more like having a first kid. We know we've got 3-6 months before
it starts breathing and there's a tendency to over-prepare because We Want
Everything To Be Right. We're still not to the point of no-return (haven't
quit our jobs yet), but I'm trying to learn everything possible and have
everything in place so that when and if that happens we can give it our best
shot.

#3 is something I'd really thought about, and is probably pretty in sync with
what should in fact happen. There unfortunately don't seem to be a lot of
smooth migration paths out there, which is what I think tempted me to start
looking at some of the more comprehensive systems. There's some overly
systematic twitch in me that says, "Get this figured out now, or it's going to
bite you in the ass later." But in reality, going with the analogy above,
that's probably like planning for a kids teenage years before they're born.

------
gduffy
I've often thought about putting together a good mix of infrastructure
software into one distro/appliance.

You could provide:

\- Router

\- VPN

\- VoIP

\- Email

\- Version control

\- Issue tracker

\- Wiki

\- File server/SMB/FTP

\- Etc.

You could save a startup a lot of headache if this stuff was boxed up for
$500-$1000 or so. It would be well worth it if it buys you more time on your
product.

As for processes, it seems like engineering processes are mainly affected by
one decision: how do you break up milestones/versions? You can 1) aim for a
constant amount of time per cycle, and cut a prioritized list of issues to fit
or 2) decide what you need to do for a milestone, estimate the time required
for each issue, and go at it until you finish. I've seen successful projects
in both areas, so maybe it's a style thing. The important thing is that you do
something.

Another important thing is deciding the lifecycle of a
bug/improvement/feature. And toss it out the window for things that are easier
to do than to file.

Also, as the project matures, you need a story for the division of eng time
between bug fixing and creating new features. If you do support, you'll need a
way to respond to the pressure from that. Maybe alternating responsibilities
between engineers would help keep a constant response time to customer issues.

For team organization, trying to split things up into silos with less than 4
engineers or so seems pretty counterproductive, unless there is a huge
disparity for some particular skill. As you grow, organize teams around major
areas: frontend, backend, developer support, etc.

If you're going to be hiring, decide on how interviews will be carried out and
what the decision criteria will be. Keeping it fairly uniform will allow you
to measure it better.

The important thing is to stay responsive to feedback from the trenches (even
if "the trenches" is just you for now).

Just some off-the-cuff ideas that your post brought to mind.

------
NoBSWebDesign
I've found Google Apps to be my savior in this instance. They are great for
having version-controlled spreadsheets, word documents, and now a company-wide
wiki with Google sites (though I'm still figuring out how to implement it).

Between Google Apps for document-versioning and mailing lists and 37Signals'
Backpackit app for to-dos and milestones (and time-tracking if you need it),
we've been pretty effectively productive.

We still need to get a good CRM tool though. I've heard good things about
SugarCRM, I'll have to take a look.

------
davidw
Something like Compiere (or OFBiz) is probably going overboard for a hacker-
oriented shop. Use good tools for the stuff that's important to you, make due
for stuff that's of secondary importance. Of course... all this depends on
what you do and how you want to grow. A quick-turnaround sell it type of deal
just doesn't need the overhead - indeed, PG seems to focus on not needing all
that crap in the early stages of a startup, because you can just work well
with the other people.

------
izak30
I'm at the same crossroads right now; 2 Guys, 6 months in

I've started playing with SugarCRM (It's good, but not great, and in my mind,
i do fine with a couple of post-its and an shared address book)

FogBugz is doing wonders for development, Time Tracking, ticketing, CVS/SVN
integration.

I know in the last couple of days I've become somewhat of a fanboy, but I'm
serious, it's great stuff.

------
dfranke
I think the best way to answer this question is to observe large open source
projects and see what works best. Not because open source is inherently better
than industry at getting it right, but rather because open source projects
conduct their business in public, so you can collect data a lot more easily.

~~~
wheels
Well, I've been on the inside of that for years (in the KDE project) and could
write volumes about what I've seen working and not working. But a lot of it
doesn't work on the same plane; in most of the larger projects the drive to
market the software and work in a business sphere comes years after the
technology is there. An open source project can survive for a very long time
with a simple website and a couple of mailing lists. But when it does try to
make that jump it's often less than finessed.

~~~
dfranke
_Well, I've been on the inside of that for years (in the KDE project) and
could write volumes about what I've seen working and not working._

If you wrote that book, I'd buy it. The only writing on the subject that I'm
aware of is a few passages of "The Cathedral and the Bazaar" and "The Magic
Cauldron", and it seems like there's a lot more to be said about the topic.

~~~
wheels
The major points that I'd mention, reacting to what you said are:

\- It's not as open as it looks. Once projects grow over a certain size,
either formally or informally a lot of the decisions are made behind closed
doors.

\- There's a lot of variety here, from open source startups (Ximian,
Canonical), to projects that after many years begin playing in the business
field (GNOME, KDE). Open source startups work more or less like normal
startups from what I can tell, except for you know, the code part and a little
nominal open-ness. Big open source projects that started open and move to
emulate corporate processes go through a lot of the fallout that happens any
time there's an attempt to change established processes in an organization,
but it's probably even uglier because the contributors have no particular
obligation to stay and often the people pushing through the changes are
learning how to do it on a several hundred person organization (which rarely
happens in business). That doesn't mean that there's no real progress, but
it's not something I'd want to emulate in a business.

\- Developers getting into a large OSS project usually learn how to be
developers in that project. Most of them start off comparatively mediocre.
This was certainly true for me, though I didn't realize it at the time. But
usually after a project has been running for a few years they've developed a
stunningly hard-core development culture which can take a mediocre hacker and
turn him into a wunderkind in six months. When marketing first shows up on the
radar, the guys are similarly mediocre, but they're several years behind the
curve on developing a marketing culture and have to deal with a couple hundred
hackers and their associated hubris to boot.

\- Eric S. Raymond is a bozo. Seriously.

And just for reference, this isn't all specifically about the KDE project. I
hang out around enough OSS guys that I've seen the same happen in several
projects. There may have been some that have avoided it. I can't name any off
the top of my head.

Edit: I take that last point back. I can think of an exception. The guys that
ate my lunch. :-) Amarok. From day one they starting building a community,
marketing, worked on bringing people of all sorts into the project. That
impressed me. (And from the get-go, we've been friends and swap a lot of code,
so there's no bad blood.)

------
rms
Great question.

