Cognitive overload is a state of mind where team members are so overloaded with cognitive tasks that they cannot complete them effectively

When founders say scaling a company is hard, what hard problems are they referring to? Let me tell what it's not. It's not improving tech infrastructure. It's not increasing product development speed. It's not ramping up sales. It's not hiring talent quickly. All of those are exceptionally hard problems but what makes scale really hard is effectively organising and managing the cognitive load across the people in your team.

Having scaled Unibuddy from 2 to 120 team members and the engineering function from 0 to 50 engineers, I've found it is at least an order of magnitude more difficult to effectively organise 100 employees than it is to organise 20 employees.

When you're a small company of 20 employees, people naturally slot into their roles and take on different hats. Engineers will build, sales people will sell and everything else gets picked up as it comes up. More importantly, you'll find team members are able to wear multiple hats easily. For example, the Chief Technology Officer in a small startup might wear the following hats:

• Lead Engineer: Coding, reviewing code and leading the engineering efforts.
• Architect: designing the core system architecture
• Product Owner: refining Jira tickets, prioritising the roadmap and managing the sprint ceremonies
• IT Manager: handle company IT such as managing the systems to onboard new employees
• Second Line Customer Support: handle technical customer support queries
• Security Expert/CIO: Write and manage data protection and cybersecurity policies.

In larger companies, these are actually six different specialist roles. One person can do this in a small startup because many of those extra hats like IT Manager and Security Expert/CIO  require negligible time - and there's not enough work to justify hiring a full time IT manager or CIO.  

Notice that while and title is "CTO", they are actually performing six roles implicitly. These implicit hats are usually not documented and the responsibilities owned by the CTO will become more confusing and opaque as the company grows. In a small team, the implicit roles work because everyone informally knows each other and can find out who is doing what through social interactions and without documentation. Basically, the communication overhead of finding out whose doing what is negligible.

As a company grows, demands will increase dramatically for each hats. In the example above, the CTO can no longer wear all six hats.  This will result in various projects stalling, for example Sales can't complete deals now because customers demand better data protection policies or the company struggles to onboard new team members as the right IT tools aren't in place. The CTO may try to work longer hours to keep up with the different demands, but eventually the explosion of demands and constant switching between tasks will lead to cognitive overload. I'm going to repeat the definition of cognitive overload because it's so important to understand this:

Cognitive overload is a state of mind where team members are so overloaded with cognitive tasks that they cannot complete them effectively

In essence, cognitive overload is what will kill productivity and performance in a company so managing it is critical to scale effectively.

How do you prevent this? This is a simple 3-step process to manage cognitive load in a company:

1. Create a Responsibility Knowledge Base (RKB): Each team member must explicitly list all of their responsibilities i.e. things that they own and are accountable for. Remember, titles and responsibilities are not the same thing - for example in the early days at Unibuddy I recall our Chief Customer Officer was also wearing the Legal hat (because he also had a legal background). Importantly, when a new team member joins or leaves, the knowledge base should be updated accordingly.
2. Measure Cognitive Load: Every 3 months these responsibilities should be reviewed and each team member should answer two simple questions: "Do you feel you are able to manage your responsibilities effectively? (take special note of new responsibilities that may have come up recently)" and "Do you feel like you have the space and time to also think proactively about your core role?".
3. Iterate the Responsibility Knowledge Base: Where team members can no longer manage their responsibilities well-  identify what can be eliminated, automated or re-distributed to others. If none of those options are possible (i.e. everything is critical) - it means you need to hire more people to take on these hats.  There are only two reasons you should hire in my opinion: either a new business need (new hat) has come up and no existing team member has the cognitive capacity to take it on or an existing team member needs to handover a hat that they are overloaded with. Whether you choose to eliminate, automate, re-distribute or hire - remember to update your RKB!

And that's it!  This isn't complicated but like most things, the key is having excellent discipline to continue to maintain and update your RKB. Startups struggle to maintain documentation - but I'd go as far as saying this is the most important and perhaps only documentation that you should worry about maintaining perfectly.  If you can achieve this, I'm confident that you'll scale your team without the kind of major problems that often kill great companies.