Imagine something growing by 39,185%. That’s a farmer planting two tomatoes and harvesting 783,600. Or, a 0.2 lb baby panda growing up to weigh 3.9 tons, bigger than the average Asian elephant. It’s the kind of “hockey stick” user growth that people drool over in the startup world. ORCID has achieved it in just six years.
Joining ORCID in 2012 as tech lead was initially a leap for me. I had worked helping to grow five startups, but never anything in the nonprofit or academic space. Six years later, upon my exit December 1st I wanted to reflect back on my experiences..
I was originally hired on as Lead Developer to help stabilize, scale, and speed up the software lifecycle of ORCID’s legacy-forked Java codebase. I joined shortly after the Registry was launched, at which time we had 10 servers and a team of three software consultants, serving a rapidly growing base of over 14K user researchers. I remember my fish-out-of-water feeling the first time I presented on ORCID to a room full of multi-PhD’d academics at CERN, armed with my community college associates degree in mathematics and unfinished bachelor’s degree. But we all shared a vision, and that brought us together to do incredible things.
Even though the domain of open research infrastructure was totally new to me, managing the day-to-day software release cycle and contributing to the code base are in my wheelhouse. We built a team that combined the best of open, commercial, and startup cultures and we were able to quickly get fixes in place and start on a path of rapid scaling. My “cowboy” approach from working in fast-moving California startups turned out to be a good match for ORCID’s mission-focus nonprofit structure and international scale. Two big pain points in those early days were server stability and pushing the code base to an open source repository, in alignment with ORCID principles. By the end of 2012, 2.5 months after our launch (!),we had grown to over 50,000 users and 25 member organizations. By the end of 2013, we neared 500K users, from every country.
There were hurdles at the start, certainly. For the first two months I couldn’t build the codebase or access the server build scripts. Why? Because parts of our codebase were locked behind a software consulting company’s firewall. This meant having to push live.jpg)
changes I couldn’t test and modifying servers by hand (both terrible practices but with the advantage of making you understand exactly what you are doing!). Not having 100% access to all part of the codebase impressed on me just how important open source and sharing can be.
Today, ORCID has over 5.5 million users around the world, and we are nearing 1,000 members. My role grew too. I transitioned from Lead Developer to Technical Director in January 2016, and during my time here, I have led a tech team of nine spread across three continents and traveled to over 40 cities. I never did get my idea approved for a team meeting in Antarctica (it has the highest density of researchers in the world, perfect for ORCID!) Along the way, a couple of key lessons stand out when thinking about what makes the ORCID story so special:
- Community. At the first Board meeting I attended, ORCID had just four employees and 14 board members! How bizarre it seemed to have a ratio of three board members for every employee – something you’d never see in a Silicon Valley startup. While those numbers evened out as we grew, the Board has continued to be a lodestar. Over the years, I came to realize how much the ORCID community cares and also how much the ORCID community deserves credit. Any sacrifices I made as an early employee were returned by the community three-fold. You are truly amazing!
- Embrace change. At launch, ORCID was following enterprise software processes and culture rules designed for large publishers. While those practices have merit, as a tiny startup, we needed to be unafraid to buck perceived best-practices and instead find the right practices for us. One example from the early days was our external software consultants insisting we go through load testing for every release. Of course, pushed to the servers, the reality didn’t match the test results. ORCID was spending a lot of time and money on something that kept proving ineffective. From a previous job at Fortune 500 company, I knew load testing usually was fraught with false assumptions. So instead, we created a culture of coders reading and understanding their code changes. ORCID was willing to engage new, more appropriate solutions every step of the way.
- Iterate fast, taking small steps toward huge goals. Pushing small changes as quickly as feasible to production has been a big part of our ability to scale. Even though the end goals were HUGE, breaking the steps down helped us get there. Small steps mean small risk. A great example is from my very first day. I knew the API first build had a critical flaw that is best described as monolithic. Mostly, this was tied to modeling the API about researchers after other APIs built for books. Researchers are far more complex than books! The team had to tackle it with small steps — 27 iterations and hundreds of code commits to get to API v. 2.0 — until we eventually had the API we needed to allow ORCID to continue to scale.
When I started there were eight production machines. Over the last six years we’ve had to double those numbers to increase the size/power of the servers to handle periods of rapid exponential growth. Currently, ORCID sees the most growth with the use of our APIs — about 3,456,000 requests a day and growing. Staying ahead of growth is ongoing work. I’m really proud to have been a part of the ORCID story, especially the early rough-and-tumble days. As I set out on my next ventures I hope ORCID finds new challenges and even bigger successes.
