Growing digital organisations well (part II)

I really like TV. Some people might say I like it too much but they’re wrong. My completely proportionate and healthy love of TV means that as well as the shows themselves, I enjoy watching documentaries about the process of making TV. That’s how I came to be watching the brilliant Showrunners. In the documentary, Shawn Ryan, co-creator and showrunner of The Shield, makes the following point :

There are two approaches I think you have to be careful about when you do TV. One is to not know, at all, where your show is going to go. And then, I would say, the other worrisome thing is to really think you do know where your show is going to go. What I mean by that is, there are some shows where they go: we have a 5 year plan. We know exactly what’s going to happen. Well, I’m always suspicious of that because these ideas are really hard to come up with. If you can come up with five seasons worth of ideas in the last two months then my guess is they aren’t the greatest ideas in the world.
I know the shows I’ve worked on it’s taken us much longer to work it out. At the same time if you don’t have any plan at all and you have a pilot that delivers an hour of entertaining hour of television but you don’t really know where it leads and where it goes to then you’re going to be in big trouble.

Now, he was talking about the process of developing a TV series so that each episode is enjoyable while contributing to a cohesive, larger story arc. But his reasoning could be applied to an analogous problem facing digital organisations as they scale – responsive iteration towards an ideal vision of a future state while avoiding over-engineering. See how TV teaches us stuff?

The impetus for truly disruptive startups is almost always a vision of a better way of doing things. A future that’s very different from the status quo is what keeps you going when everyone says you’re mad. Holding that vision in sensible tension with a pragmatic approach to implementation is the sweet spot. That’s how you build useful and adaptable products and platforms. It’s how you survive past the start up stage; it’s how you win.

Over-engineering is a hubristic trap. It’s what happens when you try to do all the things, because, even if you don’t admit it, you think you have all the answers. Or because you don’t have the courage to say no to some of the demands being made of you. So, maybe over-engineering is a problem of cowardice as much as of pride. Either way it was the downfall of the incumbents you used to sneer at. That’s how they ended up with the clunky, ugly solutions that their users got fed up with instead of the lightweight, resilient ones that got you this far. When you’re a startup, over-engineering is a luxury you can ill afford; it’s more likely to be something you do once the existential crisis has passed and you’ve got spare resource and many more ‘stakeholders’ (not to be confused with users).

Over-engineering was at least one of the things that undermined the ISO vision for a comprehensive set of standards for computer networks known as Open Systems Interconnection (OSI).

The OSI model emerged in a resource-rich environment (clever people and loads of money) and there was consensus on the goal - interoperability. This isn’t too dissimilar to the operating environment of a successful modern digital organisation once it’s out of the startup phase. And it’s why the TCP/IP vs OSI model showdown that Andrew Russell describes in his article (told you in my last post that I’d come back to it) is instructive for digital start ups.

Neither the objective of OSI – interoperability – nor the process for developing the model was dumb. In fact it’s the only sensible way to do it if you assume it can be done. If it were possible to build a system that benefitted all players, many of whom were invested in their current approaches and wanted solutions that would accommodate the edge cases these might generate, then OSI is what you’d do. TCP/IP had no such ambitions. It dealt with the messy reality of its users’ networks and aimed for no more than ‘best effort’.

Given enough money, clever people and a shared vision, you will almost certainly sleepwalk into the trap of attempting to do what OSI did. And once you’ve started on that path, your self awareness will diminish to the point of blindness. It’s important that you develop a plan to counteract this tendency. Like the ‘extractors’ in the film, Inception, you’ll need something that helps you determine whether you’re awake or in a dream state as you won’t be able to trust your senses. Cobb had his spinning top, you have your users. Because for digital organisations, as I explained in my last post, trivial adoption cost is the measure of success. Something that had obviously occurred to Louis Pouzin when he remarked:

Government and corporate policies never fail to recommend OSI as the solution. But, it is easier and quicker to implement homogenous networks based on proprietary architectures, or else to interconnect heterogeneous systems with TCP-based products.

Once adoption slows because it’s too much work for your users, alarm bells should start going off.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.