One longer-term objective of Upstarta has been to bring out a book. Having done previous analysis of the publishing industry and its effective benefits to authors (or the lack thereof – I might do a post on that some time!) I decided to self-publish. After all, shelf space is rare anyway but you can get your Lulu book to Amazon without hassle. What an expiring writer also needs is some project management to keep an eye on time, progress and structure: in summary, a good editor!
In April I had a rare opportunity to meet face-to-face with an editor-friend (we literally live on opposite sides of the planet), and while reviewing content is easy to do online, discussing structure is much easier in-person. We came up with this rough section layout:
This looked entirely sensible. But then somehow I got stuck fitting the content in to there, and worked out only months later that the above had something to do with it. This is not how disruptive non-funded businesses start! Instead it follows the flow of traditional businesses; and it’s exactly that process causing problems which Upstarta addresses…
The actual Upstarta process is not quite linear, but it can be described in chunks and some concepts should be dealt with before others. So while I love my wiki (it’s the visual-spatial thinker in me), it can be molded into a book.
The lesson is that it’s very easy to fall back in to “classic” thinking patterns, and you may not realise for quite a while that you actually did – meanwhile several layers of decisions get built on top. It can really mess with things, and in essence waste valuable time and often also money. In some cases, it might not even be fixable any more. The “getting stuck” was a pattern I should have questioned in more detail straight when it occurred. In this case it’ll be ok, just cost some time.
I’ve recently started re-reading an old book that seems appropriate to the ideals of Upstarta.
It is ‘Small Is Beautiful’ by E.F.Schumacher. Subtitled ‘A study of economics as if people mattered’, this book was written in 1973 and seems even more appropriate given the recent financial state of the world. If Schumacher was alive he’d be pointing to this book and saying ‘I told you so!’
Schumacher covers many topics from conservation, macro, micro and Buddhist economics through to forms of ownership and government, but of most interest to startups would be the final chapters. In the last chapter he takes an in depth look at a business started in 1951 called the Scott Bader Commonwealth. The rules for this business were as follows (edited for brevity):
First: The firm shall remain of limited size. No greater than 350 people or so. When it grew beyond this due to demand, new independent businesses were to be created.
Second: There was to be no more than a 1:7 ratio between the lowest and highest salaries in the organisation.
Third: All members of the organisation are to be co-partners. They cannot be dismissed other than for gross personal misconduct.
Fourth: The board of directors is full accountable to the Commonwealth. i.e. The employees have say in how the business is run.
Fifth: 40% of profit goes to the commonwealth, 60% to running the business and taxation. Of the Commonwealth’s profits, half goes to the workers and half to a designated charity outside the organisation.
It was predicted that this arrangement could not work. It did very well, at least until the time of the book’s publication.
I don’t suggest that one should take on this model in a startup but it is worth thinking about what unconventional structures may have to benefit the business, it’s workers and the world.
If you happen to be in a secondhand bookstore this old tome is worth picking up.
Modularity is about business processes as well as software or system design. The Innovator’s Solution (Clayton Christensen, Harvard Business School Press) analyses this very well, identifying modularity as a phase, or more accurately, a state in the going development cycle.
Choosing modularity as a core objective, as many appear to do these days, does not appear to be effective. Trying to make something modular when the subject is not fully understood and the interfaces not clearly defined and predictable can be fatal.
When, in order to make a product or process good enough in the current state of its market, it needs to be tightly integrated… then that’s the way to go. The system will evolve to a point where modularity at that point makes sense (for a period of time), with tightly bound sub-systems.
Looking at products (including software), consider the business processes in the market. For instance, the packaging (not necessarily physical, but documentation, support and other services) and other logistics are also part of the whole, and may well be suited to modularity (e.g., one company offering support for a product that’s built by another) even if the product itself is tightly integrated at that point in time.
In summary, modularity is not better or worse than integration. Each has its place, depending on the state of the market/ecosystem where the process/product/service operates. Part of a system can be in a modular phase, where another part of the same system needs integration.