Notes from New York: Sixteen Learnings from Our First User Conference

Vijay Swaminathan
3
min read
February 23, 2026

We held our first user conference in New York City, and about sixty people from our East Coast user community attended. The user community represented industry diversity across technology, insurance, healthcare, biopharma, fintech, banks and financial institutions, telecom, petrochemicals, and retail. We packed a lot of sessions, presentations, and panels into the day, but the intent was different from a typical conference. We wanted a learning day. The attendees told us the discussions were useful and practical, which is the only review of a day like that worth having.

We have also released an innovative Site Selection feature in the platform. It is available in your platform now if you want to test it.

What follows are my key learnings from the day, set out across four themes: work redesign, talent acquisition, strategic workforce planning, and reskilling and development. Four learnings each, with my own reading of why each one matters.

Work redesign: the leverage sits below the role

AI value shows up only when work is decomposed into tasks and reassembled intentionally into workflows. The real leverage is at the task and workflow levels. That is a simple statement with an uncomfortable implication: an organisation that has not done the decomposition work has no reliable way to know where its AI value would come from, and is effectively buying capability against a guess.

Administrative friction is the fastest place to start. Removing burden, especially in complex environments like healthcare, unlocks capacity without compromising core judgment work. There is a sequencing argument buried in that. Administrative work is where the risk of getting it wrong is lowest and the evidence of getting it right arrives soonest, which makes it the natural place to build both technical validation and organisational confidence before anything consequential is touched.

Redesign must focus on enterprise flow, not individual productivity. Isolated automation does little unless workflows across teams are stitched together. This is the failure mode that produces good slides and no result: a person is made faster inside a handoff chain that is still broken, the local metric improves, and the end-to-end time does not move at all.

Governance is not optional. In high-stakes work, “just because we can automate” is not the right lens — human oversight and guardrails define responsible redesign. I would add that governance decided at the design stage and governance retrofitted afterwards are not the same thing wearing different labels. The first constrains what gets built; the second tries to constrain something already in production, which is a considerably harder problem.

Talent acquisition: faster throughput, human decisions

AI accelerates throughput, but recruiting remains human-led. Screening and shortlisting can scale with AI. Final decisions must preserve human judgment. The distinction is worth stating precisely, because the two halves are often conflated: scaling the funnel and making the call are different activities, and the case for automating the first is not a case for automating the second.

Candidate authenticity is becoming a signal challenge. As candidates increasingly use AI tools, talent acquisition needs better validation mechanisms without over-automating. This is genuinely difficult, and I do not think anyone has solved it. The signals recruiters have relied on for years — how a written application reads, how a response is composed — are getting noisier, and the obvious fix of adding more automated screening pushes in exactly the wrong direction at the stage where reading a person matters most.

Transparency builds trust. Clear communication about where AI is used, and preserving a human final interaction, improves the candidate experience. That is a design principle rather than a values statement, and it is cheap to implement relative to almost anything else on this list.

Dual-speed talent acquisition is emerging. Some roles require tactical efficiency; others require strategic advisory work. Test-and-learn approaches are outperforming rigid models. The implication for TA leaders is structural: if two kinds of hiring need two different operating models, then a single standard process, a single service level and a single set of metrics will misserve one of them by design.

Strategic workforce planning: headcount is the wrong unit

Planning must shift from headcount to capability modeling. AI impact lies beneath the surface, at the task and skill levels, not just in job categories. A job category can look entirely stable in a headcount plan while the work inside it has been reorganised, which is precisely the condition under which a plan keeps reporting that nothing has changed.

Early signals matter. Increasing skills density, more individual contributor hiring, and slowing hiring in highly automatable areas are directional indicators. Directional is the operative word. None of these is conclusive on its own, and each has innocent explanations. Read together and over time, they are the closest thing available to an early warning that a function is drifting away from its plan.

Experimentation is part of planning. “No experiment, no readiness.” Pilot programs are the new forecasting tool. This is a real departure from how planning has traditionally worked. Historical data describes an operating model that is being replaced; a structured pilot generates evidence about the model you are moving to. Where the future is discontinuous, running the experiment is the more accurate forecast.

Long-term pipelines beat reactive hiring. University partnerships and ecosystem investments are becoming core strategic workforce planning strategies. That reclassification matters more than it sounds. It moves pipeline building out of the recruiting calendar and employer branding budget and into the planning function, where it is evaluated against a long-term capability gap rather than against the current requisition list.

Reskilling and development: skills architecture as standing infrastructure

Skills architecture is now a continuous infrastructure. It requires ongoing validation, governance, and refinement, not a one-time project. Treated as a project, it produces a model that is accurate on the day the mapping finishes and decays quietly from then on, while continuing to be used as though it were current.

Clarity on what counts as a skill is foundational. Without shared definitions, learning investments scatter. This sounds pedantic and is not. If L&D, HR and the business each hold a different working definition of a skill, none of them can tell whether they are solving the same problem, and the spend fragments across three efforts that cannot be added together.

Internal validation strengthens credibility. Surveys and real job-to-skill mapping exercises anchor models in lived work. The credibility question is the practical one: a skills model assembled entirely from external references may be perfectly defensible and still fail, because the people expected to use it do not recognise their own jobs in it.

Future readiness is a mindset shift. Critical thinking, learning agility, and the ability to review AI outputs are becoming baseline capabilities. The last of those is the newest. The ability to look at a plausible-sounding machine output and judge whether it is right is being asked of roles that were never described in those terms, and it is not a skill most learning catalogues currently contain.

What ties the sixteen together

Sixteen learnings from one day is not a research finding, and I would not present it as one. But the four themes cover quite different subject matter, and the learnings under them converge on a similar two-part answer. Go below the role — to tasks, workflows, skills and capabilities — to find where the value and the risk actually sit. Then keep a human accountable at the point where a decision is made. Work redesign called it governance. Talent acquisition called it human-led recruiting. Workforce planning called it capability modeling. Reskilling called it validation and the ability to review AI outputs. It is recognisably the same argument in four vocabularies.

If you are planning your own next step, the order these learnings suggest is reasonably clear: pick one function, decompose it into tasks, start with administrative friction, decide your governance and human accountability points before you build rather than after, and run the whole thing as an experiment with a defined read-out rather than as a rollout.

We hope to hold more user conferences across other regions, and we will keep you posted. If these themes are the ones you are stuck on, that is useful for us to know when we set the agenda.