Context
GE's OneHR platform consolidated HR experiences across a company operating in dozens of countries and several largely independent business units. My role grew from analyst to owning the full product lifecycle and leading a distributed team of ten-plus analysts.
Twenty-five-plus responsive portals shipped over that period. The number is less interesting than what made them possible.
The problem
The first few portals were built as projects. Each one collected its own requirements, made its own information-architecture decisions, and negotiated its own compromises with the business unit sponsoring it. That works at three portals and collapses at fifteen: migration time creeps upward, quality varies by whoever ran the engagement, and every new portal is a fresh argument about decisions that were already settled elsewhere.
The real problem wasn't building portals. It was that we had no product where we needed one — a platform with defaults, and a repeatable process for the parts that genuinely differed.
Constraints
- Business units with real autonomy and legitimate differences — you can't standardise by decree when the sponsor controls the budget.
- Migration from a long tail of legacy systems, each with its own data shape and its own institutional exceptions.
- A team distributed across geographies with limited overlapping hours, where anything requiring synchronous coordination became a bottleneck.
- Enterprise change management — the users didn't choose this software and had no reason to be enthusiastic about it.
What I did
Turned the second portal into a template and the fifth into a system. Common IA patterns, component decisions, content models, and migration steps got extracted, documented, and defaulted. New engagements started from the standard and argued for exceptions, which inverted the burden of proof. Migration time came down 15%.
Made the analyst practice a documentation standard, not a set of individuals. With a ten-plus person team across time zones, quality can't depend on who's staffed. I set the discovery and documentation standard the practice ran on — what a requirement looks like when it's done, what evidence has to sit behind it — so work could be handed between people and between geographies without a re-briefing.
Wrote context down instead of holding meetings about it. Distributed teams with a two-hour overlap either become asynchronous by design or become slow by default. Written decisions with visible reasoning were the only thing that scaled.
Treated business-unit objections as product input. The units pushing back hardest on the standard were usually the ones with a real edge case the template hadn't modelled. Several of those objections became platform features, which did more for adoption than any amount of persuasion.
Outcome
25+ responsive enterprise HR portals launched, migration time reduced by 15%, and a distributed analyst practice that could take on new work without the quality depending on staffing. The platform went from a series of projects to something with defaults.
What I'd take from it
This is the period that formed the view I still work from: enterprise software fails on organisational problems far more often than technical ones. The hard part was never the portal. It was getting autonomous groups to accept a shared default, and the only thing that reliably worked was making the standard genuinely better than what they'd have built alone — and being willing to change it when it wasn't.