Don’t Automate - Build Tools
Automate someone’s process - you solve one problem
Give someone tools - they can solve many problems
Ross Mayfield’s recent post made me think about the difference between approaches to solving problems and creating innovation.
For example, I think of Excel as a development environment that knowledge workers use to code solutions for just about everything. Schedules, surveys, budgets, plans, lists of people to follow-up with. In my consulting work, we use Excel to build, sort and define risk controls, data requirements, to-do lists. In my previous life, as a derivatives trader, we used Excel to price financial instruments. The bond analysts sitting next to me, used it to build projections, and analyze investments.
Web 2.0, and specifically what I think of as Web Office, is about a new class of tools that empower knowledge workers in ways that make Excel look very clumsy and old.
Today, many software shops, and most IT departments, focus on building tools to automate an existing process.
Not surprisingly, most IT departments have a rigid process for building tools. Usually, the whole thing is driven by some professional nag, moron project manager. This rigid process begins by defining user requirements, then building something, testing it, and rolling it out. By which point, often, the business process that was being automated has changed, and the whole thing has to begin again.
In the mean time, most business work is still getting done by knowledge workers building ad hoc solutions in Excel, and then laboriously working to share that information via email and the phone.
There are two things that need to change:
- The hyper rigid software development process needs to be dropped for a more interactive, cooperative and user centric approach
- Software shops need to focus on building tools, not automating process
Just to be perfectly clear, by tools, I mean software that gives knowledge workers the ability to create their own customized solutions for gathering, analyzing and sharing information. Examples include the software I have listed in my Web Office directory.
So… bottom line. If you want to encourage innovation, build tools. If you want to stifle innovation, automate processes.


