Is "do more with less" the right question to ask?
That was the topic of an event I attended last week. The event was organized through the very fine people at ELC and included a host of engineering leaders from the Seattle region. The topic is obviously quite relevant in today’s macro-economic environment where resources - capital and otherwise are constrained - which led to a healthy debate.
Macro-economic and fundraising conditions aside, I argue(d) that the “do more with less” or more generally optimizing how resources are used should be the norm, especially for startups. A healthy startup should be resource constrained, implying hard tradeoffs and optimizing how resources, people, capital, infrastructure and so on, are used. So far this is all easier said than done. The question is how do you try to minimize this waste and optimize for what you have?
I have applied a few tactics over the years, which (yes, this is subjective), I believe help with this optimization challenge.
Start small
You’re about to embark on a new project, perhaps it’s a much needed feature or new product. How many people do you assign to this endeavor? My approach is to artificially constrain the resources for this project, namely people, at the outset. The beginnings of any software project are fraught with risk and much uncertainty. Allocating more people that is needed to de-risk and refine the scope of the project is wasteful. I prefer to start with the smallest possible team size (min 2) and once major risk elements and scope has been aligned on, can add more. This approach is meant to reduce over allocating resources at the outset. Additionally, it allows you to validate that adding more resources will accelerate the timeline to deliver this feature. Not all software development work is parallelizable and even if it is, there is usually a limit to the resources and parallel paths.
Get comfortable saying “No”
This is one of the hardest things to do. Telling your customers, your product team, your sales team or your support team that you aren’t able to work on a particular project they need. There’s a fallacy that I have observed in startups and that is the willingness to default to yes, especially with customers. It’s absolutely great to be able to accommodate your customer’s needs and to deliver them quickly, but that doesn’t mean you should default to yes all the time. There’s an upper bound to resources, hence saying “no” is important.
If you find yourself in a situation where you are inclined to say “no”, you should complement that with additional context. You want the party requesting something from you to see why you are unable to accommodate them now. You should also offer some tradeoffs or alternatives. Often-times when facing with saying “no”, especially if the request is from an internal party (product management, sales..etc) is to ask the requester to re-prioritize the roadmap. What future projects should I drop to accommodate this new one? This allows the requestor to contextualize the optimization problem and also open up an opportunity for re-prioritization and tradeoffs.
Resist the urge to context switch
Because saying “no” is hard, the compromise oftentimes is to stop a project your team is working on, pick some new work (rather than say no) and revisit the stopped project once this new work completes. That is wasteful and very disruptive to your teams.
“We spend less than 50% of our time per project when working on two projects, less than 30% when working on 3 and so forth. Context switching takes a toll on our productivity.” Quality Software Management: Systems Thinking by Gerald Weinberg
Resist the urge to hire by default
Hiring and increasing startup headcount, especially software engineers, was all the rage during the ZIRP era. Money was free and falling from the sky, so why not? I’ve had no fewer than 2 mandates given to me to 2x or 3x an engineering team in under 12 months. Bigger, better, faster
I have a few issues with this approach.
First, by assuming that you can alway hire yourself out of a resource constrained environment, you never develop the muscle to focus or prioritize. Everything becomes a priority. Second, when you can no longer hire you find yourself with an unfocused and bloated organization, especially when business slows down. Then, of course you react and downsize by letting go of most of the folks you hired.
I fully realize that this post is motherhood and apple pie. Of course one should optimize resources, not over hire, not waste and so forth. The thing is, its just damn hard to do. Below are a few articles that I wrote that are relevant to this topic.
It is very hard to have the rigor and operational excellence to build a long lasting and sustainable company (read profitable). Witness the table below as an example. The table shows the operating margins of many SaaS public companies. The vast majority of them (2/3) have negative operating margins, many years post IPO.
I have no evidence that this sad state of the software industry, at least manifested by the cohort above, is because they over hired, overspend, didn’t focus and so on. But I suspect that the ZIRP induced bloat had a large impact and might explain why most of these companies cannot yield operating incomes. Some might never be able to.