Mike Murray is the founder and CEO of Scope Security, which provides technology security solutions tailored to the healthcare industry. We asked him what it’s like working with Commit.
Tell us a bit about Scope. What do you do?
Scope is a detection and response solution for healthcare delivery organizations. We help hospitals prevent security breaches. If you’ve watched the news about cybersecurity in the last 12 months, you know that hospitals are one of the most vulnerable technology environments, and they’re also one of the most sensitive.
The truth about the cybersecurity industry is that for the last 25 years, the industry has largely developed products for government and financial services because that’s where the money has been. There’s almost nothing that looks less like a bank than a hospital. The technology environment consists of medical devices and EHR [electronic health record] systems and care-workflow technology. So we started Scope with the idea that we would solve the specific problems hospitals have, not the problems of banks.
Screenshot of Scope Security Trickbot
How did you come to connect with Commit?
We officially founded Scope Security in May, 2019, but we didn’t start hiring people until late summer. I started talking with Commit in October of that year. I loved the model. I’m a bit of a Commit evangelist at this point, because I think what you’ve done is amazing.
When you’re founding a company there’s always stuff you do well and stuff you don’t do well. If I look at the founding team of Scope, most of us are security experts who have spent most of our time on the back-end of systems. When it comes building a UI, or doing things like GraphQL APIs or even building our CI/CD pipeline, we don’t have those skills on the founding team. So there’s a bit of a bootstrapping problem: How do I hire front-end engineers when I don’t have much experience with what makes a great front-end engineer? Commit has helped us de-risk that.
What role or roles were you hoping to fill when you came to Commit?
The first thing was the front-end piece: We hired a contracting firm to do the React design and front-end code, but needed help connecting that to the back-end through a GraphQL API and a Mongo database. The second conversation we had with Commit was around the need for build pipelines, especially as we get more complicated in terms of the number of customer environments.
We have a very structured environment, because of the security needs, sensitivity of the data we’re working with, and all of the compliance challenges around HIPAA and HITRUST. So build pipelines and ease of deployment are really important for us—places where we could implement security scanning.
We brought on Jason DaSilva to do the front-end work and he’s absolutely amazing. He’s got dev skills and architecture chops, which is really wonderful. We brought on Shane Gearon to build out all our build pipelines. Very quickly under Shane’s guidance we decided to move from GitHub to GitLab. Jason became a full-timer, because we need that in perpetuity. Shane’s engagement lasted two or three months, and it was exactly what we needed to get everything up and running. If we had done it internally, I’m sure it would have taken six months and would’ve taken one of us away from our core strengths to figure out how to do it.
In your experience, what are the consequences of hiring people who ultimately are not the right fit? What impact can that have on a team?
It’s old and trite to say that culture eats strategy for breakfast, but it’s true. When you’re hiring outside your sweet spot, culture fit becomes hard. I use front-end designers as my favourite example. When you take security people and pair them with front-end people, sometimes that culture fit can be a challenge. They’re often very different personality profiles, with different ways of working and work styles.
So having the ability to bring somebody in and evaluate the fit while you’re working with them is very valuable. I’m not going to say there’s no risk—there’s always risks involved in bringing somebody into a team, that they may not fit. But working with Commit, I can evaluate the situation—I can say, this isn’t working, can we do something else? That flexibility removes a lot of the risk.
It’s a lot better than hiring someone full-time and getting them on benefits and all your systems, and then all of a sudden you realize it isn’t working out.
One of the interesting things about Commit is the community that’s being built, where Engineers have access to each other for technical support and even social support, related to the remote-first environment. What do you think is the value of the community around Commit?
My exposure to the community has been through the people that we’ve hired, so it’s not like I’ve seen the back-end, but what I can say is that those folks always seem to be able to get their questions answered really effectively.
I think the interesting thing about the Commit community and all the open-source work you’re doing is that it’s at its nascence, and the bigger you get the more value it has. Even in its early stages I’m sure it’s providing value, and the bigger it gets the better it gets.
If you weren’t working with Commit, what would the hiring process look like for Scope?
I honestly don’t know, because I never considered not working with Commit once I connected with you. As soon as I did, I realized I don’t have to solve this problem anymore.
In the past, I’ve gone to my network and asked around to try to find the right person, hoping to get lucky. Ross Perot once said, “Eagles don’t flock together, you have to find them one at a time.” It’s really hit and miss. Sometimes you find a great person and sometimes you find someone and they turn out not to be the right fit. Commit’s model was so obvious that I have never even considered not doing it.