This blog post is the fifth in a five part series on the "Four Pillars". If you'd like to start from the beginning, you can find the first post here.
In many ways, it's fair to say that Bitlink started in a university. When we first got going, everyone on the core team was either studying at the University of Tasmania, or working there. For us, university wasn't just about learning a bunch of skills that might make us employable in the future, it was about exploring ideas, engaging with deep questions and trying to add to the sum of human knowledge in whatever small way we could.
We've left university now, but we didn't leave our love of knowledge and of research behind. In many ways, Bitlink is an attempt to do the same sorts of things we were doing in university, but to do it in a way that the outcomes of our work aren't just research papers or proof-of-concept demonstrations, but real products that people use in their everyday lives.
And so, research is one of our Four Pillars. However, there are a few different ways in which we use the term and a few different ways in which projects can qualify as including a research component.
The central thing that we look for when we're determining whether a project has a research component, is whether the project has some potential to help us learn something that we don't already know and that we can't easily learn by picking up a book or doing a quick internet search. There are generally three different kinds of ways that projects satisfy our requirement for all projects to have a research component.
Led By Researchers
The first way that projects can satisfy our research criterion is the simplest; if the project has been proposed to us by a researcher who wants us to help them develop some sort of tool to further their research, then chances are that project is going to have a research outcome. Given our focus on projects that have a both a social good and a research outcome, we work frequently with university researchers, staff at research institutes and other researchers who need our help. As long as the project also aligns with our other pillars, then we very rarely say no to these sorts of opportunities.
Supported By Researchers
In other cases, we have a project that we've developed ourselves, or something that we're working on with a collaborator who doesn't have any research connections, but the project itself appears to have some research value. In those cases, we'll often try to find a university researcher with a related interest, or will work to deliver some research outcomes ourselves by adding extra research tools to the products we build. This process is most common for projects that we are developing internally, where we'll generally aim to create an advisory panel of researchers and subject domain experts, both to ensure that we have the best possible advice available to us and also to try and provide avenues for academic research that focuses on the products we're building.
Of all of the four pillars, the research component is the one that we're most likely to let slip. However we do have a little loophole that we like to use to make ourselves feel better about it when it happens. If a project doesn't have any likely formal research outcomes, but to deliver the project we need to engage with existing research ourselves, or develop a deep understanding of a new knowledge domain, then we tend to assess that project as having a research outcome of some kind. It's relatively uncommon for major projects to come our way that don't have some kind of potential research outcome, but for those where achieving research outcomes is prohibitively difficult within the scope – if we're likely to learn something valuable ourselves in the process, then that usually does the trick.
Of all of the Four Pillars, the research component is the place where we're most likely to bend the rules just a little bit. Nonetheless, we've found that having a clear understanding of what makes us tick and what sorts of projects we really want to work on has been a really valuable tool for the business as a whole. When a project comes our way that just doesn't fit, it's easy for us to determine that quickly and also to communicate why we've chosen to decline a particular opportunity.
We hope you've enjoyed reading about how we use the Four Pillars at Bitlink to determine what projects we'll focus on and ensure that we're always working on projects that are meaningful to us and beneficial to the broader community.
If you have any questions about the Four Pillars, or if you think you might have a project that we'd be interested in, then please feel free to get in touch with us via our contact page.
This blog post is the fifth in a five-part series on the "Four Pillars" that the Bitlink team use to determine which development projects to focus on at any given time. Projects that align with the four pillars are actively pursued, projects that don't fit the mould are declined or referred on.
If you'd like to read more, you can find the other posts in the series here: