Developer productivity was the problem.
The infrastructure underneath it was inconsistent. Development and QA did not always work from the same assumptions. Testing depended too much on which machine somebody happened to be using. A new developer could spend time rebuilding an environment before writing useful code.
My goals for the quarter were written as a short list.
First, make local development work. Give developers a standard environment they could run on their own computers. Make the path from a laptop to integration predictable.
Second, automate more of the testing. If the same change produced different results in different places, we had not standardized enough.
Third, package two internal tools so other teams could install and use them. The best test was whether an outside developer could understand the documentation. If somebody outside Shutterstock could use the software, our own teams probably could too.
Vagrant was part of the plan. So were repeatable configurations, shared tools, and fewer one-off machines that only one person understood.
None of this sounded glamorous. That was fine. Infrastructure work is often removing the reasons other people cannot do their jobs.
The metrics were yes-or-no questions. Were the environments standardized? Could developers work locally and push to integration? Were the internal tools documented well enough to release?
I like goals that make it hard to hide behind activity. “Improve developer experience” could mean almost anything. “Can a developer bring up the environment on a laptop?” had an answer.
There was plenty of larger systems work happening around us. Data centers, networks, databases, and site performance got more attention because the failures were louder.
This work was quieter. It was also how a growing engineering team stopped rebuilding the same setup at every desk.