Some years ago I left LinkedIn to take up a new leadership role at a smaller company. I went from an organization of thousands of engineers to one with a couple of dozens. The transition has had its upsides and some surprises.
Today many engineers are making this transition, either due to layoffs or because they are looking for a change. Smaller startups that are pushing the frontiers of new ideas provide an attractive change of pace. In this post I discuss my experience in making this transition.
Moving fast again
With smaller teams, the pace of execution is naturally faster. Part of it is due to the absence of some checks and balances that are a necessity in larger companies. For example at LinkedIn we had an internal committee that reviewed all REST APIs, and data models before they are committed. This review could add days to your work, depending on the complexity of data models. Although this sounds like red tape, the results were clean and consistent APIs and data models across teams.
In contrast, at my new role at the startup, data model changes would get reviewed through a voluntary design review in some cases. At other times a team would push through without any broader oversight. This ensured that code got shipped fast. Going to prod quickly means customers got to use the features immediately and we got to see impact right away. The downside, as you would guess, is that over time data models and APIs became inconsistent and messy. A lot of similar concepts got duplicated across teams. We had duplicate endpoints doing essentially the same thing.
All that said, if you are someone with exposure to the scale of big tech, there are opportunities to consider lightweight process improvements at smaller startups that maintain speed and boost quality.
Missing the amazing tools
One thing you miss immediately at a smaller company is access to amazing in-house tools to help you scale. At LinkedIn we leveraged in-house systems for everything from storage to metrics and experimentation. For example, LinkedIns internal experimentation platform is deeply integrated with the metrics platform. Building, scaling and experimentation was fast. With a rich set of tools available at your fingertips, you are free to focus on innovating on the core problems.
At a smaller company you rely on third party services and platforms for a lot of these tools. At the time of writing, most of these systems often fall short of in terms of features and quality when compared to the tools available at big tech orgs. Although some of these third party tools provide integrations, then end result often falls short in ways that can inhibit your options and approach when scaling quickly.
In essence, many technical design discussion includes a build vs buy decision.
Build vs buy decisions
In big tech with all the resources available, the default posture is to build. There is rarely a build vs buy discussion, accept at the business strategy level or corp dev. (And by “buy” we used to mean, buy the whole company so we turn their tool into an internal asset.) Most times we used to simply go ahead and build the system that catered to our unique needs.
This is not feasible at smaller companies. And I found myself often needing to control the impulse to greenlight “build” projects instead of considering the buy option.
As I mentioned earlier, external SaaS tools will often fall short in meeting every need completely. But with limited bandwidth to build every tool internally, we need to accept the best that we can find in the market to make progress and deliver value to customers.
External coach and mentors
At large companies, you can connect with other engineers at a different part of the org to find coaches and mentors to help you grow. At smaller companies, a similar approach can help junior engineers get mentorship from senior engineers on a different team. However, finding mentors get’s difficult for the handful of Sr Staff/Principal engineers.
For senior and executive leadership, you need to invest in connecting with external communities for support coaching and mentorship.
These are some of the changes I encountered during the transition. In general, smaller teams mean a different category of problems that may not benefit from scaled-down solutions that would have worked at big tech. Instead think each problem through from first principles and leverage your exposure at big tech to produce innovative solutions that meets the specific needs.
(Photo by Maranda Vandergriff on Unsplash)
