The most difficult question for a CTO/HoE is to estimate how many Engineers and Engineering assisted roles ( PM’s , TPM & QA’s ) would be needed to scale a start-up. There are a very few mental models that exist.
Using the number of Engineers in the company is no longer a currency of success and clout for an Engineering leader. Over the last 5 years, mid to hyper scale startups have started to evaluate the impact that their Engineering teams bring to the business as a currency for capital investment in their Tech department.
“Achieving More with Less” is the way to go. Being able to create a disproportionate impact to business of the company with a small size of the Tech organisation is really the ‘currency’ of success for a good Engineering Leader.
Some common patterns that emerge at an early stage company:
A lot of extremely smart engineering leaders from already scaled up companies have a tendency to build everything from scratch internally from Day 1. This ends up inflating the need of engineers needed to get the work done.
A careful evaluation of a cloud hosted service vs building it-in house will be the key.
Think of these decisions as 2-way doors, once the company scales up to its next million/billion users , a need will present itself to make something in-house ( TCO at scale ) .
This one is going to be un-popular! As engineers, we are in awe of micro services , it indeed is beautiful , but…
If you are in an early stage company, most likely the business grew multiple folds with a monolith. Not all parts will need to be broken down to a micro service at such an early stage. Careful examination of what pieces of monolith will need to be written in a micro service for apt scaling is critical. General rule of 👍 is all P0 flows for conversion on your app/website should get done first.
A great mental model is provided by one an only Martin Fowler , he makes you think twice before joining the micro services bandwagon : https://martinfowler.com/bliki/MonolithFirst.html
Net-Net restrain from inflating the hiring needs to break the monolith apart. This will need an honest conversation with the founders on what your current tech stack can support and when will it break. At the end of the day, it’s all about tradeoffs and capital investments in the engineering function.
In a fast growing startup , most likely there would be efficiencies that will be needed in different departments. Thinking through the lens of defining your pods and business services would also go a long way in creating impact on the business via technology. Typical areas to deep dive are Business Reporting , Reconciliation and Finance. Understanding the business processes of the company would really help in estimating the capacity needed for automation.
We will continue to discuss more around bringing about Engineering teams on this SubStack and at Twitter .