Small 566e5c3c56d3e38a67788f56c89278e9 Dan McCormick on

Being fast and nimble is important to us at Shutterstock, and one way we accomplish this is by working in small teams. This approach has yielded tremendous benefits over the years, but it comes with its own challenges: Shutterstock now has over 300 people and dozens of teams. How do we coordinate everything with so many different groups?

Here’s a bit of information about how our approach to small teams has evolved, and how we continue to change it as we grow.

The Early Days

About five years ago, we learned the value of small teams the hard way — by not having small teams. Shutterstock started with a few developers who would work on a few different projects at any given time. We followed that approach as we grew the team, until suddenly we had 10 developers working on 10 projects, and nothing was getting done.

We addressed this problem by breaking into smaller teams. Each team has a product owner, a few back-end developers, a front-end developer, a designer, and a QA engineer. The teams are meant to be independent and autonomous, capable of taking any project from idea to completion without outside help. This lets them move very quickly and stay focused on their goals.

We started with three teams: a customer team, a contributor team, and a “business value” team that was meant to focus on internal projects that bring value to the business.

Lessons Learned

The customer and contributor teams got off to a great start, and exist to this day.  But the “business value” team floundered, and we learned some early important lessons about teams.

Each team needs a clear customer (or more generally, a clear target user). The team has to come to work every day excited to solve a problem for a particular audience. “Business value” was just too vague; there were many audiences within Shutterstock that needed projects, but there was no good way to prioritize one project over another. Consequently, the team was tossed from project to project, and often ended up doing things that the other teams simply didn’t want to do. After a few quarters, we decided to dissolve the team.

Each team needs a clear goal. Our customer team was living a schizophrenic existence: half its projects were focused on improving the search and download experience for our customers, the other half were about working on the signup and subscription flow to increase revenue. We addressed this by splitting the team in two. We decided that our “customer experience” team should stay focused on the primary customer experience on our site. The revenue team took over the signup and payment flow. After the split, this distinction came to feel more and more natural, and we look back on it as moving us in a better direction.

Teams need to be autonomous. As Shutterstock grew over the years, we were able to expand our offerings by creating new teams. Sometimes we’d assemble a team without making sure it had every role it needed — perhaps it would only have one developer or not have a QA engineer. We always ended up regretting this. The process only works well if the team can truly be independent and autonomous. Now we know: if we don’t have enough people to form a team, we wait until we can hire all the roles before we launch it.

Create Core Services Teams. As we added more product-oriented teams, there was a growing need to build common architectural pieces that all the teams could use. We decided several years ago to move towards a RESTful architecture, and soon many teams jointly used back-end services to support their product. But ownership of the services was problematic. If a service needed changes, it was unclear who was responsible for making that happen.

We solved that problem by introducing the latest evolution of our team strategy: core services teams. Each of these teams own one or more RESTful services, and work with the product teams to prioritize their work. Their goal is to build core infrastructure that other teams can leverage to serve their customers.

Solve the Challenge of Coordination. Today, Shutterstock has over 20 teams, all of which follow agile development practices of fast interaction and frequent customer feedback. With so many teams moving so quickly, coordination has become a challenge. This is partly addressed by returning to a core team principle: strive for autonomy and independence. We encourage teams to pursue projects that are within their power to take from idea to completion without outside help, which eliminates the need to coordinate altogether.

However, there are inevitably projects that require multiple teams to work together. In those cases, we promote four ways to improve coordination:

  • Each of our teams has a planning meeting every two weeks. Anyone can attend these meetings, and we encourage teams that are working together to attend each other’s planning meetings.

  • Each of our teams also has a demo every two weeks, in which they show off the work they’ve done recently. We also encourage teams that are working together to attend each other’s demos.

  • We have a weekly product backlog meeting, where all our product teams share upcoming projects and discuss metrics related to recently-launched features.

  • Finally, each team has a lead developer and product owner, and we give them the specific responsibility of pro-actively reaching out to other teams to discuss upcoming work.

These approaches are intentionally lightweight and simple. We rely on people’s own initiative to share their work, communicate actively with others, and work out the details themselves to address many challenges of coordination. Having a non-prescriptive process makes it clear to people that it’s their responsibility to talk to whomever they need to. So far, this approach has worked out well.

We’ll continue to evolve and adapt our team strategy as we grow. Though we’ve had some minor challenges with our approach over the years, overall it has served us very well.

This article first appeared on Shutterbits.



Dan McCormick is an Engineer at Shutterstock

Shutterstock is an engineering-driven business that embodies developer empowerment. Our engineers work on creative, cross-functional teams that drive product development forward from the ground up. We focus on fast, iterative development and deploy code more than 150x/month. We encourage our engineers to build their own tools, and also promote knowledge sharing and camaraderie across the organization via extensive internal engineering talks, events, team outings and hackathons.

Small geo Geo Grigoryan on

Clojure Programmer Geo Grigoryan talks about building mobile apps with ClojureScript and Cordova. Corodova allows you to write your user interface in HTML/Javascript and gives you access to hardware functionality via its plugin system.

In this talk, he'll cover the basic architecture, setup, and lessons he's learned while developing these apps.

This talk was given at the NYC Clojure Users Group hosted by Two Sigma Investments in NYC.


Small steve milton Steve Milton on

"You can't build it right the first time. Don't try. Look at the problems that are going to be in front of you in the next 12 months. Pick tools and capabilities that will allow you to be successful. Live to fight another day." - Steve Milton

In this fireside chat delivered at CTO School, Steve offers meaningful advice to engineers who aspire to be CTOs at high-growth and innovative startups. Engineers who aspire to be leaders in these challenging environments have to understand how to build software in the face of uncertainty, foster collaboration between teams that are moving unbelievably fast, store and analyze increasing volumes of data, and understand how software fits in the larger challenge of building a business that people love.

