How Researchers Can Find IT Engineers: Seven Routes to Collaboration

How Researchers Can Find IT Engineers

Researchers often begin by asking where they can recruit an engineer. A better first step is to make the research understandable outside the laboratory and create several low-risk opportunities to meet.

These routes draw on seven years and 165 Miyako de IT events.

Prepare a one-page research summary

Before approaching anyone, explain:

• the problem and who experiences it;
• what has already been validated;
• what software, data, or infrastructure may be needed;
• the expected first deliverable;
• the available time, budget, and decision maker.

Avoid treating “build an app” as a complete specification.

Seven routes

1. Attend a recurring local IT community

Repeated attendance creates context and trust. A regular event is more useful than collecting contacts at one large conference.

2. Join academic and regional-industry events

Events connecting universities, local companies, and public institutions can reveal engineers already interested in applied research.

3. Ask a university liaison office or URA

Industry liaison staff and university research administrators may know companies, alumni, and support programs suited to the project.

4. Give a short community talk

Present the problem, not only the paper. A ten-minute explanation of the research question and desired collaboration can attract the right specialist.

5. Share adjacent material online

Publish a non-confidential notebook, dataset description, technical note, or GitHub repository. Engineers need enough evidence to judge whether their skills fit.

6. Use a hackathon or ideathon

A time-limited event can test communication and produce an early prototype, provided participants understand what happens to intellectual property and results.

7. Consult a community operator directly

An operator can recommend the right event, review the explanation, or introduce a relevant member. Do not ask for a mass broadcast before clarifying the project.

Three principles after meeting

Start with a small proof of concept

Define a narrow technical question and a result that can be evaluated in weeks, not an entire product roadmap.

Make compensation and benefit explicit

State whether the work is paid, voluntary, academic credit, co-authorship, data access, or another exchange. Ambiguity damages trust.

Share a recurring place

Continue meeting through a community or scheduled working session. Collaboration improves when communication does not depend on formal milestones alone.

Checklist before work begins

• Is the research question understandable to a non-specialist?
• Are confidential information and publication constraints clear?
• Is there a named decision maker?
• Are scope, schedule, compensation, and ownership documented?
• Can the first proof of concept be evaluated objectively?

Conclusion

The fastest credible first action is often to attend one recurring community event with a clear one-page summary. Relationships formed before a procurement or grant deadline are more resilient than emergency recruitment.

See Miyako de IT's community overview and regional community strategy.