Introduction
As the tech lead of a startup, a founder-CTO faces many tradeoffs allocating his time. The “business founders” want you to be shipping more features — the visible roadmap. But you need to balance that with many other responsibilities:
- Recruiting, managing and retaining the right team.
- Making tech choices, considering their short and long-term implications.
- Setting and automating processes, paying technical debt, stopping fires when they happen, etc.
Those topics are not visible in the roadmap, but if they are not taken care of in time, they can cause big trouble. They are part of the “hidden roadmap”.
At our SaaSCamp, Samuel Fuentes, CTO at Ontruck, led a discussion about managing those priorities. In this article, I’m going to summarize the areas of consensus and try to open the conversation to a larger audience:
Pre-Seed stage
At this stage, you’ve identified a problem worth solving and you have a high-level idea of what you want to build. But it’s important to realize that nothing has been validated. Therefore, you must assume that every line of code you write today might end up in the recycle bin tomorrow.
What matters the most at this stage is how fast you can iterate or even switch direction completely. The single goal is to validate if there’s a business opportunity. And most of the time, it will be easier and faster to do that manually, or hacking it, rather than by coding. Do things that don’t scale — that’s the stage I’m referring to here.
At this stage when you think about coding, your speed matters more than anything else. You should work with technologies that you’re fluent with and if there’s an API for that, use it! It’s probably not the time to think about scalability issues or profitability. This is the time for rapid prototyping. Most, if not all, the roadmap is for customer-facing features. But, ideally, only those that you validated manually.
It’s very likely that you are coding on your own. Or in the best scenario, you convinced another coder to join as a co-founder. Then, it’s acceptable to have not-so-great code that only you understand. Microservices can also wait, you want to avoid any extra complexity. It matters to be quick, because anyway, you will end refactoring that sooner than later.
You should also push yourselves to simplify everything to the smaller unit of value. That means: you will force yourselves to pick only one platform — API-first or iOS-first or Chrome-first … You won’t build a self-service onboarding. You won’t try to support more than one language, or try to automate internal or business processes, like billing or payments, so early.
Remember your goal: validating a business hypotheses. Not to build a scalable business (yet!).
Your customers will help you validate the opportunity. That’s also a CTO job. Do interviews with them to see what they say — or even better, work from their offices. Put in place an NPS survey and good user analytics early on. Many times, what they say and what they do is quite different.
Seed stage
Either you found a way to make some money or you keep providing a ton of value to your engaged users. You’ve found some validation of a business. Congratulations for getting here! Please, contact us 😇
Now, there are many new challenges ahead: it’s the time to build a business and retain your customers, run experiments to see how you can grow. But now, you also need to start balancing that with the pains of growing.
Most of your roadmap will still be customer-facing features. But for the first time, you will also be refactoring and bug-smashing your old code. Sometimes you will take the painful decision to rebuild everything from scratch. Note: that’s a painful decision, in our experience, that always takes twice the expected time to complete.
Just because you found value for your customers, it doesn’t mean that you will ship code faster. But I’m sure the ideas for new features will explode! If you can, split responsibilities between the product owner and tech lead now. Also, be cautious with your estimates. Add an extra buffer for refactorings and keep being focused. Try to keep doing things manually until they don’t scale anymore. At this stage, the bottleneck is still how much software you can ship. Don’t build if you can buy. It’s very costly to build something and drop it, it’s a lot cheaper to test hypotheses doing manual stuff.
You also need to start refactoring that spaghetti-code one-server monolith — here are some tested guidelines. Don’t start building fancy APIs everywhere. It’s still too early. But implement some testing for the critical flows. You can’t afford to lose your customer’s trust.
If your finances allow it, invest in monitoring and deployment tools. The extra visibility on your infrastructure will pay back quickly. This is also the time to start setting up engineering processes that scale with a larger organization. Think about deployment, peer reviewing, testing, security, etc.
Now, if you raised some funds or your customers pay you enough, you will also do your first hires. Don’t underestimate how hard this will be and how long it will take. Convincing great people to join your crazy-risky startup is hard. Try to go for the low-hanging fruits: people in your network, people who you’ve worked with in the past, people who like and trust you. If you have good investors, use them to convince your early employees. If you have good customers, use that as social proof. It’s going to be tough, but don’t lower the bar on those first hires.
Hiring new people means that you have more capacity to develop software. But at the same time, you need to collaborate and delegate, and that brings complexity. Step one is to remove yourself from the critical path, otherwise, you become a bottleneck. Every hire you make at this stage is a contributor and a leader. That requires trust. Try to find people who can be pretty autonomous at their work. This is not the best time to hire interns — unless they are superstars.
At this stage, you’re also preparing for growth. Before you realize, you might double or triple your team. Start investing time into decoding your culture. We are talking about esprit de corps, morale, the personality of the company. The special sauce that makes a good enterprise great. Practically, define your values, document them, make them visible and bring them to the interview process. Hire versatile employees that can identify with the status quo and your vision.
Moving into the next stage will be very much dependant on your growth. Product is one of the key drivers for growth and retention. But marketing, sales and customer support are also critical. This is a good time to remind everybody in the tech team that growth is a goal where everybody has to contribute. Please, don’t under-prioritize the request from one of these teams if that can bring growth.
Series-A Stage
That’s even more impressive! You’ve found a big pain in a big market and you’re growing fast. Unless it’s too late, we would love to meet you ;-)
Now, everything will be about blitz-scaling your business, but without breaking stuff that can get you in trouble.
Most of your problems in tech are going to be solved by hiring more people. Hiring gets easier if you have a good employer brand. But if you hire developers and don’t know how to manage them to be happy and productive, you will get into trouble. This is the time when two key recruits will help you a lot. If you didn’t hire them yet, go for amazing people as your VP Engineering and your first talent recruiter. If you can attract, hire and manage great engineers, most of your problems will be solved. If you can’t do that on your own, hire someone that can help you. If you do not act on this now, then your problems will keep increasing.
This will also be the time when your role starts to shift from being an individual contributor to being a leader. Now, a big chunk of your time goes into people and organizational issues. Hiring new team members and leaders, leading and coaching them is key for the growth of the business. Don’t underestimate the difficulty in that shift. Look for a coach if you struggle.
At the technology level, it is the time to think about scaling horizontally and vertically. Moving main features into APIs is reasonable. One simple rule of thumb is to build an API when you need to split your teams in different rooms. It’s also a good time to “containerize” much of your infrastructure. Also to invest in automation: to do staged releases and automatic rollbacks, etc. If it gives you an edge, now you can also afford to build stuff that you bought in the past. You can also do one or two bets for big swings.
Your customers want reliability from you. Your infrastructure should be perfectly monitored and you should be able to trace back any incident. At this stage, you might find that some of the tools in the market don’t cover all your needs. I would suggest avoiding building your own tools.
One of those areas for internal tooling will come from your business people. They will keep asking for tools to make your sales, marketing and customer support teams more efficient. Requests to integrate tools like ERPs, CRMs, BI, etc. will be common. You might also be expanding and need localization. Don’t under-serve those teams, keep helping them — it’s your responsibility. If they have good processes and tools, your business will be more successful. Now might be a good time for some of your devs to focus on tools for those teams — junior hires might be excited about that!
Finally, the more mature the company, the higher the chances that you will be a target for the bad guys. At this stage, you have a lot to lose if you don’t deal well with those situations. Again, invest in security monitoring. Have good security checklists. Build your incident response plans. Keep good backup plans… All the effort you’ve put into getting into this stage can vanish if something really bad happens.
Where to find the time?
The short-term visible roadmap is what your customers pay you for, that’s why it’s so urgent. But the hidden roadmap builds the foundations for the business, that’s why it’s so important.
It’s always hard to balance between what’s important and what’s urgent. This is not a different case. But there are three guiding principles for a better outcome:
- Self-awareness. You can focus on different features of the hidden roadmap at different stages. You can even skip some of them for a while. Just make sure that you know when you are generating debt and when you plan to repay that.
- Communication and accountability. Discuss the potential consequences of your decisions among the leaders of the startup. It will help you reshuffle your priorities. But more importantly, it will bring transparency to different expectations. Make sure you keep your delivery pace to those expectations.
- Trust. As the tech leader, you “own” engineering and software development speed. If your cofounders don’t trust you, they will always find that you’re too slow. If they trust you, they will understand that you do what’s best for the business. It also helps if the product owner has a deeper understanding of the technical challenges involved.
If all the previous fails, add a buffer into every feature to hide “the hidden roadmap” into the visible one 😉
BONUS: Here you have the Trello board. Please share your feedback 😅
Did you like the post?
Please, let me know by clicking on the heart below ♡ or contact me at @DecodingVC.