Unifying a Fractured R&D Organization Under One Tool

The situation

Three organizations, five processes, seven tools — and no shared source of truth.

ExxonMobil's R&D function had grown up in silos — literally.

ExxonMobil's Technology R&D function was historically split across three independent "heritage organizations" (h-orgs): Chemical Technologies, Research & Engineering, and Upstream. Because each had developed on its own, they'd each built their own process — five total across the group — and their own tools — seven total — to track project progress, with no shared source of truth. That made it difficult for ExxonMobil's Planning & Budgeting team to make sound business decisions, since different parts of the organization were tracking progress using different mediums and different metrics entirely.

ExxonMobil created a new function, ExxonMobil Technology (EMTEC), specifically to oversee and unify these organizations. Stellar Elements was brought in to design and build the tool that would become that unification point: Streams, alongside a new shared process model called TIDEx. The estimated business value of solving this was roughly $84M.

The timeline wasn't fully ours to set: leadership wanted the tool's MVP launch to coincide with "Harmonization" — the broader company re-org effort — to maximize the odds of adoption. That meant compressing research and design into a shorter window than the problem's complexity really called for.

The challenge

A track record of tools that didn't stick.

Three orgs had operated independently for years, each with its own vocabulary, tools, and process — there was no existing source of truth to build from. The timeline was set by a business event outside our control, the Harmonization re-org, which meant sacrificing some research depth to hit the MVP launch window — the engagement ran September 2022 to March 2023, six months to take a 0-to-1 build from discovery through a functional MVP. Timeline-conscious product managers resisted formal design reviews, worried that opening the floodgates to structured feedback would jeopardize the deadline. And the EM UX team we reported into told us directly that ExxonMobil had a history of building internal tools that ended up "collecting dust" — users defaulted back to old habits even after a new tool shipped. That wasn't an abstract risk; it was the explicit context we were designing inside of. Streams itself was the 5th attempt at building a tool to solve this exact problem.

The approach

Building the tool and the process at the same time.

A shared vocabulary before a single screen was designed.

Before any of that discovery work started, I put together a formal Research Proposal — laying out the plan, participants, and timeline for the research itself. With the MVP launch already tied to Harmonization, time spent on discovery had to be justified up front, not assumed; the proposal was how I made the case for it and got stakeholders aligned on what we were asking people's time for.

1.0The Research Proposal, submitted ahead of discovery

Since Streams and TIDEx were being designed together, discovery had to validate both simultaneously. I ran interviews with 2–3 individuals from each h-org, walking through a past complex project using the new TIDEx model — deliberately trying to break it, looking for gaps and edge cases where the process wouldn't capture what actually needed to be tracked. Because the three h-orgs had evolved independently, they didn't even fully agree on terminology. The initiative's adoption lead hosted a couple of half-day workshops, within which I led several of the core activities — mapping user journeys for each h-org's existing process to find where they overlapped and where they genuinely diverged, and producing a glossary index so that post-unification, everyone was speaking the same language. A small deliverable, but a necessary foundation for a tool meant to unify people who didn't yet agree on basic terms.

1.1TIDEx — the Discover / Incubate / Accelerate process overview

1.2The Discover phase, expanded — decision logic underneath just steps 1–3

That gap between the two diagrams is the point: TIDEx reads as 11 clean steps at a glance, but each one unpacks into a decision tree of roles, branch points, and hand-offs once you're actually inside it. Designing a tool on top of that meant holding both views at once — the simple mental model leadership and new users needed, and the real operational complexity underneath it that the tool couldn't afford to lose.

What that looked like in practice: Key Decision Points (KDPs), the gated checkpoints built directly from the TIDEx model, where a project's core team and endorsers review and sign off before a project can move forward — shown further down, inside the Discover phase.

Gates: letting one process serve three different realities.

Requirements gathering here was collaborative by necessity — product owners, SMEs, and I worked through what an "ironclad" process needed to cover so that no h-org's edge cases fell through. One clear example: early in the process, we found that Upstream (h-UPS) had an entire workflow step at the start of their process that simply didn't exist for the other two h-orgs. Rather than force every user through it or maintain a separate process branch per org, I designed a "Gate" — a decision point that asked whether the user wanted to pursue that workflow, and if not, let them bypass it entirely and drop cleanly into the next relevant part of the TIDEx tree. That pattern — a Gate as an opt-in/opt-out branch point — ended up recurring throughout the model anywhere a workflow was relevant to some h-orgs but not others, letting one shared process actually serve three different organizational realities without forcing false uniformity.

