Building the infrastructure for innovation

That problem of not being able to support your own ideas

Before I started my job years ago in the innovation team at the Süddeutsche Zeitung the team had been building a 360°-video app, modeled on a similar app by the New York Times. The app and content were fascinating, though it never took off and was eventually shut down about a year after I joined.

The problem was simple but tricky: the team wasn’t able to find a solid project team and someone in the newsroom willing to take on the management of the app. It‘s a surprisingly common problem that surfaced with every project I was involved in during my time. It‘s a problem I have observed at other innovation teams, as well.

Innovation teams are often unable to embed their projects into the company, meaning they‘re forced to slowly transform into project management teams, instead. This — obviously — leads to conflicts. The members grow frustrated because they feel unsupported and ignored by the wider organization while other units (i.e. the newsroom) are justifiably unwilling to take on projects they were not involved in creating in the first place. In some cases, there doesn’t even exist a fitting place within the company that could take on the project.

Innovation teams are often seen (and managed) as factories for “the new”. Methods and processes are tuned for speed and quantity — the end goal is the launch. Broadly used methods like Design Thinking even lack the vital step of implementing the freshly ideated project.

The results are shallow projects, shiny on the surface using the newest tech but without any legs to stand on. What‘s often lacking is infrastructure.

Yes, that new podcast concept is amazing on paper but have we considered if we even have an appropriately equipped podcast studio, solid processes with the newsroom for content, presentable speakers or a sales team able to sell audio ads? And if not… what do we need to change? What do we need to build? Who do we have to teach?

Yes, personalized news homepages sound interesting but do we even have the data we‘d need to personalize the content selection? How will this impact news creation processes? Does the website even support personalization on a technical level?

As Guru Madhavan put it: there‘s a lot of grind necessary to reach the grand vision.

These considerations are vital but often ignored in favor of speed and “blue skies thinking” and I do hold these myths about innovation responsible for this unforced error. They focus solely on the object of innovation — the iPhone, the space rocket, the idea — all while ignoring the vital infrastructure they were built upon.

The iPhone didn’t succeed because of its design. It did because of Apple‘s globe-spanning and efficient supply chain, its culture of bending manufacturing limits in its favour and the tight integration with its software. That‘s infrastructure. Infrastructure that needs appropriate funds, staffing, strategies and considerations. In this context, it‘s not surprising that the mastermind behind this supply chain, Tim Cook, took over the reins at the company after Job‘s death and not Jimmy Ives, the person credited with the company’s product design language.

What I am trying to say is: build the infrastructures to support your new ideas and do both at the same time. Do not separate invention and delivery. And if you do, in favor of speedy tinkering, be prepared for the project to never leave your office or having to shut it down a couple of months from now.

Linked Notes

Work Infrastructing

Work Infrastructuring

Lately I‘ve been doing a lot of reading on the concept of infrastructure or to be more precise the connections between infrastructures of work.

As in the assembly of tools, processes, knowledge and standards build up over years by people to enable good work.

I quite like this definition of infrastructure by Susan Leigh Star¹. Mainly because she reaches beyond the idea of infrastructure as a technological construct:

Embeddedness. Infrastructure is sunk into and inside of other structures, social arrangements, and technologies.

Transparency. Infrastructure is transparent to use, in the sense that it does not have to be reinvented each time or assembled for each task, but invisibly supports those tasks.

Reach or scope. This may be either spatial or temporal—infrastructure has reach beyond a single event or one-site practice.

Learned as part of membership. The taken-for-grantedness of artifacts and organizational arrangements is a sine qua non of membership in a community of practice . Strangers and outsiders encounter infrastructure as a target object to be learned about.

Links with conventions of practice. Infrastructure both shapes and is shaped by the conventions of a community of practice (e.g., the ways that cycles of day-night work are affected by and affect electrical power rates and needs).

Embodiment of standards. Modified by scope and often by conflicting conventions, infrastructure takes on transparency by plugging into other infrastructures and tools in a standardized fashion.

Built on an installed base. Infrastructure does not grow de novo; it wrestles with the inertia of the installed base and inherits strengths and limitations from that base.

Becomes visible upon breakdown. The normally invisible quality of working infrastructure becomes visible when it breaks: the server is down, the bridge washes out, there is a power blackout.

Is fixed in modular increments, not all at once or globally. Because infrastructure is big, layered, and complex, and because it means different things locally, it is never changed from above.

In that sense forms, standards, the dreaded bureaucracy — all these things are in the same sense part of a companies infrastructure as are computers, servers, the buildings, electricity or air conditioning.

In many ways this notion of infrastructure can be understood as part of what Dan Hill described as “Dark Matter”, the complete overarching context (from tools, to cultures and laws) that influences every decision made inside an organization.

Susan Leigh Star (1999). ‘The Ethnography of Infrastructure’. AMERICAN BEHAVIORAL SCIENTIST, Vol. 43 No. 3 ↩

READ ➞

Minimal Supportable Product

A minimal viable product (MVP) is a version of a product, project, or concept with just enough features to satisfy early customers. It‘s a way of testing an assumption before committing to building a fully-featured product. The concept was popularized by the author and consultant Eric Ries.

But during my work in the innovation team at the Süddeutsche Zeitung I found the MVP-framework lacking in a couple of ways. As with most concepts out of the startup-to-consultancy-pipeline, it lacks a way of interfacing with the structure of the organization and its dark matter.

As a result, MVPs build by an innovation team are in danger of being created in a vacuum. They might fit the users‘ needs but aren‘t sustainable inside the organization because of lacking resources, knowledge, man-power, or a miss-fit with strategy or business goals. Such teams might end up with a perfectly fine new product, but without a way to sustain it further.

Products and projects need the political will, the people (developers, designers, etc.), the tools, and the technical infrastructure to build and maintain it. Building this infrastructure is often an implicit part of innovation, but for complex organizations, it has to be explicit to be successful.

Which in turn means, that innovation has to work on different levels inside these organizations. It might be more useful to influence the strategy, hiring, or processes to build a solid infrastructure that can then support the new product, then building the product itself.

My suggestion would be something like a minimal supportable product or (MSP). An MVP that is embedded from the start in the organization and can not only be iterated along with the users‘ needs but also the organization‘s capabilities, while also transforming both product and organization.

READ ➞