One of the most important lessons I’ve learned, first from programming and later applied across all kinds of projects, is this: to solve any problem, you must break it down to its last logical end.
And once you reach that “last logical end,” you unlock the true basis for data, decisions, and actions.
Start with Assumptions and Expected Outcomes
Every project, task, or problem starts with assumptions — the facts, contexts, and conditions we believe to be true.
But assumptions without a clear outcome are like a ship without a destination.
Before starting, I ask:
- What is the assumption here?
- What is the outcome we are expecting?
When you are clear on these two things, every function, deliverable, and conversation in the project starts making sense.
It brings alignment with the team, with stakeholders, and with yourself.
Break It Down Relentlessly
Think of a complex project or problem like a giant machine.
You cannot fix it by poking randomly.
You have to decompose it break it down into smaller and smaller parts until:
- Each part has a clear input and a clear output.
- Each part can be tested individually.
- You can trace where exactly the problem lies.
In programming, we call this modular decomposition.
In project management, it’s structured problem-solving.
Important:
Until you reach the point where you can no longer logically break a task down, you must keep going.
And when you don’t yet have all the data?
Group related information together but flag it.
Missing pieces should never be assumed completed.
Build the Process ➔ Test It ➔ Make It Scalable
Once the parts are small and logical:
- Build the process with what you know.
- Test each piece independently and together.
- Refine for scale — not prematurely.
Getting it right is getting it done.
Half-complete or half-tested processes are a silent threat to project success.
Communication is Your Code Comment
In programming, we add comments to our code — not for today, but for our future selves and future teams.
In project management, communication plays that exact same role.
Clear documentation, status updates, meeting notes, decisions these are not “optional.”
They are the code comments for the project.
Without them, when the team changes or the project scales, confusion follows.
Good communication today protects the project’s future.
Watch Out for Premature Optimisation
One fascinating concept from software development is premature optimisation.
It means trying to optimise the wrong thing at the wrong time.
For example:
Spending weeks designing an ultra-efficient system before you even know if the basic process works.
In project management, premature optimisation shows up when:
We overcomplicate processes for minor time savings.
We optimise human effort before validating if the system even needs it.
We polish something that’s still a rough draft.
First make it work, then make it better.
Efficiency is meaningless if you are speeding in the wrong direction.
Final Thought
Whether you’re coding a program or managing a complex project, the principle is the same:
Break it down until you hit the truth. Build it logically. Communicate well. Get it working. Then optimise.
This mindset has helped me across industries, teams, and project sizes.
It’s simple, but it’s powerful.