Steve is currently Co-founder & CTO at PlaceIQ, one of NY's fastest growing startups. He has been building technologies and leading teams for over 20 years (you'll enjoy his stories from the "pre-Internet" days).

This talk was delivered at a CTO School meetup hosted by Pivotal in NYC.



Steve Milton is a Co-Founder and CTO at PlaceIQ

PlaceIQ is able to take large amounts of often unstructured, unrelated, location based data such as photos, place data, event data, digital and social data (and much, much more) and – through a series of processes of data cleansing, normalization, analysis, and machine learning – extract patterns, trends, intelligence and context from the data.

Small mikebrittain Mike Brittain on

Etsy engineers deploy 40+ times per day to How does a team of 175+ committers maintain uptime for 60+ million unique monthly visitors?

In this talk, Mike Brittain (Engineering Director, Etsy) explains the structures and processes behind continuous delivery at Etsy.

You can see Mike's slides here:

This talk was recorded at the Full-Stack Engineering Meetup hosted by Gilt Group in NYC.


Mike Brittain is an Engineering Director at Etsy

At Etsy, our mission is to enable people to make a living making things. The engineers who make Etsy make our living making something we love: software. Etsy engineering team believes that code is craft, good software and systems designs are works of art, and that the work we do is part of larger creative culture represented by the hundreds of thousands of inspired makers who make Etsy such a wondrous marketplace. We believe that small, empowered, self-motivated teams can do big things. We also believe in the right tool for the job, not language-as-religion. Our current systems run PHP, Java, Scala, Python, Ruby, Solr/Lucene, Postgres, MySQL, and more.

Small turnbull James Turnbull on

James Turnbull (VP of Services, Docker) presents the roadmap for new Docker projects including libswarm and libcontainer. Watch this talk to understand new features and use cases.

James gave this talk at the DigitalOcean Community Meetup hosted by WeWork in NYC.

Small aysylu Aysylu Greenberg on

Watch Aysylu Greenberg, Software Engineer at Google and maintainer of the Clojure library Loom, speak on the paper "One VM to Rule Them All" by Thomas Wuerthinger, Christian Wimmer, et al.

The paper explains how you can write an interpreter and get an optimizing just-in-time (JIT) compiler for free. This enables language designers to focus on features without worrying about the complexities of compiler optimizations and code generation. This paper presents a Java Virtual Machine (JVM) that allows the application to control the JIT compiler behavior at runtime. Aysylu discusses how various programming languages can take advantage of this framework.

To intrigue compiler aficionados, the authors show how combining AST node rewriting during interpretation, optimization, and deoptimization produces high performance code from the interpreter without a language-specific compiler. In addition, they present how features of a variety of programming languages, such as JavaScript, Ruby, Python, R and others, map on the framework.

Check out Aysylu's slides:

This talk was presented at June's edition of Papers We Love hosted by Viggle in NYC.


Aysylu Greenberg is a Software Engineer at Google

Google is and always will be an engineering company. We hire people with a broad set of technical skills who are ready to tackle some of technology’s greatest challenges and make an impact on millions, if not billions, of users. At Google, software, hardware, network, test and site reliability engineers not only revolutionize search, they routinely work on massive scalability and storage solutions, large-scale applications and entirely new platforms for developers around the world. From AdWords to Chrome, Android to YouTube, Social to Local, Google engineers and designers are changing the world one technological advance after another.

Small franc Franco Ponticelli on

Franco Ponticelli (VP Client Side Engineering, Pellucid Analytics) gives an introduction to Promises for JavaScript as defined by the Promises/A+ specification.

Small joe crobak Joe Crobak on

Big data processing with Apache Hadoop, Spark, Storm and friends is all the rage right now. But getting started with one of these systems requires an enormous amount of infrastructure, and there are an overwhelming number of decisions to be made. Oftentimes you don't even know what kinds of questions you can or should be answering with your data.

As a first step, Joe Crobak (Software Engineer, Project Florida) describes the types of problems that people typically solve with a data pipeline—things like A/B testing and data warehousing. Then, drawing from his personal experience of building data tools at Foursquare and a from-scratch data pipeline at a new startup, he'll highlight the key questions to ask and best practices you should implement to encourage success.

This talk was presented at the Axial Lyceum in NYC.


Small sean o connor Sean O'Connor on

Over the years, bitly has built a number of large scale systems to handle and analyze billions of clicks each month. Distributed systems can often be challenging to build and operate, but they can offer significant benefits in terms of availability, cost effectiveness, and capacity.

In this talk, Sean O'Connor (Lead Application Developer, bitly) explains the challenges of building distributed systems and practical strategies to overcome these challenges. Specifically, Sean speaks to the benefits of Service Oriented Architecture, using asynchronous streams, scaling, dealing with failure, and monitoring.

This talk was presented at BaconConf.



Sean O'Connor is a Lead Application Engineer at Bitly

At Bitly, we are obsessed with making the internet work better. We started in 2008 as a humble URL shortener and have evolved into an real-time intelligence engine, fueled by billions of clicks and petabyes of data. Our comprehensive social media monitoring platform leverages our unique scale and empowers The New York Times, ESPN and IBM (to name a few) to monitor, understand, and engage with their audiences. We're predominately a Python shop, but we don't stop there. Oh no, we use Ruby, Java, C, C++, Go, and even a little Tickle. We've got nerf guns, but that doesn't stop us from solving problems at scale without breaking a sweat. Fine, sometimes we sweat, but we still look good. You'll be working in a flat, transparent, fast-paced start-up environment in the heart of Union Square NYC. Most importantly, we offer you the chance to work with smart people on difficult problems at huge scale that impact how millions of people use the Internet.

Join Us