01
Time criticality
Transition could only fire after the manager officially notified the employee. HR controlled the timing via Notification dates — not a minute earlier.
Randstad RiseSmart · Senior PM · 2023–2025
Building a Global Identity Platform for the Hardest Moment of Someone's Career
TL;DR
I led product for the global Identity & Access Management (IAM) platform powering Randstad RiseSmart's career coaching across 110+ countries. The hardest part wasn't the tech — it was designing a system that handled the exact moment an employee is laid off, without telling them through a login screen, without breaking compliance, and without making enterprise IT teams wait weeks for SSO setup.
10x faster
customer go-live
~90% reduction in time-to-value
<1%
support tickets
post-launch, across the global SSO migration
30%+
engagement lift
via A/B experiments & behavioral analytics
110+
countries
with full regional compliance
01
The Business Context
Randstad RiseSmart sells career coaching to Fortune 500 employers. It comes in three flavors — and they're more different than they look.
| Coaching type | Who it's for | What's tricky |
|---|---|---|
| Worklife | Current employees | Standard SSO. Easy. |
| Redeployment | Employees on notice — find a new internal role or leave | Standard SSO, but a ticking clock. |
| Outplacement | Employees who've been let go | Their corporate SSO no longer works. But they still need access. |
Enterprise customers buy these as a package and offer them to employees. From an identity perspective, that third bucket is where things get hard.
02
Two Problems Sitting on Top of Each Other
Problem 1
SSO setup was a slow, painful, manual ritual
Every new enterprise customer needed SSO. The flow looked like this:
- 1Customer emails metadata files to our engineering team
- 2Engineering manually configures SSO in test
- 3Customer tests, finds issues
- 4Email back-and-forth troubleshooting
- 5Repeat the entire dance for production
Result: weeks per customer. Engineering hated it. Sales pipeline bottlenecked.
Problem 2 — The hard one
The "moment of layoff" identity transition
When an employee is laid off, their corporate email stops working — but they still need access to outplacement coaching. So at the exact moment of layoff, the system had to:
- Detect the official layoff event from the customer's HR system
- Switch the user's login from corporate SSO to personal email
- Never flip that switch a minute early — you cannot legally or ethically let someone find out they're laid off because their login changed
- Place them in the correct coaching package (different tiers get different coaching)
- Stay GDPR compliant
- Respect regional data residency rules
An orchestration problem, a compliance problem, and a human dignity problem — all at once.
03
The Constraints That Shaped Everything
Before writing a line of spec, I made the constraints explicit. Once named, the right architecture became obvious.
02
PII sensitivity
Layoff info is the most sensitive data anyone has at work. A leak means lawsuits, broken trust, broken people.
03
GDPR + data residency
User data couldn't leave certain regions. Multi-country, sovereign cloud constraints shaped every data flow.
04
Enterprise-grade trust
Fortune 500 customers expected zero downtime and zero tolerance for errors.
05
Self-service and security
Customers wanted speed, but compromising on security wasn't on the table.
04
My Approach
I broke the work into two product bets.
1
A self-serve SSO configuration portal
Instead of email + manual config, I built a portal where customer IT admins could configure SSO themselves end-to-end.
Guided wizard, not raw config.
Most enterprise IT admins aren't identity specialists. The wizard walked them through metadata upload, attribute mapping, and test login — without ever exposing them to an XML file they didn't want to look at.
Sandbox-to-production parity.
A huge chunk of the old back-and-forth was "it worked in test but broke in prod." I designed the test environment to be a true mirror, with a one-click promote flow.
Action-tied error messages.
Generic "configuration failed" was banned. Every error had to say what went wrong and what to do about it. This single decision killed most support tickets.
Tradeoff I made: Self-serve as the default, with a white-glove option for top-tier accounts. Sales pushed back — they wanted to be involved in every setup. Customer data won the argument: customers preferred speed.
2
SCIM automation + the Registration Engine
Most user lifecycle activity could be automated. I built that on SCIM — the industry standard for syncing user accounts between identity systems:
- Customer's identity provider (Okta, Azure AD, Workday) syncs with RiseSmart automatically
- New employees → auto-provisioned into the right coaching package based on tier
- Role, department, or manager changes → auto-synced
- Normal departures (resignations, transfers) → auto-deprovisioned
This handled ~95% of user activity with zero manual work — and made the platform scale across 110+ countries without drowning operations in CSV uploads.
But the layoff transition couldn't go through SCIM.
Wrong timing. A SCIM deprovision event might fire hours — or a full day — after HR had actually notified the employee.
Wrong action. We didn't want to deactivate the user. We wanted to keep their access and switch their login method. SCIM doesn't have a graceful primitive for that.
Wrong sensitivity. If it ever fired wrong, it would end up in a news article. Some triggers belong in human hands.
The Registration Engine
A deliberate manual override — designed for the highest-stakes flow in the system:
- 1Customer's HR team sent impacted employees and their official Notification dates to our account manager
- 2The Registration Engine ingested this list and held each user's transition until their Notification date passed
- 3At that moment, it switched authentication from corporate SSO to personal email and routed them into Outplacement coaching
- 4Every step was logged for compliance audits — who, when, by what trigger
Tradeoff I made: Rules-based engine over a flexible workflow tool. Rules were faster to build and easier for ops to reason about. They limited some edge cases but handled 95% of scenarios and shipped on time. For the remaining 5%, we built escape hatches.
05
Cross-Functional Leadership
The PM job here was less "write specs" and more "keep 5 functions aligned on the same definition of done, every week, for 18 months."
Security
Compliance review on every identity transition flow
Infrastructure
Sovereign cloud and data residency setup
Regional teams
Country-specific compliance nuances
Customer Success
Rollout and customer migration sequencing
Sales
Managing expectations around self-serve vs. white-glove
Engineering
Multiple pods — identity, integrations, platform
06
What I Took Away
The hardest PM problems are orchestration problems.
The Registration Engine wasn't a beautiful interface. It was a disciplined choreography between five different systems. That's where the value was.
Knowing when not to automate is a Staff-level skill.
SCIM handled 95% of the lifecycle. But the layoff transition stayed manual on purpose — because the cost of a wrong automated trigger was a person finding out the worst news of their year through a glitch.
'Boring' infrastructure compounds.
Identity, onboarding, provisioning — none of it is glamorous. But when you do it well, every other product team gets to move faster on top of it.
Constraints aren't obstacles — they're the design.
Once I named the time-criticality + PII + GDPR + enterprise-trust constraints, the architecture wrote itself. Most of the PM work was in seeing the constraints clearly.
Want to talk about identity, IAM, or building products in regulated environments? Let's talk.
© 2026 Garima Kalra