SaaS did not start with software.
SaaS has always existed. We just recently started calling it software.
If you go fundamental, a human operates on a logic that is remarkably close to Software as a Service. The only difference is that this software does not run in a cloud server — it runs on biological hardware. And that hardware is old, of uneven quality, emotional, energy-limited and often badly documented.
Our body is hardware. Our psyche is software. Our behaviour is the user interface. Our results are the output. Our relationships, work, environment and roles are integrations.
And as with any SaaS, most problems do not come from the fact that "the product is bad" — they come from the fact that it is being used in the wrong place, in the wrong way or with the wrong expectation.
A human does not leave the factory perfect
Every person is born with an initial configuration.
Inside it are strengths, limitations, flaws, potential, sensitivities, reaction patterns and learning capacity. Some parts work very well right away. Some parts need years of development. Some parts will always remain fragile. Some functions only unlock in the right environment.
Like software, a human has born-built flaws. Not in a moral sense. Not that the person is broken. Just in the sense that every system is born with limitations.
- Some people process information quickly, but tire socially.
- Some are great idea generators and poor finishers.
- Some are excellent in a crisis and weak in routine.
- Some can influence in sales but cannot stand detailed administration.
- Some need autonomy. Some need structure. Some need a clear goal. Some need a safe pace.
If we do not know this, we start using a person as a generic universal tool. And then we wonder why they do not work.
Every assembly line adds its own modifications
A human is not only biology.
After birth, layer after layer is added to the system: parents, school, friends, traumas, successes, shame, culture, workplace, managers, relationships, money, failures, recognition, fears and ambitions.
Every "assembly line worker" tweaks something.
- Some add courage.
- Some add insecurity.
- Some teach you to think.
- Some teach you to hide.
- Some make a person believe they must constantly prove themselves.
- Some make a person believe it is safer not to be seen.
This is how a person's current version is built. Not the final version. The current version.
And this is where the key difference between old and new leadership lies.
Old leadership asks: "What is your job title?" Better leadership asks: "What system is this person actually, what are they suited for, and in what conditions do they create value?"
Most people just use your brain
At work, many people use your brain.
- The client wants a result.
- The manager wants accountability.
- The colleague wants an answer.
- The company wants profit.
- The market wants competitiveness.
- The family wants attention.
- Society wants compliance with norms.
Everyone has some kind of query against your system. But very few ask whether the system is correctly configured, overloaded, up to date — or even suited for the task at all.
It is the same as asking a single SaaS product to do ten things it was never designed for and then blaming the software for not scaling. We do this to people every day.
- "They are not motivated."
- "They do not take ownership."
- "They do not fit the team."
- "They do not get it."
- "They are not fast enough."
- "They are not strategic enough."
- "They are not detailed enough."
Maybe. Or maybe the person is simply in the wrong role, with the wrong load, the wrong expectation, the wrong team or under the wrong management.
A person's product owner is often missing
A good SaaS needs a product owner. Someone has to understand:
- what the product was built for;
- for whom it creates value;
- which functions are critical;
- what is not worth developing;
- where the bugs are;
- when an update is needed;
- when the architecture has to change;
- when the system is overloaded.
People have the same problem. Many people do not really have a product owner for their own life, work and development.
As a child it is the parents. At school it is the teachers. At work it is the manager. In a crisis it is the therapist, coach or mentor. But at some point product ownership should genuinely move into the person's own hands.
That rarely happens. Many people live in such a way that their backlog is filled by others. Other people's expectations, fears, needs and standards.
The result is a situation where a person works as a "service" for everyone else, but no one manages their roadmap. And then, at some point, burnout arrives.
Not because the person is weak. But because the system has been used for too long without maintenance, prioritisation or a version upgrade.
Competition demands updates
A SaaS that is not updated dies.
Once upon a time, a good product could sit on the market for years almost unchanged. Not today. Customer expectations shift. Technology shifts. Competition shifts. The market shifts.
The same is true for a person. Once you could learn one profession and do it for 30 years in almost the same way. Not anymore.
- AI changes processes.
- Automation changes roles.
- The content of work changes.
- Expectations change.
- Teams change.
- Responsibilities change.
- Leadership changes.
If a person does not update their inner operating system, they start doing yesterday's work in tomorrow's world.
That does not mean everyone has to learn to code or use AI tools simply because it is fashionable. It means every person and every leader has to ask:
- Which part of my current work will remain?
- Which part will change?
- Which part will disappear?
- What new value has to be created through me?
- Does my current role use me correctly?
Wrong usage does not mean a bad person
In SaaS there is a simple principle: when a customer uses a product incorrectly, the problem is not always with the customer. Sometimes the problem is in onboarding. Sometimes in the documentation. Sometimes in the positioning. Sometimes in the design of the product itself.
We should think about people the same way. When a person does not deliver, the first conclusion should not be: "bad employee". The better questions are:
- Is the role clear?
- Are the expectations clear?
- Does the person fit this role?
- Are their natural strengths being used?
- Are their weaknesses critical for this role?
- Does the team compensate for or amplify their limitations?
- Does the manager know how to use them?
- Does the person themselves understand how they work?
Very often the problem is not in the person. The problem is that the person is integrated incorrectly.
Leadership is system design
The leadership of the future is no longer only about motivating people. It is the co-design of people, roles, processes and technology.
A good leader does not only ask: "Can this person do this job?" A good leader asks: "Is this job the right use case for this person?"
That is a huge difference.
- A person can be highly capable and still ineffective in the wrong role.
- A person with an average CV can be extraordinarily valuable in the right role.
- A person can be a problem in one team and the solution in another.
- A person can be locked under the wrong manager and unstoppable under the right one.
Exactly like SaaS. Wrong customer, wrong onboarding, wrong integration, wrong expectation — and even a good product feels bad. Right customer, right use case, right integration, right support — and value shows up quickly.
Human as a service does not mean dehumanising the human
The thought "a person as SaaS" might sound cold. In reality it is the opposite. It helps us stop blaming and start understanding.
When we see a person as a system, we start looking at the conditions in which they work, when they freeze, when they create value, when they need support, when they need an update — and when they are simply being used incorrectly.
That is more humane than saying: "They do not fit." "They are lazy." "They are difficult." "They are too emotional." "They are not good enough."
A person is not a static resource. They are a living system. They need the right role, the right environment, the right load, the right feedback, the right integrations and continuous development.
In closing
A human is like SaaS.
- They run on biological hardware.
- They have an initial configuration.
- They have inborn limitations.
- They have use cases.
- They have bugs.
- They have integrations.
- They have users.
- They have maintenance needs.
- They have a roadmap.
- They need updates.
- And if you use them incorrectly, they will not deliver the promised value.
For leaders, the practical conclusion is very simple:
Do not only ask whether a person is good or bad. Ask whether the system you placed them into uses them correctly.
Because most so-called people problems inside a company are not actually people problems. They are design problems.