Reviewing your company’s organisational design

James Routledge
2 min readOct 12, 2020


Many people are currently reviewing how they design the structure of their companies to embrace a new normal. But even in historically remote companies, the same basic structures have persisted. Before making large changes around how your teams work it’s worth just remembering that only a few core systems have been proven, regardless of the working environment.

Organisational design (engineering inclusive) for startups is one that has no definitive answer, but companies usually share in one of three main architectures and all of them can scale:

  1. Customer squads — you arrange the organization around serving each respective customer segment (e.g. Enterprise, SME, Micro) and each segment has their own full-function set of resources: Marketing, Tech, Design, Customer service…
  2. Functional lines — the business shares it’s customers collectively and divides itself into departments: Marketing, Tech, Sales…
  3. Business units — Everything runs from a P&L and resources align who can afford them, each business unit as a managing director and whoever has the biggest budget gets most of the people

The last one is a little hard to manage as its sometimes at odds with the customers but all three are proven to be as functional as the other. Startups normally flip between 1&2 until someone spends too much on a consultancy that one time and the mgmt refuse to change it again

When it comes to engineering org structure and process design it’s really a question of the types of engineers you have in your co and the amount of vulnerability people can express to make a collective change, at pace:

  1. In SF engineers HATE specs and expect to produce at least 50% of the requirements/product, they get heavily involved and the entire team all sweat it out together end to end. Coding is <50% of an engineers time
  2. In most of the EU, engineers prefer clear strict definitions of their work, a cultural hangover from our being great builders of more traditional institutions. In this case, the goal is instead to have great comms open between product and engineering to make sure that those unanswered questions which surface during the work don’t get forgotten, nor the work misunderstood

There is no right or wrong here and most places blur this so it’s more a people/culture point, one thing I’ve found in EVERY company (friend/client/my own) is that engineers are singly the most underutilized knowledge-centre; in this, there are specific things you can do to include their collective experience in building the product