About Agility and Innovation

With the important caveat that my insights are based on experiences I’ve gathered in my own little bubble.

In recent years, I’ve worked in and for a variety of companies, ranging from hands-on SMEs, through more or less organized startups, to large corporations and agencies. I mention this not to brag, but to illustrate the breadth on which my following observations are based.

The larger the company, the less capable it is of developing innovative ideas, realizing them, or optimizing itself and its processes. (This is not a universal statement, but certainly a tendency.)

Why is that? So far, I’ve identified two important reasons:

1. Bureaucracy, Compliance & Processes

The larger the company, the less individual the processes. My favorite example is “Code of Conduct” courses. These typically cover four illustrious topics: Social Ethics, Business Ethics, Data Protection, IT Security. First Aid and Fire Safety are also often included. There’s nothing wrong with the content; everyone should “attend” these courses at least once. But the content is often very broad. For example, “Bribery” is a popular topic, but it undoubtedly serves a limited audience. Not to mention the impact: If I want to accept a bribe, the corresponding course certainly won’t stop me.

Nevertheless, everyone must deal with it. The participation requirement is often, if not always, distributed using the watering can principle: They are part of onboarding; must be repeated once a year. If you switch to another agency, you take part in such courses again. If you switch clients within the agency, the new client requires participation in their “own” courses - which are, of course, identical in content.

The result: Frustration, boredom, and unnecessary costs. The companies’ reaction: They spend a lot of money to pack the content into “modern” formats, conveying it playfully or in “stage plays”.

Why isn’t there a Code of Conduct driver’s license, a certificate? A test tailored to my field, which I take once a year and can show if needed!

But it’s also the processes in daily business that stifle innovation. I once worked for a large German employer, and we wanted to set up a service to simplify the import of CSV files. Technically, it wasn’t complicated; the files were small, and it was just about adjusting column names. However, we needed a service, a small virtual server or Docker container running in the background. It took months to find out which department could help us. Ultimately, we had to stop the project without success. A hurdle that would be unthinkable in a startup.

Recently, I stumbled upon a very nice talk on the Skunk Works principle, explaining its origin and impact. The idea is, roughly summarized: A small team of experts works independently and as free from corporate constraints as possible on a project.

Another solution would be to not only allow but actively promote U-boat or pet projects with the necessary infrastructure. Shortly after my studies, I worked at a somewhat larger “startup” and eventually implemented a technically simple search mask that massively facilitated the team’s work. Needless to say, my team lead wasn’t very happy about the “misallocated” hours.

2. Turf Protection, Tunnel Vision

This is a phenomenon I’ve observed many times; I call it the “wrong Gallic village”. A Gallic village that defends itself against invaders can be a good thing. But what if it’s not invaders but innovators? New ideas are either quickly perceived as negative criticism of the previous quality, or there’s simply fear of losing one’s established position. A Gallic village that resists any outside influence has detached itself from the company’s goal.

Existing solutions are rarely questioned. This is a big problem, especially in the technological field, where new possibilities arise weekly. Three arguments are then used to protect against the impending invasion innovation:

1. Never change a running system.
2. No capacity.
3. Too complicated.

I’m not saying that the motto “Never change a running system” is fundamentally wrong. You don’t have to jump on every bandwagon. But eventually, the last train has left the station. And before you know it, the solution is based on an outdated technical platform that is no longer supported or mastered by anyone. Software development, in particular, suffers from this phenomenon: A program is never finished.

“No capacity” is an excuse that shifts the current, perhaps unknown problem into the future. But this shift is not linear. If you shift every adjustment into the future for ten years, they don’t spread over a period of ten years in the future. They accumulate at the point where the future begins. And that’s tomorrow.

“Too complicated” is an argument that undermines itself. If adjustments to the current solution are too complicated, we should invest time sooner rather than later. Because software development also suffers from this: A program rarely becomes less complex over time; rather, the opposite is true.

The art is to have an agnostic attitude towards change without succumbing to it.