There are good and bad coders. There are good and bad business leaders. The talent that separates good from bad is their discipline.
Discipline needs to be applied to the tactical and the strategic. I’ll start with the strategy.
Have you ever used software that, over time, has grown big, complicated and unwieldy? It might have started out simple, but it’s core focus diminished and ended up with lots of features, but lost its simplicity and key selling point. Inconsistency of fonts, text sizes, input fields, functionality and naming are all unwanted features of making a piece of software a “jack of all trades, but master of none”.
The same happens in business. Organisations can lose their way (and their customers) by becoming distracted by too many ideas and not enough understanding of the focused value they want to bring to the market.
Jim Collins’ “Good to Great” explores some of this concept and is worth a read.
We can apply some of those teachings to the products and propositions our businesses take to market. That brings us onto the tactical.
It’s no surprise that agile and lean principles, common in manufacturing and software development, are now being utilised in other areas of our businesses.
These principles drive us to focus on the most valuable things to our businesses by dispelling the fiction of being able to deliver every interesting idea simultaneously. We do fewer things, but see faster results; a paradox to those who haven’t taken the time to learn. The question is, how do you prioritise?
Again, the answer in business is the same as the answer in coding.
Let’s say we have a “problem space”. That is, a list of user needs that could be satisfied. Those needs or problems usually have a value. In business, those might be efficiency problems (often increasing cost) or too much friction in customer experience (often reducing revenue). By understanding the positive financial impact to the customer of solving those problems, alongside an understanding of the market, the value to a business solving them can be derived.
Also, it should be understood how much effort is involved in solving those problems, which is where we start to move into a “solution space”. That is, a list of potential options for solving one or more problems. The bigger the effort, the longer it takes to deliver or the higher the cost.
I highly recommend Dan Olsen’s “Lean Product Playbook” for further advice.
It is important we don’t confuse the problem space with the solution space, which can cause disastrous results. The phrase “solutions looking for problems” is something we say when we’re not entirely convinced by the value of something compared to its associated effort.
Through weighing up problem vs solution, or value vs effort, a natural ordering can be understood and prioritisation can happen. We can actually agree to do fewer things concurrently, in the right order, delivering the greatest impact, for the least effort.
The ability to stay focused requires discipline and control over emotion. The real talent being the ability to decide what not to do and sticking to it.
This behaviour usually results in rapid continuous improvement; the same reason why apps on your phone keep getting updated with lots of minor upgrades that gradually improve the experience or add minimal features, gaining fans along the way. That is actually lean and agile at work in coding….. when done properly.
When done badly, too many problems get grouped together, or worse still; the problems aren’t fully formed, understood and valued before creating the solution. This leads to bloated projects with delays, increases in cost, fewer checkpoints for feedback, fewer opportunities to fail quickly and greater uncertainty about the real outcome. We’ve all seen the Gantt charts. You start with a waterfall, but end up in meandering rapids that take you to hell and back.
Modern leadership requires us to manage and accelerate business transformation more than ever. It’s easy to see how learning from industries like coding, that have proven how agile transformation works, helps us with business leadership.
I’m not suggesting everyone learns how to write code, but it’s the industrial principles of coding and it’s methodology that is going to drive our businesses this century.