Nathan Milford, Director of Infrastructure, Shutterstock
While hot technologies emerge at the speed of light in the universe of IT, the questions we debate tend to remain static. One such long-running conversation: Whether a company’s technology needs will be better-served by relying heavily on “commercial off-the-shelf” software solutions or will business enterprises see a better return on investment and less “it’s 3 a.m. and we can’t fix this” grief by customizing software and systems in-house?
At Shutterstock, as with many companies of size, the answer to the “build it or buy it?” question has grown more complicated in proportion to the sheer volume of data we need to manage. The solutions we generate absolutely must be scalable and nimble – able to grow and change directions in real time, in ways that almost certainly can’t be foreseen five years out as technology and business needs rapidly evolve. At the same time, with 33 engineering teams spread worldwide, these solutions also need to transcend geography and be easy to coordinate and communicate. In short, what works in New York City today must scale up and be workable in Berlin tomorrow. And, perhaps most importantly, our IT solutions must always reinforce what makes us unique and gives us a competitive business advantage, which brings me to my core point:
No one knows your business like you do. No one better understands what your technology must do, what your team and your clients need or how your business model will evolve in order to create maximum ROI and success. No one gets like you do the differentiators encoded in your company’s DNA.
That’s true at Shutterstock. And it’s true at the smallest of small businesses.
Technology solutions work best when they fit best – when engineers combine science and art to holistically solve problems. At Shutterstock, that has driven us to combine minimal off-the-shelf shopping with an emphasis on customizing software and systems in-house. We’re scavengers, basically. We pluck the important “bits and pieces” of different technologies and we glue them together and use them in very narrow places. We do so in ways that allow us to swap these “bits and pieces” for new and better technologies at any point in time, while keeping the middleware the same throughout.This “sample a little, customize a lot” method works for us because our team has the technical competency to stitch together the right capabilities to keep our framework functional. Does it take more work than a strictly off-the-shelf paradigm? Of course. But the advantages are numerous:
There’s a freedom to being “vendor agnostic”
While we do standardize as much as possible, we don’t want to be wedded to a single vendor any more than we want to be reliant on a single school of thought or a single approach. Again, because we favor holistic problem-solving, fluidity and nimbleness are keys in our framework design and in our people.
Free thinking solutions create a reflective culture
Lately, when I go to conferences or skim the news, I see a trend that makes me wonder. As a sector, we spend a lot of time listening to and emulating consultants who have big names on their resumes – Google, say, or Facebook. I’m not devaluing anyone’s expertise, but chances are your company doesn’t prioritize internal and external needs in the same way as Twitter or LinkedIn. Again, no one knows your infrastructure better than you do. That means we can’t build out our infrastructure in anyone’s shadow. We need to create what works best for us, not what worked best up the street six months ago. By putting a heavy emphasis on customizing our own infrastructure, we also emphasize the need to stop and think, solve and iterate and solve again.
Right now at Shutterstock, we happen to be in the midst of a particularly reflective stage. Continuing to be successful means rethinking our architecture and constantly re-visioning our infrastructure. Not every element – the middleware we’re building now will stay constant – but surely there will be emergent technologies we don’t know about yet that will get us to the next version and iteration. We want to standardize where it makes sense, but customize where it will make the most profitable, more efficient difference.