Ask HN: How Do I Successfully Manage Academics on My Software Team?
6 comments
> to do R&D themselves that the software team can then refactor and ship to production
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).
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).
I have a background in research and academia.
> 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.
> 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.
> Research is done, paper is published, engineers take the paper and implement. Standard operating procedure.
Sounds awful (from a developer perspective). If engineers are not getting involved until research is done and paper is published, you run the risk of writing a useless paper (useless from the perspective of the engineers who have to implement it; obviously, from the perspective of the researchers, it’s not useless at all, as in they got to publish yet another paper).
Sounds awful (from a developer perspective). If engineers are not getting involved until research is done and paper is published, you run the risk of writing a useless paper (useless from the perspective of the engineers who have to implement it; obviously, from the perspective of the researchers, it’s not useless at all, as in they got to publish yet another paper).
I work with academic teams all the time. I think it is unfair to say they work less. Some academics work many more hours than the software engineers I manage.
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 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"
How do I set timelines when it's hard to understand the work? For example, taking someone with a phd and a ton of specific experience on a technical topic that's out of the realm of understanding of most people on earth: how does one set timelines?
But, noted on saying they work less. I guess I just mean the ones I've worked with. Impressive cutting edge output, but slower pace. Should they integrate with software best practices or just be their own thing throwing successful R&D over the wall?
But, noted on saying they work less. I guess I just mean the ones I've worked with. Impressive cutting edge output, but slower pace. Should they integrate with software best practices or just be their own thing throwing successful R&D over the wall?
However you organize your team, it's important to have goal alignment. Some academics work for the sole purpose of research, learning, or expanding the world of knowledge. It's important for them to understand, up front when they are hired, that the business needs to create products that you can sell.
In my experience, people from academic institutions work on a different schedule, typically fewer hours, with different motivations. They will want to work with tools like Matlab or Python, when we typically work with languages like Rust. They also don't seem to have a big sense of the urgency needed at my small company.
It doesn't seem like they should be treated as a separate team because too much will get lost in translation or we won't be able to move too quickly.
Does anyone have any tips or reading materials for integrating in these types of situations? This is different than engineering management per se, because it deals with a specific problem.