Nethy left an interesting comment the other day in regards to a potential new feature I mentioned:
I’m always impressed with how your processes [flow]. Having a system like this that works properly needs:
a) the programming doing the work and
b) someone to plan the process.
That’s something that’s very hard to do on a small business budget. It’s something that’s hard to do via consulting, for example. For a competitor, they might think “Adam blogged that he took 1 week to do this. 40 hours. I can get that done for $4000 (or $400 on elance) by a consultant.” They can’t. The communication between programmer & business owner isn’t simple.
I would be very surprised if your competition had your combination of low-tech & high-tech working together this well. The upshot is that they just won’t [build] such smooth systems.
Here’s how our programming projects go. I take the role of project manager and programmer. After an initial discussion of the goals of the project, I sit down and map out a plan. I go pretty in depth, trying to take into consideration exactly how each potential change will be implemented and how it will impact the existing features.
I then call a meeting to present the plan to my partners. I generally talk through how the system will work, using demos from other sites or printouts if necessary. They bring up anything I’ve missed, any potential problems they see, and any potential features they’d like to see added in addition. We then decide exactly what will be in the final version, taking into consideration how much of my time each part will take, when we need it done by, and how big of an impact each part will make.
At that point I have a pretty good idea of what we need. I then sit down and program a demo that’s one step away from being deployed. We meet to review and test the demo. If any adjustments need to be made, I make them and then we release the final version. For the first few weeks I ask my partners to monitor certain things in case there are any bugs. I also pay super close attention to make sure there isn’t a chain reaction somewhere that I didn’t foresee.
Here’s the real key to the process: all along the way I make a million mini business decisions without ever running them by my partners. Each decision speeds up the development time a ton, considering the alternative would be posing a question , awaiting replies from everyone, and then coming to a final decision. Of course, I can do this because I’m an owner and the programmer.
Unfortunately (or maybe fortunately for us), I think most mid-size e-commerce companies (10 – 50 employees) have an owner or management team and then a separate programmer or programming team. They have now introduced communication breakdowns that cause all sorts of problems, stemming primarily from two things:
- The owner/management team doesn’t have a programming background, nor do they have any real understanding of modern e-commerce.
- The programmer doesn’t have a complete understanding of how their features impact the business, partially because they don’t understand how the entire business functions (accounting, customer service, supply chain, etc), partially because they don’t support their own software, but mostly because management doesn’t make an effort to ensure that they do those things.
What happens next? The project goes through extra iterations because the owner is frustrated with the results: “He can’t do what I tell him to. How hard is it?!?!” Of course, the programmer is equally frustrated “He doesn’t know what he wants/what he wants isn’t feasible/what he wants will cost far too much time or money for what it’s worth.”
The end result is that the project takes twice as long as it should. Neither party is happy with how it came out because they feel like the other side ruined it.
The root cause of the problem goes back to the very beginning of the company. This seems obvious, but at some point, if you’re going to make your living selling stuff online, you have to place an importance on the technology that connects you to your customers.
That means having someone on your executive team that comes from a programming background and still actively programs (even if it’s just a few hours a week). This person should have a voice in every business decision you make. They should be able to then communicate to the programming team what needs to be done (or, if they’re small like us, go ahead and program it themselves like I do because I am the “team”). But this programmer needs to have the trust of ownership to know that they can make business decisions without fear of being questioned every time.
The executive team also has to take an active role in understanding online business. This means that everyone in the organization reads books, magazines, and/or blogs about e-commerce and online business. After all, this is your industry. You can’t do your job to the best of your ability if you don’t understand it.
Of course, this also applies to the programmers. There has to be an emphasis on making sure that the programmers understand how the other areas of the business function. They have to have a point of contact with their users so that they know what is or isn’t working. Small incremental improvements will come from programmers that the regular customer service reps just won’t think of.
Do some companies do this? I think so, but I also think it’s rare. Especially when you’re under $50 mil/year in sales. The owner probably built the company successfully because of their operations or retail skills, which is certainly to be commended, but to stay competitive in this modern web economy you need a programmer as part of your decision making process.
[Side note: same goes for a new web start-up. If you have 2-3 partners in a team, one of them damn well better be a programmer. Otherwise this problem will soon become one you’re trying to solve…likely after you’ve wasted a ton of time and money.]