One of the easiest traps startup CTOs fall into when they start scaling their team, usually in the expert stage (5-15 engineers in the team), is to transform themselves into a DNS server, answering queries from everyone in the team all day long. When you have many newcomers in the team who donât know about the architecture, the product and all the shortcuts you took to build it (aka technical debt), itâs normal to answer their questions. But answering too many questions for too long induces two cultural behaviours that will damage the team in the long term.
Access to knowledge
First, answering questions orally (or on Slack) creates a culture where knowledge is unevenly distributed, unclear and ephemeral. Letâs be honest, when a team member asks you a question, itâs so much easier and quicker to answer orally, perhaps using a piece of paper to draw on the side. But when doing so, the information shared is stored only in the team memberâs head, and itâs not even the exact information, but their interpretation. So when another team member has the same question, you will either have to do it all over again or, worse, they will have to physically ask who in the team has the answer, only to get another version of the initial information.
As the team grows, this situation will only happen exponentially, creating huge gaps in information and delays in projects. Instead of âhelpingâ team members by answering questions orally, savvy CTOs create documentation along the way, like GitLabâs handbook first culture. When a GitLab team member has a question about a process or a product, they must check the handbook first. If they donât find their answer, they submit their question in writing and the person who has the answer then updates the handbook in writing. Without going to the extreme of having a 2 000+ pages handbook like GitLab, you can still force team members to submit their questions in writing and write the answer back in a shared document. It takes more time, but you make sure that information is evenly distributed, clear and long-lasting.
Promoting autonomy
The second cultural behaviour induced by answering team membersâ questions as fast as possible is that youâre educating them to rely on you, the all-powerful CTO, to help them in any way possible. A bug; letâs ask the CTO. A technical decision; letâs ask the CTO. A question about a feature; letâs ask the CTO. While answering these questions might seem like helping in the short run, it completely disempowers team members to look for answers by themselves and make their own decisions. Moreover, this situation becomes completely unsustainable when the team goes above ten engineers, with a CTO answering questions all day long and coding during nights and weekends. Instead, savvy CTO should ensure that team members have the proper knowledge, skills and behaviours to solve problems autonomously.
The first reason team members would ask the CTO questions is if they lack knowledge about products or processes. If you have been building documentation along the way as described above, team members should have access to the proper knowledge for 80% of their questions. The remaining 20% being opportunities to update the documentation đ The second reason team members might ask questions to the CTO is a lack of skills, like how to interact with the database, how to push into production or anything theyâre not used to doing. The proper answer to lack of skills is training, and you should always allocate a couple of hours of group training per week to ensure everyone on the team has the proper skills to get their projects done.
Finally, the last reason team members would be asking questions to the CTO, providing they have access to knowledge and the right skills, is because theyâre afraid to make mistakes or theyâre used to having someone else solve their problems. In this case, this is a behaviour problem that you can solve through coaching. A team member is asking you to help them with a technical problem? Try rubber duck debugging to help them find the answer. Another team member doesnât act when stuck? Use weekly one-on-one(s) to empower them to act and talk to other people before going back to the CTO.
Itâs important to note that all the solutions above always take more time than actually answering questions orally and might look like youâre slowing the company down. But in the long run, having proper documentation and ensuring that team members have the right skills and behaviours will make the organisation much faster, independently of its size. This way, youâre not the DNS server anymore but you have built a system where each team member is empowered to find their own answers and act autonomously.
Are you ready to scale your engineering team and grow as a leader?
Membership includes weekly live learning sessions, online resources, exclusive events and a community of 100+ engineering leaders