4 ms·

Ask YC: The business process sweet spot

8 points by wheels 19y ago

In the last 6 years I've worked for two different companies, Company A with 40,000 employees, Company B with 150. 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. 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. When looking at founding a company, it seems important to find the middle ground. 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. 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.

rms 19y ago
Great question.
dfranke 19y ago
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 19y ago
  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 19y ago
    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 19y ago
      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.)
gduffy 19y ago
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.
izak30 19y ago
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.
davidw 19y ago
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.
suboptimal 19y ago
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 19y ago
  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.
NoBSWebDesign 19y ago
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.

8 points by wheels 19y ago

rms 19y ago

Great question.

dfranke 19y ago

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 19y ago
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 19y ago
  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 19y ago
    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.)

gduffy 19y ago

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.

izak30 19y ago

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.

davidw 19y ago

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.

suboptimal 19y ago

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 19y ago
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.

NoBSWebDesign 19y ago

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.