Leaders like to talk about outcome orientation, but their data architecture still reflects functional silos. When recruiting, learning and performance systems don't share basic data standards, outcome-based teams can't operate. The blocker isn't org structure. It's whether systems can answer simple questions. Are we talking about the same person? Is this data current? Can we trust what we're seeing?
Most organisations discover their data makes outcome orientation impossible. Systems use different IDs for the same people. Data is weeks or months old. The same skill shows three different assessments. The future belongs to enterprises with less software and better data underneath it.
The questions an outcome-based team needs answered
Organisations claim to be outcome-orientated, but their data tells a different story.
When a team is accountable for "a fully staffed, capable workforce in region X", it needs to answer basic questions. Who do we have? What can they do? Where are the gaps? What's in progress?
In most organisations that data lives in separate systems that don't talk to each other properly. The recruiting system knows who you're hiring. The learning system knows who's in training. The performance system knows who's ready for new challenges. But the systems can't connect the dots.
Same person, three different IDs
Why? Because they identify people differently. Recruiting uses one ID, learning another and performance a third. Even when it's obviously the same person, the systems can't reliably match them.
So when your team asks "should we hire someone or develop internally?", it can't get a straight answer. The data exists, but it's trapped in systems that can't talk to each other.
Data from three different moments
Then there's timing. Your recruiting data is current: you know who's in the pipeline today. Your learning data is three months old, showing courses completed last quarter rather than what's happening now. Performance data is older still, from last year's annual review.
You're trying to make decisions with data from three different moments in time. Good luck.
And the data doesn't mean the same thing across systems. "Skill level" in recruiting means something different from "skill level" in learning, and performance uses yet another definition. When you compare them, you aren't measuring the same thing.
What happens when you reorganise anyway
Most organisations discover this the hard way. They reorganise around outcomes, create cross-functional teams and set clear goals. Then those teams spend their time piecing data together by hand instead of making decisions.
The problem isn't commitment to outcome orientation. It's that the data architecture wasn't built for it. Outcome-based work needs data that works across functions:
the same person in recruiting, learning and performance
data current enough to act on
definitions that mean the same thing in every system
the ability to trace where data came from, and trust it
Without this, outcome-orientated teams are stuck. They can't answer basic questions without manual data archaeology, and they can't make joined-up decisions because the data won't join up. If your systems can't answer "who is this person and what can they do right now?", you're not ready.
Why less software and better data comes next
Enterprises will run on less software with better data underneath it.
The current approach of buying more systems, integrating later and hoping for the best creates complexity that compounds. More platforms mean more IDs to reconcile, more definitions to align and more data to keep current.
The future belongs to organisations that get the data right first: common identity, current data, shared definitions and clear lineage. With that in place you need fewer systems, the ones you have work together, and teams make decisions instead of fighting data.
The shift from functional silos to outcome orientation isn't about reorganising. It's about building data architecture that makes joined-up work possible, then resisting the urge to bury it under another round of software.
