Appearance
When staffing a digital humanities project goes wrong, the symptom is usually one of three things: a critical skill sits with a single person (bus factor of one), nobody owns the data and metadata, or the technical and domain sides cannot communicate. The fix is to map roles to the actual workflow, name an owner for every essential function, and build redundancy into the skills you cannot afford to lose. Staffing is a risk-management problem as much as a hiring one.
What roles does a DH project actually need?
Map roles to the workflow, not to job titles. Most projects need these functions covered, even if one person wears several hats:
| Function | Typical owner | What breaks without it |
|---|---|---|
| Domain expertise | Historian / archivist | Wrong questions, misread sources |
| Technical build | Developer / data engineer | No working pipeline or site |
| Data & metadata | Curator / data manager | Unusable, undocumented outputs |
| Project management | PM or PI | Drift, missed deadlines |
| Design & access | UX / web | Outputs nobody can use |
| Outreach | Engagement lead | No audience, no impact |
On a small grant the first three are non-negotiable; the rest can be part-time or shared.
Why is "one person does everything" the most fragile model?
A single person carrying domain, technical and curation work is a single point of failure. If they leave — and DH contracts are often short and fixed-term — the project can stall completely. This is the bus factor: how many people must become unavailable before the work halts. A bus factor of one is a critical, common DH risk.
The fix is not always another hire. It is documentation, code review, and design choices that a second person could pick up:
text
docs/
README.md # what this is, how to run it
WORKFLOW.md # step-by-step processing, with commands
data-dictionary.md # every field defined
contacts.md # who knows what, and how to reach themHow do I diagnose a staffing failure mid-project?
Work backwards from the symptom:
- Outputs are undocumented and inconsistent → no owner for metadata and curation. Assign one immediately.
- The developer is overloaded and behind → the technical scope outgrew the role; cut scope or add review capacity, do not just demand longer hours.
- Domain and technical staff talk past each other → missing shared vocabulary; introduce a weekly working session and a glossary.
- Progress stops when one person is on leave → bus factor of one; pair them with a backup and document the critical path.
How do I staff a project with no money for a technical hire?
This is common, and survivable. Three strategies:
- Choose minimal-computing approaches — static sites, existing platforms, plain files — so the maintenance burden is low and a non-specialist can sustain them.
- Partner with a university library, DH centre or museum that already employs the skills you lack, in exchange for co-authorship or shared outputs.
- Budget training time so a domain expert can handle routine technical tasks like running a transcription tool or editing a CSV.
Who should own the data and metadata?
A named individual, written into the role description — never "whoever has time". Unowned metadata is the single most common reason a finished project's data turns out to be unusable. The owner does not have to do all the entry, but they set the standards, run the quality checks, and sign off the final dataset.
How do I keep DH developers engaged and retained?
Short contracts and flat career ladders push developers out. You cannot fix the sector single-handed, but you can reduce churn damage: share knowledge from day one, insist on documented and reviewed code, and avoid clever architectures only one person understands. A project that survives a developer's departure is one whose technical decisions were always legible to others.
Key Takeaways
- Map roles to workflow functions; domain, technical and data ownership are non-negotiable.
- Treat staffing as risk management — watch the bus factor for every critical skill.
- Name a single owner for metadata and curation explicitly.
- Document workflows so a second person could resume the work.
- With no technical budget, prefer minimal computing, partnerships and training.
- Diagnose staffing failures from the symptom back to the missing or overloaded role.
Frequently Asked Questions
What core roles does a DH project need?
At minimum: a domain lead (historian or archivist), a technical lead (developer or data engineer), and someone owning data and metadata. On larger projects these split further into PM, designer, and outreach roles.
Can one person do everything on a small DH project?
Sometimes, but it is the riskiest model. A single person carrying domain, technical and curation work becomes a single point of failure; budget at least a few days of a second person for review and bus-factor insurance.
Why do DH projects struggle to keep developers?
Short fixed-term contracts and a lack of career progression. Mitigate by sharing knowledge early, documenting code, and avoiding designs that only one person can maintain.
What is the bus factor and why does it matter?
The bus factor is the number of people who would have to be unavailable before the project stalls. A bus factor of one — common in DH — is a critical risk; aim for at least two for every essential skill.
How do I staff a project with no technical hire budget?
Lean on minimal-computing approaches and existing platforms rather than custom builds, partner with a library or DH centre, and budget training time so a domain expert can handle routine technical tasks.
Who should own metadata and curation?
A named person, not "whoever has time". Unowned metadata is the commonest cause of unusable project data; assign it explicitly even if it is only part of one role.