Oct 7th, 2022
Series A funds are generally used to grow business, often to scale as a startup finds a product market fit (PMF). Often times, startups slow down and fail 3-4 years after this stage because of decisions made during this stage, especially when it comes to product engineering. Here are some things I think founders and engineering leaders should care about, and set straight at this stage if they haven’t started already. The cost of fixing things grows with time, akin to Boehm’s law.
When I say mistakes, below, it doesn’t mean things won’t work, it just means that the probability of long term success lowers, or the cost of fixing problems goes high, with such actions.
Setting the right product engineering culture and practices
Investment in the right practices at this stage reaps oversized benefits in future, and not investing makes companies often becoming very slow in building products and features, and get easily outcompeted by a faster peer. This is the right time to push teams to be disciplined about code quality, continuous delivery, high unit test coverage, automated functional tests, infrastructure automation, observability, product instrumentation, well written stories with acceptance criteria etc.
Cost of doing this later is quite steep and has wide ranging affects, including high attrition, low morale, costly rewrites and firebreaks, lethargic teams and of course buggy and slow development in a year or two, right when you need it to be otherwise.
Avoid copying org structures from other companies blindly
Many companies make the mistake of copying the org structure of successful companies without finding out the problems that come with those structures and how those companies mitigate them. A classic one is setting up separate product and engineering groups, and hiring leaders for both who operate as peers. Such a structure works well for bigger product engineering teams, but creates more problems and slows down execution in smaller teams. At this stage, trust and alignment between people has an outsized impact and miscommunication or trust issues can really damage execution and team morale.
A product engineering team with one leader is much more agile and faster than having two, and your focus should be on building such teams. Another reason why founders may think this kind of structure works is because at many companies, co-founders play these roles; the key here is that in most companies, co-founders have deep trust between themselves and communicate with each other easily. This is really hard to replicate with senior new hires at these roles.
Hire the right Senior Engineering Leaders for your team
A common mistake founders make is to hire senior leaders, often at a very high cost and without truly understanding and mitigating the effects of such a hire on the existing team. Your current team has taken the company to this stage. A new leader brings in new people they trust, at peer or manager levels to current engineers and this has an effect on current engineers.
Another oft made mistake is to ignore the culture where such a senior leader is coming from, and their values. Founders should actually overindex on how aligned a person is to their company culture. It is far harder for senior leader to unlearn and then learn these things, and its better to hire or promote someone maybe a little less experience but one who fits the company culture.
Letting go of misaligned and mishired people early
As product engineering teams are smaller at this stage, it is a bit easier to find people who are not performing well and to help them get back to track. However, if you are not seeing any changes, its best to let them go early. Similarly, leaders should be vigilant about toxicity and new hires who are not aligned to the company culture and ethos. If feedback doesn’t work, let them go, and improve your interview process, keep the house clean. The mistake young companies make is to worry more about headcount and past loyalty and less about keeping a fast moving tight ship. A small setback now saves a lot of problems from later.
Avoid overspending on building peripherals
Early stage teams should be focused on building custom software products that have a direct customer or competitive impact. And using OSS1 or buying off the shelf products that are already available as commodities. The cost of bulding is almost always very high at this stage and with limited and costly product engineering capacity, you are better off building stuff that doesn’t exist and makes your business excel. This isn’t any different advice than to prioritise hard on things because of limited and costly capacity, but crucially, many startups get distracted by building peripheral software in order to save money. You’ve got the funds, use them to increase focus.
A common response is, if companies buy everything, culture of innovation will die. However, at this stage building an innovative and pathbreaking product is exactly what you are doing. And this does not mean that you should not invest in individual side projects.
Avoid building throwaway software
While trying to find PMF quickly, in general you are not building big systems. You may not be focused on software architecture and code quality while continuing to find what the market wants (or needs). You may be discarding and rewriting software a lot. But at this stage, you are trying to scale your business. It is important to start investing in building durable systems that can be built on top of, and in future don’t slow you down. The next few years would be spent on iteratively building on top of your primary product. And even a rewrite or two if needed. Standardising stack, spending time discussing scale, hiring some senior engineers who have seen bigger systems helps a lot. Turn the dial a bit on discipline and building systems that allow for incremental changes is the key, not to build overdesigned systems as it is tough to predict where changes may be needed.
Talk to any engineer or product manager of a series C or bigger company, and ask what slows them down. The most common answer I would bet on is legacy code.
Set standard expectations for Product Engineering Roles and Job Ladder
If not done already, this is the right time to setup role progression and growth paths for your staff. People you have hired till now understand your vision and embody the company culture that you want to set for the future. It is important not only to retain them, but to also help them grow and become leaders in their own right. Job ladders are painful, but they are the least painful way to communicate expectations from your staff. Not investing here will increase the likelihood of unwanted attrition.
Most probably your product engineering team will grow, maybe double or more in this period. A job ladder also helps you to standardise your hiring process, standardise salaries and help you in overall budgeting as well.
Word of caution, do involve your current staff when setting these standards.
Protect and refresh org culture
A lot of new people join your mission at this stage, and often company culture changes very fast. A big part of your daily job also changes now into custodians of the culture and thus the company you want to build. New people bring in values that may help the company culture or go against it. Only you can decide what to borrow and what to resist.
A good way to help others understand and propagate your design is by sending a weekly/fortnightly musings. Not a collections of links, not your reading lists, but what’s going on through your mind and what you want the team to focus on. Think of behaviours you want to promote, and mention them often in the letter. Encourage your senior leaders to highlight such behaviour in their teams too. The important bit is, do this yourself, do not outsource this to an HR partner.
Fix your recruitment philosophy and hiring practices
As you scale your product, and start building more software, you will be hiring talent at a higher pace and from outside of your direct network. A standard process for talent acquisition will help bridge the trust gap. The goal for any recruitment process should be that any candidate hired should be implicitly trusted by the team from the day they join. Not how many. You will also need to start monitoring metrics like TAT 1 for candidates by role, drop-off rates, conversion from offer to joining etc. so you can accurately put fixes in when there are problems.
Based on the job ladder, you should be able to tell your recruitment team the salary budget for each role. You have to expect desperation to hire, and set processes that can help avoid hiring people at very high salaries for their levels and disrupting harmony in your teams.
Some simple and low cost changes like interviewer training, role based recruitment pitch, quality check go a long way in improving candidate experience.
Prepare and adhere to budgets for product engineering
If not done till now, this is the best time to invest in fixing budgets and guidelines on spending. Also to start measuring monitoring cost of product engineering based on an output metric that the company is using to define its success. If its orders or transactions, then measure cost of product engineering staff per order will help you ask for budgets based on growth projections. These may not be linear, but not measuring isn’t a solution.
The same goes for infrastructure and tooling cost. Server cost of each order or transaction is a great way to measure if you are building decent quality software that can help you become profitable. For eg - if server cost grows linearly with the number of orders, you may have chosen the wrong architecture and 3rd party systems.
Invest in infra and data security
Before this stage, unless forced by regulatory reasons, startups rarely care deeply about data and infra security. The cost of adding PII data and infra security as one of the primary deliverables becomes very costly with time. Data security audits consistently tell the same story, that companies should have invested in better data security practices early on, because changing the stance later becomes so costly that decisionmakers abandon these plans. If not done already, get a security audit and hire people if needed to work in this area.
Security risks are one of those few where one incident can cause complete ruin for a company. And because security incidents don’t happen often, under the carpet is where all worries go, till it all blows up. And it doesn’t take a lot to have baked it in from early on, its like a little physical exercise, invest in it early and over years you will see less problems.
Invest in developer productivity and management tooling
As your product engineering team builds more complex systems, they will need all the help that dev and management tools can provide. Getting better machines, IDEs, observability and security tools, project and program management tools can be slowly brought in, based on budgets improves speed and predictability of delivery and reduces overall cost of development.
Early stage engineers and managers can build systems and manage teams because they are talented and driven, but beyond a size, very few can continue to excel without the right help they can get, from mentoring to tooling.
Invest in the right people policies
Its a good time to start budgeting in for people focused policies. Happy people build higher quality products consistently. It takes very little to ensure that people feel cared for, however, many companies make the mistake of leaving it too late or over-worrying about the costs. Ironically, funding decks mention things like CAC1 and customer LTV1, but very rarely these ideas are applied to employees. The long term value of a good engineer or product manager performing at their peak consistently for 2-3 years is immense and grows with time. It can be the difference between you and your competitor (not kidding). And the cost of acquiring a new engineer and building the level of trust and ownership in lieu of them is also immense and is growing higher as time goes. Its best to therefore look at these costs and then budget for policies that treat people well.
Another classic mistake big(ger) companies make is to treat employees as kids who are unruly, not to be trusted. While they may say that they think employee first, their policies point in a different direction. As your company culture is acquiring new people and values while you are still small, build a culture that treats people as adults who are intelligent, and have the company’s best interests in their thoughts. Mostly your teams are small enough that one or two rogue employees will not be able to hide their mischief for long. Instead of punishing the whole group proactively with rigid and painful benefits and boundaries, think of what can help nurture your people and make them feel secure at work, and build around that.
Start small on branding, and help your people build their personal brand
You need to hire good people, and fast. This is incredibly hard in today’s market, with a lot of different well funded startups and established businesses vying for the same talent. To differentiate themselves, normally companies take one of two paths - a big bang employer branding campaign or a slow and steady way to ensure candidates outside know you are doing good work. Very few can afford the both of them. A good start is to spend a steady amount over a long period of time, and invest in the personal brand of your people.
One common, low cost and effective way is to start a product engineering blog for the team, and help people write about their breakthroughs, help them present at conferences and invest in open sourcing parts of your systems that may benefit others.
Hire real HR folks, not a shield but a coach
There are two types of HR or people partners - one who are there to protect you from employees, and the other who are advocates for employees and will fight with you for employee benefits. As you may be hiring a new people partner, try to find people who belong to the second group. A poor hire here can become a costly blunder, invest in deep reference checks and do not just depend on intereviewing skills. Also, treat them as your coach, this I have learnt as a great test for a good people partner.
Setup a standard prioritisation and decision making process
Early stage companies are driven by a few people making a majority of decisions. But as team sizes grow, decision making doesn’t scale well. There are many reasons why this happens, one that is pertinent is communication of company priorities. To solve for this, you may have to invest in processes and practices that ensure that everyone in the company knows what your company’s quarterly and annual goals are. Early on this may seem like an overkill, deceptively so. Product managers and engineers make smaller but painfully hard to reverse decisions everyday, for eg - How to define the MVP 1 of a feature ? So overcommunicating values and goals doesn’t hurt anyone, and helps a lot quite often.
One easy and low cost way of communicating to people how you prioritise is to have a regular, frequent cadence with all you teams. On a fortnightly or monthly basis, allow people to meet you and present their results, plans and see how you make decisions, what do you prioritise. Goes a long way, especially for new employees who may not have worked with you on the same table.
Additional reading
- Simon Wardley’s excellent note on Pioneers, Settlers and Town Planners
Thanks for reading.
Acknowledgements - Thanks to Puneet Goyal for reading and adding the note on Org Culture, those are his wise words.
And Pete Hodgeson, Alex Belovs and Keith Morris for reading an early draft and giving valuable and actionable inputs.