Your engineering org chart is your roadmap

As startups grow, leaders must decide how to structure their engineering teams. Intuition suggests that multiple small teams will be easier to manage than one massive team. So, any organisation successful enough to have more than a handful of engineers will eventually need to do some organisational design.

Knowing that you should divide your engineers into small teams is easier than knowing precisely how to do it. These days, cross-functional models for teams prevail, and most people know to avoid teams larger than five or so engineers¹. But how should product development efforts be divided across teams?

My advice: your engineering organisational chart is your roadmap. While teams tend to frequently prioritise and deprioritise individual initiatives, what rarely changes is your team structure. Aligning your resources (in the form of engineering teams) to important focus areas is what it looks like to put your money where your mouth is regarding product development.

Many startups talk about the important things, but when it comes to product development, they get distracted by shiny new product ideas, longtail features, and feature requests required to close new deals. But no amount of talk will deliver real results in product development. This hypocrisy is why startup leaders should permanently allocate engineering resources to the areas that matter most.

First, identify the core outcome that your product delivers to customers. While the value proposition for many products is a web of connected user benefits, most startups understand the core value they provide. Most SaaS products improve operational efficiency or increase revenue, for example. The better you understand the value you can deliver to customers, the more sensible your resourcing strategy will be.

Second, dedicate most of your engineering resources to your identified core value proposition. Because markets and technology constantly evolve, no product is ever complete. To protect and improve your position in the market, you must continuously improve your product and the technology that supports it.

Third, invest in the future. After achieving product-market fit, most companies underinvest in the customer onboarding experience. A dramatic reduction in the customer onboarding timeline for future customers is better than a feature that will help you win a few more customers because fast growth today is better than future growth potential. Eventually, the time comes when it is clear that you will exhaust your total addressable market. It probably makes sense to dedicate one or more teams towards market-expanding initiatives. Even now, you must continue investing in your core value proposition. It takes a surprisingly short window of neglect for a software product to become a painful liability, expensive to support, grow, and maintain.

Footnotes