The Zen CTO: Every Startup Needs Pruning Shears
Rethinking resource allocation- When scaling; When operating; and When validating great software products
When tech startups begin scaling, founders often think of time-to-market as “the amount of execution time it takes their development team to get the job done”.
They should instead think about scaling as both the man-hours needed to build out their product and the man-hours need to then support the operations and growth of the product.
Understanding the difference between the two types of resource allocation helps founders clearly define their hiring needs.
People often say the founder’s journey is a marathon made up of of sprints, but after years of building, I am discovering the journey looks more like a sprouting tree.
While branches are part of the tree, the trunk holds it all together and ensures the tree’s survival. To me products take on a similar shape. The trunk is the core innovation (value proposition) and the features are the branches that extend the tree’s reach. As those branches grow farther away from the trunk, smaller ones begin to extend in a catenating fashion.
Branches, like features, start small. When new branches sprout from the trunk, they search for light to give the tree energy. Branches that find light are given more resources and will compound additional growth. Branches that don’t find light do not receive resources resources and wither. For the tree, each branch is a test. The tree gives branches resources in accordance to how much light they capture.
As new features are built out, each needs to be validated before they become part of the product that hold them together. Like the tree testing if a branch has found light, we can test the strength of each new feature before we devote resources to it by testing the riskiest assumptions about the new feature first. The riskiest assumption is the most obvious reason why an effort will have failed should it be built and not found to be successful.
When I provide interim CTO and technology strategy coaching solutions to our clients, I always make sure I first understand their core value proposition to their users and their long term goals before even looking at one line of code. Understanding a team’s hypothesis for their core offering helps me understand how the tech should most pragmatically take shape. Technology needs to surround and support a product’s main value offering the same way branches grow out of a tree. As more resources are devoted, development becomes more complex, and when it becomes more complex it becomes a dependency. A dependency is a distraction, and when things are distractions the reasons for keeping them aren’t being validated. So always validate when possible before committing additional resources.
A distraction is an unvalidated riskiest assumption.
People often devote too many resources to branches that aren’t their core offering. I usually see this occurring with over-engineered solutions from enlarged teams who keep hands busy by building more product without doing an analysis of user engagement. In some scenarios I’ve seen startups build new features without planning how much support it will take to manage when it is done. In this case an analysis of engagement could have surfaced ways to repurpose what existed with similar functionality instead of building out a new branch at the cost of more resource allocation and time. The goal of development is to build more with less, not the other way around… I say build less and give the team a vacation :)
Another very common thing I’ve seen is startups trying to figure out whether a feature that was built, should have been built it in the first place… as a repeat startup-founder, I know the value of finding the most efficient path to implementation is often in the opportunity and it occurs when the feature really matches a users expectations. Users expectations can be measure with different techniques like NPS scores.
Features are designed out of users needs but are validated when they match user expectations.
It’s important to validate before building not just because of the time and resources wasted but because of the distraction it can create if it becomes part of the product tree. I seek a holistic understanding of a team, it’s business plan, its go-to-market strategy, and its current development pipeline so that my recommendations support a product not just now but in the long term. The comprehensive understanding of a core value proposition will allow a product to be flexible and still have its core identity, and make sure each feature that branches out supports itself, its product and the company.
