software development

We’re not a factory

Posted on by will
Old factory workers

Factories must be awfully dull places. Factory workers working on a production line follow a strict process. Work is divided out into narrow and highly controlled portions. The guy working at machine #1 is an expert at machine #1, but not at machine #2 or #3. But that’s ok; if he stays focussed on his machine, the production line moves on and many widgets will roll off the end.

Factory workers take a given process or specification and assemble it. That the solution is provided is a given. There’s no room for initiative or individual innovation on the factory floor. If one machine doesn’t produce output of exactly the right type at exactly the right time, the system breaks down. Process improvement and innovation is for senior managers; observing the factory floor below from an air-conditioned room behind a wall
of glass.

In the early 1800s the factory revolutionised the production of goods and heralded the onset of the industrial era. It raised millions of people from poverty and created countless jobs (and millionaires). It brought about a new kind of competition: one fought along the bottom line. The problem with the factory is that the race to the bottom is over: we hit it long ago. When every factory can produce widgets as cheaply as you can (or cheaper), your ability to differentiate lies elsewhere – it’s not enough just to be able to sell widgets cheaper than anyone else.

Luckily in the software product business we’re not factory workers. We encourage individual initative. We challenge our teams to help us improve our processes. We believe that innovation can (and should) come from anywhere.

Right?

If that’s true, why do we keep treating our teams like factories, and our people like factory workers? Why do companies push solutions to teams and expect them to be just assembled, (where possible by yesterday), without asking too many questions or making a fuss? Why do organisations rebuff any innovation or ideas that don’t come from their own team? Why do we incentivise teams and individuals on the quantity of output, and not the quality or impact?

It’s not enough to talk about supporting innovation and encouraging initiative… our daily working process has to support it too; otherwise, we’re just another factory.

Move fast

Posted on by will

The world moves fast. Your competitors move fast with it.

Users move fast, too. Users are more fickle than ever before. This month’s UK WIRED magazine rated Twitter as “tired”. This for a service that’s only five years old with a still-growing userbase. Ouch!

In the world of web products, building and releasing beautiful and delightful products and user experiences is only half of the battle. The other half is winning (and keeping) your userbase. Your product could have a net promoter score of +80, but if it still only has 10 users, is it really successful? If you build it, they won’t necessarily come.

Users want stability and reliability. Once they have settled in to a product that solves a particular need, it’s that much harder to get their attention to yours. At the same time, and perhaps contradictorily (who said human beings were simple?), users also crave the new. New updates, new versions, new features. News, blogs and social channels thrive on the new.

The web has sped up business dramatically and continues to speed up software product innovation. It’s a race to the bottom – at some point we won’t be able to go much quicker – but we’re not at the end of that race just yet. The strategy to compete in this space, I think, has two major components:

1. Work fast. Build fast, iterate fast: improve fast.
2. Be ready for when we hit the bottom. When we can’t go faster, on what track will the next race be run? Which race can you win?

Important note: fast doesn’t mean chaotic and unplanned.