Editor’s Note: This post was originally published on Seattle 2.0, and imported to GeekWire as part of our acquisition of Seattle 2.0 and its archival content. For more background, see this post.
By Anthony Stevens
A concept has been bouncing around in the back of my head for a couple weeksnow that I’d like to explore with you. The hypothesis is this: that one of themost fruitful things you can do as you’re building your tech startup is to takesteps to aggressively simplify things on a regular basis.
What form does this “Active Simplification” take? Let’s look at some examples:
Code: Remove old, unused lines of code. Eliminatecomplicated edge case handling. Use fewer languages.
Infrastructure: Pare down the number and variety ofsoftware and hardware vendors. Standardize on one or a few platforms.
APIs and Formats: Work with vendors/partners/end users tostandardize on fewer formats. Actively refactor and simplify your APIs on an ongoing basis.
Customers: Cut loose the most complicated and needycustomers. Reduce and consolidate the categories of customers you target.
Pricing: Simplify and consolidate your pricing schemes.
Product Development: Eliminate all but the top threemost-requested features from your backlog. Reduce the number of SKUs or customconfigurations.
Operations: Constantly reassess, and eliminate wherepossible, the implementation of custom tools that support operational functions,such as payroll, accounting, or legal. Use templates and industry-standardtools where possible.
You get the idea. This is a holistic strategy that can be applied to anyaspect of your business, and it doesn’t apply only to tech startups, either. The notion of “Active Simplification” came to me after spending some timereading systems theory, a field in which many writers argue that large systemsare inherently dysfunctional. Following the string backward, one could make theargument that for any two systems that meet the same need, the simpler one isbetter.
This makes sense. The more complex your system/business/codebase/customerlist, the more effort it takes to learn, maintain, and grow. The fewerexceptions you have to address, the faster you can move forward. The lessoverall volume of “stuff” you have to worry about, the lower your costs.
I’m not convinced, not thoroughly anyway, but it is interesting to workthrough the practical ramifications of this theory.
First of all, you have to put complexity on the table as an equal partnerwith other things you care about, like customers, features, or profit. How canyou possibly do this? You have to buy into the notion that simplicity is aprimary driver of business success, that all sorts of good things will accrue toyou when you no longer have all these complex systems to deal with.
Second of all, you have to make hard decisions. One of your softwaredevelopers wants to use custom tools? Hm. Maybe not. One of your customerswants some complicated, custom code written in to support their business? Maybenot. Your new bookkeeper wants to use their own preferred accounting package,when you’ve spent the last year in QuickBooks? Maybe not. All sorts of toughdecisions, made tougher by the fact that the answer to the question “Well, whynot?” has never had a very good tangible answer. To answer “We’re activelytrying to manage complexity” seems shallow, abstract, and too theoretical byhalf. And perhaps it is.
I would close by suggesting that this is not a black-and-white, either-ordecision: simplicity vs. complexity. It’s a VERY long spectrum, with many, manyshades of gray. But maybe thinking through the advantages that simplicity maybring to your business can be a useful exercise.
