Development conversations without the guesswork

When I moved into a leadership role, I noticed the same pattern I'd seen everywhere: development conversations were real, but the infrastructure supporting them wasn't. Goals were set in Workday at the start of the year, maybe revisited at mid-year check-in, and then reconstructed from memory at the end. No running record. No signal between reviews. No way for a researcher to walk into a performance conversation with documented evidence of what they'd done and why it mattered.

The cost isn't dramatic — it shows up as vague feedback, end-of-year surprises, and a system that rewards whoever can articulate their work best rather than whoever did the best work. I wanted something different: a system that built the record continuously so that check-in conversations could be about growth, not documentation.

Development conversations only work if everyone agrees what they're developing toward. I built the UXR Competencies Framework for 2026 — a structured document defining the skills, behaviors, and expectations at each level of the research career path, grounded in the Korn Ferry competency framework we use organization-wide.

The framework isn't aspirational language. It's the concrete reference that makes feedback specific. Instead of "you should be more strategic," the conversation becomes "here's what strategic looks like at your level, here's where I see you, here's what the gap is." That's a different quality of conversation — and it scales, because every researcher on the team is working from the same map.

Artifact — UXR competency framework

Having goals written down is not the same as having visibility into them. I built individual OKR health dashboards — one per direct report — that show goal status at a glance: which objectives are on track, which are partial, which need attention, and which are blocked or on hold. The dashboard pulls from documented work rather than asking the researcher to self-report from memory every two weeks.

The format matters. A status badge of "Partial" next to a goal is a different kind of prompt than a manager asking "how's that goal going?" It surfaces the conversation without making it feel like surveillance. And because the status is tied to actual work output, the researcher can walk into any check-in with the same view their manager has.

The most time-consuming part of development tracking has always been the update itself — pulling together what you've done, framing it against your goals, deciding what matters. I co-designed a system with one of my researchers that does this automatically using Claude, Jira, and Confluence.

Every two weeks, on the 1st and 15th, the system runs: Claude searches Jira tickets and Confluence pages for recent activity, maps what it finds against each goal, flags what's progressing and what needs attention, writes a structured update with "so what" impact statements on major wins, and creates a Jira ticket with the full output — automatically. The whole thing runs on a schedule in Cowork without anyone having to trigger it.

What makes it useful rather than just technically interesting is the design of the output. The system doesn't just list activity — it identifies goals with no visible Jira signal and flags them as needing self-report. It writes actionable suggestions for the next two weeks, not just a summary of the last two. And it outputs in a format the researcher can use directly for their Workday performance review, reducing end-of-year reconstruction to a copy-paste.

That side effect — better Jira hygiene as a natural consequence of using the system — is the kind of infrastructure benefit that doesn't show up in the spec but shows up in the culture. The system rewards documentation without having to mandate it.

Co-designing this with my researcher — not just handing down a process — meant the prompts, the format, and the output structure reflect how the researcher actually wants to think about their work. It's their system as much as mine. That matters for adoption.

Every direct report now has a Confluence changelog accumulating dated entries under each OKR across the full year. When mid-year or end-of-year check-ins arrive, the record is already there — specific, timestamped, framed in impact language. The researcher doesn't reconstruct. They curate and learn to tie everything to business impact and outcomes, and encourages ongoing measurement of experiences.

From the changelog, Claude can draft a Workday-ready summary in two to three sentences, past tense, leading with impact.

The OKR health dashboard gives me, as a manager, a weekly pulse on where each person stands without requiring a check-in. If someone's goal is showing "Partial" for a second cycle, I have something concrete to bring into our next 1:1 — not a vague sense that something might be stuck.

And the competency framework grounds all of it. When I write developmental feedback, I'm writing against a shared definition. When a researcher sees feedback, they can locate it on the map. The development conversation becomes navigable instead of impressionistic.

Building the infrastructure was the straightforward part. The harder thing was making sure it felt like a tool for the researcher, not a surveillance mechanism for me. The difference is in the design: the researcher owns their Claude Project, the researcher controls their Confluence changelog, the scheduled task runs under their credentials.

The behavioral goals problem is real and intentional. Goals like "practice directness in difficult conversations" or "build visibility with senior stakeholders" don't generate Jira tickets. The system flags them as needing self-report and doesn't try to fill the gap with noise.

What's changed is the quality of the development conversation itself. We spend less time establishing what happened and more time deciding what it means, and making sure the business pays attention to our work.