“Non-engineer” at a Rocket Start Up
Mapping out Business Operations
Picking up the thread from my last post, I joined Relativity in July 2016 as its second employee and first non-engineer to work with our CEO on “the business” side of the company. I initially held the title of “Lead Business Operations”, which looking back still doesn’t really make sense to me semantically. Like is “Lead” a noun or a verb? 🤷🏻♂️
Of the first 5 of us at Relativity, everyone except me was a University of Southern California aerospace engineer who had previously worked together as part of a student group called the USC Rocket Propulsion Lab. On the other hand, I was a former PE investor and UCLA MBA that still had yet to grasp how a rocket actually worked.
Clearly, I was the unknown quantity of the bunch, and a “rival” UCLA Bruin at that— talk about getting started out on the right foot. Nevertheless, I had scrounged for an opportunity like this, so my isolation was truly of my own making.
So, what is business operations?
Walking in my first day, I realized I didn’t actually know what “business operations” actually meant. I had come across “business administration” and “operations management” quite often across my career, but had never heard of the portmanteau of the two. After my four years and change at Relativity, this is what I’ve got.
Business operations is a somewhat not-so-helpful, catch all term for a broad grouping of functions that attempt to support and amplify the development and selling of a company’s product. It can take on different nuances based on industry, be partitioned into different reporting structures, and include different functions across the various stages of a company’s growth and maturity. Let’s just say it can be both broad and narrow depending where you’re at.
Granted, any brief description of business operations is probably insufficient without getting into details of a specific company, especially for a startup. So perhaps it’s better to describe it through the exclusion of what it is not. Early on at Relativity, before we entered production, it meant touching everything that wasn’t strictly engineering.
As became the case at Relativity when we scaled our headcount, many business operations units began to mature to develop their own concerted focuses and organizational structures. However, in our nascent days, we set up business operations to have a very lean set up. Given our fledgling team size, we grouped business operations into a single flat function to administrate all the banal functions necessary for any company.
Our CEO and I pretty much had a blank slate to start building up the systems and processes needed to support our product. This freedom to operate often collided with our exuberant inexperience.
While all of our founding team had come from one “New Space” company (such as SpaceX or Blue Origin) or another, none of us had yet actually built a company or had worked at one at this stage. This meant we had to learn most things on the fly. But it also provided flexibility provided for a fantastic trial and error learning environment.
Double clicking on Disciplines
Breaking up the narrative, I think it’s useful to outline some of the functions that make up the business operations disciplines above. That way, you can use it as a reference to navigate my future posts to understand where I talk about a particular topic that might interest you.
Goals for Business Operations
So…that’s a ton of different verticals and functions listed above. It can definitely be daunting to think about all of this scope for any early business when time is scarce and resources are thin. But what I think is important to highlight early on in this exercise is the importance of understanding what exactly needs to get done and aligning your business operations’ goals with your product’s goals.
Just as important, is the honest awareness that your business operations will constantly be changing as you discover what works. At an early stage, it’s hard to have a competitive advantage in every function. Pick what you will be exceptional at and be flexible with the rest.
At Relativity, we initially set up our business operations to achieve a minimum viable structure to support our product’s development. We decided that we wanted our competitive advantage early on to be the speed of our learning and adaptability. Our goal with business operations was to have all the basic capabilities in place, and prioritize tasks that would unblock the pace of our engineering development on our 3D printer and propulsion system. Admittedly, this culture translated to a ton of context switching and firefighting.
In a typical day it wasn’t uncommon to juggle strategic work with a cascade of seemingly unrelated tasks. For example, on a random day, my calendar consisted of negotiating a building lease and securing specialty test insurance, to moving desks for paint jobs, setting up interviews, and processing payroll.
Oh and, lest I forget, deep clean our sole bathroom hours before a board meeting. It’s a fast way to build camaraderie :)
This lean ops that prioritizes speed over everything else definitely has its drawbacks, as it can lead to a lot of reprioritizing and a lack of time to institute process. But we accepted that we’d be constantly changing as we grew, subscribing to the mindset that every time we doubled in size, all of our processes would break and need to be redone. So why introduce needless process that would rapidly change? We had to embrace the absurdity of our early days, recognize quickly where we were falling short and reconfigured quickly where we could.
Now the good news is that this state isn’t permanent. As we got through our early existential development milestones, we freed up bandwidth for us to focus on charting out how to grow our structure and business processes more sustainably. We were able to start bringing on more team members with specialty focuses and clear business goals. And this practice forced us to rethink our business operations goals to buttress a nascent business transitioning from a development focus to building a business that scales.
Reflecting back on my early days at Relativity, going in I honestly didn’t have a clue about business operations. I had come from the perspective of transactions and investing, which can be largely high-level. But, if investment banking takes a 30,000 square foot view, and Private Equity takes a 10,000 square feet view, then establishing business operations at a startup is subterranean. But business operations early on is extremely intuitive.
As every company grows, business operations will take on different meanings. But every company starts out with the same basic needs. All companies need some form of legal, payroll, finance, HR, facilities, supply chain, etc. And while you can outsource many of these functions, it’s important to understand what they will need to evolve into so you can chart out how to get there.
What you need to determine early on is how to set up your business operations to support the current stage of your product. As your product evolves, then your business operations must also to meet your organization’s needs.
Understanding the roles of all of the functions I listed above can definitely help you to leverage the most out of your business operations and adapt to constant context switches. And good operators are super valuable to any company — especially when things are hectic, and in states of transition. We’ll dive deeply into what to look for in each of the verticals in the following articles.