Working around a blocked design-review process.

When product managers pushed back on structured design reviews out of concern for the timeline, I didn't let that eliminate feedback entirely — I folded it into the research we were already doing, gathering reactions to the h-tools and TIDEx process directly within the same user interviews, and applying what we learned to the Streams design. It's a good example of protecting the quality of the work without fighting the organization on its own terms.

Designing for a scale that didn't exist yet.

Leadership was clear that if Harmonization and the Streams rollout succeeded, more organizations would likely be brought under the same umbrella later. I built a tiered information architecture specifically so the tool could absorb new organizations and features without a rebuild, and included placeholder structures for more advanced customization and user profiles as the user base grew — balancing the needs of the current, smaller user base against a known future one, rather than over-building for a scale that didn't exist yet.

Craft highlights

Built to lower the adoption risk everyone warned about.

Given the EM UX team's explicit warning about tools that failed to gain adoption, I made a deliberate effort to keep TIDEx and Streams tightly connected — designing the tool's structure to mirror the process model closely, so the learning curve stayed as low as possible and the tool felt like a natural extension of the process rather than another disconnected system to learn.

1.3Project summary, stage toggle, and KDP A — shown in the Discover phase (scroll to explore the full page)

With three orgs' worth of projects, documents, and people now living in one place, finding anything specific couldn't rely on users already knowing where to look. Search spans projects, documents, programs, and roles at once, with columns that sort and filter independently — built for a user base that, after unification, could no longer assume everything relevant sat inside their own h-org.

1.4Unified search across projects, documents, programs, and roles

As part of final deliverables, I recommended ExxonMobil send out satisfaction surveys to users post-launch — a lightweight way to keep tracking adoption and sentiment after the project team moved on, and to surface concrete signal on what to improve or build next, rather than treating launch as the end of the feedback process.

Outcome

Still in use, years later — by more than the three orgs it started with.

ExxonMobil declined to share internal adoption metrics when I followed up after the engagement — understandably; they're protective of internal data as a matter of course. But I was able to get qualitative confirmation directly from people at the company, and it's meaningful given the context: this was the 5th attempt at solving this problem, and prior tools had a track record of failing to gain adoption.

A few things about that feedback are worth pulling out. It directly reflects the adoption risk the project was designed around — given that previous tools "collecting dust" was the explicit failure pattern we were warned about, sustained, positive-sentiment usage is a meaningful outcome, not a routine one. Two additional organizations have adopted the process and tool since I left the project, a direct validation of the tiered, scalable information architecture built specifically to accommodate exactly this kind of future expansion. And the sentiment data itself likely reflects the satisfaction-survey recommendation taking hold — the ongoing feedback loop I recommended as a final deliverable appears to be the mechanism producing this kind of insight today.

Delivered as a complete, functional MVP despite a compressed design timeline, covering all major patterns, unique workflows, and components engineering needed to build.

Retrospective

A safety net that, so far, hasn't been needed.

Late in the engagement, ExxonMobil's internal Lead Experience Designer asked me to put together a retrospective specifically documenting the recommendations I'd made that targeted user adoption but weren't ultimately acted on by stakeholders — the reasoning behind each one, and its likely impact if the risk it addressed ever materialized. The intent was straightforward risk management: given the project's adoption-focused stakes and the company's track record with prior tools, he wanted a clear record of what had been flagged, by whom, and why, in case adoption ever did fail and those decisions needed revisiting.

1.5The Streams Retrospective Report

Given that Streams is still in active use years later, with positive sentiment and two additional organizations having since adopted it, that retrospective has, as far as I know, never had to be pulled off the shelf. It's worth including here anyway — not as evidence of anything going wrong, but as a real example of designing, and documenting, with accountability in mind, even under pressure to move fast. It's a good marker of taking the stakes of an adoption-critical project seriously, independent of how things ultimately turned out.