The Laws Of Innovation

October 18, 2021

This post discusses some “laws” that we commonly hear.

Some are well-known, others less well-known ¯\_(ツ)_/¯

It’s a bit of light-hearted reading considering that Auckland is still in Lockdown. 

Work expands to fill the time allotted for its completion.

TenX's take on Parkinson's Law: 100% true. 

Ask any student. Ask any project manager. 

People are terrible at estimating and are born procrastinators.

Bonus tip: Give yourself far less time than you are comfortable with to do something. Force a deadline upon yourself. It’s might make you uncomfortable but it will focus you considerably.

80% of a system's functionality is provided by 20% of its features.

TenX's take on Pareto's Law: 100% true. 

I would love for MVP to be redefined as Minimum-Valuable-Product. 

What is the smallest thing that can be launched which provided the most value?

Adding manpower to a late software project makes it later

TenX's take on Brooke's Law: Sadly, this is also 100% true.

Getting the resourcing right for a Project is an art form.

Smaller is generally better. In the early days of Amazon Jeff Bezos instituted a rule - every internal team should be small enough that it can be fed with two pizzas

Unfortunately, we have seen time & time again that adding additional resources to a project, especially late in a project causes havoc. It’s a hindrance rather than a help and it invariably upsets the rhythm of the existing team.

People have to be up-skilled, tasks have to be broken down, and more meetings are required to “align” activity.

It's not worth the effort.

Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure.

TenX's take on Conway's Law: Super true. 

Think about all the times that you are on a call to a call centre & the number of times you have been transfered to another ‘department’.

It's madness.

Software will always consume more time and money than originally estimated.

TenX's take on Stephenson's Law: Mostly True. 

Unless you have a strong Product Function then things are never finished and you keep on adding features.

The more features that you have, the more technical debt you will have. The more technical debt you have, the more difficult it is to maintain. The more difficult it is to maintain, the more time and money you spend on it.

It’s a vicious circle.

Bonus tip: Empower your Product Function to say “No” (to features)

The cost of integrating software will always exceed the cost of developing it.

TenX's take on Keener's Law: This is a good one. 

Integration is very hard and requires a lot of effort. 

Bonus tip: Make it easy to integrate. 

As innovators we know that we should make it as easy as possible to integrate our stuff. 

Most of the time though, we don’t care as much as we should because we’re super excited about the features we’re adding. 

The problem is that our customers don’t use our software like we do. They want to do the same thing we want them to do, but we need to make sure we don’t make it difficult for them. 

Bonus, Bonus tip: Make it easy to integrate and make it easy to use.

A complex system that works is invariably found to have evolved from a simple system that worked.

TenX's take on ​​Adams' Law: 100% True.

For things to work, they have to start simple.

The inverse proposition is also true: A complex system designed from scratch never works and cannot be made to work.

From Blog

Recent posts

Ready to talk

Feel free to contact us