Johns Hopkins is staffing a 24-FTE success coaching program as data-driven advising shifts from pilot to operating model

Johns Hopkins University is hiring a Senior Director for Success Coaching and Academic Advising to run a program with 24 full-time employees and a possible expansion to 27, according to a July 27, 2026 posting on The Chronicle of Higher Education Jobs. That’s a staffing signal, not an HR curiosity. It suggests student retention has moved into “operating model” territory, with org charts, outcomes reporting, and cross-campus workflows that look more like a service line than a series of advising appointments.

The same week, Ellucian published a post arguing that advising is becoming a data-and-automation problem as much as a counseling one, with institutions unifying student data, automating follow-ups, and using early indicators to reach students sooner (Aug. 19, 2026). Read together, the two sources point to a practical implication for higher ed operators: retention programs are now being built around integrated data flows and a capacity plan for advisors, not only around new student-facing initiatives.

A job posting that reads like an operating blueprint

Johns Hopkins’ posting outlines a Success Coaching Program created in 2019 to support first-generation and/or limited-income students, a population the posting says now represents about one-third of Johns Hopkins undergraduates. The Senior Director role is responsible for leadership, vision, and strategic direction, as well as meeting and reporting the program’s goals and outcomes, according to the Chronicle listing.

The operational detail is unusually concrete for a public job ad. The role directly supervises up to six staff members and oversees a total staff of 24, supported by a senior administrative coordinator, the posting says. It also notes the unit could add roles under a “new framework,” taking the total to 27 FTEs.

That matters because it telegraphs where budget, governance, and systems work are likely to land. A 24-person coaching and advising organization embedded across multiple locations with “dual accountability,” as the posting describes, generally can’t run on ad hoc spreadsheets and inbox triage. It needs consistent case management, shared definitions of risk, and a way to coordinate with schools and departments without duplicating outreach or losing handoffs.

Ellucian’s playbook: unify data, then automate the work

Ellucian’s Aug. 19, 2026 post frames the problem in blunt terms: many advising strategies are still built on periodic check-ins or reactive outreach, while “today’s learners” need support that adapts across the journey. Ellucian also cites a common completion challenge, noting nearly half of four-year students don’t graduate on time.

Ellucian’s recommended operating model is rooted in connected data. The company argues advisors need a unified view that brings together signals from systems such as learning management platforms, financial aid, and engagement indicators, so teams can monitor performance in near real time, surface early risk indicators, and prioritize outreach. The post also stresses automation for appointment scheduling, reminders, triggered communications, and case management follow-ups.

For enterprise IT and student affairs operations leaders, the sequencing is important. Analytics alone doesn’t fix throughput. The post’s implicit constraint is advisor capacity: if staff are spending hours per week on manual administrative tasks, then the first measurable win from “data-driven advising” is usually time recovered through workflow design and automation, not a new dashboard.

Where the operational work shows up: integration, governance, and caseload design

Johns Hopkins’ posting emphasizes outcomes reporting and alignment to a Student Success Strategic Plan focused on timely graduation and integrated services. Ellucian emphasizes early identification and coordinated interventions that include non-academic signals. Put those together and the “hard part” for many institutions becomes data governance: who owns the definition of an at-risk flag, what triggers an outreach sequence, and how exceptions get handled when a student’s situation doesn’t fit the model.

This becomes especially relevant for campuses with fragmented tooling, for example where the SIS, LMS, and financial aid systems are owned by different teams and engagement data lives in separate student success, CRM, or event platforms. Ellucian’s premise depends on unifying those feeds into a usable, trusted profile that advisors can act on without hunting for context. The Johns Hopkins org design implies that the advising function will be held accountable for results, which raises the stakes on data quality and timeliness.

There’s also a procurement nuance. As institutions formalize coaching teams and embed them across multiple locations, platform selection often shifts away from “features” and toward operating requirements: role-based access, case routing, audit trails, student privacy controls, and the ability to coordinate across advising, faculty alerts, and support services without parallel records. Ellucian’s post highlights case management and triggered communications, which are exactly the functions that determine whether a multi-team model behaves like one program or a set of loosely coupled offices.

Questions to put in the next advising and student success platform RFP

• Can the advising platform create and govern early-alert triggers that pull from the LMS, financial aid status, and engagement signals, and can teams explain those triggers well enough that advisors trust them (Ellucian’s connected-data premise depends on this)?
• What is the end-to-end workflow for a student “case,” including handoffs across departments and dual-accountability teams, and what gets logged automatically for outcomes reporting (a need implied by Johns Hopkins’ goal-and-outcomes reporting responsibilities)?
• How will automation change advisor capacity in measurable terms, for example time spent on scheduling, reminders, and follow-ups, and what baseline will be used to prove it (Ellucian’s automation emphasis turns this into an operational metric)?
• If the retention org grows from 24 to 27 FTEs as Johns Hopkins anticipates, what happens to licensing, role configuration, queue design, and caseload balancing, and can those changes be made without a services project?