Startup Growing Pains — Lessons & Questions — Part 2— Organisational Structure

Learn from our mistakes so you don’t repeat them.

The Red Planet
6 min readFeb 25, 2022

This is not a ‘how to’ guide. This post was edited from the notes I wrote for myself, to record the lessons learned from my own experience, and to remind myself to ask the right questions when I’m at the scaling phase next time.

No two startups are the same.

This post continues the Startup Growing Pains — Lessons & Questions series. Here’s the link to Part 1 — Culture, in case you are interested.

Part 2 — Organisational Structure

In the early days of a startup, each person covers one or more functions. When the company scales, early employees often become team leaders, and small teams are built around their capabilities. Many startups’ organisational structure were shaped through such natural evolution, until it’s no longer viable and the founders have to rethink what structure best suits the business. I personally don’t think there is a universally “best” startup organisational structure or you can get it right the first time. I would like to share my lessons learned to help you get it right sooner for your own startup.

The Story

When we scaled to 40+ employees, we had 7 CXOs and 10 Head of’s. Most early employees were promoted and got senior titles. Experienced new hires wanted senior titles to maintain career track or compensate for the greater risk (and sometimes lower salaries) they took. Other new joiners were promised ‘plenty of opportunities to progress’ and many demanded promotions after a year. While budget was tight, “career progression” (aka bigger job titles) seemed to be the only thing we could offer.

When there were too many senior roles, we started to have ‘Manager’ managing another ‘Manager’, ‘Head of’ managing another ‘Head of’, ‘CXO’ managing another ‘CXO’. Then new levels had to be invented to provide space for progression. i.e. ‘Assistant’ and ‘Coordinator’ titles were created between ‘Administrator’ and ‘Manager’ , ‘Senior Manager’ was created to avoid having another ‘Head of’. While it was intended to be a pyramid-shaped organisation, the org chart became a fat diamond shape.

Needless to say, it didn’t work. Everything slowed down, too many ‘commanders’ for every decision. Organisational restructure started to take place, then almost every 6 months. Some teams were regularly reformed. Teams led by early employees with strong personalities got passed around different CXO departments. Some teams were created, rapidly scaled, and then shrank/dismantled within months. Some teams were moved solely to balance the power of CXOs.

During the period of constant organisational restructure, many team leaders developed a habit of quickly claiming credits for every success however big and small and fighting for more management attention, in order to have a better chance to protect themselves and their teams in the next wave. New boundaries were created between teams as a defensive measure, but resulted in more organisational changes made solely to break the boundaries and enforce collaboration.

The changes eventually slowed down. When I looked at the last version of the org chart, the observations were surprising:

  • The last version was very similar to one of the earliest versions in terms of team grouping and allocation between CXO departments. Maybe we got it right early on, maybe we just went in circles and made the same mistakes we made before.
  • The structure and resource allocation closely reflected the shape of our products as perceived by our customers, which was not quite the same as what we claimed to offer.
  • All early employees that were promoted to ‘Head of’ level early on as a reward or retention incentive left the business. All early employees that remained and held management positions were those who successfully built a team before getting ‘Head of’ titles.

Lessons Learned

Organisational structure is the foundation of the organisation. The way the organisation is structured and resourced is reflected in its prioritisation of activities, staff behaviours, and eventually its products would be shaped like the organisation.

Pre-mature promotions are often not in the best interest of the individual and the company. Job titles are not free currencies. While they seemed cost-free, especially when we have nothing else to offer, they have lasting impact on the structure of the organisation and other employees’ expectations.

While scaling rapidly, scaling a team disproportionate to the size, stage and priorities of the business is likely to lead to rapid failure. Hiring a number of expensive ‘done it before’ experts to scale a team within weeks is often not viewed very positively by existing teams, causing integration challenges. Such significant investments often come with unreasonably high expectations, quickly leading to disappointments and disengagement from the plan.

Although it’s not unusual for startups to change organisational structure based on evolving business needs, organisational structure is not a product to test — learn — pivot in regular short cycles. When the staff constantly feel their self-interest is at risk, self-interest preservation becomes their primary motivation, changing their mindset, behaviours and the company’s culture.

I wish we did more to identify and learn from our own mistakes. The only way to avoid making the same mistakes again is to first have a record of all the organisational changes, why we changed each element, what worked/what didn’t, what knock-on effects happened unexpectedly. I personally would share this record with my management team next time, but if you don’t feel comfortable doing so, at least keep it for yourself, review and update regularly.

Questions:

  • Look at your product, both the core and all the operational/supporting elements, what’s the shape of it today and what’s the target shape you are building for tomorrow? How does it compare to your current/target organisational structure?
  • When you promote an early employee, what percentage of the decision is based on your confidence in their ability to take on additional responsibilities? Some people grow fast with the company and are ready to take the next steps. Some people are technical experts who would rather not manage people but they see management as the only path to success. Some people are your loyalists and their peers have been promoted, so you feel obliged to reward them. What’s the primary reason for your decision?
  • When you hire an experienced candidate and they demand a bigger job title than the original role, are you giving the title only as an incentive? Are you expecting them to take on more responsibilities? There’s nothing wrong changing the role scope for the right candidate. You need to consider and address the knock-on effects first.
  • Are you closely monitoring the scaling progress across the business, or only reviewing each new headcount request as a standalone case? Are your management team aligned on what’s considered proportionate to the size and stage of the business?
  • If you are doing an organisational restructure within months from the last one, how do you explain this to your staff? Are you acknowledging any issues/mistakes or just giving them a seemingly all positive statement? If you hide from your mistakes, they will do the same.

Coming next: (links to be added once published)

  • Part 3 — Hiring
  • Part 4 — Firing

About me

I founded 3 businesses🚀 , helped creating 17 companies from university labs🔬, and spent 8 years building and scaling start-up operations📈. I write this blog to share my first-hand experience, lessons and thoughts with fellow entrepreneurs. I hope you don’t mind that, in order to share fully and freely, I have to write anonymously🥷 to avoid having some of the stories and quotes traced back to the companies/individuals involved.

About this post

This is one in a series of blog posts covering the topic of Startup Growing Pains from my first-hand experience. If you find it interesting or helpful, please give me a few 👏🏼 , follow me, and share with anyone that may be interested. Thank you!

--

--