BLOG
Någonting har legat begravt länge
Någonting har legat begravt länge.
Inte bara i jorden.
I historien.
Vi bygger vår bild av det förflutna av det som råkat överleva – några ristningar, några föremål, några ruiner. Resten är tystnad.
Men tystnad är inte samma sak som tomhet.
Under en längre tid har jag arbetat med en ny roman. En berättelse som börjar på nyårsnatten 1984, när fyra vänner ser något falla från himlen över ett svenskt fjäll.
Det de hittar borde inte finnas.
Och ändå ligger det där.
Därifrån sträcker sig gåtan bakåt genom människans historia – mot förlorade språk, glömda platser och spår efter sådant vi kanske aldrig varit menade att hitta.
Jag tänker inte avslöja mer ännu.
Bara detta:
Vissa hemligheter begravs för att glömmas.
Andra väntar på rätt tid att bli upptäckta.
Snart börjar jag berätta mer.
🎧 The Lost Colour — Now Available as an Audiobook
A blue parrot appears outside Timothy Scott’s classroom window.
Then comes a message in a bottle, addressed to him by name.
Before long, Timothy and his new friend Anna are drawn into the World Within — a hidden realm where colours hold magic, impossible creatures roam, and a darkness thought defeated is beginning to stir again.
Step into The World Within.
When ten-year-old Timothy Scott encounters a mysterious blue parrot carrying a message meant for him, an ordinary summer becomes the beginning of an extraordinary adventure. Together with his new friend Anna Calor, Timothy enters a hidden world of colour magic, strange creatures, ancient secrets, and gathering darkness.
The Lost Colour, Book One in The World Within, is now available as an audiobook on Spotify — written and narrated by Johan Edfeldt.
✨ A magical middle-grade fantasy adventure for young listeners, families, and anyone who still believes another world might be waiting just beyond our own.
🎧 Listen now on Spotify:
https://open.spotify.com/show/2lmweQzIAWnylMpH0YcN1g?si=0279cd0aa4b74687
Devformance Goals: Combining Development and Performance
Most organisations separate development from performance.
One conversation asks: What do you need to learn? Another asks: What do you need to deliver?
I have never been convinced that these questions should live so far apart. Learning without application can become abstract, while performance without development can become unsustainable.
So why not connect them?
That is the idea behind what I call Devformance Goals.
A Devformance Goal combines a Development Goal with a Performance Goal. You develop a skill, capability or area of knowledge while using that development to achieve a measurable business outcome.
You do not only complete the level. You level up while doing it.
What is a Devformance Goal?
A Devformance Goal is a goal that deliberately combines development and performance in the same objective.
Traditional Development Goals focus on improving skills, knowledge or competencies. Traditional Performance Goals focus on delivering a specific result. Both matter, but they answer different questions.
A Development Goal might be:
Improve my data analytics capability.
A Performance Goal might be:
Reduce reporting turnaround time by 30%.
A Devformance Goal connects them:
Develop advanced data analytics capability and apply it to reduce reporting turnaround time by 30%.
Now learning has a purpose, and performance creates development.
That connection is the important part.
Development Goals build capability
Development Goals are primarily about becoming better equipped for the future. They might involve learning a new technology, developing leadership capability, improving negotiation skills, understanding a new market, strengthening communication, building financial knowledge or improving teamwork.
These goals may create significant long-term value even when they do not immediately produce a measurable financial outcome.
Think of an RPG. You spend time developing your character, acquiring new abilities, improving your equipment, increasing your stats and unlocking new parts of the skill tree.
You are becoming more capable.
But levelling up is not the objective of the game. Eventually, you need to use those abilities.
Performance Goals create the win condition
Performance Goals are different. They define what must actually happen.
Launch the product. Increase sales. Reduce cost. Improve service quality. Complete the project. Shorten cycle time. Increase customer satisfaction.
These are the mission objectives. They provide direction and a measurable definition of success.
The problem appears when performance becomes detached from capability. An organisation can continuously raise targets without asking whether the people expected to achieve them are developing the skills required to do so.
Eventually that becomes unsustainable.
You cannot indefinitely demand higher performance from the same capabilities, processes and resources. Something has to improve.
Why separate the two?
Imagine an employee development plan containing:
Improve presentation skills.
Fine. But why? Where will those skills be used? What will become better as a result?
Now imagine a performance target:
Increase executive approval of investment proposals.
Also reasonable. But perhaps one of the reasons proposals are struggling is that the person presenting them needs to become better at structuring complex information for senior decision-makers.
The two goals belong together.
A Devformance Goal could therefore be:
Develop executive presentation and storytelling skills and apply them to investment proposals, increasing first-round approval rates from X to Y.
The development is no longer a side activity. It becomes part of achieving the performance objective.
The problem with development that never leaves the classroom
Organisations spend significant amounts on training: courses, certifications, leadership programmes, conferences and learning platforms.
Some of that creates enormous value. Some of it becomes something employees complete because the system says they should.
The difference is often application.
You can attend an excellent course on negotiation, but if you never negotiate anything important afterwards, how much capability have you actually built? You can complete a data analytics programme, but if your job continues exactly as before, the organisation may never benefit from that investment.
Development becomes much more powerful when people have an immediate reason to use what they learn. That creates practice, feedback, iteration and eventually competence.
The opposite problem: performance without development
The opposite problem is just as common.
Someone performs well, so next year the target increases. They perform well again, and the target increases again. More responsibility arrives. More complexity. More stakeholders. More pressure.
But the person's capabilities, tools and support remain largely unchanged.
Eventually the system reaches its limit.
This is why development is not something that should happen only when performance is poor. High performers need development precisely because organisations expect them to keep performing in increasingly difficult environments.
Performance and development should reinforce each other.
Four ways to build Devformance Goals
There is no single template that works everywhere, but I find four combinations particularly useful.
1. Skill acquisition with a targeted outcome
Learn something new because achieving the performance objective requires it.
For example:
Develop advanced analytics capability and use it to reduce data analysis turnaround time by 30%.
The learning component is explicit, and so is the performance result.
This is much stronger than simply writing:
Complete advanced analytics training.
Completing the course is not really the objective. Using the capability is.
2. Competency improvement with measurable results
Sometimes the capability already exists. The objective is to become significantly better at it.
Imagine a leader responsible for improving an underperforming operation. A traditional Development Goal might be:
Improve Lean leadership capability.
The Performance Goal might be:
Reduce operating cost by 15%.
Combined:
Strengthen Lean leadership capability and apply it to redesign the operating model, targeting a 15% reduction in operating cost.
Again, capability and outcome reinforce each other.
3. Knowledge expansion with performance integration
Some objectives require deeper knowledge rather than a completely new skill. You might need to understand a market, a customer segment, a technology, a regulation, a competitor landscape or a business model.
The Devformance Goal should connect that knowledge directly to a decision or outcome.
For example:
Develop deeper knowledge of an emerging market and use that insight to create and execute the market-entry strategy.
Now "learning about the market" is not an isolated research exercise. It is preparation for execution.
4. Teamwork and leadership with goal alignment
Development does not have to be individual. Teams develop capabilities too.
A leader might need to become better at managing a distributed team while simultaneously delivering a difficult transformation.
A Devformance Goal might be:
Develop cross-functional leadership practices while leading the global team responsible for delivering the product launch on schedule.
The project becomes the environment in which leadership develops, and leadership development increases the probability that the project succeeds.
The performance target still needs to be credible
Combining learning and performance does not remove the fundamentals of good goal setting.
A bad target does not become good because you attach a development activity to it. The objective still needs appropriate ownership, assumptions, resources and alignment.
This connects directly to the Goal Trilemma.
The Goal Setter, Approver and Team Working Towards the Goal need a shared understanding of what is being asked. If someone is expected to learn an entirely new capability while simultaneously delivering an aggressive target, that additional learning effort needs to be recognised.
Development requires time. Practice requires time. Mistakes are part of learning.
Pretending otherwise simply hides another dependency inside the goal.
Do not confuse activity with development
Attend a leadership course is an activity.
Improve leadership capability is development.
Improve leadership capability and use it to increase the team's delivery reliability begins to resemble Devformance.
The objective is not the course. The objective is increased capability that contributes to improved performance.
That means the development side should also be observable. Did the person actually learn? Did behaviour change? Did the capability improve? Was it applied? Did it contribute to the intended result?
Training completion alone tells us very little.
Not every goal needs to be Devformance
I would not force this concept onto everything.
Some Performance Goals should simply be Performance Goals. Some Development Goals genuinely need space without an immediate business target attached. Learning something exploratory can create value that is impossible to quantify beforehand.
That is fine.
Devformance Goals are useful when there is a natural connection between what someone needs to become better at and what the organisation needs them to achieve.
Do not manufacture a connection simply to make the framework look complete.
The framework should serve the work, not the other way around.
Development can become a leading indicator of performance
There also matters for performance-management implication.
If future performance depends on capabilities that do not yet exist, development itself becomes part of the performance chain.
Suppose an organisation wants to automate a major process. The final Outcome KPI might be cost reduction. Before that comes process improvement. Before that comes technology adoption. But somewhere even earlier, people may need new skills to design, operate or manage the automated process.
Capability development therefore becomes an early signal.
If six months into the transformation nobody has developed the required skills, the final financial result may already be at risk.
That is why human capability belongs inside Enterprise Performance Management. People are not separate from execution. They are part of the system that produces it.
Devformance and the growth mindset
I also like how this changes the relationship with performance.
Development creates a different psychological relationship with performance.
A pure Performance Goal can become binary: hit or miss, green or red.
A Devformance Goal contains another dimension. What did we learn? What capability did we build? What are we now able to do that we could not do before?
That does not mean poor results should be excused because somebody learned something. Performance still matters.
But an organisation that continuously builds capability while pursuing results is better positioned for the next challenge than one that looks only at the current score.
Careers already work this way
When I look at my own career, most of the important development did not happen separately from work.
I learned by moving into unfamiliar environments: engineering, offshore operations, investment and portfolio management, transformation, performance management and data.
Each new challenge required me to learn something I did not fully understand before. And the learning mattered because there was an actual problem to solve.
That combination is powerful.
You are not learning because a development plan says you should. You are learning because you need the capability to succeed.
The mission creates the motivation. The development improves your chances of completing the mission.
How to write a Devformance Goal
A simple structure is:
Develop [capability] and apply it to [performance objective], measured by [result].
For example:
Develop advanced stakeholder-management capability and apply it to the transformation programme, increasing milestone acceptance from 70% to 90%.
Or:
Build advanced data-modelling skills and use them to automate the monthly reporting process, reducing preparation time from five days to two.
Or:
Develop coaching capability and apply it across the team, increasing internal readiness for critical roles over the next twelve months.
The exact wording matters less than the logic. There should be a visible connection between what you are learning and what that learning should help you achieve.
Review both sides of the goal
When reviewing a Devformance Goal, do not only ask whether the final KPI was achieved. Ask two sets of questions.
Development: What capability was supposed to improve? Did it improve? How do we know? Was the new capability actually applied?
Performance: What outcome was expected? Was it achieved? What contributed to the result? What prevented it?
Then look at the connection between them.
Did the development actually help performance?
If not, perhaps the wrong capability was developed. Or perhaps the assumed relationship between capability and outcome was wrong.
That is useful information too.
Development is an investment in future performance
Organisations often talk about people as their most important asset. The real test is whether they invest accordingly.
Development should not be something squeezed into whatever time remains after "real work" is finished. Building capability is part of the real work when future performance depends on it.
At the same time, development becomes more credible when it connects to genuine organisational needs.
That is the balance Devformance Goals try to create.
Development gives people the capacity to take on bigger challenges. Performance gives development direction and application.
One prepares you for the next level. The other gives you a reason to reach it.
Put them together and you get something more powerful than either one alone.
You do not only beat the level. You become a better player while doing it.
This article develops the Devformance Goals concept originally explored through my EPM Mondays series and later expanded in Performantria: Master the Game of Enterprise Performance Management.
Explore the full Performantria framework for Enterprise Performance Management.
Download the e-book for FREE!
Two years ago I unveiled the icy world that is Polar in my book "Polar: The Ice Dragon's Curse." Life is too short not to celebrate, so today and the next couple of days you can download the e-book for FREE!
I got my inspiration to write Polar from many late nights with my friends playing Drakar & Demoner (similar to, but not the same as, Dungeons & Dragons). I saw these two dwarves sitting by a small fire that barely popped on the frozen tundra and thought—what are their purpose? What do they aspire to besides just staying alive?
That's where my story started. They were in a cold place, but why was it cold and what could they do not to perish?
I remember the drilling fluids from my offshore days being referred to as "Mud" and thought that was a fitting name for a fluid that kept these two warriors warm.
But I needed magic – as I so often do – so I thought we should make the bad guys the elves who had enslaved magic through their fire bracelets.
But then again, I wanted to make a comment on the world's ever-turning towards consumption and aspiration of getting more of something expensive instead of chasing what is free. So then I saw it: True Love. Known to put fire in people's hearts, I saw that as my take on overcoming the coldness.
So welcome to the world of old magic, freezing cold landscapes, and an unlikely band of heroes coming together to end the reign of the Ice Dragon Claymore.
What moment sparked your biggest creative breakthrough? I'd love to hear about it.
📖 Grab your free copy: https://a.co/d/cF1nkCp
hashtag#Fantasy hashtag#Writing hashtag#BookPromo hashtag#Storytelling
Why Data Governance Is the Foundation of Performance Management
Everyone wants better dashboards.
Better analytics.
Better AI.
Better decisions.
But there is an uncomfortable problem underneath all of them.
What if the data is wrong?
A beautiful dashboard built on weak definitions, inconsistent master data or unclear ownership is still a beautiful presentation of uncertainty.
That is why I see Data Governance as one of the foundations of Enterprise Performance Management.
You cannot reliably manage performance if you cannot reliably understand the data beneath it.
Performance management starts below the dashboard
When people discuss performance management, they often start with the visible layer.
KPIs.
Scorecards.
Dashboards.
Reports.
Those are important, but they sit surprisingly high in the information chain.
Underneath every KPI are definitions, calculations, business rules, master data, transactional data, systems and people responsible for maintaining all of it.
If those foundations are weak, problems eventually surface further up.
Two departments report different versions of the same number.
A KPI suddenly changes because a definition changed.
A product appears differently across systems.
A customer is duplicated.
A calculation works technically but measures something nobody intended.
Then the meeting that should be about performance becomes a meeting about data.
That is expensive.
A dashboard cannot compensate for weak foundations
This is a principle I keep coming back to.
A dashboard cannot compensate for weak foundations.
Technology can make data easier to process, visualise and distribute.
It cannot automatically make the underlying information trustworthy.
If a source contains duplicates, the dashboard can display duplicates faster.
If ownership is unclear, automation can scale the uncertainty.
If definitions differ between systems, AI can summarise the disagreement beautifully.
The technology is not necessarily the problem.
The foundations are.
What is Data Governance?
Data Governance provides the structure for deciding how important data should be defined, owned, maintained, protected and used.
It establishes accountability.
Who owns this data?
Who maintains it?
Who can change it?
Which definition is authoritative?
Which system is the source?
How do we measure quality?
What happens when something is wrong?
Good governance makes those questions answerable.
It should not exist simply because an organisation wants a governance framework.
It should make the organisation easier to operate.
Governance is not the same as bureaucracy
There is always a risk that governance becomes synonymous with committees, documentation and approval chains.
That is not the objective.
Good governance should reduce friction.
If everybody knows the authoritative definition, there are fewer debates.
If ownership is clear, issues move faster to the right person.
If standards are built into normal processes, fewer defects need to be corrected later.
If metadata explains what data means, users spend less time reverse-engineering dashboards.
Governance should therefore be embedded as closely as possible into normal business processes.
The goal is not more governance activity.
The goal is better-controlled data.
Start with ownership
One of the simplest questions in Data Governance is also one of the most powerful:
Who owns the data?
Someone needs accountability for important data domains.
That does not mean the owner personally updates every record.
It means somebody is accountable for ensuring that the data is fit for its business purpose.
The Data Owner provides that accountability.
But ownership alone is not enough.
You also need people working much closer to the data.
That is where Data Stewards become critical.
The role of the Data Steward
I think of Data Stewards as the guardians of organisational data.
They work closer to the day-to-day reality and help make sure data remains accurate, complete, consistent, usable and properly controlled.
Depending on the organisation, stewardship may be a dedicated position or part of another role.
The title matters less than the responsibility.
Typical stewardship activities include maintaining data quality, supporting users, monitoring standards, handling or reviewing master data changes, helping resolve issues and working with Data Owners to improve the data over time.
Without stewardship, governance risks remaining theoretical.
Policies may exist.
Standards may exist.
But nobody is actively protecting them where the data is created and changed.
Master Data matters more than people think
Some data objects appear again and again across an organisation.
Products.
Customers.
Suppliers.
Locations.
Contracts.
Employees.
Organisational units.
These are examples of Master Data.
They may look simple.
They rarely are.
A Product can have a commercial definition, financial classification, operational representation, technical configuration and reporting hierarchy.
If different systems describe that product differently, the problem travels downstream.
Sales may quote one thing.
Operations execute another.
Finance reports something slightly different.
Analytics tries to reconcile all three.
That is why Master Data Management is not simply a technical data exercise.
It is part of operating the enterprise.
Definitions are data too
Many performance problems are really definition problems.
Imagine two people discussing revenue.
One includes a certain category.
The other excludes it.
Both calculations are technically correct according to their own definitions.
The meeting can continue for an hour without anyone realising they are discussing different things.
Metadata helps prevent this.
Metadata is data about data.
It explains context such as:
What does this field mean?
Where does it originate?
How is it calculated?
Who owns it?
Which system uses it?
How does it relate to other data?
In gaming terms, metadata is the map.
You can explore without one.
You will just spend considerably more time getting lost.
Data Quality must be measurable
Saying that data should be "high quality" is not enough.
Quality needs dimensions.
Depending on the data, you might assess things such as:
Completeness.
Accuracy.
Consistency.
Validity.
Timeliness.
Uniqueness.
The important part is choosing dimensions that actually matter for the business use case.
If a field is mandatory but nobody needs it, 100% completeness may tell you very little.
If a customer identifier must connect transactions across five systems, uniqueness and consistency may be critical.
Data Quality should therefore always be connected to purpose.
First time right beats endless cleansing
There is also an important difference between preventing data defects and cleaning them afterwards.
Organisations can spend enormous amounts of effort cleansing poor data downstream.
That may be necessary.
But the stronger solution is usually to move closer to the point where the data is created.
Why was the wrong value possible?
Was the definition unclear?
Was validation missing?
Did the user lack the information needed?
Did two systems allow different structures?
Was ownership unclear?
The further downstream you fix the problem, the more places the defect may already have travelled.
A "first time right, every time" mindset is therefore much more powerful than an endless cycle of cleansing.
Not because perfection is realistic.
But because prevention scales better than repair.
Data Governance and EPM are inseparable
Now return to Enterprise Performance Management.
Suppose leadership is reviewing an important KPI.
For that KPI to be trustworthy, several things need to be true.
The definition must be understood.
The calculation needs to be correct.
The source data needs sufficient quality.
The relevant master data must be consistent.
The refresh timing needs to be understood.
Ownership should be clear.
Changes need to be governed.
Only then can leadership confidently discuss the performance represented by the number.
Otherwise, the performance review becomes:
"Where did this number come from?"
"Why is Finance showing something else?"
"Has the definition changed?"
"Can somebody check this after the meeting?"
At that point, Data Governance has become a performance problem.
Data Quality is not an IT problem
Another mistake is treating data quality as something the technology organisation should fix.
IT operates and supports important parts of the data environment.
But business data usually describes the business.
Product definitions require Product knowledge.
Customer data requires commercial understanding.
Financial data requires Finance.
Operational data requires operational expertise.
That is why Data Governance needs both business and technology.
The business provides meaning and accountability.
Technology provides systems, controls, integration and scale.
Neither side can do it properly alone.
Better AI makes governance more important, not less
As analytics and AI become more capable, the quality of the underlying information becomes even more important.
AI can process an enormous amount of information.
But scale works both ways.
Reliable data can create better insight faster.
Poor data can spread ambiguity faster.
Before asking whether an organisation is AI-ready, I would therefore ask some much less glamorous questions.
Do we understand our critical data?
Do we know who owns it?
Do we trust the definitions?
Can we trace where it comes from?
Do we understand its quality?
Can important systems connect the same business objects consistently?
Those foundations will matter regardless of which AI technology comes next.
Governance should improve decisions
This is the test I would apply to any Data Governance initiative.
Does it improve the organisation's ability to make decisions and execute?
If not, examine why.
Maybe the governance is too theoretical.
Maybe ownership exists only on paper.
Maybe policies are impossible to find.
Maybe Data Stewards lack authority.
Maybe the organisation measures governance activity rather than data outcomes.
The objective is not to prove that governance exists.
The objective is to make important data more reliable, understandable and usable.
Build from the business backwards
A useful starting point is not:
"What governance framework should we implement?"
Start with:
Which business decisions depend on reliable data?
Then work backwards.
Which KPIs support those decisions?
Which data feeds the KPIs?
Which master data objects do those processes depend on?
Which systems create and consume them?
Who owns the definitions?
Who stewards the data?
Where are the quality problems?
Now governance has a purpose.
And that purpose connects directly to performance.
Data is part of the operating model
Ultimately, data is not something sitting beside the business.
It is part of how the business operates.
Products are data.
Customers are data.
Contracts are data.
Transactions are data.
KPIs are data.
Strategy itself eventually becomes translated into objectives, targets and measures that depend on data.
This is why Data Governance belongs inside Enterprise Performance Management.
Without trustworthy data, leaders cannot reliably see performance.
Without clear ownership, defects persist.
Without metadata, meaning is lost.
Without Master Data Management, systems drift apart.
And without those foundations, increasingly sophisticated technology simply gives us more sophisticated uncertainty.
Good performance management therefore does not begin with the dashboard.
It begins with the data beneath it.
This article brings together ideas originally explored through my EPM Mondays series and later expanded in Performantria: Master the Game of Enterprise Performance Management.
Explore the full Performantria framework for Enterprise Performance Management.
🌨️ The 2025 Edition of Polar: The Ice Dragon’s Curse is here!
This new version of Polar comes with a fully redesigned world map, a new foreword, updated character descriptions, and full Kindle X-Ray support. If you're reading on a Kindle device or app, you can now tap on names or places to instantly get background info—without ever leaving the page.
Already own the ebook? Just re-download it to get the update. 👉 Buy it on Amazon
“Dream until your mind is at ease… Dream until the world is at peace.”
This story began with two dwarves huddled by a dying fire. I had no idea what they were chasing—only that it mattered. That image sparked a world. From there came Aether and Mud, frost and flame, falcon spears and dragons, spellcasters and thieves, priests and princesses. It became a world where true love is rarer than gold—and more powerful than anything else.
If you’ve been with the series since the beginning: thank you. If you're just discovering Polar: welcome. The 2025 edition is truer to the soul of the story than ever before—and it moves fast. Really fast. No waiting around. No filler. Just the chase.
🔗 Click here to get the new edition on Amazon
Or scroll down to explore the new world map and cast of characters.
The Map of Polar
The Goal Trilemma: Why Good Business Goals Fail
A goal can be perfectly reasonable when it is created.
Then somebody approves it.
Somebody else increases it.
Another team adds a dependency.
The budget changes.
The people expected to deliver it discover that the assumptions no longer match reality.
And suddenly a good goal is no longer a good goal.
This is what I call The Goal Trilemma.
It is one of the concepts I developed while working with Enterprise Performance Management and later expanded in Performantria.
The idea is simple:
A goal does not exist in isolation.
Its success depends on three parties being aligned.
The Goal Setter
The Approver
The Team Working Towards the Goal
When those three perspectives are aligned, a goal has a reasonable foundation for success.
When they are not, even an excellent goal can fail.
What is the Goal Trilemma?
The Goal Trilemma is a framework for understanding the relationship between the person or function setting a goal, the person approving it, and the team responsible for delivering it.
These roles often see the same target from very different perspectives.
The Goal Setter may have performed the detailed analysis.
The Approver may be looking across a much broader organisational portfolio.
The Team may understand operational constraints that neither of the other two can see.
None of those perspectives is necessarily wrong.
The problem appears when one perspective changes the goal without properly understanding the others.
That creates misalignment.
And misalignment creates bad performance management.
Think of the Project Management Iron Triangle
The idea is partly inspired by one of the most familiar concepts in project management.
The Iron Triangle.
A project needs to balance:
Time.
Cost.
Scope.
Change one and something else usually moves.
If you shorten the schedule while keeping the scope fixed, you may need more resources.
Reduce the budget while keeping the deadline and scope unchanged, and you have created a different problem.
The constraints interact.
Goals work in a similar way.
But instead of balancing time, cost and scope, the Goal Trilemma balances the people involved in creating, approving and delivering the target.
The dependencies are less visible.
That is why they are so easy to ignore.
The Goal Setter
The Goal Setter is usually the person or team that develops the target.
Ideally, they understand:
What needs to be achieved.
Why it matters.
What the historical performance looks like.
Which resources are available.
What assumptions have been made.
What dependencies exist.
What level of improvement appears realistic.
A properly developed target therefore represents more than a number.
It is the result of analysis.
If that analysis suggests that 2.5% improvement is realistic, 2.5% should not automatically be interpreted as a lack of ambition.
It may simply be the best estimate supported by the information available.
That distinction matters.
A target should be challenging.
But there is a difference between challenging and imaginary.
The Approver
The Approver has a different responsibility.
They need to challenge assumptions.
They may have access to information that the Goal Setter does not.
They may see competing priorities across the organisation.
They may understand investor expectations, financial constraints or strategic ambitions at a different level.
That challenge is valuable.
The problem begins when challenge becomes arbitrary escalation.
A target should not increase simply because:
Last year's number was higher.
Another department has a higher target.
The number looks too small on a PowerPoint slide.
Or somebody wants a cleaner number to present upwards.
Ambition without understanding is not performance management.
It is wishful thinking.
The Team Working Towards the Goal
Then there is the team actually expected to deliver the outcome.
This perspective is often the most overlooked.
The team understands the operational reality.
They know where the bottlenecks are.
They know which dependencies are fragile.
They know whether the resources exist.
They know whether the timeline is realistic.
And they often know something else that becomes extremely important:
Whether they actually believe the goal is achievable.
You can approve a target without creating commitment.
If the team sees the number as arbitrary from the beginning, you have already created a performance problem.
When a 2.5% target becomes 10%
Here is an exaggerated version of a situation I have seen more than once.
A team performs the analysis.
They break the goal into components.
They examine historical performance, assumptions and available resources.
The conclusion is that a 2.5% improvement is challenging but achievable.
Then the goal begins travelling upwards.
A VP looks at the target and says:
2.5%?
Last year we achieved 4%.
Make it 4%.
The EVP sees targets from several other functions and thinks 4% does not look particularly ambitious.
Make it 7%.
Eventually it reaches the CEO.
Seven is an awkward number to explain to the Board.
Make it 10%.
Now imagine that the team eventually delivers 3%.
Against the original analysis, they have actually outperformed.
Against the final target, they have failed badly.
The manager is disappointed.
The manager's manager is disappointed.
Leadership sees red.
But what exactly failed?
The execution?
Or the goal-setting process?
Donkey Kong explains the problem surprisingly well
Think about the original Donkey Kong.
The objective is clear.
Reach the top.
Rescue Pauline.
Then the barrels start coming.
You adapt.
More barrels.
Fireballs.
Different platforms.
More obstacles.
Now imagine that somebody keeps moving Pauline further away every time you get closer.
That is what badly governed goal setting can feel like.
The team begins with a clear objective.
Then unexpected requirements and management changes are added while the goal remains supposedly unchanged.
Eventually the organisation is measuring the team's ability to dodge obstacles rather than its ability to achieve the original business outcome.
The Goal Trilemma makes those dependencies visible.
Alignment does not mean everyone has to agree immediately
This is important.
The Goal Trilemma does not mean that the Team gets to choose an easy target.
It does not mean the Goal Setter owns the final number.
And it does not mean senior management should stop challenging targets.
Challenge is healthy.
What matters is that the challenge becomes a discussion between the three perspectives.
If leadership believes 2.5% should really be 5%, ask why.
What assumption needs to change?
Can more resources be allocated?
Can the scope change?
Can another dependency be removed?
Is there evidence suggesting that higher performance is realistic?
Now you are having a performance conversation.
Simply replacing 2.5 with 5 is not the same thing.
Goals also collide across organisational boundaries
The Goal Trilemma becomes even more important when one team's target affects another team's target.
I experienced a simple example offshore.
Our operations team wanted to minimise the time specialist service personnel spent on the rig.
These specialists could be expensive.
If their work was finished, we wanted them on the next helicopter home.
Makes sense.
But the helicopter operations team had its own objective:
Reduce the number of helicopter flights.
That also makes sense.
Now we have two individually reasonable KPIs pushing the organisation in opposite directions.
One team saves money by sending people home quickly.
Another saves money by reducing flights.
Optimise either KPI in isolation and you may increase the total cost to the company.
This is why the Goal Approver needs to understand more than one target.
Enterprise performance is not the sum of locally optimised KPIs.
Sometimes the organisation needs to sacrifice one local measure to improve the overall outcome.
A green KPI can still be bad performance
This leads to one of the dangers of performance management.
Local optimisation.
Imagine Team A has a green KPI.
Team B also has a green KPI.
Yet together their decisions create a worse outcome for the enterprise.
Both teams can technically claim success.
The company loses.
That is why performance governance needs to connect goals across functions.
The question should not only be:
Did you achieve your target?
It should also be:
Did achieving your target help the organisation achieve its objective?
Those are not always the same thing.
Be careful when changing targets
Targets sometimes genuinely need to change.
The world changes.
Budgets disappear.
Markets move.
Priorities shift.
Dependencies fail.
But changing a target should be a governed decision.
The same perspectives involved in establishing the goal should understand why it is being changed.
Otherwise, the organisation loses the integrity of the original agreement.
My preference is usually to first analyse the deviation and adjust the strategy rather than immediately rewriting the target.
If performance falls behind, ask:
Why?
What changed?
Can we alter the approach?
Can resources move?
Can a dependency be solved?
What have we learned?
Changing the target should not become the easiest way to make a red KPI green.
Imagine doing this outside your company
Some organisational behaviour becomes absurd when you move it outside the office.
Imagine walking into a restaurant.
A sirloin steak costs $25.
You tell the restaurant:
I am only giving you $20.
But I still want exactly the same steak.
Same quality.
Same size.
Same service.
Same delivery time.
The restaurant will probably tell you that something has to change.
Yet organisations regularly do the equivalent internally.
Here is 80% of the budget.
The deadline stays the same.
The scope stays the same.
The quality must stay the same.
And the target stays the same.
Then everyone acts surprised when performance suffers.
Constraints matter.
Pretending they do not exist does not make the goal more ambitious.
It makes the plan less credible.
How to use the Goal Trilemma
Before finalising an important goal, make the three perspectives explicit.
Who is setting the goal?
Who approves it?
Who actually has to deliver it?
Then make the assumptions visible.
What data supports the target?
What resources are assumed?
Which teams does it depend on?
Which other goals could conflict with it?
What happens if one of those assumptions changes?
Most importantly, create the discussion before the target is locked.
It is much easier to challenge an assumption during planning than to explain six months later why the target was impossible from the beginning.
Goal setting is governance
This is why I see goal setting as part of Enterprise Performance Management rather than a standalone annual exercise.
Goals connect strategy with execution.
They determine what receives attention.
They influence resource allocation.
They shape KPIs.
They affect incentives.
And they tell teams what the organisation considers important.
A poorly governed goal therefore creates consequences far beyond one number on a scorecard.
It can make people optimise the wrong behaviour.
It can create conflicts between functions.
It can damage trust.
It can make good performance look bad.
And perhaps worst of all, it can make people stop believing in the performance system itself.
The goal is alignment, not perfection
Even a perfectly aligned Goal Trilemma does not guarantee success.
Things still go wrong.
Assumptions fail.
Markets change.
People make mistakes.
That is business.
The point is to create a common foundation from which those discussions can happen.
The Goal Setter understands why the target was approved.
The Approver understands the assumptions beneath it.
The Team understands what it is committing to.
And when reality changes, everyone has the same starting point for deciding what to do next.
A good goal should create direction.
Not confusion.
Not politics.
Not a number that gradually changes as it travels through the organisation.
If the Goal Setter, Approver and Team are not aligned, you do not really have one goal.
You have three different interpretations of one.
And sooner or later, the barrels will start coming.
This article develops the Goal Trilemma concept originally shared through my EPM Mondays series and later expanded in Performantria: Master the Game of Enterprise Performance Management.
Explore the full Performantria framework for Enterprise Performance Management.
KPI Dimensions: Why Leading vs Lagging Is Not Enough
KPIs are everywhere.
That does not mean organisations understand what they are measuring.
One of the most common ways to categorise KPIs is:
Leading.
Lagging.
Useful?
Yes.
Enough?
I do not think so.
Performance is rarely one-dimensional.
If you only look at the final outcome, you may know whether you won or lost.
You may have very little idea why.
That is why I use a broader concept in Performantria that I call KPI Dimensions.
What are KPI Dimensions?
KPI Dimensions are a way of categorising Key Performance Indicators according to the part of the performance journey they help us understand.
Instead of relying only on leading and lagging indicators, I typically look across six broad dimensions:
Deliverable
Adoption
Process
Performance
Outcome
Tech Platform
They do not need to become rigid boxes.
Their purpose is to force us to examine performance from several perspectives.
Because a single KPI almost never tells the whole story.
Think beyond the final score
Imagine launching a new digital product.
Revenue is the obvious outcome.
If revenue is high, great.
If revenue is low, something went wrong.
But what?
Was the product actually launched as planned?
Are customers using it?
Is the underlying process efficient?
Does the product work properly?
Are users satisfied?
Is the technical platform stable?
Revenue alone cannot answer those questions.
You need different types of indicators along the journey.
That is what KPI Dimensions provide.
1. Deliverable KPIs
Deliverable KPIs answer:
Did we actually produce what we said we would produce?
They are especially useful in projects, transformation and product development.
Examples could include launch readiness, milestones completed, functionality delivered or the completion of a required capability.
This is often the first layer of performance.
Before asking whether something created value, it helps to know whether it actually exists.
But completing the deliverable is not the same as success.
A project can deliver everything on time and still produce something nobody uses.
That brings us to Adoption.
2. Adoption KPIs
Adoption KPIs ask:
Are people actually using what we delivered?
This might include utilisation, participation, engagement, activation or user uptake.
Imagine developing an expensive new system.
The project delivers successfully.
Everything is green.
Six months later, most employees are still using Excel.
Was the project successful?
From a Deliverable perspective, perhaps.
From an Adoption perspective, clearly not.
This distinction becomes extremely useful in transformation.
Delivery tells you that change was created.
Adoption tells you whether change actually entered the organisation.
3. Process KPIs
Process KPIs examine:
How efficiently and reliably does the work happen?
Examples include cycle time, processing time, error rate, rework, throughput or unit cost.
These indicators help us understand how work moves through the organisation.
Imagine that customer orders eventually ship successfully.
Your Outcome may look reasonable.
But if every order requires twelve manual interventions and several corrections, the process underneath is weak.
Outcome KPIs may hide this.
Process KPIs reveal it.
4. Performance KPIs
Performance KPIs look at:
How effectively is the product, service, team or operation actually performing?
This is the operational effectiveness layer.
Depending on the context, examples might include productivity, service quality, responsiveness, reliability or workload performance.
The exact distinction between Process and Performance KPIs can vary between organisations.
That is fine.
The important part is agreeing on the definitions and using them consistently.
A taxonomy only creates value when people share the same language.
5. Outcome KPIs
Outcome KPIs answer the big question:
Did it create the result we actually wanted?
Examples might include revenue growth, cost reduction, customer satisfaction, ROI, market share or another business outcome.
These are often the KPIs senior leadership cares about most.
And understandably so.
Outcomes connect performance with value.
But they also occur relatively late in the chain.
If you wait until the final Outcome KPI tells you something went wrong, your options may already be limited.
That is why you need the other dimensions.
6. Tech Platform KPIs
Modern companies are increasingly technology-enabled.
That creates another dimension that is easy to overlook.
Can the technology reliably support the performance we expect?
Tech Platform KPIs might include uptime, response time, incident frequency, data pipeline reliability or another measure of technical health.
A customer-facing process can be excellent on paper.
If the system supporting it is unavailable, none of that matters.
Technology health therefore deserves explicit visibility where technology is critical to the business outcome.
Think of a chain, not six isolated boxes
These dimensions become most useful when you connect them.
Imagine a new digital sales capability.
You could have:
Deliverable: Was the functionality launched?
Adoption: Are sales teams using it?
Process: Is the new process faster?
Performance: Is sales productivity improving?
Outcome: Is revenue or conversion improving?
Tech Platform: Is the system reliable enough to support all of the above?
Now performance becomes a story rather than a collection of unrelated numbers.
If the Outcome is poor but Adoption is also poor, you immediately have a clue.
If Adoption is high but Process performance is deteriorating, you look somewhere else.
If everything appears healthy except Platform reliability, you have another direction.
That is much more useful than one red number.
Leading and lagging still matter
I am not arguing that leading and lagging indicators are useless.
They are valuable.
But they describe a different characteristic.
An Adoption KPI might be leading in relation to a financial Outcome KPI.
A Process KPI might also be leading.
An Outcome KPI is often lagging.
So "leading or lagging" and "which performance dimension does this KPI represent?" are not competing taxonomies.
They answer different questions.
That is precisely why performance should be viewed multidimensionally.
The hierarchy matters too
Not every number should be called a KPI.
Organisations often have thousands of data points.
Some become metrics.
Some become Performance Indicators.
A much smaller number should become Key Performance Indicators.
The word Key matters.
If everything is key, nothing is.
A useful KPI should tell us something important enough to influence attention, discussion or action.
Otherwise, it is probably supporting information.
There is nothing wrong with supporting information.
It just does not need executive status.
One of my own KPI mistakes
I learned this the practical way while working with Transformation Performance.
We identified KPIs that looked conceptually right.
They represented the outcomes we wanted to understand.
Then we discovered something rather inconvenient.
The data needed to calculate some of them did not actually exist.
We had selected the KPI before confirming the data foundation.
The solution was not to invent a weaker number and pretend it meant the same thing.
We stepped back.
We clarified the performance framework.
We examined the scorecard structure.
We identified the data gaps.
And we created dedicated work to source the information properly.
It reinforced a basic lesson:
An excellent KPI without reliable data is not an excellent KPI.
It is an aspiration.
Define the KPI properly
A KPI should be more than a name and a number.
For important KPIs, I want to know considerably more.
What is it called?
What unit does it use?
Which KPI Dimension does it belong to?
Why does it matter?
Who owns it?
What exactly is the definition?
How is it calculated?
Which data source does it use?
How often is it refreshed?
Is higher better or lower better?
What is the baseline?
What are the thresholds?
Which other KPIs depend on it?
What risks could affect performance?
How reliable is the underlying data?
This may sound like overkill.
It is not.
If an organisation is making important decisions from a KPI, it should understand what that KPI means.
The vector is surprisingly important
One tiny detail causes more confusion than it should.
Is higher good or bad?
Revenue?
Usually higher is better.
Cost?
Often lower.
Defects?
Lower.
Customer retention?
Higher.
Without an explicit performance vector, people can stare at the same number and interpret the direction differently.
Small pieces of metadata like this dramatically improve the quality of performance discussions.
Again, clarity beats sophistication.
Do not choose KPIs because the data is convenient
There are two bad extremes.
The first is designing the perfect KPI and discovering there is no data.
The second is allowing whatever data happens to exist to dictate what the organisation measures.
Neither is ideal.
A pure top-down approach can create theoretically perfect measures that are impossible to calculate.
A pure bottom-up approach can trap the organisation into measuring only what was historically available.
I prefer a middle-out approach.
Understand the desired outcomes.
Look at the available data.
Identify the gap between the two.
Then deliberately decide which new measures are worth creating.
That creates a more realistic path from strategy to measurement.
KPIs should help you diagnose performance
Think of a warning light in a car.
The light is useful because it tells you where to start looking.
A KPI should serve a similar purpose.
A red Outcome KPI alone tells you that the organisation has a problem.
A set of well-structured KPI Dimensions can help tell you where the problem may be.
Did we fail to deliver?
Did people fail to adopt?
Is the process inefficient?
Is operational performance deteriorating?
Did the expected business outcome fail to materialise?
Did the underlying technology become unstable?
Now the conversation moves from:
"We are red."
to:
"Here is where the performance chain appears to be breaking."
That is a much better starting point for action.
Avoid KPI overload
Once people become interested in measurement, another danger appears.
Everything becomes a KPI.
More dashboards.
More indicators.
More reporting.
More red, amber and green circles.
The objective should be the opposite.
Use the smallest set of KPIs that gives you enough information to understand and steer performance.
Detailed data can remain underneath.
Leadership does not need every metric.
It needs the measures that help identify whether the organisation is moving towards its objectives and where intervention may be required.
The purpose is understanding, not categorisation
The six KPI Dimensions are not valuable because six is a magical number.
They are valuable because they force a broader conversation.
Are we measuring only delivery?
Only outcomes?
Do we understand adoption?
Can we see the process?
Are technology dependencies visible?
Do our indicators collectively explain performance?
That is the real test.
A taxonomy should help people think.
If it becomes an administrative classification exercise, simplify it.
Better KPIs create better conversations
Enterprise Performance Management is not about collecting more numbers.
It is about creating enough shared understanding to make better decisions.
KPI Dimensions help because they expose the path between activity and outcome.
You can see what was delivered.
Whether it was adopted.
How the process behaves.
How performance is developing.
Whether value was created.
And whether the technology underneath can sustain it.
The Outcome still matters.
It is usually the reason you started.
But if you only look at the final score, you miss most of the game.
This article develops the KPI Dimensions concept originally explored through my EPM Mondays series and later expanded in Performantria: Master the Game of Enterprise Performance Management.
Explore the full Performantria framework for Enterprise Performance Management.