The CTO as DNS server

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.