We recently formalized our engineering principles. Principles are important to guide and make people find out the best decisions, especially when faced to different situations. However, it is a waste of time for routines and common sense. That is why we also need practices to accelerate the process of making decisions. But not having principles and just practices are also bad since your team will just follow rules and don’t really think.
Practices could change over time, principles usually don’t. Have both when scaling.
The pain will always exist. No matter the size of your company. No matter how experienced you became. No matter how the context changed for the better. It does not matter at all.
It is the same for high-performance athletes: it will never become easy or painless, they actually train and change to support it. After thinking and acting like that, you truly discover that you can get more pain than was used to. And then more, and more. Finally, you discover that your pain tolerance can be much higher. It then becomes an advantage for yourself and the company.
The real question for being successful: how much pain can you get? Are you mentally prepared?
There are a lot of thoughts and a battle of ego when passing the sticks.
Don’t be afraid of it. Your legacy will be there. If you are a founder, people will know how you started the company. If you were an early employee, people will know how important you were to move the business.
Whatever your merit was, it will always be there.
At some point of the journey, you should pass the sticks. Building a company is a marathon. You can’t run a couple of triathlons in a sequence. It is the same that you won’t be able to teach your kid everything she needs to know for the whole life, she will need to learn from other people and experiences.
New oxygen is great for evolving. A machine needs feedback to become better.
If you are a manager and still dictates what to do next in a specific discipline, you haven’t solved the real problem. You shouldn’t be leading it. Your main skill should be hiring someone that is better than you to solve the problem. Dictating won’t scale for long.
You will automatically notice that you really fixed the problem when you start learning from the person you hired and then start worrying less about it.
There are two categories of great individual contributors: the ones with great technical skills and also maturity, and the others without maturity.
The first rule is that you should never bring people without a great technical background or adequate for their level, so let’s focus on people with that – right side of the chart.
The best people I worked in my life were very mature. I learned a lot from them. They know how to solve complex problems, but also how to stay focused, motivated and positive, communicate well, and empower people and teams.
A lot of great people I met without enough maturity became mature over the time after different experiences. Self-knowledge and openness are crucial for that. They also became the first group.
But a couple of them stayed the same and took ages to take a small step. They will never become rock stars.
Depending on your bar, you won’t want them too.
Every day is a different day in a startup. There are good days and positive signals that make everybody get happy however there are bad days when you have to deal with loses and incidents for example. Sometimes this also changes during the period, there is no rule.
No matter what happens, you have to control your emotions and learn how to deal with it. You have to operate in a regular bandwidth. Nothing is too wrong that you are dead, neither too good that the game is won.
Everything breaks during scale phase. Your software will break. Also your processes, individuals, leaders, data, office, and structure. Even your wi-fi will break.
Every time you decide for something think how would feel to add 10x in it. This could help you in extending the breaking lifetime of your decisions.
Understand that everything breaks and choose what won’t break in each cycle.
We are always in a rush. And we are always looking ways to be more productive, and also to do productive meetings. For instance, send me the items earlier, a 30min slot at the max, try to solve it async, rigid agenda, etc. I do that a lot.
However, sometimes to achieve the best result you need to let people talk. When you are doing big changes, interconnecting teams and going deep into pain points, you need to let people talk. Part of the process to achieve the best result is guaranteeing everything was said. People need to go through this.
So the next time you have a big change and need to listen to your team, don’t try to create the most productive meeting, focus on creating the most effective one.
I usually receive questions regarding the role of CTO and VP of Engineering. There is a couple of great blog posts on this topic such as Suster’s and Dickert’s one.
Forget about the roles. Both functions are important. In the early days, you will have to define the technical direction – and code a lot! After the MVP and a couple of new employees, you will have to start scaling: hire people, coach them and fix processes. The first job is usually attributed to the CTO and the second to the VP of Engineering.
Anytime, you will need to keep scaling and driving the technical direction. It could be the same person doing the same functions at some point, or maybe you with a manager, or maybe you with a senior developer. It usually ends with having a CTO and a VP of Engineering, at least someone leading each function.
If you are the tech co-founder, don’t be confused about your role or what you want to become. Don’t let your ego drive your decisions and don’t be in the wrong job. Your interests could also change over time. Understand both functions, review your role and scale the company.