Ask HN: How Do I Successfully Manage Academics on My Software Team?

What they do have is different priorities. Your company is product focused while the academic might have courses to teach, grade, and prep. They have students to advise, researchers teams to manage, papers to write guest lectures to present, tenure cases to review, 3rd party research to vet, service commitments to their institutions...

The list goes on and on. Most productive academics are essentially CEOs of their own mini startups.

So, with any team member or external partner, you need to set clear expectations and timelines. Otherwise your ask will fall someplace on their timeline that likely "six weeks from now after the term ends and grading is done"

What academics produce is most likely proof of concept or a prototype, not something you can "refactor" and ship. It's not a matter of tooling and programming languages, but of what is actually produced. Software engineers produce software that meets all sorts of non-functional requirements, experts care about functional side only. So get all sides to agree on what will be produced and then ask developers about how they will proceed with putting that in production. It may require redoing most or even everything.

> They also don't seem to have a big sense of the urgency needed at my small company.

You don't do creative work to a schedule, especially urgent one. The only thing you can predict reliably are the ones you have already did (and only if the circumstances don't change). People promised self-driving cars long time ago, and we still don't have them, regardless of any company sense of urgency. You deal with that issue by discussing stages and scope of delivery with all sides, not by expecting their understanding of urgency.

> It doesn't seem like they should be treated as a separate team because too much will get lost in translation

That's true, getting managers to act as translators between experts and technicians is a really bad idea.

> How do I set timelines when it's hard to understand the work?

You ask them to set them for themselves. You don't need to understand the details, you need to understand what will be produced and how all involved sides will use it and that they all agree here.

> Should they integrate with software best practices or just be their own thing throwing successful R&D over the wall?

That depends, but most likely you will have more success passing what they do to your developers (who are great at being software developers) than by teaching software development to someone who doesn't understand it. Some training may be beneficial though (so that their work can be used by developers).

> They will want to work with tools like Matlab or Python, when we typically work with languages like Rust.

I don't see them problem with this. Research is done, paper is published, engineers take the paper and implement. Standard operating procedure.

I will also note that there are A LOT of academics interested in compute that would love to work in languages that are more strongly typed than python. That said, they'd probably still mock things statistical things in python or R 'cause libraries.

> They also don't seem to have a big sense of the urgency needed at my small company.

If you can tie the work to prestige you can change that. For example, if there is a timeline for a paper to be published. I've seen a lot of research set to a cadence successfully. At times it felt like a product launch, 11th hour shenanigans included.