3 Frameworks for Scaling Startup Operations On The Way to Unicorn Status
3 Frameworks for Scaling Startup Operations On The Way to Unicorn Status
Building any business is hard. Scaling is a uniquely difficult stage of building a business. But building and scaling a unicorn is 10x harder. Things are moving lighting fast and there's never as much information to make decisions as one would like. As a result this requires the organization to be more agile, live with many sub-optimal interim states, and deal with more ambiguity.
How can managers and leaders navigate this?
In this post I'll introduce three very simple yet powerful management frameworks that have been helpful to me in building and scaling a unicorn, as well as other organizations.
WHY>WHAT>HOW
The first framework is for problem solving and applies whether it's a group collaborating or an individual contributor figuring out what to do. Let's define what each is about.
WHY — is all about what problem is being solved or what goal that needs to be achieved
WHAT — is about coming up with what the options are for solving it (Note: This is generally an analytical exercise like making a decision tree.)
HOW — is all about the method of execution
Typically executives are operating at the WHY and WHAT level. Managers typically operate at the WHAT and HOW levels. Individuals execute the HOW but need to understand the WHY and WHAT.
As Simon Sinek proselytizes good leaders give people the WHY, paint a vision for WHAT needs to be done, and empower others to figure out the HOW. Let's look at this simple framework in action.
Example: WHY>WHAT>HOW
Let's say we have a great product, but sales are lagging. How would we use the framework?
WHY: people are not aware of our product
WHAT: invest in digital marketing, media marketing, event marketing; run a customer referral campaign; do nothing
HOW: would be all the steps involved with planning and executing an event, ad campaign, etc.
The way this might work in practice is the executive team might identify the WHY. Then work with the sales and marketing teams to layout the options, debate them, and coalesce around an option. Let's say they decide to attend conference events to demo the product in an effort to get the word out. Now someone on the marketing team needs to figure out the events to attend, plan a demo, book tickets, order banners, setup a booth, make flyers, email potential customers, etc.
I hope the key thing you notice is that the executives don't have THE answer and send it down to the team from atop the mountain. They are facilitating the team moving through the WHY>WHAT>HOW framework.
The biggest problems I see are often a result of people not operating at the right level or not connecting the parts. For example, the individual executing doesn't know the WHY or an executive is ignoring the feedback signal about implementation coming from the person executing the HOW. To be successful leaders and managers need to be able to navigate the levels and align the organization's WHY > WHAT > HOW.
No matter what level you are in an organization you can practice this mental framework. I do this in meetings by writing out the WHY>WHAT>HOW and filling each in for the topic at hand. If I can't do it on a post-it note that means we're not clear enough on what we're doing. Try it! It will make you better, your team better, and your organization more successful at achieving its goals.
NOW>SOON>LATER
In college I did home remodeling construction and nothing was ever on time because we always ran into something unexpected. Then in my professional career the same thing happened with product development and software implementations. Through software agile development I came to appreciate the power of failing and incorporating lessons learned quickly. This is why I don't fear the F word (failure) and strive for quick feedback loops in everything I do.
This turned into a useful framework while scaling a unicorn. Everything was moving too fast to predict timelines and setting deadlines was a sure path to failed expectations. Because humans are expectation machines I found it better to synthesize through time progress at the conceptual level and give ranges for time estimates.
NOW — define the current state (i.e. where are we now)
SOON — define the interim state (i.e. what will it look like soon)
LATER — define the desired end state (i.e. where are we heading)
This framework is flexible enough to outline where we are and where we're heading for people to take action, but leaves space for learning. It also accounts for something most people miss, which is that there's always a messy interim state of things. Every software developer knows this, but not every manager plans accordingly. The refrain I hear to this is that it's too much ambiguity, that people can't plan around it or that it causes people too much stress. The flaw with this type of thinking is that people think they have more power to control the world or predict the world than they do. Yet research shows humans are fundamentally bad at estimating how long it takes to do things. Furthermore, it shows a lack of self-awareness and humility. So if you're feeling that way I recommend practicing getting comfortable sitting in ambiguity. How? Practice.
Example: NOW>SOON>LATER
DO>PROCESS>AUTOMATE
This framework pairs well with NOW>SOON>LATER one.
DO — someone manually figure out how to do the thing
PROCESS — standardize the solution into a process
AUTOMATE — automate repeatable tasks with software
Let's say you are solving an operational problem. It's often best to begin by having someone manually work on it. They will figure out the nature of the problem and build a working solution. But having one person who knows how to solve it is not sustainable nor scalable. So the next step is to iterate upon the solution until it can be standardized into steps that can be documented — a process. Having a process allows for the steps to be shared among several people (i.e. providing leverage) or enables multiple people to do the process, which provides increased capacity. But as scale increases that has limitations. You then migrate what you can into a software process as much as possible. This is typically repeatable mundane tasks (e.g. data integration between two systems). As the context changes when moving through each stage the solution will likely need adjustment, that's OK. As long as things get better with each iteration. It takes patience and discipline, but after all Rome wasn't built in a day!
Example: Airbnb
In Blitzscaling by Reid Hoffman he writes about doing things that don't scale and gives a great example from Airbnb that shows the DO>PROCESS>AUTOMATE beautifully.
DO
Consider how the founders of Airbnb solved the problem of hosts posting poor-quality photos of their rental properties on Airbnb.com: They became the photographers. As Brian Chesky told me, “We would borrow cameras from our RISD [Rhode Island School of Design] friends in Brooklyn, then literally knock on the doors of all our hosts.” Together, Brian and co-founder Joe Gebbia could photograph about 10 homes per day.
PROCESS
As Airbnb took off, the photography function had to scale up considerably. So the founders hired photographers from Craigslist, hit up their RISD friends, and even recruited Airbnb hosts who listed photography as a hobby. By tapping these sources, the company was able to build a stable of five to 10 photographers who were paid $50 per home and tracked them using the sophisticated management tool of a spreadsheet listing photographers and their assignments. Pretty soon, this system was overwhelmed. So they hired Ellie Thiele from Syracuse University as a summer intern and made managing photographers her full-time job.
AUTOMATE
By focusing solely on managing the photography, Ellie was able to increase the number of active photographers to about 50. It was only at this point that Airbnb went to a truly scalable solution: software. Nathan wrote some code, adding two buttons to the site: one for hosts to request a photographer and the other for Ellie to trigger a payment when a photographer finished an assignment. Eventually, the founders hired Joe Zadeh as an entry-level engineer and asked him to work with Ellie to fully automate the photography process.