As the Founder/CEO, you might have pondered over the slowing pace at which you are able to build and deliver quality features. You would have gotten feedback that you would need more Product Managers and Engineers to accomplish the same. You feel you may need more engineers — but most probably you do not. Sometimes the problem lies in the way the org is structured and the process through which the org picks problems to solve.

Specifically, a Technology and Product Org that is prematurely divided up in teams with a restricted domain tend to be become less impactful with time.

Why do we divide orgs ?

At the beginning, the founding team is responsible for building, distributing and operating their product. As the business scales up, the org structure evolves and require to:

• Build specialisations in Building, Distribution and Operations
• Build depth in various problem areas and iterate on solutions
• Drive multiple initiatives in parallel

The most common org structure is where the org is divided based on specialisations such as Technology, Product, Sales and marketing, and Operations (back office, customer support, facility operations etc). The Technology and Product org (referred to as Technology org) together plays a significant role in Build phase and an important role in figuring out the right Distribution model.

Given the large surface area of impact of Technology Org, it is important to ensure they remain effective as the business scales and org grows.

Technology orgs adopt multi-dimensional structure to manage impact, productivity and quality of the product. These dimensions are:

• Specialisations — the nature of work you are required to do — ex: Product, Engineering, Quality, Infra Operations, Security, etc

• Impact Area — the area in which impact is required to be created — ex: growth, retention, app experience etc

• Maturity Levels — the level of impact the person can create and the level of ownership and accountability this person can take

Theoretically, these dimensions equips an organisation with ability to solve a problem with the right skill sets. It also helps identify people that needs to grow and areas where to build depth.

In reality, they devolve — Levels turn into hierarchies, Impact Areas become rigid and silo-ed, and People find problems to justify their role.

When this happens, the org structure becomes counter productive and slows down the pace of execution within the org. In such an org, ability to communicate and rally people behind a common goal becomes challenging.

Why do org structures devolve ?

With time, the context of the team gets narrower as:

• The teams are required to work on a strictly defined charter
• Product Managers gets a discretion on what they share via PRDs
• The “leadership” decides what information to share

As the context becomes narrower for a team, they become successful only by finding and solving problems within the narrow domain set for them. The Managers, try to solve tangible problems rather than take on audacious goals. This may hurt the business eventually — as small irritations are solved on priority rather than looking at the big picture. Eventually, the team becomes comfortable with prioritising and solving incremental problems which misaligns with top priorities and will reduce the overall impact created by orgs.

What’s the solution ?

Org Structure

The org structure should be fluid rather than rigid.

Do not overspecialise the roles. Try and minimise specialisations within the org. More the specialisation, more the complexity of managing division of labour and communication overhead.

The teams should be formed around a large domain rather than a small/restricted problem areas (ex in e-commerce, large domains are Supply Chain, Accounting, Retail etc). The teams are responsible for building high quality systems and ensuring that the customer’s get a well rounded, surprise-free experience. The teams can own more than one domain — as it will improve the context within the team, reduce the communication overhead and build sufficient redundancy within the team.

PMs should be solving key problems prioritised centrally that help move the company forward. PMs will need to ensure that the company goals are aligned with their customers’ needs. Engineers (specifically product engineers) should own the bottoms up problem solving within the domain they are aligned with. They take guidance from PMs where necessary to ensure right customer experience.

Execution

Any work to be done should be prioritised first — centrally in a top-down manner. Carefully select key company wide initiatives that needs to be prioritised and executed. Rule of thumb is — such initiatives can be monitored by the CEO. Rest of the available execution bandwidth should go into improving products and systems through bottom’s up initiatives.

All projects should necessarily have a Lead that is responsible for ensuring right solution for the problem is found, and planning the execution for it’s timely delivery. The project teams can consist of different types of people — engineers, PMs, operations etc. All of them are required to understand the context behind the problem being solved. All of them are required to participate in the solutioning.

All the people in the company need to understand the problems that were prioritised to be solved and why. It’s necessary that people have as much context as possible to understand that they are all rowing in the same direction. They are all part of the solution. No one, is prioritising anything else.

---

In conclusion, avoiding over-specialised teams and having centralised prioritisation will help drive audacious outcomes in a startup. This approach will not only accelerate the pace of execution but also ensure that the org continues to deliver high-quality features that drive the business forward.

We @ Propelr.Tech understand how the org structure of technology orgs accelerates the growth of a startup. Do reach out to us (at [email protected]) for a quick discussion to check if your org structure is slowing you down ?