(Reading about) Eating Intalio's Dogfood
- January 30, 2009
- 0 Comments
Ismael has lately been posting about dogfood lately – er, rather, Intalio eating its own dogfood by deploying Intalio’s BPM software to run internal processes at Intalio. It goes into a bit too much detail for my interest- listing just about every open-source project known to man-kind that is being leveraged at Intalio (which is great, but more detail than necessary for me!). However, the point raised by this is a valid one. Often software startups write software that is purported to help with some general-purpose endeavor, but then fail to employ their own software for their own business. At a previous employer, we wrote software to improve salesforce productivity, but we didn’t use our own software in our salesforce. I think that not using our software actually hurt our business, and hurt our ability to understand customer complaints and issues. While I was at Lombardi, we used our own softare (Teamworks) for building the support site. It had great advantages for the company over using a pre-packaged solution:
- Our support staff had to become very intimate with our product in order to build the support site.
- We gained an important production beta-test site for new releases.
- We gained an important migration site from one version of software to another.
- We could actually see our own warts.
Lombardi also used Teamworks for certain internal processes – running the build and test processes for example. But we didn’t use Teamworks to run our sales process – we used Salesforce for that – for the simple reason that Salesforce is a specialized application around that process, and the benefits of using a mature technical solution outweighed the benefits of eating our own dogfood. And, as it turns out, it helped us understand how to help customers with processes that Salesforce didn’t quite handle. One thing I learned about using your own software: the commitment to develop the applications has to be critical to getting your job done, or include support from the top. Support from the top doesn’t just mean “I like that idea, go do it!”, and it doesn’t just mean tacit support of getting it done, or even pressure to get it done. It means providing the air cover, equipment, time, and funding to get it done. “What funding?” some would ask – after all, you own your own software. But if you are applying a developer’s time to an internal task, that is time she is not spending on product development – an opportunity cost. If it is a consultant, then your opportunity cost is that consultant’s hourly rate, plus the cost of a potentially under-served customer base. So there is a real cost to the time devoted to internal projects. Why air cover? Because there will be demands to pull you or your staff away from these internal improvement projects – just like there are these demands with your customers’ teams. In order to resist the temptation to distract your team with too many competing priorities, you need to provide the air cover for them (with your management), or your management needs to offer that air cover to you. Equipment? You’ll need to deploy your application somewhere when it goes into production. It may not require dedicated hardware, but you need some kind of environment to deploy to, and the support of your IT staff to keep it up and running. You may well need development hardware and test hardware (or allocations in a shared environment, which again will require support from the IT staff). If you get everything lined up, there can be a lot of benefits from deploying your own software internally – and those benefits tend to last and build on themselves over a long period of time. But if you are missing the key ingredients you run a pretty high risk of delay and/or failure.